/srv/irclogs.ubuntu.com/2014/09/29/#juju.txt

=== uru_ is now known as urulama
=== CyberJacob|Away is now known as CyberJacob
=== barrypri1 is now known as barryprice
=== CyberJacob is now known as CyberJacob|Away
badsyntaxcan juju manage containers on ec2? i'm getting a "Sub-containers not supported" message in the juju-gui.08:24
lazyPowerbadsyntax: 1 moment, let me bootstrap and try. Shouldn't be an issue though08:26
lazyPoweri admittedly haven't tried with the new GUI, and its a bit early for the GUI folks to be poking around08:26
lazyPowerbadsyntax: appears it works without an issue on AWS - this may be a gui defect surfacing. http://paste.ubuntu.com/8453759/08:32
lazyPowerpaste of a container started in case that comes into question: http://paste.ubuntu.com/8453794/08:40
=== fabrice_ is now known as fabrice|lunch
=== fabrice|lunch is now known as fabrice
=== ericsnow_ is now known as ericsnow
mwenninglazyPower, good morning!14:08
lazyPowerMorning mwenning o/14:08
mwenninglazyPower, I saw your comment about the charm - my main problem was that squid-deb-proxy only allows certain repos - linux.dell.com is not one of them.14:10
mwenningnot sure when this went in.14:10
lazyPowermwenning: you can add that to the squid config14:11
mwenninglazyPower, yes that14:11
lazyPoweri had to do that with ppa.ubuntu.com, as those weren't in by default either14:11
lazyPowerDo you need me to fish up the config you need to edit?14:11
mwennings what I did.  So do I just add this to the README>14:11
lazyPowerthe fact you had to update squid?14:11
lazyPowerI woudl add it under caveats, that if you're behind a squid-deb-proxy, that the host needs to be added. I wouldn't think that effects many installations, but the info is there if they find an issue fetching the packages.14:12
mwenninglazyPower, if people actually want to use the charm they need to know this.  So I assume I need to add something to the doc14:12
* lazyPower nods14:12
mwenningok cool.14:12
lazyPowerdid you capture the test run output?14:13
mwenninglazyPower, I'll ping you a bit later, it's still complaining about something.14:13
lazyPowerack. Looking forward to seeing resolution on this one for ya mwenning14:13
mwenningme too :-)14:13
tvansteenburghif i force-terminate a bunch of machines, should i expect juju to eventually destroy all the services on those machines?14:21
lazyPowermwenning: not to be a pest, but are you documenting your papercuts as you run into them?14:21
lazyPowertvansteenburgh: if you leave the bootstrap node in tact you have to follow upd estroy the services.14:22
lazyPowertvansteenburgh: inversely, you can juju deployer -T, which will do this for you.14:22
mwenninglazyPower, is there a way to put constraints on amulet?  I've got one machine marked as "bootstrap"; I'd like to tell amulet to, um use that as the bootstrap node.14:22
lazyPowermwenning: i'm assuming you mean consuming maas tags?14:22
mwenninglazyPower, yup.14:23
mwenningyup on your previous question as well.  main one was the squid-deb proxy14:23
tvansteenburghyes you can pass contraints to the add() method14:23
lazyPowerhazmat: does deployer understand maas tagging?14:24
mwenningtvansteenburgh, I'm assuming that d=amulet.Deployment() is what bootstraps juju, so that's before I can use add14:25
lazyPowermwenning: if deployer supports maas tagging, the same format you would put in a bundle you specify inline in the test, and it shoudl just hand it off.14:25
hazmatlazyPower, for constraints, its pass through .. ie. yes14:25
lazyPoweri thought so, awesome.14:25
hazmatconstraints: "tags=mymaastag"14:26
lazyPowernot sure about on the bootstrap though mwenning14:26
mwenninglazyPower, hazmat, so d=amulet.Deployment( 'constraints "tag=bootstrap"');14:27
mwenningthen d.add("tag=")14:27
mwenningto shut it back off14:27
mwenningsorry d.add( set-constraints "tag=")14:29
mwenninglazyPower, ok forget that for now ;-)14:29
mwenningI'll dump juju status in a pastebin, stby14:30
lazyPowerack14:30
mwenninglazyPower, https://pastebin.canonical.com/11781814:32
lazyPowermwenning: interesting. looks like the first machine choked on the series?14:33
mwenningjuju 1.20.814:33
mwenninglazyPower, correct.14:34
mwenningrelation sentry wants to be precise14:34
lazyPowercan you file a bug about this against amulet?  launchpad.net/amulet14:34
mwenninglazyPower, sure will do.14:34
=== kwmonroe_ is now known as kwmonroe
=== mwenning is now known as mwenning-needs-c
=== mwenning-needs-c is now known as mwenning
=== bladernr_30kFeet is now known as bladernr_
gnuoyjamespage, two branches to hopefully unbreak neutron + juno15:24
gnuoyhttps://code.launchpad.net/~gnuoy/charms/trusty/neutron-api/next-fix-1372893/+merge/23637015:24
gnuoyhttps://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/next-fix-1372893/+merge/23637115:24
=== Guest13468 is now known as balloons_
tvansteenburghhazmat: i'm almost done with the deployer patch to force-terminate machines. do you want that to be the default for an env reset?15:31
hazmattvansteenburgh, sounds good to me15:32
hazmatshould be faster and avoids having to do the inane code for retrying every single unit..15:33
tvansteenburghhazmat: any reason to even make non-forced an option? right now i'm passing this 'forced' param around, but maybe it should just always force, thoughts?15:38
hazmattvansteenburgh, no.. force always.. its faster15:41
tvansteenburghhazmat: sweet, that simplifies things15:42
hazmattvansteenburgh, if there tearing down the entire env.. there's not much cause to do things slowly imo15:42
hazmathmm15:42
hazmattvansteenburgh, there is some call for a non forced option.. for external resources management.. ie. aws-elb or dns charm wanting to clean up there15:43
=== fabrice is now known as fabrice|family
tvansteenburghhazmat: well i'm still destroying services b4 terminating machines, doesn't that cover the cleanup?15:45
tvansteenburghi have to do that, otherwise the machines die but the services hang around forever15:46
hazmattvansteenburgh, not really unless you wait for units to die and resolve on error them they won't have all the lifecycle hooks invoked which is what the current impl tries to do.. and then terminate machines after that. (at which point the force doesn't matter)15:48
tvansteenburghbleh15:48
hazmattvansteenburgh, yeah.. force by default is fine for now though. the commands in deployer need to be split out at some point so they can take options without more global option pollution.15:49
tvansteenburghhazmat: sounds good15:49
hazmatand orderly destroy can be revisited there.. mostly reset is about geddon.. and speed of nukes counts :-)15:49
tvansteenburghhazmat: https://code.launchpad.net/~tvansteenburgh/juju-deployer/force-terminate-machines/+merge/23638116:10
hazmattvansteenburgh, danke16:10
=== scuttle|afk is now known as scuttlemonkey
=== seelaman is now known as IS_hr_bot
=== IS_hr_bot is now known as seelaman
=== niemeyer_ is now known as niemeyer
=== roadmr is now known as roadmr_afk
=== cmagina_ is now known as cmagina
marcoceppicory_fu: we should talk about services framework being default charm template, I don't think it's a good opinion18:24
cory_fuWhy not?18:25
marcoceppiI think it's too specialized18:26
marcoceppifor a default18:26
cory_fuI disagree.  It's a general purpose pattern that solves several issues that are common to most charms in a consistent way that makes the charms much easier to understand and follow.  It also encourages making the charms unit testable18:28
cory_fuIt's a new pattern, and I can see maybe not wanting to make it the default yet, until it is used more, but I would definitely recommend it for any charm.18:29
marcoceppiI think it requires too much investment to get started compared to some of the other templates18:29
cory_fuThat doesn't make any sense18:29
cory_fuIt doesn't require any investment; that's the point of a template18:29
marcoceppithe pattern18:29
marcoceppiitself18:29
cory_fuYou charm create, and then you fill in the actions and requirements18:29
cory_fuIf anything, it requires *less* investment, because there are fewer places that you have to add code and reason about interactions18:30
marcoceppiI think we should drop the notion of a default altogether and instead have it prompted on first one and saved as a user seting18:31
marcoceppiIMHO ^18:31
cory_fuI'm not averse to that18:31
cory_fuI know that was your original idea for how the templates would work, and I'm entirely ok with that18:32
marcoceppigoing forward, since "services framework" isn't really clear, would this be better summarized as a declaritive framework?18:32
marcoceppior rather, a declaritive template?18:33
cory_fuYeah, the "name" sucks, we just hadn't come up with a better one yet.  Declarative framework is ok, but still not great.18:33
=== uru_ is now known as urulama
=== CyberJacob|Away is now known as CyberJacob
=== roadmr_afk is now known as roadmr
cory_fumarcoceppi: How about python-managed18:56
bic2kQuick question, does juju 1.20.7 support ec2 regionally availability zone constraints. My region is out of a container type in the default AZ. Just nee to specify us-east-1a or us-east-1c19:23
bic2klooks related to this bug #118383119:25
mupBug #1183831: unable to specify availability zone <charmers> <constraints> <ec2-provider> <landscape> <reliability> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1183831>19:25
bic2kI don't see any documentation specific to ec2 machine constraints on the juju site19:26
=== balloons_ is now known as balloons
lazyPowerbic2k: see the add-machine directive listed in HA docs: https://juju.ubuntu.com/docs/charms-ha.html19:36
=== balloons is now known as Guest63150
=== Guest63150 is now known as balloons_
bic2klazyPower: perfect, thanks. Didn't think about it in terms of HA since it was related to availability :-)19:46
lazyPowerbic2k: i have a bug open discussing where it should go: https://github.com/juju/docs/issues/18719:46
lazyPowerfeel free to chime in19:46
hazmatbic2k, juju will auto balance units across multiple azs for a service. on a per unit basis its not a constraint per se but a placement directive for  a given unit --to="zone=us-east-1a"20:20
=== balloons_ is now known as balloons
Subbu__Hi I am deploying openstack with juju charms from: ~openstack-charms/charms/trusty/openstack-dashboard/next deployment to lxc:1 is all good, but horizon login fails: I see this from error.log from apache2:: RSA certificate configured for 10.0.3.36:433  does NOT include an ID which matches the server name20:45
arosalesmbruzek: is the VPN some thing we can share from Brian's docs20:59
arosalesmbruzek: just point it at the new setup for thumper?20:59
mbruzekarosales: I don't know, I may be able to share it but I was given an id21:00
arosalesah ok so there wasn't a general one that was provided in Brian's doc21:01
arosalesmbruzek: no worries on sharing your ID.21:01
arosalesmbruzek: do you know if akash was able to reproduce the problem on the other maas set up?21:11
mbruzekI haven't talked with him in a bit now.21:11
arosalesmbruzek: do you know who was going to try that?21:11
* arosales doesn't see akash in here21:11
mbruzekarosales: I do not know21:11
* arosales pinged in #canonical.21:12
arosalesmbruzek: in order to keep this thing going you may want to give that new maas a try before you eod21:15
mbruzekarosales: The new one ?21:15
arosalescorrect21:15
mbruzekThe one that Canonical set up or ?21:15
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob
=== thumper is now known as thumper-afk
jamespageSubbu__, you are probably getting the standard snakeoil certificate which is auto-generated22:26
jamespagehorizon also listens on port 80 as well22:26
=== CyberJacob is now known as CyberJacob|Away
=== thumper-afk is now known as thumper

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