Moderate Activity


  Analyzed 13 days ago based on code collected 17 days ago.
Posted 4 months ago
We have created a LaunchPad team and mailing-list for Linux Padawan.  This blog also has it’s own feed here.
Posted 4 months ago
As linuxpadawan gets fully grounded we have some exciting things coming soon. Firstly there will be the cloud server going live thus allowing masters to run the different linux flavours in an environment where padawans can ‘blow them up’ in complete ... [More] safety. Blowing up servers is one of the best ways to learn! As these cloud instances have a short life expectancy, I have allocated 500 GB of hard drive space for padawans to keep any files / scripts that they need backing up. [Less]
Posted 4 months ago
This is a guest post by Lisa Smith of Blueberry Labs and introduces an infographic with some stats of the Magento ecommerce software marketshare along with 16 reasons why to choose it.


Facilitating unmatched web commerce success ... [More] for enterprising businessmen, Magento has now captured a little more than a quarter of the ecommerce CMS market space. That’s mostly owing to the inimitable range of core and extendible features packed into the platform. Import and export your site data quicky, build upon the inherent SEO capabilities to ensure search engine visibility of your web store, integrate payment gateways and trust the quick checkout – all of which combine to deliver a convenient, secure, and comfortable online shopping experience to your users. Detailed customer account management capabilities, advanced search options, customer support centric feature, and customized extensions to add any desired capability to the web store – all these features make Magento the most comprehensive and advanced ecommerce software in the modern times.

The post Why choose Magento ecommerce software appeared first on deshack. [Less]
Posted 4 months ago
When charming, I think it's important to remember that there are a few things worth
keeping in mind. If you approach charming with the following mind set, it will enable
you for success.

Keeping hook ... [More] code simple

With these three listed above, lets dissect down into the first thing listed: Encapsulation

Lets Find a good example
The first task for my team this new year has been to look into Kubernetes - with a few existing
prototype charms from Hazmat we were set along our path of discovery.
A few man hours have already been spent writing the services, and getting things together - but
this just didn't bode well with me. To take a prototype, and run headfirst down the long hallway
of container orchestration. I'm goign to 'pick' on one charm in particular - the
Flannel charm I exhibited in a
prior post

It really is a brilliant piece of work. The primary directive of the Flannel charm was to Install
a container environment, either LXC or Docker - and add a Software Defined Network bridge that
enabled cross-host communication with the containers. And it did this rather well - but the one
thing that irks me is it was a mashup of concerns.

No Clearly Defined Boundaries

Install a container provider
Install a networking bridge for either provider
Communicate with ETCD to enable SDN for either provider
Handle updates for aforementioned container provider

These concerns being mashed into one charm, while they might be feesable for proto-ware, it
doesn't sit well with me for composability.

Composability Illustrates Good Encapsulation
When green-field developing charms, the first thing I like to do after prototyping is to aggregate
facts and run down a checklist of concerns for the charm outline as so:

Whats the intended / primary use case
How does this relate to other charms
How will that data-handoff look
Which service does this data-interchange effect
Does it make things easier to maintain if I do it another way?

In some cases, it may make sense to co-locate services in the same charm. For example, if I were
to deplay a LAMP stack - it makes complete sense to co-locate the database, webhead, and PHP
daemon on the same machine and manage those services. (I can argue the point, but its a very
familiar example)

What I would rather do, is separate those concerns into a microservice model, and relate/manage
them interchangeably. I may not always want a MySQL server with my App, and this becomes simple
to do with the JUJU model by changing the MySQL component out with say PostGRES and using the
proper relationship handlers. This illustrates good encapsulation. My concerns are independent
and it wont change anything but a database adapter on the webhead, which will be managed - by the
webheads relationships.

Approaching Refactoring the Flannel Charm
Lets take a look at how we can split this apart. A Venn Diagram should outline the overlap quite
well, as we can clearly see when they intersect. A key thing to remember, is that these services
will continue to live on the same host, however they are completely separate services, with their
own concerns about what to do to the state of the host.

The above may not express the full extent of the charms concerns, but are good for the example
case given.

Should there ever come a time where we want to move away from flannel to another SDN solution - we can now change out the service on each host, allowing for a live migration away from Flannel to <Service>. As well as taken a tightly coupled service definition, and changed it into a relation with simple datapass between then.

We have done a few things as a byproduct:

Defined clear boundaries for each service
Made the services related, but not dependent
Made testing simpler per service
Allowed for interchangeable components

Now lets look at the actual Implementation of this - which is where my real discovery began.

Service Topology

We see that we have 3 components.

Flannel-Docker (scope: container)

The interesting bit here is the relationship cycle/sequence that occurs during setup, lets take a look at how we do this:

juju deploy cs:~trusty/hazmat/etcd --to 0
juju deploy local:trusty/docker
juju deploy local:trusty/flannel-docker
juju add-relation flannel-docker:docker-host docker
juju add-relation flannel-docker:network docker:network
juju add-relation flannel-docker etcd

Pitfall You may be asking why two relationships with the docker charm. Lets explore why.

The docker-host relation is a juju-info interface relationship, which is special for making
the subordinate connect and deploy within scope: container.

