[06:56] <vila> Hi there !
[06:56] <vila> I get the following error during a bootstrap:
[06:56] <vila>     > ERROR bootstrap failed: cannot start bootstrap instance: cannot set up groups: failed to create a rule for the security group with id: <nil>
[06:58] <vila> This is part of a job that ensure that the juju related security groups are *deleted* before calling 'juju bootstrap'
[06:58] <vila>  http://162.213.34.117:8080/job/uci-engine-integration-test/34/
[08:01] <vila> jam: Any idea about that 'security group with id: <nil>' during juju boostrap above ?
[08:01] <vila> bootstrap even
[08:05] <jam> vila: sinzui has been observing HP not actually giving us the number of security groups that we expect. (horizon says that we have 200, but starts giving us "no more security groups" after 10)
[08:05] <jam> vila: so it at least sounds like an HP problem.
[08:05] <jam> with id: <nil> at least sounds like we weren't able to create a security gorup
[08:05] <jam> I don't know why you wouldn't get a "failed to create security group" rather than "failed to set attribute"
[08:08] <vila> jam: hmm, HP limit... but 'nova secgroup-list' tells us we only have the 'default' group defined... Is there a place to check for some "hidden" ones ?
[08:18] <Mosibi> Hi all.
[08:19] <Mosibi> When doing a 'juju bootstrap -e openstack', the bootstrapped instance is trying to connect (apt) to internet sources.
[08:19] <Mosibi> How/where can i configure that our own internal mirror is used for that?
[08:21] <Mosibi> Okay, possible my question got lost in the middle of the netsplit :)
[08:21] <Mosibi> again...
[08:21] <Mosibi> Hi all.
[08:21] <Mosibi> When doing a 'juju bootstrap -e openstack', the bootstrapped instance is trying to connect (apt) to internet sources.
[08:21] <Mosibi> How/where can i configure that our own internal mirror is used for that?
[10:11] <jamespage> gnuoy, stable updates for https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1330906
[10:11] <_mup_> Bug #1330906: NSX support is broken in icehouse <nova-cloud-controller (Juju Charms Collection):In Progress by james-page> <nova-compute (Juju Charms Collection):In Progress by james-page> <quantum-gateway (Juju Charms Collection):In Progress by james-page> <https://launchpad.net/bugs/1330906>
[10:14] <vila> jam: did I miss your answer to "hmm, HP limit... but 'nova secgroup-list' tells us we only have the 'default' group defined... Is there a place to check for some "hidden" ones ?" from the netsplit ?
[10:15] <jam> vila: I don't *know* that it is the problem. But it does seem like more than coindidence that you're getting an error and we have a "nil" security group from HP around the same time that Curtis is saying something changed in HP and he's unable toget enough security groups.
[10:15] <jam> It might be that HP APIs changed and we're now using them wrong.
[10:16] <gnuoy> jamespage, the mps look good to me. Do you want me to approve and merge ?
[10:16] <jamespage> gnuoy, just regression testing them again neutron plugin
[10:16] <jamespage> gnuoy, happy for you just to approve - I'll merge once tested
[10:16] <gnuoy> ack
[10:17] <vila> jam: ha, right. We've seen that for quite some time but it occurs only rarely (best kind of bug you know :-/), if Curtis starts seeing related issues, I'll try to get in touch with him (he's offline, vacations ?)
[10:17] <jam> vila: I thought he was around, though US times so he wouldn't be awake right now
[10:17] <vila> jam: ack and thanks
[10:41] <jamespage> gnuoy, time for https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1329251 ?
[10:41] <_mup_> Bug #1329251: ssh-keyscan of hosts in MAAS environments is incomplete <nova-cloud-controller (Juju Charms Collection):In Progress> <nova-compute (Juju Charms Collection):In Progress> <https://launchpad.net/bugs/1329251>
[11:40] <Mosibi> When doing a 'juju bootstrap -e openstack', the bootstrapped instance is trying to connect (apt) to internet sources.
[11:40] <Mosibi> How/where can i configure that our own internal mirror is used for that?
[14:44] <marcoceppi> tvansteenburgh1: hey
[14:44] <tvansteenburgh> marcoceppi: hey
[14:45] <marcoceppi> so, I'm not sure if making Python the default charm template is a good idea
[14:45] <marcoceppi> I mean, it's a GREAT idea
[14:45] <marcoceppi> but I want to expose more of the "oh, here's a Python template, you can use -t to do stuff
[14:46] <tvansteenburgh> yeah i just thought we wanted to encourage people towards making python charms instead of bash
[14:47] <tvansteenburgh> besides, there will be plenty of chances for people to use -t once we get some more templates in there
[14:47] <tvansteenburgh> e.g. ansible - i was going to add an ansible template once the initial release was done
[14:47] <DaWoop> guys, the IRC link on the website redirects to the wrong channell
[14:48] <DaWoop> #juj instead of #juju
[14:48] <marcoceppi> DaWoop: really? what page?
[14:48] <DaWoop> http://ubuntuonair.com/
[14:48] <marcoceppi> DaWoop: oh, that's something else
[14:48] <DaWoop> the "Join from yout IRS Client!"
[14:48] <marcoceppi> jose: ^^
[14:48] <DaWoop> IRC*
[14:48] <jose> marcoceppi: still, it's going to be changed now, community team Q&A
[14:48] <jose> no moar juju :(
[14:48] <marcoceppi> DaWoop: thanks for the info
[14:49] <DaWoop> np marcoceppi
[14:50] <marcoceppi> tvansteenburgh: what I'm getting at is it would be great to say "Using default charm template: python, use -t to switch" when no -t flag is given
[14:50] <jose> mbruzek: thanks for your review
[14:50] <marcoceppi> tvansteenburgh: I've got a few other knitpicks, will post in merge
[14:50] <marcoceppi> otherwise this is badass
[14:51] <jose> marcoceppi: sent you an email
[14:51] <tvansteenburgh> marcoceppi: sounds good, thanks for the review :)
[14:51] <DaWoop> watcha guys up to?
[14:53] <DaWoop> nothing, I see
[14:53] <DaWoop> gotta love monospace fonts
[14:55] <lazyPower> DaWoop: Charming up big data charms, rifling through the rev queue, working on charm tooling, presentations. You know - being a charmer. What are you up to?
[14:57] <ZooZ> Question, i need to define Sound Fusion CD46xx soundcard , no voice in Ubuntu 12.10 , can anyone advise me from where to get installation package for sound driver ?
[14:58] <ZooZ> It is CS46xx sound fusion driver, iam also new to ubuntu
[14:59] <lazyPower> ZooZ: that would be better suited to #ubuntu
[15:01] <DaWoop> lazyPower: I'm watching some Improv Everywhere stuff
[15:02] <DaWoop> lazyPower: What are those Charming thing you're talking about? NEver heard of those!
[15:02] <lazyPower> DaWoop: juju.ubuntu.com
[15:03] <lazyPower> The most amazing data center orchestration tool on the planet
[15:03] <nuclearbob> ahoy!  I'm having trouble with the local provider on trusty.  I get "agent-state-info: '(error: error executing "lxc-start": command get_state failed"
[15:03] <DaWoop> alright, Juju is actually something, not a person
[15:03] <DaWoop> good to know
[15:03] <marcoceppi> tvansteenburgh: everything looks good, just looking to expose templates better. Discuss
[15:04] <DaWoop> lazyPower: Linux and GUI-based application? What's this breakthrough?
[15:04] <lazyPower> DaWoop: the future of devops
[15:04] <DaWoop> lazyPower: first time I actually see a gui-based app in linux
[15:05] <DaWoop> interesting stuff
[15:06] <tvansteenburgh> marcoceppi: i like the log message approach
[15:07] <marcoceppi> tvansteenburgh: cool, I figured the prompt might be a little annoying
[15:07] <DaWoop> lazyPower: sorry for the retard question, but could we use Juju on a windows system?
[15:07] <tvansteenburgh> marcoceppi: it seems annoying to me :)
[15:07] <marcoceppi> DaWoop: there's work being done to do so, and we have a demo already of juju driving windows systems
[15:07] <tvansteenburgh> marcoceppi: if you're okay with the log msg approach i'll add that real quick. no other nitpicks?
[15:08] <marcoceppi> tvansteenburgh: that one about the messaging
[15:08] <fpermana> what is juju?
[15:08] <tvansteenburgh> marcoceppi: oh, in the diff comments, i missed that the first time
[15:09] <DaWoop> fpermana: https://juju.ubuntu.com/
[15:09] <DaWoop> lazyPower: Would it be possible to run it on, say, debian on a Raspberry Pi?
[15:09] <DaWoop> and access the interface with the web app on windows?
[15:11] <arosales> hatch: good morning
[15:11] <hatch> morning arosales
[15:11] <arosales> hatch: were you planning on putting http://manage.jujucharms.com/~hatch/precise/ghost in the charm store ?
[15:12] <hatch> arosales yes there are just a few updates needed from the last review https://bugs.launchpad.net/charms/+bug/1229377
[15:12] <_mup_> Bug #1229377: Charm needed: Ghost blogging platform <Juju Charms Collection:Incomplete by hatch> <https://launchpad.net/bugs/1229377>
[15:12] <hatch> arosales here is the primary repo if you want to stay on the bleeding edge :) https://github.com/hatched/ghost-charm
[15:12]  * arosales looks at bug
[15:13]  * DaWoop can't stand the music they play at the radio
[15:14] <arosales> ah you just updated the bug on june 11
[15:14] <hatch> arosales yeah, it's only some pretty small changes from the last comment to get it into the store
[15:14] <arosales> hatch: did you have any worked planned in the the near term?
[15:15] <hatch> arosales my goal is to have it up for review again this week
[15:15] <arosales> some tests would be a plus too
[15:15] <arosales> hatch: good stuff :-)
[15:15] <hatch> yeah tests aren't going to happen until someone other than me actually uses it :D
[15:15] <arosales> hatch: I am looking to deploy my blog with it :-)
[15:15] <hatch> haha darn
[15:16] <hatch> well you can use the charm from GH right now - it deploys like a....charm....
[15:16] <hatch> ;)
[15:16] <hatch> arosales the only real change is the default port and some clarification in the documentation
[15:16] <hatch> so you can easy do that yourself
[15:17] <hatch> from the config options
[15:17] <hatch> if you wanted to get it going sooner than it gets into the store
[15:17] <arosales> hatch: good to know, and thanks for the work on it.
[15:17]  * arosales also looks forward to seeing it in the store
[15:17] <hatch> arosales np, I wanted to try and figure out how to do theming with the charm
[15:17] <hatch> so we can use your site as a test bed :)
[15:18] <marcoceppi> tvansteenburgh: let me know that change is pushed, I'll roll out 1.3.0 shortly after
[15:18] <tvansteenburgh> marcoceppi: kk
[15:19] <arosales> hatch: cool. I'll let you know how it goes.
[15:21] <hatch> arosales basically I'm not entirely sure how theming should work with the charm....it obviously needs to apply the theme to every instance as it scales up - but the theme can't be stored in the charm because it will be different for everyone. We also don't want them to require an extra data store somewhere to store it
[15:21] <hatch> arosales so I was hoping that I could use the juju storage somehow....?
[15:22] <arosales> hatch: how about a config set from a git hub repo?
[15:22] <hatch> arosales has this been solved with Discourse or Wordpress?
[15:23] <arosales> hmmm, marcoceppi your thoughts on theming in wordpress ^
[15:23] <hatch> well theming but also scaling a themed blog
[15:24] <hatch> because each unit needs the same theme applied
[15:24] <marcoceppi> hatch: wordpress lets you point to a wp-content repo
[15:24] <marcoceppi> which is a git/bzr repo that has the contents of that directory (aka themes and plugins)
[15:24] <hatch> marcoceppi right so that's an external url somewhere?
[15:24] <marcoceppi> basically
[15:25] <arosales> marcoceppi: does add-unit preserve the original/parent config?
[15:25] <marcoceppi> arosales: it's a repo, so it just gets branched again
[15:25] <hatch> that doesn't seem ideal - do charms not have access to Juju's storage instance?
[15:26] <tvansteenburgh> marcoceppi: pushed
[15:26] <marcoceppi> hatch: no
[15:26] <arosales> marcoceppi: but I don't need to config-set again on the add-unit to keep the same theme
[15:26] <marcoceppi> arosales: correct
[15:27] <arosales> marcoceppi: thanks
[15:27] <hatch> because we want to keep the charms fat (ghost is included in the charm) I feel that going out over the net again to request data from a source (which may change) is not the best possible story
[15:27] <arosales> hatch: so I would just provide a config to pull a theme from a github repo.
[15:27] <hatch> we should look into enabling storage support for charms
[15:27] <hatch> arosales yeah that's going to be the only option now I guess....but not a very good one IMHO
[15:28] <arosales> hatch:  I think the juju-core is working on that very feature this cycle.
[15:28] <hatch> you could end up with two units with two different themes if you updated the repo then scaled heh
[15:28] <hatch> arosales oh awesome
[15:29] <arosales> hatch: ya if you updated the gitrepo post deployment you would need to config set on each service
[15:29] <hatch> arosales the other story is that the user wants to customize the theme once deployed
[15:29] <arosales> but on deployment with the same config the services should have all the seame theme
[15:30] <hatch> yeah I'm just saying that it's very likely that someone updates the repo then scales without realizing
[15:30] <hatch> and now they get two themes depending on which unit they hit
[15:30] <arosales> well the original one wouldn't update unless the user took a specific action
[15:30] <hatch> exactly - so keeping the theme in juju would make it so that that could never happen
[15:31] <hatch> because it would only pull down the theme once, or when you tell it to
[15:31] <arosales> hatch: but an interesting point on passing down config to scaled services
[15:33] <arosales> hatch: well I think cofig works the same way. Juju only pulls the theme on deploy or config set
[15:33] <hatch> not if you scale
[15:33] <hatch> if you scale it'll go out and pull whatever  is on the end of that url
[15:33] <hatch> so if that content is changed you now have two units with different themes
[15:33] <arosales> hatch: ah, I follow you
[15:35] <hatch> yeah so atm a config option to a url will have to do, and I'm sure it'll be just fine for 80% of the use cases out there
[15:39] <egoist> hi
[15:39] <arosales> hatch: I think that would be helpful.
[15:39] <arosales> hatch: thanks again for the work on ghost
[15:39] <egoist> what hook is executed when you add unit to service
[15:39] <egoist> ?
[15:39] <hatch> no problem - and now that I have someone who's not me using it I will have to put some extra time on it :D
[15:40] <arosales> jcastro: note http://www.oscon.com/oscon2014/public/schedule/detail/34243 at oscon
[15:42] <jcastro> yep
[15:42] <jcastro> arosales, talking to leslie now on irc actually
[15:42] <arosales> jcastro: cool
[16:17] <egoist> what hook is executed when you add unit to service?
[16:19] <jose> egoist: all the hook sequence is executed in the new instance
[16:20] <jose> that is install, config-changed, start
[16:27] <egoist> jose: ok, but whgat with relation?
[16:27] <egoist> what*
[16:28] <jose> egoist: then it's install, config-changed, start, name-relation-joined, name-relation-changed
[16:29] <egoist> jose: ok, but every instance have relation data about new unit?
[16:30] <jose> can you give me an example? that way it'll be a bit easier to explain :)
[16:30] <jose> yeah, all instances should have data about the new unit
[16:30] <egoist> yeah
[16:32] <egoist> today i deploy mongo, to create replica set, and execute 'deploy ..... -n 3' and i want add new unit to this service. But this service was related to another instance. Problem is that this another instance don't have relation data about new unit
[16:34] <lazyPower> egoist: when you add a unit to service - there is a peer-relatioin hook that is fired on the units to do any peering
[16:34] <lazyPower> egoist: so 'every unit having data about teh new unit' is dependent on how the peering hook is built and what is sent over the wire via relation_set - in the case of mongodb, you get the full fange of credentials you would expect
[16:34] <lazyPower> IP:Port combo
[16:35] <egoist> oh ok o get it
[16:35] <egoist> lazyPower: Thank you very much
[16:35] <egoist> jose: Thank you very much
[16:36] <egoist> for yours help
[16:36] <lazyPower> egoist: there is a slight issue with deploying a  sharded / replicated server when relating to mongos
[16:37] <lazyPower> i've got some WIP to fix it, but its far from complete, and is kind of a hack at the moment.
[16:37] <lazyPower> just FYI if you're going to build a large production ready cluster.
[16:42] <Egoist> lazyPower: but if i remove relation, and add new unit to replica, is this will be work, new unit as another secondary host?
[16:43] <lazyPower> Egoist: so long as they share a replicaset key, they will be setup to replicate.
[16:46] <Egoist> lazyPower: ok, get it thanks
[17:28] <SIGILL> For my bachelor thesis I'd like to test 'virtual network embedding' algorithms in the wild, escpecially with latency in mind. Do you think there's room for improvement in juju regarding that? AFAIR juju just chooses "the first" machine when deploying a new service
[17:31] <SIGILL> The goal would be to optimize the latency and/or amount of resources used by services. But I'm not sure if latency is really a problem in the real world, because all machines are in the same datacenter or something.
[17:37] <lazyPower> SIGILL: sounds interesting. This would be better served in #juju-dev as thats where the core developers hang out.
[17:38] <lazyPower> SIGILL: sorry i dont have a better answer for you - however if you're GO for hacking on the juju-core GO code to optimize a provider based on resources/latency, i'm positive someone would be happy to review the work
[17:56] <SIGILL> lazyPower: ok, thanks — I asked the question a few days back in #juju-dev but got no answer
[17:56] <lazyPower> SIGILL: Have you tried emailing the list?
[17:58] <lazyPower> I'm pretty sure this is of interest to the core-developer base at large - considering its got implications of optimization on providers beyond what we have now. However they are pretty busy this sprint landing the roadmap we planned out a month ago. Sending it to the list will give the core team more time to respond than the catch/miss on IRC
[17:58] <SIGILL> not yet, that'd be my next step. i prefer IRC though
[17:59] <lazyPower> SIGILL: thing is, there's a pretty large overlap in timezones if you're US based. The project lead is a Kiwi and around when I'm headed to bed. So thats why I think you'll have better luck with the mailing list. Sorry you haven't gotten an answer yet though
[17:59] <lazyPower> its frustrating when trying to gain traction on interest
[17:59]  * lazyPower feels your frustration
[17:59] <lazyPower> been there, done that.
[17:59] <SIGILL> Nice, thanks for your help. I always hesitate to bother devs with my questions
[17:59] <lazyPower> Nah, we're a friendly lot
[17:59] <SIGILL> Heh, CEST it is...
[17:59] <lazyPower> bother away
[18:00] <lazyPower> SIGILL: juju@lists.ubuntu.com for reference.
[18:00] <SIGILL> wonderful — I'd be so glad to combine thesis, Go and juju
[18:01] <SIGILL> Got it
[18:01] <lazyPower> also, let me know when you start work. I'll blog about your progress
[18:03] <SIGILL> Oh nice — will do. If everything goes well that'll be in a few weeks
[18:03]  * lazyPower doffs hat
[18:03] <lazyPower> best of luck to you SIGILL, ping if you need anything
[18:23] <tvansteenburgh> stub: any tips on getting `make test` to work on the postgresql charm?
[19:16] <_mup_> Bug #1331151 was filed: 'juju destroy-environment' sometimes errors <pyjuju:New> <https://launchpad.net/bugs/1331151>
[19:32] <lazyPower> jamespage: ping
[19:51] <ahasenack> hi, I tried to deploy the hadoop cluster from the charm store, the bundle,
[19:51] <ahasenack> and got a notification saying
[19:52] <ahasenack> "Failed to load charm details.
[19:52] <ahasenack> Charm API error of type: no_such_charm "
[19:52] <ahasenack> and that's it
[19:52] <ahasenack> it doesn't tell me which charm it was looking for
[19:52] <ahasenack> oh, in juju-gui it's where I got that note
[19:53] <ahasenack> any clues?
[20:01] <achiang> what's the best practice for organizing source code + charm/yaml configs? specifically, a nodejs app. should i just stick the yaml into same dir as my node app?
[20:01] <achiang> https://github.com/achiang/openmotion is the repo, if it helps...
[20:04] <tvansteenburgh> achiang: one idea would be to make the charm deploy your app from github
[20:04] <tvansteenburgh> achiang: i did something similar with this meteor charm: https://github.com/tvansteenburgh/meteor-charm
[20:04] <achiang> tvansteenburgh: yeah, that's the plan. but the charm config still needs to live somewhere, so my question is where?
[20:05] <tvansteenburgh> the config and metadata yaml files should live in the root of the charm
[20:05] <achiang> tvansteenburgh: thanks, i'll take a look at your example
[20:47] <breeze411> Hello newbie here, how do i set the proxy for juju ? juju set-environment http-proxy=http://10.0.44.15:80  gives me error ERROR environment is not bootstrapped
[20:48] <tvansteenburgh> breeze411: `juju bootstrap` first
[20:49] <lazyPower> ahasenack: actually yes
[20:49] <lazyPower> ahasenack: i may have broken the bundle when i was resolving a related issue with hadoop yesterday
[20:49] <lazyPower> the lp:charms/hadoop now points to the trusty version of the charm.
[20:49] <breeze411> hmm the quick start doc syays juju --sync-tools and juju bootstrap ... This is a totally new juju env
[20:50] <ahasenack> lazyPower: debugged that error and it's an issue in juju-gui
[20:51] <ahasenack> lazyPower: I'm hitting other errors, though
[20:51] <lazyPower> ahasenack: Which bundle?
[20:51] <ahasenack> one I can workaround, it's a hostname call that failed
[20:51] <ahasenack> lazyPower: hadoop-cluster
[20:51] <lazyPower> ack, let me run a deploy on it and see what happens.
[20:51] <ahasenack> I don't have proper dns in this cloud, and the install hook at some point calls hostname -f
[20:51] <ahasenack> and that fails
[20:51] <ahasenack> so let me fix that by hacking /etc/hosts and then I can get to the second error about which I have no clue
[20:52] <lazyPower> ahasenack: which version of the hadoop charm as well? the precise version deploying hadoop 1 or the trusty version deploying 2.2?
[20:52] <ahasenack> lazyPower: precise
[20:52] <ahasenack> whatever is in the store, I don't know what it is deploying precisely
[20:53] <ahasenack> it deployed hive, hadoop-master, hadoop-slavecluster and mysql
[20:53] <ahasenack> and only mysql is green
[20:53] <breeze411> so to be clear first do juju bootstrap ? and then juju ync-tools ? sorry for the basic questions
[20:53] <ahasenack> hive has that hostname error which I'm fixing and I'll shortly run a retry
[20:57] <lazyPower> ahasenack: ok. i just fired off a quickstart against amazon
[20:57] <tvansteenburgh> breeze411: sync-tools followed by bootstrap is correct. i was just pointing out that you must bootstrap before using set-env
[20:59] <breeze411> Oh i see , thank you. So how do i set the proxy for sync-tools ? it doesnt seem to use the shell env set with http_proxy
[21:01] <ahasenack> lazyPower: hive is green, it was just the hostname -f error
[21:02] <ahasenack> previously I had this, but it didn't happen again:
[21:02] <ahasenack> 2014-06-17 19:54:59 INFO config-changed cp: cannot stat `/etc/hive/conf.dist': No such file or directory
[21:02] <ahasenack> now let me check the others, what's going on there
[21:02] <ahasenack> looks like it's hostname too
[21:02] <ahasenack> 2014-06-17 20:36:38 INFO install hostname: Name or service not known
[21:05] <lazyPower> ahasenack: wrt /etc/hive/conf.dist - it appears that its not creating it on the first run so there is a race condition in the charm somewhere if it resolvs on second run
[21:06] <ahasenack> lazyPower: ok
[21:07] <lazyPower> all of these issues are fair game for bugs against the charm however.
[21:07] <ahasenack> lazyPower: got this on hadoop-master now, after a resolved --retry
[21:07] <ahasenack> 2014-06-17 21:04:31 INFO config-changed cp: cannot stat `/etc/hadoop/conf.empty': No such file or directory
[21:07] <ahasenack> should I just issue another resolved --retry?
[21:07] <lazyPower> weird
[21:07] <ahasenack> this is the whole unit log:
[21:08] <ahasenack> http://pastebin.ubuntu.com/7660415/
[21:08] <ahasenack> at 2014-06-17 20:35:50 was the hostname error
[21:08] <ahasenack> which I fixed and ran a resolved --retry
[21:09] <ahasenack> that explains the time gap
[21:09] <ahasenack> between lines 19 and 20
[21:12] <tvansteenburgh> breeze411: have you tried https_proxy? i think sync-tools uses https
[21:12] <lazyPower> ahasenack: ok i'm still pending the bundle deployment
[21:12] <lazyPower> let me see if mine run into the same issues so we have common ground for starting the debug process
[21:13] <ahasenack> install_base_packages() didn't even run
[21:14] <lazyPower> ahasenack: it was skipped?
[21:14] <ahasenack> hostname -f is called in configure_hosts()
[21:14] <ahasenack> that was the call that failed before
[21:14] <ahasenack> I fixed /etc/hosts so hostname -f doesn't fail
[21:14] <ahasenack> ran resolved --retry
[21:14] <ahasenack> and somehow it didn't retry, it didn't run that again...
[21:15]  * lazyPower blinks
[21:15] <lazyPower> somethings not right
[21:15] <lazyPower> if it skipped an entire hook or logic path in the charm
[21:16] <ahasenack> the install hook runs configure_hosts, configure_sources, install_base_packages, install_optional_packages, configure_hadoop, configure_tmp_dir_perms
[21:16] <ahasenack> hostname -f is in configure_hosts
[21:16] <ahasenack> it failed
[21:16] <ahasenack> see my previous pastebin
[21:16] <ahasenack> then I ran resolved --retry
[21:16] <ahasenack> and the first log entry in the pastebin after the failed hostname is "Installing optional packages..."
[21:16] <lazyPower> ahasenack: everything here just greend on a public cloud. seems that the hostname woes are def. a root of the issue
[21:16] <ahasenack> and that comes from install_optional_packages
[21:17] <lazyPower> ahasenack:  i have a prelim DNS charm that may help some of this in your environment.
[21:17] <lazyPower> ah wait, no - it wont do the relations until the service is installed. so its a moot point
[21:17] <ahasenack> interesting that configure_hosts, the first thing it calls, tries to fixup /etc/hosts
[21:18] <ahasenack> the whole hook is run with set -e
[21:25] <ahasenack> I ran the install hook via juju run now
[21:25] <ahasenack> I'll debug this some other time, introduce a failure in an install hook, let it fail, fix the failure, run resolved --retry and see where juju picks it off
[21:26] <ahasenack> that was very weird that it didn't try the install hook again
[21:26] <lazyPower> yeah
[21:26] <lazyPower> resolved -r should re-run the failed hoo
[21:26] <lazyPower> *hook
[21:26] <lazyPower> i call schenanigans
[21:27] <ahasenack> yep
[21:27] <ahasenack> well, I'm on 1.19.x
[21:27] <ahasenack> anything could happen :)
[21:28]  * ahasenack runs terasort
[21:29] <leftyfb> Any idea why the nagios -> wordpress relationship only monitors ssh? Shouldn't it be monitoring nginx as well as load, users, disk space, total processes, etc?
[21:30] <leftyfb> same with monitoring a mysql charm, it should be monitoring the mysql daemon
[21:31] <leftyfb> I'm going to guess it's because we don't have snmp or the agent install on the individual charms ... but I would assume if you build a relationship between the charms, it should install and configure the necessary packages (snmp)
[21:31] <lazyPower> leftyfb: it leverages NRPE to make those connections.
[21:31] <lazyPower> i'm not positive about nginx monitoring, etc. but the NRPE charm does populate more than just SSH
[21:32] <lazyPower> leftyfb: those are however excellent feature requests to file against the NAGIOS charm.
[21:33] <leftyfb> lazyPower: I just deployed nagios with connected to a wordpress bundle as well as monitoring the juju-gui charm itself. Besides localhost, the other charms are only monitoring SSH
[21:33] <lazyPower> leftyfb: in its current incantation, you use NRPE to get those metrics.
[21:34] <leftyfb> lazyPower: so that's something I have to configure manually
[21:34] <lazyPower> if you want to tweak it from the default setup, correct.
[21:35] <leftyfb> "Usage
[21:35] <leftyfb> This charm is designed to be used with other charms. In order to monitor anything in your juju environment for working PING and SSH, just relate the services to this service. In this example we deploy a central monitoring instance, mediawiki, a database, and then monitor them with Nagios"
[21:35] <leftyfb> so the default is to only monitor ping and ssh for the charms in it's relationships
[21:36] <lazyPower> It appears that way. You can specify additional configuration through the config parameter on nagios - or by using NRPE + config.
[21:39] <jamespage> lazyPower, evening
[21:39] <lazyPower> jamespage: greetings. Did you have a chance ot read the email i sent you earlier?
[21:40] <jamespage> lazyPower, yes - trusty ntp charm right?
[21:40] <lazyPower> indeed
[21:40] <lazyPower> its half promulgated. looks like the branch alias was defined before the repository was fully promulgated. A symptom of not specifying -s when doing juju promulgate charm - that has an existing precise branch.
[21:40] <jamespage> lazyPower, I think the ganglia* ones are in the same state
[21:41] <lazyPower> jamespage: i ran into this when i botched the hadoop promulgation to trusty
[21:41] <jamespage> lazyPower, I pushed the branch but did not promulgate intentionally as I'd not added tests
[21:41] <jamespage> lazyPower, if that's not a hard requirement then all three of those charms work just fine on trusty :-)
[21:42] <lazyPower> jamespage: yeah, we *really* need those tests
[21:43] <jamespage> lazyPower, yeah - I know
[21:43] <lazyPower> even if its stand up, validate services are running - with some follow up. I dont want to set that precident, but tests are a required mechanism to make it into trusty
[21:43] <lazyPower> :|
[21:43] <lazyPower> I don't like being the bearer of bad news
[21:44] <lazyPower> ok, i just pinged marco on this - and our bare minimum is unit tests. if you can drop in some units on that puppy you're g2g
[21:47] <lazyPower> jamespage: thanks for the follow up.
[21:47] <jamespage> lazyPower, sure
[21:55] <lazyPower> jamespage: for now i'm going to unpromulate the trusty version of the NTP charm so its not interfearing with the API requests. Its causing all kinds of fun artifacting with the GUI - https://bugs.launchpad.net/juju-gui/+bug/1331202
[21:55] <_mup_> Bug #1331202: Incomplete Charm data causes artifacting in the GUI <juju-gui:New> <https://launchpad.net/bugs/1331202>
[21:55] <jamespage> lazyPower, please do
[21:58] <jamespage> lazyPower, interestingly the charm store was ingesting that fine - you just had to address it like cs:~charmers/trusty/ntp
[21:58] <jamespage> but that would appear no longer true
[21:58] <lazyPower> jamespage: thats a work around to a larger problem
[21:58] <lazyPower> during the promulgation command, if you dont specify the series when you prom it - it moves the branch tip before it promulgates the series branch
[21:59] <lazyPower> which in turn causes the owner to return as 'charms' - because promulgate fetches that branch tip instead of the lp:~charmers/charms/foo/bar
[21:59] <marcoceppi> lazyPower: can you open a bug against charm-tools that promulgate will require a series going forward and not assume precise?
[21:59] <lazyPower> its a hairy thing that i only half understand.
[22:01] <lazyPower> marcoceppi: https://bugs.launchpad.net/charm-tools/+bug/1331211
[22:01] <_mup_> Bug #1331211: require a series flag on promulgate <papercut> <Juju Charm Tools:New> <https://launchpad.net/bugs/1331211>
[22:01] <marcoceppi> lazyPower: thanks, I'll get that in the 1.3.0 release