[09:07] <AskUbuntu> MAAS & juju trubles from KAZAKHSTAN | http://askubuntu.com/q/307205
[10:07] <jamespage> adam_g_, I proposed a couple of merges for nova-cloud-controller and nova-compute off the back of the serverstack quantum work I've been doing
[10:07] <jamespage> wedgwood_away, can you give me a ping re consistency of return values in hookenv when you are around
[11:36] <ehw> hey, everyone, o/ , are there current docs for setting up juju-core + maas?  getting errors following the steps on the wiki; namely, 'no public ssh keys' are defined in the environments.yaml, but it's not documented anywhere how to set this up
[13:52] <wedgwood> jamespage: ping
[13:52] <jamespage> hey wedgwood
[13:52] <jamespage> hows things?
[13:52] <wedgwood> not much to complain about
[13:52] <wedgwood> you?
[13:53] <jamespage> yeah - good thanks
[13:53] <jamespage> anyways; I was having a dig through charm-helpers this morning
[13:53] <jamespage> and started to review the stuff in core/hookenv against what we have in contrib/hahelpers/utils
[13:53] <jamespage> as there is alot over overlap
[13:54] <jamespage> specifically with regards to relation/unit/config accessors we have a bit of inconsistency
[13:54] <jamespage> in contrib/hahelpers/utils if the return value from a juju cli call is empty, the function returns 'None'
[13:54] <jamespage> makes it nice and easy to detect an unset of missing value in python
[13:55] <jamespage> its a little different in core/hookenv; do you think its going to be possible to agree on a single approach?
[13:56] <jamespage> there are also some inconsitencies - relation_get does the None thing; unit_get does not
[13:56] <jamespage> wedgwood, any opinion on which is the right* way
[13:56] <jamespage> *tm
[13:56] <jamespage> adam_g_, you will be interested in this as well ^^
[13:57] <wedgwood> sorry, got pulled away a bit
[13:58] <wedgwood> It's hard to say. There is such a thing as a null value in yaml.
[13:58] <wedgwood> I think None is right, but I disagree that it indicates that a value is not set
[14:02] <wedgwood> jamespage: I agree that we should return None more consistently in the case of either a) an unset value or b) a value that is null
[14:03] <jamespage> wedgwood, coolio
[14:03] <jamespage> the other nice thing I added to contrib/hahelpers/utils was some transparent function caching
[14:03] <wedgwood> the alternative is to throw an exception for unset values and nobody wants that. nor is there any way to know really since the relation-* tools just return nothing
[14:03] <jamespage> wedgwood, indded
[14:04] <wedgwood> tbh, I haven't looked closely at hahelpers. I did see a lot of overlap so I turned my attention to what seemed like more pressing things.
[14:04] <wedgwood> I'll have a look at the function caching if you think that's the most ripe for promoting
[14:06] <jamespage> wedgwood, its only a couple of functions - I'm happy to refactor it into hookenv
[14:07] <wedgwood> that'd be much appreciated!
[14:07] <jamespage> wedgwood, but I wanted to checkin with you on the return type thing first
[14:09] <jamespage> wedgwood, OK - lemme take a run at the hookenv None thing first
[14:09] <jamespage> and then I'll work in the caching
[14:09] <jamespage> it hugely improves performance of some of our charms
[14:15] <stub> marcoceppi: How are your test tools going?
[14:28] <marcoceppi> stub: good, I should have a simple first cut out this week
[14:29] <stub> marcoceppi: ok. Let me know if you want eyeballs on it :)
[14:29] <marcoceppi> stub: I'll give you a ping for sure!
[14:30] <stub> I'm just updating my test harness for gojuju. Found a few gotchas.
[14:32] <marcoceppi> stub: anything I should keep an eye out for?
[14:33] <stub> marcoceppi: Having to wait for services with life: dying to actually die was the main one I found.
[14:35] <stub> marcoceppi: Trying to diagnose if/when openstack nodes get reused atm... gojuju seems to like spawning new nodes rather than reusing ones that are idle or soon will be.
[14:54] <marcoceppi> stub: I'll make sure to add "dying" checks in. Didn't think of that
[15:30] <noodles785> wedgwood: hi! No rush, but if you've time over the next few days, could you pls look at https://code.launchpad.net/~michael.nelson/charm-helpers/add-declarative-support/+merge/168961
[15:30] <noodles785> jcastro: ^^ That's the declarative helper I mentioned on G+ using saltstack's states.
[15:31] <wedgwood> noodles785: that looks an awful lot like a saltstack module, rather than a generic helper.
[15:32] <wedgwood> do we want to choose saltstack over puppet or chef?
[15:34] <wedgwood> noodles785: at the spring we discussed the idea of having some package-specific helpers, and I think this would be a good one.
[15:34] <wedgwood> but that implies to me that the naming should be a bit more package-specific.
[15:35] <noodles785> wedgwood: I've tried to write it in a way that we could use other packages too (just a thin wrapper). I have in the past done similar charms using puppet to set the state. I don't care which we go with personally, but some people don't like puppet.
[15:35] <noodles785> wedgwood: Happy to re-work it as needed - I just want to be able to declare machine states rather than write (and test them) procedurally.
[15:36] <wedgwood> +1 on that
[15:36] <noodles785> salt seems like a good choice (it's python, and they're getting involved with ubuntu stuff too: https://plus.google.com/u/0/116015965439782966698/posts/FhL9ahHqdbR )
[15:36] <jcastro> wedgwood | do we want to choose saltstack over puppet or chef?
[15:36] <mgz_> what's the oldest version of ubuntu that juju actually supports?
[15:36] <jcastro> hey so I'm the ecosystem guy, I of course want to see as many integration points with as many tools as possible
[15:37] <jcastro> wedgwood: that probably doesn't jive with your real-world needs though, heh
[15:37] <wedgwood> noodles785: The structure isn't there, but I envision this going somewhere like charmhelpers.package.saltstack. please feel free to suggest a better namespace
[15:37] <wedgwood> (there=in the package, yet)
[15:38] <noodles785> wedgwood: that sounds fine - but why not charmhelpers.contrib.saltstack ?
[15:39] <wedgwood> noodles785: that works too. right now, contrib implies temporary and unstable, but that can develop over time to be the home for things like this
[15:39] <noodles785> wedgwood: cool, I'll update it to that, and rename the two methods so that they're obviously salt and not generic (?)
[15:40] <wedgwood> noodles785: and btw, this looks great and I think it'll be immedately useful to other too
[15:40] <wedgwood> noodles785: that would be perfect
[15:40] <noodles785> Excellent, will do. Thanks!
[15:41] <wedgwood> mgz_: I seem to remember that we shipped some version with oneiric, but I could be wrong
[15:41] <jcastro> mgz_: we have oneiric stuff in the store
[15:42] <jcastro> but it's not very supported, it's there but I don't think we officially say it's supported
[15:42] <jcastro> "we only care about precise" is a good reflection of the current reality
[15:43] <mgz_> thanks guys, responding to mailing list post
[15:54] <rick_h__> jcastro: I think that's on the way out, well the browser is removing it
[15:58] <arosales> Charm Meeting starting at the top of the hour. Pad URL = http://pad.ubuntu.com/7mf2jvKXNa
[15:58] <jcastro> Charm hangout in a few minutes, you can follow along on http://ubuntuonair.com
[15:58] <jcastro> or just ask us to jump in if you want to participate
[15:58] <jcastro> https://plus.google.com/hangouts/_/41d46ad46b450f9e8a5d57259121f6ed436e6af9?authuser=0&hl=en
[16:34] <_mup_> Bug #1190293 was filed: preinstall packages for charms <juju:New> <https://launchpad.net/bugs/1190293>
[16:44] <jcastro> marcoceppi: I need the youtube link for the video when you have it
[16:46] <marcoceppi> jcastro: waiting for it to upload
[16:48] <marcoceppi> jcastro: https://www.youtube.com/watch?feature=player_embedded&v=0qaxWHnqxNQ
[17:38] <jcastro> negronjl: https://code.launchpad.net/~patrick-hetu/charms/precise/gunicorn/python-rewrite/+merge/167088
[17:38] <jcastro> this is ready!
[18:21] <FunnyLookinHat> Do the images at http://cloud-images.ubuntu.com/precise/current/ come ready with a specific key-pair or password?
[18:23] <jcastro> smoser: ^^
[18:23] <jcastro> I think it's ubuntu/ubuntu but not sure
[18:24] <arosales> also utlemming  may know.
[18:24] <arosales> I _think_ the default user was made optional in the latest images
[18:24] <arosales> default user = ubuntu
[18:25] <smoser> :)
[18:25] <smoser> of course they do not
[18:25] <smoser> in 12.10 there is no user at all in the image
[18:25] <FunnyLookinHat> smoser, just a keypair ?
[18:26] <jcastro> http://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html
[18:26] <smoser> in 12.04 and prior, there was a 'ubuntu' user, but its password login was locked.
[18:26] <FunnyLookinHat> jcastro, perfect, thx
[18:26] <smoser> jcastro's link will get you want you want. (assuming what you want is to be able to login)
[19:42] <cmars232> is anyone working on a charm for the horde PHP applications, esp webmail?
[19:45] <jcastro> I've not seen anyone working on that
[19:45] <jcastro> it's up for grabs if you want to snag it!
[19:45] <jcastro> we have a mailstack and MySQL already, I think you'd just need the fronend bits
[19:50] <jcastro> marcoceppi: m_3: is there any other nuclear option remaining for removing drupal6?
[19:51] <lifeless> jcastro: you want more nukes? or non-nuke options ? :)
[19:54] <jcastro> I think nuking it is the only way to be sure
[19:57] <cmars232> jcastro: mailstack.. excellent. will consider it, though it might be a non-trivial first charm. thx
[19:58] <cmars232> jcastro: where is mailstack, i don't see it in the charm store? does that include postfix, etc.?
[19:58] <jcastro> http://jujucharms.com/~ivoks/precise/mail-stack-delivery
[19:58] <cmars232> ah
[19:58] <jcastro> I'll annoy ivoks to get back to working on it
[20:04] <m_3> jcsackett: hmmm... dunno
[20:05] <m_3> jcsackett: sorry, that was meant for jcastro
[20:05] <m_3> but he quit the channel
[20:05] <m_3> win 19
[21:34] <jhf> hey all - trying to understand charm upgrades. is it expected that charms can do an "in-place" upgrade?  for my charm (which installs Liferay, a java-based portal server with an embedded Tomcat servlet container), I really need to a)stop the server, b) extract the new bits to a parallel directory to the old bits, c) copy and change config files, d) start up the new bits, and e) delete the old bits. this seems *really* heavyweight.
[21:34] <jhf> not to mention, the new bits would now be in a different directory than the old bits.
[21:35] <jhf> so I can't just re-install over top the old bits, with the server still running. that would not  be good for the system.
[21:37] <sarnold> jhf: can you not re-organize those a litle? something like (a) extract new bits into temp directory (b) copy and change config files (c) stop the server (d) rename running directory to old, rename new directory to running (d) start the server (e) delete the old bits
[21:37] <sarnold> directory renames are near enough to instant (especially compared to jvm startup)
[21:38] <jhf> yep I sure could… that sounds like a good approach, but what about the relations established on the "old" bits?  does juju need to know anything, can I just do what you suggest without juju knowing?
[21:39] <jhf> it won't call any other hooks besides upgrade-charm, during an upgrade?
[21:39] <sarnold> I know the order of hook calls is well-defined, but I'm less certain about timing
[21:39] <jhf> like the db relation in particular. are any of the db-relation-* hooks called during an upgrade ?
[21:41] <jhf> https://juju.ubuntu.com/docs/charm-upgrades.html implies that this is the only hook called during an upgrade.  "After the upgrade-charm hook is executed, new hooks of the charm will be utilized to respond to any system changes."
[21:42] <jhf> I presume that means that other hooks are only called in response to operator actions like adding/removing relations
[21:42] <jhf> but not automatically, as part of the upgrade process
[21:42] <sarnold> oh, nice :)
[22:23] <marcoceppi> jhf: no other hooks, other than hooks/upgrade-charm will be run by juju. If you want to execute a hook you'll need to execute it inside the hooks/upgrade-hook hook
[22:23] <marcoceppi> err hooks/upgrade-charm* hook
[22:23] <m_3> jhf: or... just use config for service "upgrades" :)
[22:24] <marcoceppi> +1, use a "version" configuration option to allow users to move between and "pin" a version of the software
[22:24] <m_3> upgrade-charm just for upgrading the charm bits themselves... doesn't _necessarily_ even need to stop the service
[22:25] <m_3> best practice is on the fence between those approaches... depends on what's more natural for the service
[22:25] <sarnold> I feel like this is an area for juju to provide more opinion :)
[22:25] <m_3> sarnold: ack
[22:25] <m_3> ok, so do it my way :)
[22:25] <m_3> jk
[22:26] <m_3> I really do like the upgrade in config
[22:26] <m_3> but there's really a lot of variation between services
[22:26] <m_3> I guess the framework charms are the worst
[22:26] <sarnold> I'll grant it is difficult because every service is slightly different.. and some vastly different.. but i think someone administering a few thousand nodes would much prefer them to all act identically across all services for all service upgrades.
[22:26] <m_3> charm bits with versions, framework bits with versions, other deps with verisons, and then an actual application with versions
[22:27] <m_3> sarnold: oh, yeah... good point
[22:27] <sarnold> knowing which services upgrade themselvs on charm upgrade and which ones have a config option to set to push an upgrade would be a bit detailed.
[22:27] <m_3> yeah
[22:27] <m_3> sarnold: but often you're infra is only a dozen or so actual services
[22:27] <m_3> even if it's 15,000 instances
[22:27] <sarnold> m_3: true.
[22:28] <m_3> but yeah, good point... I'd be in favor of restricting upgrade-charm to just do the charm bits
[22:28] <m_3> push all service upgrades into config
[22:28] <m_3> makes charms more complicated in general though
[22:28] <m_3> so steeper learning
[22:28] <m_3> but...
[22:29] <m_3> that'd at least be consistent between framework charms and other charms
[22:30] <m_3> upgrade-charm only upgrades charms
[22:31] <sarnold> I presume it's a bit late to suggest upgrade-service hooks? :)
[22:31] <m_3> sarnold: ha
[22:31] <m_3> nope, suggest away!
[22:32] <m_3> well, I can't say about late or not
[22:32] <m_3> but... suggest away!
[22:32] <m_3> :)
[22:33] <sarnold> hey! I suggest an upgrade-service hook to explicitly upgrade a service, so upgrade-charm can perform exactly charm upgrades!
[22:33] <sarnold> proposed. :)
[22:33] <m_3> the bug'll go smoother if you're asking rather than me
[22:37] <marcoceppi> sarnold: You could always just write a hooks/upgrade-service and have config-changed run it when someone changes the version config option
[22:38]  * marcoceppi runs away
[22:39] <m_3> :)
[22:39] <sarnold> marcoceppi: hahaha
[22:39] <sarnold> marcoceppi: actually..
[22:39] <m_3> makes sense
[22:39] <m_3> future-proof?
[22:39] <sarnold> that feels like a very reasonable Best Practice to suggest.
[22:40] <marcoceppi> sarnold: well, i'd be better to create an upgrade_service function and just stub it in the config-changed hook
[22:40] <sarnold> I don't really care about the details; it just seems like the current "whatever the charm author wants" is a bit vague and more opinion could help.
[22:40] <m_3> one of the biggest best practices I'd like to start pushing is to put your hook impls in a library...
[22:40] <marcoceppi> I wouldn't want to polute the hooks/ space with non-hook files
[22:40] <marcoceppi> m_3: +1
[22:40] <m_3> marcoceppi: yeah, exactly!!!
[22:40] <m_3> sarnold: yes, accepted... wild wild west only works for so long
[22:41] <m_3> we did actually get some great ideas from organic growth though
[22:41] <m_3> we just gotta now clean things up
[22:42] <sarnold> m_3: that's cool to hear :)
[23:37] <AskUbuntu> how to turn on and start openstack and openvswitch in a 32 bit machine running ubuntu 13.04? | http://askubuntu.com/q/307514
[23:38] <marcoceppi> Does someone have a list of all the agent-states that pyjuju and gojuju show?