[05:13] <nvalerkos> morning
[05:13] <nvalerkos> marcoceppi: Marco are you there?
[05:15] <nvalerkos> I have a problem with creating a mysql database, its not providing the password file to login as root in order to create the user/database when I add a relationship with an webapp i created
[05:16] <nvalerkos> I think i have my metadata.yaml wrong or something on the relationship with mysql
[10:35] <BlackDex> Hello there. I get the following error, does some know where to look? "Service placement to machine not supported"
[10:54] <magicaltrout> what you doing BlackDex ?
[11:07] <BlackDex> magicaltrout: Deploing ;)
[11:07] <BlackDex> But i fond the problem
[11:07] <BlackDex> i pointed to a wrong machine
[11:08] <magicaltrout> cool
[11:08] <magicaltrout> that was going to be my suggestion :P
[11:49] <BlackDex> hehe thx !
[12:02] <marcoceppi> jamespage: https://github.com/juju-solutions/layer-basic/pull/45 however, you can patch this in the charms in the future by having the following in your layer.yaml http://paste.ubuntu.com/15340870/
[12:03] <marcoceppi> those will be evaluated before any pip calls are made (so if you need like buildessentials or libX-dev installed for a pip module, you can have that defined in the packages option)
[12:11] <jamespage> marcoceppi, oh nice - thanks!
[12:11] <marcoceppi> jamespage: either way, it'll land when cory_fu or someone else takes a look and +1's it
[12:12] <jamespage> marcoceppi, thanks for doing the fix - I was about to poke around and see if I could fix that up
[12:12] <jamespage> marcoceppi, btw
[12:12] <jamespage> http://paste.ubuntu.com/15340899/ works lovey
[13:57] <nvalerkos> marcoceppi: Hello Marco, I have a quick question.
[13:57] <nvalerkos> if you are there that is
[13:57] <marcoceppi> o/ nvalerkos
[13:57] <nvalerkos> so, I am trying to generate a new database connection with a non root user through metadata.yaml
[13:58] <nvalerkos> but I am not getting it right
[13:58] <marcoceppi> nvalerkos: sounds good, which charm are you connecting to?
[13:58] <marcoceppi> postgresql? mysql?
[13:58] <nvalerkos> I am making my own charm, I am using the mysql
[13:59] <marcoceppi> nvalerkos: sounds good - do you have your charm uploaded somewhere so I can follow along and take a look?
[14:00] <nvalerkos> marcoceppi: sent on prv message
[14:01] <marcoceppi> nvalerkos: okay, so your charm "requires" a MySQL interface, it's not a peer
[14:02] <nvalerkos> marcoceppo: I used it that, however it was connecting without the root password when using the db-relation-joined and getting a couldn't connect in log of python charm (mysql side)
[14:05] <marcoceppi> nvalerkos: the MySQL relations will provide database, user, password, port, hostname, you will need to check to make sure you have those values before contining since tihs is an async system
[14:05] <nvalerkos> oh
[14:06] <nvalerkos> ok got it, so the relation with requires is correct I just need to wait for complete relation credentials.
[14:06] <nvalerkos> Async.
[14:08] <nvalerkos> marcoceppi: thanks.
[14:08] <marcoceppi> nvalerkos: here's an example of a charm that does tomcat + MySQL and it's hook: https://api.jujucharms.com/charmstore/v5/~spagobi-charmers/trusty/spagobi-4/archive/hooks/metadatadb-relation-changed and https://jujucharms.com/u/spagobi-charmers/spagobi/
[14:08] <marcoceppi> metadatadb is the name of the MySQL relation for this charm
[14:09] <marcoceppi> nvalerkos: the system is async, but don't block the hook waiting. If you don't have the data just exit 0 from the hook and wait for the hook to be called again
[14:10] <nvalerkos> marcoceppi: ok got it. I am using python
[14:10] <marcoceppi> nvalerkos: ah, same concept, but without all the base ;)
[14:10] <marcoceppi> bash
[14:10] <nvalerkos> ah
[14:10] <nvalerkos> ok
[14:10] <nvalerkos> will do. thanks again.
[14:11] <nvalerkos> I saw that when you first gave me that charm link yesterday and did not gave any attention to it.
[14:11] <jamespage> thedac, coreycb, beisner: got time for a quick one?
[14:11] <jamespage> https://review.openstack.org/#/c/291146/
[14:12] <beisner> jamespage, sure.  2-for-1? :-)   https://review.openstack.org/#/c/290943/     https://review.openstack.org/#/c/288483/
[14:13] <jamespage> beisner, sure - looking
[14:13] <beisner> jamespage, ps, we've got the charm-single config file repo live now.  https://github.com/openstack-charmers/bot-control/tree/master/config/charm-single
[14:13] <beisner> so ceph single is good, and the odl ones get the right vars, but odl seems to be trusty-only
[14:13] <jamespage> beisner, I just put up a fix for odl - it was missing systemd support for wily
[14:14] <beisner> jamespage, sweet, thanks
[14:14] <jamespage> I had that in an old bzr branch that I had some other stuff in
[14:14] <jamespage> picked it out - hopefully should work OK now
[14:14] <beisner> jamespage, did you see the c-h fork that one of the odl charms is using?
[14:14] <jamespage> beisner, yes
[14:15] <jamespage> beisner, openvswitch-odl is a bit of a mess tbh - we need to move it to layers properly
[14:15] <jamespage> beisner, it now passes amulet smoke at least
[14:15] <jamespage> https://review.openstack.org/#/c/287153/
[14:16] <jamespage> beisner, just kicked off a full run of that
[14:18] <jamespage> beisner, another fairly trivial one - https://review.openstack.org/#/c/289249/
[14:19] <beisner> jamespage, oooo.  idea.  we should have more magic words to kick of relevant mojo specs.  in this case, it'd be the ssl-everywhere specs.  it would take rejigging the specs a bit to use the change branch, but doable and probably what we want.
[14:19] <jamespage> sounds awesome
[14:25] <jamespage> tinwood, not sure whether you spotted but https://review.openstack.org/#/c/288733/ needs a rebase
[14:27] <tinwood> jamespage, Thanks for spotting this.  I was waiting on gnuoy's keystone_v3 to get merged before I did the rebase.  I'm guessing that's gone through, so I'll rebase after I push this fix to charm-helpers.
[14:27] <jamespage> tinwood, it has
[14:28] <tinwood> thanks, will do.
[14:31] <jamespage> thedac, narindergupta: hey - I'm due to push the nuage charms live today - but I think they are all in a private team I can't see
[14:32] <jamespage> https://bugs.launchpad.net/charms/+bug/1510672
[14:32] <mup> Bug #1510672: Nuage Canonical Charm: vrsg <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1510672>
[14:33] <narindergupta> jamespage: let me give you access for same.
[14:33] <jamespage> narindergupta, ta
[14:34] <narindergupta> jamespage: you are part of team now and will subscraibe you that bug
[14:35] <narindergupta> jamespage: done
[14:37] <narindergupta> jamespage: please let me know once live so that we can comnunicate the same to nuage team as well
[14:40] <jamespage> marcoceppi, ok I'm going to put these nuage charms into the charm store using charm upload/publish etc...
[14:40] <marcoceppi> jamespage: gl
[14:40] <jamespage> marcoceppi, if I place them under 'charmers' does that make them the official charm?
[14:41] <marcoceppi> jamespage: no, that's not really how it works
[14:41] <jamespage> marcoceppi, ok I'm missing a step then
[14:41] <marcoceppi> jamespage: you upload then publish them /somewhere/
[14:41] <jamespage> I could see how to go from development to published
[14:41] <marcoceppi> ie ~nuage/trusty/nuage-charm
[14:42] <marcoceppi> or whever
[14:42] <jamespage> ok
[14:42] <marcoceppi> then, you just "charm promulgate"
[14:42] <jamespage> oh - ok
[14:42] <jamespage> lemme try that
[14:42] <jamespage> and that makes that revision the actual official one then...
[14:44] <marcoceppi> jamespage: pretty much
[14:47] <jamespage> marcoceppi, bleh - charm-store does not know I'm a member of nuage-charmers...
[14:47] <jamespage> I suspect regular injestion from lp?
[14:47] <marcoceppi> jamespage: what's the error you're getting? have you `charm login` yet?
[14:48] <jamespage> "unauthorized: access denied for user "james-page"
[14:48] <jamespage> "
[14:48] <jamespage> marcoceppi, I've been publishing aodh all morning so I know I'm normally ok
[14:48] <jamespage> https://jujucharms.com/u/james-page/aodh/9
[14:49] <jamespage> I guess I can put them under charmers for now and move them later
[14:49] <marcoceppi> jamespage: huh, looks like you're a member as of 2 mins ago ;) https://launchpad.net/~nuage-charmers
[14:49] <jamespage> marcoceppi, yeah - I just created that team :-)
[14:49] <marcoceppi> jamespage: I wouldn't moving later sounds painful
[14:49] <marcoceppi> jamespage: try logging in again?
[14:50] <marcoceppi> jrwren: help ^?
[14:50] <marcoceppi> err, frankban ^?
[14:51] <rick_h__> jamespage: will have to log out/in to catch the new team?
[14:51] <jamespage> rick_h__, how do I logout?
[14:51] <jamespage> being a dumbass
[14:51] <rick_h__> jamespage: oh, from cli?
[14:51] <rick_h__> jamespage: rm -rf .go-cookies
[14:51] <jrwren> rm ~/.go-cookies, IIRC
[14:51] <rick_h__> jamespage: think it's still there
[14:52] <jamespage> ta that did the trick
[14:52] <marcoceppi> \o/
[14:53]  * marcoceppi pines for the new charm command
[14:55] <jamespage> working nicely
[14:55] <jamespage> narindergupta, https://jujucharms.com/u/nuage-charmers/
[14:56] <jamespage> rick_h__, marcoceppi: the series in metadata support is great bt
[14:56] <narindergupta> jamespage: thanks
[14:56] <jamespage> w
[14:56] <rick_h__> jamespage: <3
[14:56] <marcoceppi> jamespage: yeah, I can't take credit for that, but it makes charming so much easier
[14:56] <narindergupta> jamespage: vrsg is not listed yet. Are we releasing vrsg as well?
[14:57] <jamespage> narindergupta, I have slow upstream internet :-)
[14:57] <marcoceppi> jamespage: what a concept, you're the bottleneck to the store and not some ingestion process ;)
[14:57] <jamespage> marcoceppi, lol
[14:58] <narindergupta> jamespage: thanks
[14:58] <jamespage> marcoceppi, I was local deving this morning and deploying on serverstack - boucing via the charm-store was neat
[14:58] <jamespage> narindergupta, all done
[14:58] <narindergupta> jamespage: thanks I can see it now
[14:58] <marcoceppi> :D jamespage with the new channel stuff, it'll be even more awesome to rev around in the store
[14:58] <jamespage> narindergupta, a bundle would be a nice next step :-)
[14:59] <narindergupta> jamespage: yeah thay have bundle and i will ask team to work on with latest upstream charm and submit for review
[14:59] <jamespage> narindergupta, sure
[15:02] <jamespage> thedac, all promulgated - did it new style
[15:02] <jamespage> thedac, I'll explain later
[15:04] <marcoceppi> jamespage: looks great https://jujucharms.com/nuage-vrs/
[15:04] <jamespage> marcoceppi, indeed
[15:05] <jamespage> something is odd with interface-rabbitmq - always takes forever to clone
[15:11] <lazyPower> marcoceppi - just one thing, and i'm guilty of this too. but the card says "by: undefined"
[15:11] <lazyPower> we're missing a data point on the charms to populate that field in the card
[15:12] <marcoceppi> lazyPower: that's something for the charmstore
[15:13] <magicaltrout> also it would be cool (if you can't already) to embed a paragraph of the readme into the card
[15:15] <beisner> jamespage, shall we land openvswitch-odl?  full passes too.  https://review.openstack.org/#/c/287153/
[15:15] <jamespage> beisner, go for it
[15:16] <jacekn> could one of the charms tell me if hold up on https://bugs.launchpad.net/charms/+bug/1538573 is expected? AFAICT it just needs to be merged
[15:16] <mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1538573>
[15:23] <jamespage> thedac, gnuoy, beisner: retro'ed my upload script into designate* charms
[15:23] <jamespage> https://jujucharms.com/u/openstack-charmers-next/designate
[15:23] <jamespage> https://jujucharms.com/u/openstack-charmers-next/designate-bind
[15:23] <magicaltrout> jacekn: for some reason that request is blankly ignored :) I even asked yesterday for you and got no response either......
[15:24] <jamespage> marcoceppi, is the 'charm' binary a go binary?
[15:24] <magicaltrout> you must have done something mean in a past life
[15:24] <beisner> jamespage, cool.  we should probably add both to openstack-charmers @ github for dev, then propose upstream projects from there.
[15:24] <beisner> aodh and designate that is
[15:24] <jamespage> beisner, we can actually just slurp them direct from lp
[15:24] <beisner> jamespage, oh cool.
[15:24] <jamespage> beisner, yah - them being git repos and all
[15:25] <jamespage> beisner, we should probably sort out some tests first tho
[15:25] <beisner> right
[15:25] <jamespage> they are a bit cowboy right now but only due to the very early lifecycle they are in
[15:25] <jamespage> I'd prefer to push under openstack once we have them in better shape...
[15:25] <beisner> ack
[15:26] <jamespage> beisner, series in metadata is a must for all of our charms...
[15:26] <jamespage> its a single charm upload command and the charm-store does the rest!
[15:26] <beisner> jamespage, yes. so, what happens if we define series now, and try to use the charms with 1.25.x ?
[15:26] <jamespage> beisner, it all works
[15:27] <beisner> well then we should add that metadata now :-)
[15:27] <jamespage> beisner, charm store interprets the cs:xxx request and figures out the right thing todo
[15:27] <jamespage> beisner, agreed
[15:27] <jamespage> beisner, I feel we could move to a post-commit charm upload quite quickly now
[15:28] <jamespage> beisner, http://paste.ubuntu.com/15341662/
[15:28] <jamespage> its that simple
[15:29] <jacekn> magicaltrout: maybe people are afraid of collectd :)
[15:30] <magicaltrout> jacekn: indeed
[15:30] <magicaltrout> spam the mailing list as well until you get a response :)
[15:30] <magicaltrout> post a commend on the LP tracker as well
[15:30] <magicaltrout> someone will be watching somewhere
[15:31] <jacekn> I'm also afraid that there is a bigger problem with the review process here
[15:32] <magicaltrout> jacekn: i believe the process is being overhauled so its a lot more visible, but you need to ask marcoceppi and/or tvansteenburgh about that stuff
[15:32] <jacekn> there should be no need to chase your contributions, it's charmers who should be chasing and encouraging people to do this work
[15:32] <tinwood> jamespage, beisner: are you seeing anything odd with ceilometer testing?
[15:32] <magicaltrout> it shouldn't take 3 or 4 days of asking to get an answer :)
[15:32] <magicaltrout> absolutely jacekn
[15:32] <jamespage> tinwood, yes - what do you see?
[15:32] <magicaltrout> kick marcoceppi
[15:32] <tinwood> TypeError: can't pickle thread.lock objects.
[15:33] <jamespage> tinwood, nope never seen that one
[15:33] <tinwood> jamespage, it's in ceilometerclient/v2/client.py
[15:33] <tinwood> Might be a version thing.
[15:33]  * tinwood hmmm
[15:33] <jamespage> maybe...
[15:34] <marcoceppi> jamespage: it is, it's being switched to that in xenial
[15:34] <magicaltrout> jacekn: my charm went into the review process, got reviewed once then stopped, but I didn't know if I had to do something or not to get it re-reviewed, so its just waiting until I get enough time to stand it back up again
[15:34] <magicaltrout> so I know what you mean
[15:34] <thedac> jamespage: narindergupta: \o/ Thanks for getting nuage charms promulgated. That was a long time coming.
[15:34] <marcoceppi> jacekn: there's a huge problem with the review process, it's being overhauled with a public beta of the new process coming out in a few weeks
[15:35] <jamespage> narindergupta, what's your lp id?
[15:35] <narindergupta> thedac: thanks for your patience as well i know it was long dur
[15:35] <thedac> no problem
[15:35] <narindergupta> jamespage: narindegupta
[15:35] <jacekn> marcoceppi: cool! Maybe in the mean time nominate one person a day and put them in the topic here so that people know who to chase?
[15:36] <marcoceppi> jacekn: what do you mean?
[15:36] <jamespage> narindergupta, thedac: I created https://launchpad.net/~nuage-charmers
[15:36] <jamespage> that's the team under which the charms are uploaded and published on the charm store
[15:36] <thedac> great
[15:36] <jacekn> marcoceppi: so instead of me asking every day and getting silence I could hilight somebody directly and get a response, even if that response is "your review is in the queue"
[15:36] <narindergupta> jamespage: thanks
[15:36] <jamespage> so adding people to that will allow future charm upload's
[15:37] <narindergupta> jamespage: gotch you
[15:37] <jamespage> thedac, narindergupta: they are one of the first partners I've promugated this way ...
[15:37] <jamespage> its neat
[15:37] <thedac> Sounds like a much better process
[15:37] <narindergupta> jamespage: yeah looks cool
[15:37] <jamespage> narindergupta, if they want to move they charm development out of launchpad that's ok - the requirement for bzr branches for charm injestion is going away
[15:37] <narindergupta> jamespage: is it possible to move other partners also on same process specially plumgrid?
[15:38] <jamespage> narindergupta, yes
[15:39] <narindergupta> jamespage: please look into it whenever gets time. Also it seems nuage and plumgrid wants to stick to launchpad for now. May be in future they might move to github
[15:39] <jamespage> narindergupta, they can do git on launchpad if they prefer - and this is only vcs
[15:39] <jamespage> not bug tracking etc...
[15:40] <narindergupta> jamespage: gotch you and will inform them.
[15:41] <jamespage> narindergupta, I made you an admin of nuage-charmers so you can add the nuage guys
[15:41] <narindergupta> jamespage: sure will ask the team who else to be involved and add them.
[15:41] <tinwood> jamespage, is ceilometer charm written against the v2 client?
[15:42] <jamespage> tinwood, tbh you're outside of my knowledge now
[15:42] <jamespage> it might be - the tests?
[15:42] <tinwood> oh it's definitely tests.  Whose our ceilometer specialist? :)
[15:42] <marcoceppi> jacekn: well, the queue is open, http://review.juju.solutions
[15:43] <jamespage> tinwood, sounds like you might be now :-)
[15:43]  * tinwood lol
[15:43] <tinwood> jamespage, I will dig into it.
[15:43] <jamespage> tinwood, tbh its always been a peripheral charm - not that many users user it
[15:43] <jamespage> we don't on serverstack
[15:44] <tinwood> ah, I see.  I don't think it'll be a big change, just need to work out what's going on and whether it needs to be backwards compatible.
[15:44] <jamespage> lazyPower, you gonna use charm upload for nexenta as well?
[15:44] <lazyPower> Yep!
[15:45] <lazyPower> Now that all the pipeline bits are there, there's almost no reason not to :)
[15:45] <jamespage> indeed
[15:46] <beisner> tinwood, ceilometer charm tests seem ok.  lmk if you see troubles therein.
[15:51] <tinwood> thanks beisner - it's probably a difference in versions on the test box vs my bastion.
[15:52] <tinwood> beisner, I have on the bastion: python-ceilometerclient             2.3.0-0ubuntu1
[15:57] <cory_fu> Is it always the case that the first leader-elected hook will run before install?
[16:08] <deanman> Is there a way to download manually the cloud-trusty lxc image before issuing a deploy --to lxc:x ?
[16:13] <marcoceppi> deanman: there is
[16:13] <marcoceppi> kind of
[16:13] <marcoceppi> well, in general, it's in http://cloud-images.ubuntu.com, but the process for preseeding on a deployed node I'm not 100% on
[16:16] <deanman> marcoceppi: when issuing a deploy it's not very informative on what goes on the background and whether is downloading the lxc or something. So i was thinking that maybe if i could download it manually i could present some more feedback to the user...
[16:24] <marcoceppi> tvansteenburgh: my stab at updating charmworldlib turned out pretty decently using theblues instead, finishing up tests now
[16:24] <tvansteenburgh> marcoceppi: excellent
[16:24] <marcoceppi> it's not a perfect match charmworldlib -> libcharmstore, but it's easy enough to patch
[16:34] <aisrael> It looks like the base charm layer is installing/upgrading pip outside of what's packaged in trusty, creating a /usr/local/bin/pip that calls python3 instead of python2. Does that sound right?
[16:35] <aisrael> I'm running into issues because something I'm installing has a syntax error with python3. I expect pip vs. pip3 similar to the packaged versions.
[16:43] <stokachu> wallyworld: new bootstrap for maas built-in is nice
[16:43] <stokachu> wallyworld: especially now you can just define your credentials for maas and not a local name
[16:46] <pmatulis> with ec2 provider, how do i specify the instance type for the controller? tried '--config instance-type=t2.micro' but it didn't work, and did not complain
[16:52] <marcoceppi> aisrael: if you need to, use the venv flag in the basic layer to work around this
[16:53] <aisrael> marcoceppi: ack. I'm trying the wheelhouse approach, but I'll look at that next if this doesn't work.
[16:54] <aisrael> marcoceppi: in general, though, I'm worried this behavior could be problematic (pip actually being pip3)
[16:55] <marcoceppi> aisrael: yes, this is why I always recommend we use virtualenv for all packaging and managing of pip
[16:55] <marcoceppi> deb and pip are competing packaing formats, and many people don't care
[16:57] <jamespage> tvansteenburgh, hey - can we get the juju-deployer release into https://launchpad.net/~juju/+archive/ubuntu/stable ?
[16:57] <jamespage> then I can transition our core bundles over to use git directly rather than lagging on bzr mirrors...
[16:57] <aisrael> marcoceppi: That totally sounds like a blog post waiting to be written. ;)
[16:58] <marcoceppi> aisrael: I will, getting tired of finding problems because people pip install willy nilly
[16:58]  * marcoceppi rage posts
[16:59] <tvansteenburgh> jamespage: yeah. have you used the latest release?
[17:00] <jamespage> tvansteenburgh, yes I put it in xenial last week and have been using it since...
[17:00] <tvansteenburgh> jamespage: great, thanks. i'll get it in stable then
[17:03] <marcoceppi> tvansteenburgh: lmk if you need help backporting to the ppa
[17:03]  * marcoceppi has a script
[17:04] <jamespage> tvansteenburgh, ta
[17:04] <tvansteenburgh> marcoceppi: i always just ask frankban to do it. i need to fix a build problem first though
[17:05] <frankban> tvansteenburgh: I think we decided to just copy the daily built deployer package when you are ready for a new release and you have QAed the deb
[17:06] <tvansteenburgh> frankban: yes that's correct!
[17:06] <marcoceppi> frankban: where's that built?
[17:06] <cholcombe> how do you specify the amazon machine image when deploying ?
[17:06] <tvansteenburgh> https://launchpad.net/~ahasenack/+archive/ubuntu/juju-deployer-daily
[17:07] <tvansteenburgh> marcoceppi:  ^
[17:07] <frankban> marcoceppi: there
[17:07] <rick_h__> cholcombe: the instance type?
[17:07] <marcoceppi> cool
[17:07] <cholcombe> rick_h__, yeah i want to deploy on xenial to test
[17:07] <rick_h__> cholcombe: oh series?
[17:07] <rick_h__> cholcombe: --series=
[17:07] <cholcombe> ah cool
[17:07] <rick_h__> cholcombe: on 2.0?
[17:07] <rick_h__> cholcombe: or 1.25?
[17:07] <cholcombe> no i'm 1.25
[17:08] <rick_h__> cholcombe: so there you need to local charm it and do the series directory/etc
[17:08] <cholcombe> looks like maybe juju set-env "default-series=xenial" ?
[17:22] <stokachu> so how do i bootstrap with juju 2.0 and define a different default model?
[17:23] <stokachu> I was thinking something like: juju bootstrap maas-production:prod1 maas/192.168.10.114 --debug --upload-tools
[17:23] <rick_h__> stokachu: 'default model'?
[17:23] <stokachu> so when you define the controller it creates a model with the same name
[17:23] <rick_h__> stokachu: oh, that's coming in the future code
[17:23] <rick_h__> stokachu: I thought it was in beta2 to go out today but I'm told it didn't make it
[17:23] <stokachu> ah ok
[17:23] <stokachu> i would like to have like maas-production:development,staging,production models
[17:24] <rick_h__> stokachu: soon, (beta3?) the default model will always be called admin, and that's the main controller model. Juju will also create a model called 'default' which you are auto put into
[17:24] <rick_h__> stokachu: and to change that you can pass an arg that's something like '--default-name'
[17:24] <rick_h__> stokachu: so you'd have models "admin" and your custom name passed on the flag
[17:24] <stokachu> so there will always be a default model for admin?
[17:24] <rick_h__> stokachu: there will always be an "admin" model as that's technically the 'controller'
[17:25] <rick_h__> stokachu: but folks shouldn't mess with it much, but we expect folks to do things common to all models there
[17:25] <stokachu> yea i think that's a bit confusing, having a 'controller' but a model that is also the 'controller'
[17:25] <rick_h__> stokachu: yea, it's an implementation detail that's leaked that we'll work on over time
[17:25] <stokachu> ok cool
[17:26] <rick_h__> stokachu: but yea, you can't remove-model admin
[17:26] <rick_h__> stokachu: because that's your controller
[17:26] <stokachu> ah right, yea i think once the definition of the admin model is more clearer that'll help the confusion
[17:26] <rick_h__> stokachu: yep
[17:26] <rick_h__> that's the hope
[17:27] <stokachu> is the --default-name something that was part of the changes in beta2 that didnt make it?
[17:27] <stokachu> im running from master as well
[17:35] <tvansteenburgh> ahasenack: ping
[17:37] <ahasenack> tvansteenburgh: hi
[17:39] <tvansteenburgh> ahasenack: hey, i'm trying to figure out why juju-deployer daily build started failing. i can see the test failure in the build log, but the confusing bit is when i look in older (successful) build logs, there's no indication that `make test` was ever run
[17:39] <ahasenack> tvansteenburgh: I think, if I remember correctly, that tests might be skipped if it detects it's in a launchpad buildd
[17:39] <ahasenack> tvansteenburgh: maybe that check failed, and it thought it should run the tests
[17:40] <ahasenack> I have to check
[17:54] <bbaqar> Hey guys. Any way I can get the CIDR of the maas network in a charm?
[18:00] <tvansteenburgh> ahasenack: okay thanks for your time. i just pushed a test fix so we'll see if that fixes the build
[18:03] <tvansteenburgh> jamespage: whenever this build succeeds we can get the package moved to stable ^
[18:11] <tvansteenburgh> ahasenack: okay the build is fixed, but the version is behind (should be 0.6.4, not 0.6.1). how does that get updated?
[18:19] <ahasenack> tvansteenburgh: it's in the packaging branch
[18:19] <ahasenack> tvansteenburgh: let me update that
[18:20] <ahasenack> tvansteenburgh:  juju-deployer - 0.6.1~bzr168~48~ubuntu16.04.1 <-- that's your build?
[18:20] <tvansteenburgh> ahasenack: yep
[18:21] <ahasenack> tvansteenburgh: updated, r49
[18:22] <jose> marcoceppi: ping
[18:22] <marcoceppi> o/
[18:22] <jose> marcoceppi: do you have a sec to take a look at an ubucon branch?
[18:23] <marcoceppi> jose: link me up
[18:23] <jose> https://code.launchpad.net/~ubucon-site-developers/ubucon-site/update-source-action
[18:23] <tvansteenburgh> ahasenack: ta. for future reference, do i need to contact you for version bumps?
[18:23] <ahasenack> tvansteenburgh: I think so, the pkging branch the recipe uses is mine, https://code.launchpad.net/+branch/~ahasenack/juju-deployer/juju-deployer-packaging
[18:24] <jose> marcoceppi: so, I think that update-source action is pretty straightforward, but are there any services that need restarting apart from that?
[18:24] <jose> marcoceppi: action is here http://bazaar.launchpad.net/~ubucon-site-developers/ubucon-site/update-source-action/view/head:/actions/update-source
[18:24] <marcoceppi> jose: that won't work
[18:24] <marcoceppi> jose: you have to run an entire migration, etc in addition
[18:24] <tvansteenburgh> ahasenack: ok thanks!
[18:24] <jose> marcoceppi: the site isn't live-running from the directory?
[18:24] <ahasenack> tvansteenburgh: if you want you could copy the recipe to a team-owned account perhaps
[18:25] <marcoceppi> jose: it is, but you have to run db migrations and such in addition to just updating the files
[18:25] <jose> hmmk I'll dig a bit more into it
[18:26] <marcoceppi> jose: you need the event to show up in the reactive framework and to reset the djang.ready or intalled or whatever event
[18:27] <jose> ok, thanks
[18:27] <tvansteenburgh> ahasenack: can you force a new build so i get the new version?
[18:27] <ahasenack> tvansteenburgh: yep
[18:27] <tvansteenburgh> ahasenack: ta
[18:27] <ahasenack> done: https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily
[18:28] <ahasenack> tvansteenburgh: can you kick that as well? Just curious
[18:28] <tvansteenburgh> ahasenack: i don't see a way to do so
[18:29] <ahasenack> ok
[18:29] <ahasenack> "Request build(s)" green link just above "Recipe contents"?
[18:29] <tvansteenburgh> ahasenack: heh, there it is
[18:29] <ahasenack> cool
[18:30] <tvansteenburgh> good to know, thanks
[18:34] <tvansteenburgh> ahasenack: just noticed that frankban is offline now. can you copy that build to juju/stable, or tell me who can? jamespage has been using it for a week now and is ready to get it in stable
[18:35] <ahasenack> wow, that built fast
[18:35] <ahasenack> tvansteenburgh: hm, there might be a problem with the version number
[18:36] <ahasenack> tvansteenburgh: xenial has 0.6.4-0ubuntu1
[18:36] <ahasenack> that's the same?
[18:36] <ahasenack> I mean, it's higher than my PPA, and on purpose
[18:36] <tvansteenburgh> it's the same
[18:37] <ahasenack> tvansteenburgh: that being said, no, I cannot copy. I don't see the juju stable ppa in the target list
[18:37] <tvansteenburgh> ahasenack: ok, will wait til tomorrow, thanks
[18:37] <tvansteenburgh> jamespage: ^
[18:38] <ahasenack> tvansteenburgh: have you tried sinzui?
[18:38] <ahasenack> or any of the juju a folk I bet
[18:38] <tvansteenburgh> ahasenack: good idea, will try sinzui
[18:38] <ahasenack> s/a/qa/ I meant
[18:55] <cholcombe> for systemd with charmhelpers host.service_stop i need to pass an id parameter.  It looks like I need to add that to the function
[18:56] <cholcombe> wait.. i think i can pass the service name with the id.  I'm going to try it
[19:51] <wallyworld> stokachu: yeah, the built in maas was a last minute idea which seemed worthwhile. we'll get the credentials stuff sroted and it will be even better
[19:51] <tvansteenburgh> jamespage: new deployer is in juju/stable
[20:06] <stokachu> wallyworld: yea man sounds awesome
[20:30] <stokachu> wallyworld: is there a way via list-models to determine which one is the admin model?
[20:30] <stokachu> i want to be able to fitler out the admin model when presenting deployment models to an end user
[20:31] <wallyworld> stokachu: for now, it's the one called "admin". we'd have to look at tagging or something to do it better
[20:31] <wallyworld> stokachu: wait
[20:32] <wallyworld> that will be the case in the next beta
[20:32] <stokachu> ah ok
[20:32] <wallyworld> for this beta it's the one named after the controller
[20:32] <wallyworld> juju bootstrap mycontroller lxd
[20:32] <stokachu> right i figured as much, rick_h__ mentioned --default-name will that be exposed for the admin model?
[20:32] <wallyworld> the admin model will be mycontroller
[20:33] <wallyworld> --default-model will be to name the initial hosted model
[20:33] <wallyworld> the admin model will be "admin"
[20:33] <stokachu> not the admin model correct?
[20:33] <stokachu> ok
[20:33] <wallyworld> the default hosted nodel will be "default"
[20:33] <stokachu> cool so i can just filter out based on the name
[20:33] <wallyworld> yeah
[20:33] <stokachu> ok perfect
[20:33] <wallyworld> we may do it better with an attribute or something
[20:33] <stokachu> can i change the name of default with --default-model?
[20:33] <wallyworld> but for now that will work
[20:33] <wallyworld> yes
[20:34] <wallyworld> in the next beta
[20:34] <stokachu> ok cool
[20:34] <wallyworld> the nme of the hosted model
[20:35] <stokachu> wallyworld: https://paste.ubuntu.com/15343579/ just to clarify what im thinking
[20:35] <wallyworld> looking
[20:36] <wallyworld> stokachu: yep, looks good to me. the next beta should drop next week
[20:36] <stokachu> sweet
[20:36] <wallyworld> lte next week
[20:36] <stokachu> also, one last thing i promise, did you see my bug on determining the provider type through list-controllers?
[20:37] <wallyworld> yeah, we're looking into it
[20:37] <stokachu> ok cool thanks man
[20:37] <wallyworld> np, might be a nice surprise next beta also :-)
[20:37] <stokachu> hah ill keep a lookout
[20:40] <wallyworld> stokachu: btw, thanks for the awesome feedback and bugs etc - we're racing against time to get this work done so that external perspective if great
[20:41] <stokachu> wallyworld: np! so far i think the experience is great, just small things here and there
[20:42] <wallyworld> yeah, we can fix those :-)