/srv/irclogs.ubuntu.com/2013/06/12/#juju.txt

=== wedgwood is now known as wedgwood_away
=== defunctzombie_zz is now known as defunctzombie
=== negronjl` is now known as negronjl
=== defunctzombie is now known as defunctzombie_zz
=== TheRealMue is now known as TheMue
AskUbuntuMAAS & juju trubles from KAZAKHSTAN | http://askubuntu.com/q/30720509:07
jamespageadam_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 doing10:07
jamespagewedgwood_away, can you give me a ping re consistency of return values in hookenv when you are around10:07
ehwhey, 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 up11:36
=== danilos_ is now known as danilos
=== wedgwood_away is now known as wedgwood
wedgwoodjamespage: ping13:52
jamespagehey wedgwood13:52
jamespagehows things?13:52
wedgwoodnot much to complain about13:52
wedgwoodyou?13:52
jamespageyeah - good thanks13:53
jamespageanyways; I was having a dig through charm-helpers this morning13:53
jamespageand started to review the stuff in core/hookenv against what we have in contrib/hahelpers/utils13:53
jamespageas there is alot over overlap13:53
jamespagespecifically with regards to relation/unit/config accessors we have a bit of inconsistency13:54
jamespagein contrib/hahelpers/utils if the return value from a juju cli call is empty, the function returns 'None'13:54
jamespagemakes it nice and easy to detect an unset of missing value in python13:54
jamespageits a little different in core/hookenv; do you think its going to be possible to agree on a single approach?13:55
jamespagethere are also some inconsitencies - relation_get does the None thing; unit_get does not13:56
jamespagewedgwood, any opinion on which is the right* way13:56
jamespage*tm13:56
jamespageadam_g_, you will be interested in this as well ^^13:56
wedgwoodsorry, got pulled away a bit13:57
wedgwoodIt's hard to say. There is such a thing as a null value in yaml.13:58
wedgwoodI think None is right, but I disagree that it indicates that a value is not set13:58
wedgwoodjamespage: I agree that we should return None more consistently in the case of either a) an unset value or b) a value that is null14:02
jamespagewedgwood, coolio14:03
jamespagethe other nice thing I added to contrib/hahelpers/utils was some transparent function caching14:03
wedgwoodthe 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 nothing14:03
jamespagewedgwood, indded14:03
wedgwoodtbh, 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
wedgwoodI'll have a look at the function caching if you think that's the most ripe for promoting14:04
jamespagewedgwood, its only a couple of functions - I'm happy to refactor it into hookenv14:06
wedgwoodthat'd be much appreciated!14:07
jamespagewedgwood, but I wanted to checkin with you on the return type thing first14:07
jamespagewedgwood, OK - lemme take a run at the hookenv None thing first14:09
jamespageand then I'll work in the caching14:09
jamespageit hugely improves performance of some of our charms14:09
stubmarcoceppi: How are your test tools going?14:15
marcoceppistub: good, I should have a simple first cut out this week14:28
stubmarcoceppi: ok. Let me know if you want eyeballs on it :)14:29
marcoceppistub: I'll give you a ping for sure!14:29
stubI'm just updating my test harness for gojuju. Found a few gotchas.14:30
marcoceppistub: anything I should keep an eye out for?14:32
stubmarcoceppi: Having to wait for services with life: dying to actually die was the main one I found.14:33
stubmarcoceppi: 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:35
=== defunctzombie_zz is now known as defunctzombie
marcoceppistub: I'll make sure to add "dying" checks in. Didn't think of that14:54
noodles785wedgwood: 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/16896115:30
noodles785jcastro: ^^ That's the declarative helper I mentioned on G+ using saltstack's states.15:30
wedgwoodnoodles785: that looks an awful lot like a saltstack module, rather than a generic helper.15:31
wedgwooddo we want to choose saltstack over puppet or chef?15:32
wedgwoodnoodles785: at the spring we discussed the idea of having some package-specific helpers, and I think this would be a good one.15:34
wedgwoodbut that implies to me that the naming should be a bit more package-specific.15:34
noodles785wedgwood: 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
noodles785wedgwood: 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:35
wedgwood+1 on that15:36
noodles785salt 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
jcastrowedgwood | 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
jcastrohey so I'm the ecosystem guy, I of course want to see as many integration points with as many tools as possible15:36
jcastrowedgwood: that probably doesn't jive with your real-world needs though, heh15:37
wedgwoodnoodles785: The structure isn't there, but I envision this going somewhere like charmhelpers.package.saltstack. please feel free to suggest a better namespace15:37
wedgwood(there=in the package, yet)15:37
noodles785wedgwood: that sounds fine - but why not charmhelpers.contrib.saltstack ?15:38
wedgwoodnoodles785: that works too. right now, contrib implies temporary and unstable, but that can develop over time to be the home for things like this15:39
noodles785wedgwood: cool, I'll update it to that, and rename the two methods so that they're obviously salt and not generic (?)15:39
wedgwoodnoodles785: and btw, this looks great and I think it'll be immedately useful to other too15:40
wedgwoodnoodles785: that would be perfect15:40
noodles785Excellent, will do. Thanks!15:40
wedgwoodmgz_: I seem to remember that we shipped some version with oneiric, but I could be wrong15:41
jcastromgz_: we have oneiric stuff in the store15:41
jcastrobut it's not very supported, it's there but I don't think we officially say it's supported15:42
jcastro"we only care about precise" is a good reflection of the current reality15:42
mgz_thanks guys, responding to mailing list post15:43
rick_h__jcastro: I think that's on the way out, well the browser is removing it15:54
arosalesCharm Meeting starting at the top of the hour. Pad URL = http://pad.ubuntu.com/7mf2jvKXNa15:58
jcastroCharm hangout in a few minutes, you can follow along on http://ubuntuonair.com15:58
jcastroor just ask us to jump in if you want to participate15:58
jcastrohttps://plus.google.com/hangouts/_/41d46ad46b450f9e8a5d57259121f6ed436e6af9?authuser=0&hl=en15:58
_mup_Bug #1190293 was filed: preinstall packages for charms <juju:New> <https://launchpad.net/bugs/1190293>16:34
jcastromarcoceppi: I need the youtube link for the video when you have it16:44
marcoceppijcastro: waiting for it to upload16:46
marcoceppijcastro: https://www.youtube.com/watch?feature=player_embedded&v=0qaxWHnqxNQ16:48
=== rick_h__ is now known as rick_h
jcastronegronjl: https://code.launchpad.net/~patrick-hetu/charms/precise/gunicorn/python-rewrite/+merge/16708817:38
jcastrothis is ready!17:38
=== niemeyer_ is now known as niemeyer
FunnyLookinHatDo the images at http://cloud-images.ubuntu.com/precise/current/ come ready with a specific key-pair or password?18:21
jcastrosmoser: ^^18:23
jcastroI think it's ubuntu/ubuntu but not sure18:23
arosalesalso utlemming  may know.18:24
arosalesI _think_ the default user was made optional in the latest images18:24
arosalesdefault user = ubuntu18:24
smoser:)18:25
smoserof course they do not18:25
smoserin 12.10 there is no user at all in the image18:25
FunnyLookinHatsmoser, just a keypair ?18:25
jcastrohttp://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html18:26
smoserin 12.04 and prior, there was a 'ubuntu' user, but its password login was locked.18:26
FunnyLookinHatjcastro, perfect, thx18:26
smoserjcastro's link will get you want you want. (assuming what you want is to be able to login)18:26
=== defunctzombie is now known as defunctzombie_zz
cmars232is anyone working on a charm for the horde PHP applications, esp webmail?19:42
jcastroI've not seen anyone working on that19:45
jcastroit's up for grabs if you want to snag it!19:45
jcastrowe have a mailstack and MySQL already, I think you'd just need the fronend bits19:45
jcastromarcoceppi: m_3: is there any other nuclear option remaining for removing drupal6?19:50
lifelessjcastro: you want more nukes? or non-nuke options ? :)19:51
jcastroI think nuking it is the only way to be sure19:54
cmars232jcastro: mailstack.. excellent. will consider it, though it might be a non-trivial first charm. thx19:57
cmars232jcastro: where is mailstack, i don't see it in the charm store? does that include postfix, etc.?19:58
jcastrohttp://jujucharms.com/~ivoks/precise/mail-stack-delivery19:58
cmars232ah19:58
jcastroI'll annoy ivoks to get back to working on it19:58
m_3jcsackett: hmmm... dunno20:04
m_3jcsackett: sorry, that was meant for jcastro20:05
m_3but he quit the channel20:05
m_3win 1920:05
jhfhey 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
jhfnot to mention, the new bits would now be in a different directory than the old bits.21:34
jhfso 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:35
sarnoldjhf: 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 bits21:37
sarnolddirectory renames are near enough to instant (especially compared to jvm startup)21:37
jhfyep 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:38
jhfit won't call any other hooks besides upgrade-charm, during an upgrade?21:39
sarnoldI know the order of hook calls is well-defined, but I'm less certain about timing21:39
jhflike the db relation in particular. are any of the db-relation-* hooks called during an upgrade ?21:39
jhfhttps://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:41
jhfI presume that means that other hooks are only called in response to operator actions like adding/removing relations21:42
jhfbut not automatically, as part of the upgrade process21:42
sarnoldoh, nice :)21:42
marcoceppijhf: 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 hook22:23
marcoceppierr hooks/upgrade-charm* hook22:23
m_3jhf: or... just use config for service "upgrades" :)22:23
marcoceppi+1, use a "version" configuration option to allow users to move between and "pin" a version of the software22:24
m_3upgrade-charm just for upgrading the charm bits themselves... doesn't _necessarily_ even need to stop the service22:24
m_3best practice is on the fence between those approaches... depends on what's more natural for the service22:25
sarnoldI feel like this is an area for juju to provide more opinion :)22:25
m_3sarnold: ack22:25
m_3ok, so do it my way :)22:25
m_3jk22:25
m_3I really do like the upgrade in config22:26
m_3but there's really a lot of variation between services22:26
m_3I guess the framework charms are the worst22:26
sarnoldI'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_3charm bits with versions, framework bits with versions, other deps with verisons, and then an actual application with versions22:26
m_3sarnold: oh, yeah... good point22:27
sarnoldknowing 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_3yeah22:27
m_3sarnold: but often you're infra is only a dozen or so actual services22:27
m_3even if it's 15,000 instances22:27
sarnoldm_3: true.22:27
m_3but yeah, good point... I'd be in favor of restricting upgrade-charm to just do the charm bits22:28
m_3push all service upgrades into config22:28
m_3makes charms more complicated in general though22:28
m_3so steeper learning22:28
m_3but...22:28
m_3that'd at least be consistent between framework charms and other charms22:29
m_3upgrade-charm only upgrades charms22:30
sarnoldI presume it's a bit late to suggest upgrade-service hooks? :)22:31
m_3sarnold: ha22:31
m_3nope, suggest away!22:31
m_3well, I can't say about late or not22:32
m_3but... suggest away!22:32
m_3:)22:32
sarnoldhey! I suggest an upgrade-service hook to explicitly upgrade a service, so upgrade-charm can perform exactly charm upgrades!22:33
sarnoldproposed. :)22:33
m_3the bug'll go smoother if you're asking rather than me22:33
marcoceppisarnold: You could always just write a hooks/upgrade-service and have config-changed run it when someone changes the version config option22:37
* marcoceppi runs away22:38
m_3:)22:39
sarnoldmarcoceppi: hahaha22:39
sarnoldmarcoceppi: actually..22:39
m_3makes sense22:39
m_3future-proof?22:39
sarnoldthat feels like a very reasonable Best Practice to suggest.22:39
marcoceppisarnold: well, i'd be better to create an upgrade_service function and just stub it in the config-changed hook22:40
sarnoldI 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_3one of the biggest best practices I'd like to start pushing is to put your hook impls in a library...22:40
marcoceppiI wouldn't want to polute the hooks/ space with non-hook files22:40
marcoceppim_3: +122:40
m_3marcoceppi: yeah, exactly!!!22:40
m_3sarnold: yes, accepted... wild wild west only works for so long22:40
m_3we did actually get some great ideas from organic growth though22:41
m_3we just gotta now clean things up22:41
sarnoldm_3: that's cool to hear :)22:42
=== wedgwood is now known as wedgwood_away
AskUbuntuhow to turn on and start openstack and openvswitch in a 32 bit machine running ubuntu 13.04? | http://askubuntu.com/q/30751423:37
marcoceppiDoes someone have a list of all the agent-states that pyjuju and gojuju show?23:38

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!