Fig 1.1 - metadata.yaml

interface: overlay-network
scope: container
interface: etcd
interface: juju-info
scope: container
interface: flannel-mesh</code></pre>

Pass Data between units, outside of the relationship context
Another advanced topic in charming here, is you have to pass data outside of the relationship
context. Normally we exchange all of this data because we have it up-front. But what if someone
were to relate flannel-docker:network after they related flannel-docker to etcd? This is where the
dependency chain gets interesting.

Fig 1.2 Snippet from ansible playbook

<pre><code># Send data so we can take down docker bridge and bring it back up
# under flannel directed networking config

- name: Find Docker-Host network relation-id
shell: relation-ids network
register: docker_host_rel_id

# Read data from flannel config
- name: Read Flannel Subnet
shell: cat /run/flannel/subnet.env | grep FLANNEL_SUBNET | cut -f2 -d"="
register: flannel_subnet

- name: Read Flannel MTU
shell: cat /run/flannel/subnet.env | grep FLANNEL_MTU | cut -f2 -d"="
register: flannel_mtu

- set_fact:
host_rel_id: "{{ docker_host_rel_id.stdout }}"
flannel_mtu: "{{ flannel_mtu.stdout }}"
flannel_subnet: "{{ flannel_subnet.stdout }}"

- name: Send Data to Docker Host for bridge configuration
shell: relation-set -r {{ host_rel_id }} flannel-subnet={{ flannel_subnet }} flannel-mtu={{ flannel_mtu }}</code></pre>

We have data that we didn't have until the database relationship joined - this is what triggers
flannel to restart it self and populates /etc/flannel/subnet.ev with the proper information that
came back from etcd. We're clearly not in the network-relation-changed event, how do we send this
information back over the wire without breaking encapsulation?

THe magic is line 24 in Fig 1.2 - we aggregate facts, and pass them over the context of the network
relationship using relation-set -r #id. This took a bit more dancing of the juju jig to get the

Scan the relationship ids
Scope our request to the relationship id
transmit the data over the context of the relationship-id

Learning and Discovery - Avoid Pitfalls

Pitfall: Juju-Info relations are reserved for Juju and should never be assumed that you
can hand off data over this relationship. I ran into this and cycled for a few hours trying to
discover why info-pass wasn't happening during development. This necessitated the new relationship.

note If you want to keep the relationship limited to its co-located service, simply add
scope: container to the relationship.

With all of these in mind - I'm confident we are building a good example for the community to follow
with regards to service encapsulation, proxying information, and building a better, more composeable
ecosystem for everyone to enjoy.

Happy Charming! [Less]
Posted 4 months ago
I know many of my readers here are Ubuntu fans and I wanted to let you know of something neat.

For just over a year now I have been doing a podcast with Stuart Langridge, Bryan Lunduke, and Jeremy Garcia. It is a fun, loose, but informative ... [More] show about Open Source and technology. It is called Bad Voltage.

Anyway, in the show that was released today, we did an interview with Michael Hall, a community manager over at Canonical (and who used to work for me when I was there).

It is a fun and interesting interview about Ubuntu and phones, release dates, and even sets a challenge to convince Lunduke about the value of scopes on the Bad Voltage Forum.

Go and listen to or download the show here and be sure to share your thoughts on the show in the community discussion.

The show also discusses the Soylent super-food, has predictions for 2015 (one of which involves Canonical), and more!

Finally, Bad Voltage will be doing our first live performance at SCALE in Los Angeles on Fri 20th Feb 2015. We hope to see you there! [Less]
Posted 4 months ago
Mozilla will be at Southern California Linux Expo (Scale13x) again this year with a booth so be sure to stop by if you live in the area or will be attending. This year the organizers have offered Mozillians a special promo code to get 50% off their registration simply use the code “MOZ” when registering!
Posted 4 months ago
I usually do not write about politics, but this evening I am going to make an exception.

In case you haven't heard the news, this morning gunmen entered the building of Charlie Hebdo, a French satiric newspaper, and opened fire on ... [More] journalists, killing 12 people.

I am deeply affected by all those tragic deaths, but one of them hurt me even more: Jean Cabut, known as Cabu. Cabu was a long time anarchist who drew caricatures for many satiric newspapers, but he was also part of a TV show for kids: Récré A2. In this TV show Cabu drew live to illustrate whatever was happening. I was around 6 or 7 by then and I remember being amazed by the precision of his strokes, especially since he was drawing directly with an ink pen, without any prior sketching.

I can't find a good video of Cabu drawing, but the author of this homage does a good rendition of how he drew:

This evening it feels like a piece of my childhood (and of others French people around my age) has been murdered. May Cabu, his colleagues and the two policemen who died today rest in peace. [Less]
Posted 4 months ago
If you do not know what Je Suis Charlie means you should read this!
Posted 4 months ago
Posted 4 months ago
Hello everybody,

I heard no objections when I asked, so the next Ubuntu Online Summit is going to happen:

5-7 May 2015

Thanks a lot everyone.

Originally posted to the Community-announce mailing list on Tue Jan 6 15:57:22 UTC 2015 by Daniel Holbach