Juju feedback from the Launchpad Yellow Squad

Clint Byrum clint at ubuntu.com
Thu Feb 16 07:03:28 UTC 2012


Excerpts from Kapil Thangavelu's message of Wed Feb 15 19:02:54 -0800 2012:
> Excerpts from Clint Byrum's message of Wed Feb 15 20:27:53 -0500 2012:
> > Excerpts from Gary Poster's message of Wed Feb 15 13:23:46 -0800 2012:
> > > On 02/15/12 15:18, Kapil Thangavelu wrote:
> > > >
> > > > Greeting Graham.
> > > >
> > > > Excerpts from Graham Binns's message of Wed Feb 15 13:30:51 -0500 2012:
> > > >> Hello Juju people (Are we supposed to call you priests? Shamans?
> > > >> Anyway...)
> > > >>
> > > >> We on the Launchpad Yellow Squad have been working on producing a couple
> > > >> of Charms for buildbot (one for the buildmaster, one for buildslaves)
> > > >> over the last few weeks. Now that we're ready to submit our Charms to
> > > >> you for review, we also wanted to put together some feedback about our
> > > >> experience with Juju and with developing Charms. Hopefully it will be of
> > > >> some use to you.
> > > >>
> > > >
> > > > Awesome, thanks for the feedback, its great to hear about user experiences and
> > > > how we can improve juju.
> > > >
> > > >
> > > >> Feedback
> > > >> ~~~~~~~~
> > > >>
> > > >>   * The current Juju Docs are excellent, but they still have significant
> > > >>     holes in them. We've spent quite a while trying to get Juju to fit
> > > >>     into our collective brain, is a hard but valuable goal. A couple of
> > > >>     items missing from the documentation that would be worth including:
> > > >>     * Your local terminal needs to be in UTF8 (not by default on
> > > >>       my Precise machine for some reason! ANSIX3.4-1968) or else byobu
> > > >>       will render the bottom line problematically.
> > > >>     * There are several cases in which the best way to learn something
> > > >>       is to look at other Charms (e.g. MySQL does a nice job of handling
> > > >>       multiple slave services deployed from the same charm but with
> > > >>       different configurations). There should be an FAQ or similar
> > > >>       pointing Charm developers at good practice example Charms like
> > > >>       this.
> > > >>   * We spent quite a while doing a lot of work in the config-changed
> > > >>     hooks before realising that this wasn't the most efficient way to do
> > > >>     things and was prone to breakages (because Juju doesn't keep track of
> > > >>     what's changed for you; we implemented our own config caching as a
> > > >>     result). Charm authors should be encouraged to use the install hook
> > > >>     primarily, with "deploy --config" to set config options.
> > > >
> > > > What sort of juju interface would be helpful for changes and why? Afaics its a
> > > > fairly trivial thing for a charm todo, but if its a common enough use case, then
> > > > juju should accomodate it. Could you clarify the usage that needed this?
> > > >
> > > > Ideally, charms should be able to deploy with reasonable defaults even sans
> > > > config at deploy time. That doesn't apply to all charms though, but its a good
> > > > default.
> > > 
> > > Our point is not that juju does not support something.  It does 
> > > everything we need in this regard (well...see below for a suggestion, 
> > > but it's very much a nice-to-have).
> > > 
> > > Our point is about best practices for charm writing, or at least for 
> > > first-cut charm writing.
> > > 
> > > It can be easier and saner--and, importantly, easier to write automated 
> > > tests--if you declare that your charm primarily supports setting things 
> > > up via initial configs.  Only certain changes are available 
> > > subsequently.  Maybe none are.
> > > 
> > > This limits the various states you have to handle.  It can let you 
> > > provide immediate feedback to a user if the requested state is insane or 
> > > broken. It can limit the tests you have to write for a basic feeling of 
> > > coverage.
> > > 
> > > Moreover, we think that charms that follow this pattern will be "good 
> > > enough" for the common case.  People who write their first charms maybe 
> > > should be encouraged in this direction.  We wish we had gone this way. 
> > > It would have been simpler and faster.  We would have identified early 
> > > on the config that we wanted to be able to be dynamic, and made 
> > > everything else frozen initially.  Really, adding the rleationships is 
> > > the primary bit of dynamism that we needed/wanted.
> > > 
> > > The only thing that I can think of that juju could do to help this would 
> > > be to allow a setting of "initial-config-only" for a given config name. 
> > >   If the name were not provided initially, juju would refuse to start 
> > > the charm; and if the name were set after start up, juju would refuse to 
> > > send it, with a helpful error message.
> > > 
> > > >>   * The one-way communication aspect of relation-set was surprising (so I
> > > >>     can relation-set foo=bar but I can never find out later on what I've
> > > >>     already told a relation about config options).
> > > >>     It would be great if there were a utility to retrieve whatever had
> > > >>     been sent to a relation. This would also be a nice way of caching
> > > >>     things for Charms :).
> > > >
> > > > Could you explain this a bit more, how is it one-way, you can use relation-set,
> > > > and retrieve values set with relation-get.
> > > >
> > > >   $ relation-get key $JUJU_UNIT_NAME
> > > >
> > > > currently unit name is supplied by the default value of the $JUJU_REMOTE_UNIT in
> > > > the hook.
> > > 
> > > Yes, thank you.  I replied to this separately, after our discussion on IRC.
> > > 
> > > >
> > > >
> > > >>   * Juju should allow service-destroyed hooks: bug 932269
> > > >
> > > > the 'stop' hook is the equivalent for a unit: bug 872264
> > > 
> > > Ah, good to know.  Does juju destroy-service fire the stop hook on all 
> > > the units?
> > > 
> > 
> > Uhh, uhh, wait!!!
> > 
> > Stop is not supposed to delete stuff!
> > 
> > From here:
> > https://juju.ubuntu.com/docs/charm.html#hooks
> > stop - Runs when the service unit is stopped. If relations exist, they
> > will be broken and the respective hooks called before this hook is called.
> > 
> > Charms don't know what they've touched. Thats going to be a nightmare
> > for anything that isn't confined to packages (which do have a nice
> > purge method, but even those are very often wrong).
> > 
> > I think the LXC everywhere idea is actually better than having a
> > destroy-relation hook.
> > 
> > > >
> > > >>   * Optimization in ec2 (and presumably Canonistack) of reusing machines
> > > >>     is painful, especially without any kind of "destroy service" hook.
> > > >>     There's no way to ensure that the previous Charm has cleaned up after
> > > >>     itself, which gets particularly problematic when you deploy the same
> > > >>     charm to the node later on (because if the old one hasn't cleaned up
> > > >>     properly, directories may exist that shouldn't and ports may be bound
> > > >>     to that should be free).
> > > >
> > > > reuse of a machine is problematic regardless of a stop hook. we'd have to
> > > > promote lxc everywhere to get towards this. A container per machine always would
> > > > suffice for reuse sans incurring too many networking challenges (forward all).
> > > 
> > 
> > (this is more to Kapil):
> > As I've suggested in the past, we need to look into the fact that LXC
> > does not actually have to namespace the networking of the container. So
> > we can very easily just create containers that just share networking
> > with the host. This solves the networking problem, and only creates a
> > minor issue where the sshd that runs on the host or in the containers
> > will need to be moved to some other port.
> 
> That would be ideal if it worked for a full container. I tried a quick 
> experiment with this, it looks like things like upstart will conflict as well 
> with the same network ns.
> 
> Trying to start a full container sharing the host networking for example gets.
> 
> init: Unable to listen for private connections: Failed to bind socket "/com/ubuntu/upstart": Address already in use
> mountall: Unable to listen for private connections: Failed to bind socket "/com/ubuntu/mountall/server/": Address already in use
> 

Interesting.. I wonder if there is a way to have LXC namespace DBUS
without namespacing TCP/IP.



More information about the Juju mailing list