[01:15] <themonk> hi all
[01:16] <themonk> can anyone tell me when i should use peer?
[01:20] <jose> themonk: afaik it's when the service will relate to itself
[01:28] <lazypower> themonk: whenever you ahve scale out situations. as in you go from a single node to 2+
[01:28] <lazypower> those nodes are by defintion peers of one another. this is handy for say exchanging cookie secrets in webapps
[01:31] <themonk> another question if 2 charm require each other, do i use different name for same relation or same name?
[01:31] <themonk> hello lazypower :) how are you?
[01:34] <themonk> hello jose :)
[01:34] <jose> hey themonk!
[01:35] <jose> it's the same relation I think
[01:35]  * jose hasn't looked too much into peer relations
[01:36] <themonk> jose, forgate peer talking about normal relation :)
[01:36] <themonk> jose, forgate peer talking about normal relation  now:)
[01:36] <jose> oh
[01:37] <jose> themonk: what do you specifically mean by relation name?
[01:38] <lazypower> themonk: its all dependent on the interface you use. its dictated by the provides: and requires: directive in your metadata.yaml
[01:38] <lazypower> and i'm doing well, thanks :)
[01:41] <themonk> jose, lazypower, charm1->provides->relname1->interface1 and charm2->requires->relname1->interface1  then charm2->provides->relname2->interface2 and charm1->requires->relname2->interface2
[01:41] <themonk> this is the case
[01:43] <themonk> or will i do it like this: charm1->provides->relname1->interface1 and charm2->requires->_relname1->interface1  then charm2->provides->relname2->interface2 and charm1->requires->_relname2->interface2
[01:44] <jose> yeah, I think that's fine
[01:44] <themonk> jose, which one
[01:45] <jose> both are the same, I don't see any difference
[01:45] <lazypower> you've got a circular reference in relationships
[01:45] <lazypower> unless they need 2 specific defined interfaces
[01:45] <lazypower> you only need the provides/requires one way
[01:45] <lazypower> its a bidi comunication interface
[01:45] <lazypower> as in you can set on both sides, and receive on both sides. so you're good 2 go to exchange whatever data you need to send/receive across teh wire with just the singular interface
[01:46] <lazypower> these aren't governed by RFC's they are loosely coupled/typed relationships. arbitrary variables and values
[01:46] <jose> should we do a charm school about relations?
[01:46] <themonk> lazypower, hmm
[01:47] <lazypower> jose: there are several already
[01:47] <themonk> jose, yes that will be great
[01:47] <lazypower> juju.ubuntu.com/videos
[01:47] <jose> themonk: see ^
[01:47] <themonk> ok thanks man :)
[01:47] <lazypower> ugh
[01:47] <lazypower> its not clearly labeled as "relationships"
[01:48] <jose> who could've done that? *cough* jcas *cough* tro *cough*
[01:48] <lazypower> its in one of the getting started videos
[01:48] <lazypower> so it encompases more than just relationships
[01:48] <lazypower> i'm sorry i dont have a direct video link for you
[01:48] <lazypower> i'll raise the issue at tomorrow's standup that we need to do a video over relationships
[01:49] <lazypower> themonk: there's also an open call to 'what should we do next' on the list - which we'd love to have your feedback if you've got grey areas that a charm school would help with
[01:49] <lazypower> we're always upping our game, one week at a time, on getting new videos out there for our user base to really grokk what we're doing with juju
[01:49] <lazypower> so make sur eyou're subbed to juju@lists.ubuntu.com to get in on all the community voting action
[01:50] <themonk> hmm ok i will
[01:51] <themonk> AFK 15 min
[03:48] <l1fe> quick question: i've been creating and destroying some juju environments
[03:49] <l1fe> however after destroying an environment, juju-mongodb is leftover
[03:49] <l1fe> when i try to purge/auto-remove it
[03:49] <l1fe> an upstart script somewhere keeps on redownloading the package and reinstalling mongodb
[03:49] <l1fe> how the heck do i stop this?
[03:51] <l1fe> i'm currently on juju 1.19.4 running on maas with trusty nodes all over
[03:58] <l1fe> n/m...had to remove the upstart scripts in /etc/init and then purge
[04:35] <lazypower> l1fe: sounds bugworthy. can you file a bug against juju-local about that?
[08:06] <mwhudson> 237.872  + juju deploy --to 0 nova-compute237.873  ERROR cannot upload charm to provider storage: Head http://10.254.30.125:8040/: dial tcp 10.254.30.125:8040: connection refused
[08:06] <mwhudson> would this be a race condition?
[08:06] <mwhudson> it's in a script that does more or less "juju bootstrap; juju deploy --to 0 nova-compute"
[08:07] <mwhudson> (manual provider)
[11:33] <schegi> anyone here who could help with a cloud-init-nonet issue during boot??
[13:03] <voidspace> https://github.com/juju/testing/pull/17
[13:27] <l1fe> sorry to be a bother, but i'm trying to deploy juju-gui on my juju environment, it every time i try, my node stays in pending status
[13:27] <l1fe> i'm deploying on a MAAS controlled, 4 node environment
[13:28] <l1fe> bootstrap worked, relatively well, although i had to manually go in an create a /var/lib/juju/nonce.txt in order for it to not timeout
[13:28] <l1fe> when i do a "juju deploy juju-gui" it kicks off the process fine, and in maas it shows the node as going from ready to "allocated to root"
[13:29] <l1fe> but ultimately nothing is ever done on the node
[13:30] <l1fe> also, nothing really shows up in the all-machines.log in /var/log/juju
[16:35] <cory_fu> So, jose commented on my choice of using a juju run script for setting admin passwords in the Apache Allura charm (https://bugs.launchpad.net/charms/+bug/1314699), but I'm still not convinced that having a config option is the right approach for admin passwords.
[16:35] <_mup_> Bug #1314699: New charm - Apache Allura <Juju Charms Collection:Incomplete> <https://launchpad.net/bugs/1314699>
[16:37] <jose> cory_fu: hey, I recommended that because juju set is the default for any options you can configure, I would personally not have it as a run script
[16:38] <lazypower> cory_fu: didn't you email the list about it?
[16:38] <cory_fu> Yes.
[16:38] <lazypower> was there any traction from your list mailing that was pro/against?
[16:38] <jose> hmm, i didn't see that one
[16:39] <lazypower> i think its a unique approach - and it's definately work further investigation / discussion.
[16:39] <cory_fu> It kind of went off on a tangent about password-typed config options
[16:39] <lazypower> s/work/worth/
[16:39] <cory_fu> But I'm not convinced that passwords make sense as options at all, regardless of whether there's a password type
[16:40] <lazypower> if they're a salted hash in the database - whats the argument against that?
[16:40] <cory_fu> For one thing, the passwords can be changed outside of Juju, leading to a mismatch between Juju's idea of the password value and the actual password value
[16:40] <lazypower> sarnold: ping
[16:41] <cory_fu> I think Juju options make sense for things that can't be configured from within the application, but trying to manage application settings from Juju seems incorrect to me.
[16:41] <cory_fu> Honestly, it would be better if the application in question handled the initial admin password itself, on first run.
[16:41] <lazypower> cory_fu: whys that? we have several charms that support application configuration.
[16:42] <cory_fu> lazypower: So how do you handle the possibility of Juju resetting options that were changed from within the application due to Juju having an outdated idea of what the value should be?
[16:43] <lazypower> cory_fu: within the domain of what we're talking about, if juju has an idea of the application configuration, it makes sense to me to change those within juju and not the application.
[16:44] <lazypower> what's being described is very much a smiliar problem that exists with all CM frameworks - if you deploy msyql and tweak your my.cnf by hand - its going to be lost on the next convergence.
[16:44] <cory_fu> And if Juju doesn't cover all of the settings, you end up in a weird place where you should use Juju to set some of the options, and the application others, even if those options are on the same page within the application.
[16:44] <cory_fu> In Allura's case, there are three default users set up.  So you would presumably set the "root" user's password via Juju, but none of the others?
[16:45] <jose> you can have three config options
[16:45] <cory_fu> Though that's not as bad as being in a situation where you have to remember "the 5th option down on the settings page shouldn't be touched, since it's handled by Juju"
[16:46] <lazypower> cory_fu: so a lot of this sounds like it would be well served by juju-actions when they land. Such as setting up username/passwords
[16:46] <cory_fu> jose: That seems like config.yaml bloat.  :)  What about the other users that will later be added?  And what if the admin removes the default users and creates a new admin user?
[16:46] <lazypower> that prevents it from being a configuration option and exposed
[16:46] <cory_fu> lazypower: +1 and that's what I was using the run script as a makeshift version of.  :)
[16:47] <lazypower> and exposes an option for you to add/remove users with juju through an action.
[16:47] <lazypower> cory_fu: oh i'm pretty much for your implementation
[16:47] <lazypower> cory_fu: i'm playing devils advocate here so its being fleshed out in everybody's face so when we start doing more of this, i can point to the irc log and say "we talked about it on the list and here - i like this better +1 for participation"
[16:47] <cory_fu> jose: Just to be clear, I'm not entirely averse to adding a "root-password" option to the Allura charm.  Just raising it for discussion.  :)
[16:48] <cory_fu> lazypower: Good
[16:49] <cory_fu> That's also why I raised it here.  I'm currently adding the option to the charm, anyway, though I'm going to leave the run scripts in (since I basically need them to set the password anyway)
[16:49] <lazypower> cory_fu: nah leave the run script
[16:49] <lazypower> what you've got makes all the sense in terms of domain specific configuration
[16:49] <lazypower> the service doesn't expose a default password that can be hacked
[16:50] <lazypower> i wont nack it for a missing password config value - especially since as you pointed out, there are 3 users with only 1 configuration option.
[16:50] <lazypower> bcsaller: will you have a chance to review allura this week? Cory's got a really interesting implemenation that could set the model for charm security moving forward.
[16:51] <cory_fu> It also uses the services framework (though it's probably not the best poster-child)
[16:51] <lazypower> well - i know that actions are going to land in the not so distant future
[16:51] <lazypower> so this is a really good stop gap / prototype implementation until we get 'juju actions'
[16:52] <lazypower> its the first charm that i'm aware of that will have a juju-run based config step too, which i like. its exposing more usefuleness to juju-run
[16:52] <cory_fu> jose: What was that charm I gave you a +1 on recently?
[16:52] <lazypower> HAHAHA cory_funo retroactive -1's!
[16:52] <lazypower> j/k, nack away ;)
[16:53] <jose> cory_fu: tracks I think?
[16:53] <cory_fu> No, I think it started with a C?
[16:53] <lazypower> chamilio
[16:53] <cory_fu> I wish there was a way to see my past activity on Launchpad
[16:53] <cory_fu> lazypower: That's the one.
[16:53] <jose> I've been working in many charms lately
[16:54] <cory_fu> That would be awesome to convert to the services framework, since it would make all of the effort of having to maintain the dot-files go away
[16:54] <lazypower> cory_fu: services framework?
[16:54] <cory_fu> jose: You're a charming monster.  :)
[16:54] <lazypower> he's Charmbot 5000
[16:54] <jose> BTW, I do like the approach you have and believe it's worth a Discussion
[16:55] <jose> yeah, see my /nickserv info
[16:55] <cory_fu> lazypower: The thing that we have proposed for merging into charmhelpers, and that I use in the Allura charm, that we developed while working on Cloud Foundry
[16:55] <lazypower> Ah, i saw teh inclusion of custom helpers
[16:55] <lazypower> i didnt dive too deep into it, when i reviewed allura it was a pretty fresh cut
[16:55] <lazypower> you'e since remixed the charm haven't you?
[16:56] <cory_fu> lazypower: Yeah, quite a bit
[16:56] <lazypower> that must be a post-review inclusion
[16:56] <lazypower> if bcsaller doesn't ping back about being able to review allura, ping me tomorrow and i'll dive into it
[16:56] <bcsaller> I see the branch, but I don't see it in the review queue
[16:57] <cory_fu> lazypower: The services framework, in a nutshell, is a system to automatically manage the complexity of dealing with figuring out at what point you have all the info you need to actually set up the software, which could come from disparate sources such as config, relation data, etc, and could end up being completed in any of a number of hook invocations
[16:57] <lazypower> bcsaller: the bug is incomplete
[16:57] <lazypower> https://bugs.launchpad.net/charms/+bug/1314699
[16:57] <_mup_> Bug #1314699: New charm - Apache Allura <Juju Charms Collection:Incomplete> <https://launchpad.net/bugs/1314699>
[16:58] <cory_fu> bcsaller: I'm about to update said bug, as I've made some changes
[16:58] <lazypower> cory_fu: whoa. thats awesome
[16:58] <lazypower> so you define the required params, and once everything in this dictionary is complete, we say "Ok return true and configure now"
[16:58] <bcsaller> lazypower: we did try to sell you all on this in Vegas :)
[16:59] <lazypower> bcsaller: i probably said shut up and take my money, then forgot i voted for it.
[16:59] <cory_fu> However, jose, I wasn't able to reproduce that issue with the mongodb hook error, nor even see how it could have occurred, since it could only happen if the pymongo library was broken
[16:59] <bcsaller> ha
[16:59] <cory_fu> As in, not properly installed
[16:59] <lazypower> bcsaller: you guys are like kickstarter - too many good ideas, me with too little money
[17:00] <bcsaller> just waiting for fb to dump 19M on us
[17:00] <lazypower> cory_fu: moving forward, when you want reviews - make sure the bug is "Fix Comitted" or "new"
[17:00] <lazypower> otherwise it gets scrubbed from teh queue
[17:00] <cory_fu> lazypower: Yeah, I know.  I was still in the process of making fixes
[17:00]  * lazypower flips tables
[17:00] <cory_fu> I literally *just* pushed up my last fix.  :)
[17:00]  * lazypower puts it back
[17:01] <lazypower> k
[17:02] <cory_fu> lazypower: Where are the IRC logs posted at?
[17:02] <jose> cory_fu: I'll have to check once I'm back home
[17:02] <jose> irclogs.ubuntu.com
[17:03] <cory_fu> lazypower: http://imgur.com/gallery/5VDqD3L
[17:04] <lazypower> cory_fu: you sir, have taken it to the next level.
[17:08] <sarnold> lazypower: pong :)
[17:09] <lazypower> sarnold: we had abit of a discussion up above between cory, jose and myself. From a Sec Audit perspective, how do you feela bout charms using isolated scripts to perform user/password management in leu of a configuration option on a charm?
[17:12] <sarnold> lazypower: heh, nice can of worms we've got here :)
[17:12] <lazypower> isn't it though?
[17:13] <lazypower> if you've got any input on the matter, i'd love to hear your opinions.
[17:14] <sarnold> ideally we wouldn't even have passwords -- they have to be stored somewhere, whether it is in mongo or a plain text file in ~/.juju/ somewhere. the danger of storing them in ~/.juju is that someone might check them into git as an easy way to 'distribute' juju control amongst a team..
[17:15] <sarnold> so it'd be wonderful if services that support key-based authentication could use keys, instead, but that's unrealistic to hope for that; some services just require passwords.
[17:15] <lazypower> sarnold: this is about a service thats being deployed with juju - in the event of apache allura - it come swith a root, a git, and a reviewer user (paraphrasing) - and we need to set them up in the application. Key based auth is not an option unfortunately - its a webapp.
[17:16] <sarnold> I would much prefer a centralized place to store them all, and using the juju set functionality is easily flexible enough to handle them all, but I further hope admins wouldn't actually need to set (or see) passwords as a regular part of business
[17:17] <sarnold> lazypower: ah; I had expected something more like pgsl accounts for applications, these are users "within" an application.
[17:17] <sarnold> lazypower: you just added some nuts to this can of worms :)
[17:17] <lazypower> correct. the 3 users are required to finalize a core installation.
[17:17] <lazypower> haha, well - i was thinking this was going a bit askew based on your answer
[17:18] <lazypower> and i'm also known as the master of no-context
[17:18] <sarnold> .. and so firing up e.g. juju set just to change the reviewer password seems heavy-handed :)
[17:18] <cory_fu> sarnold: Like I said above, ideally the application itself would manage the admin user / password and juju wouldn't have to get involved, but in this case (and others), the application needs a "bootstrap" user / password that can't be set up properly from within the application
[17:18] <sarnold> lazypower: well, it's certainly my fault for not reading -all- of scrollback, just enough to jump to the wrong conclusion :)
[17:19] <cory_fu> Really, once the admin password is set, it should be managed from within Allura, which is another argument against having it as a config option, IMO
[17:19] <sarnold> yeah, that makes sense
[17:21] <cory_fu> But I can also see having Juju actions for managing admin users as a convenience option.
[17:21] <sarnold> though, if we think about e.g. apache httpd; it has a pluggable authentication and authorization mechanism, different kinds of authetication can be required, and user/passwords can be handled via e.g. htpasswd or ldap or gdbm or any other number of tools; I might expect a "protected filesharing with apache" charm to provide configuration switches for the different mechanisms, and perhaps even a pre-seeding mechanism for the htpasswd method..
[17:23] <cory_fu> Exactly.  And Actions would seem like an ideal candidate for managing that.  Using a config option would seem wrong to me.
[17:23] <sarnold> so I might also expect that an allura charm could provide a way to preseed the values with a plain text file -- when they eventually grow a pluggable auth system to use e.g. github users or something, it might not be necessary..
[17:25] <cory_fu> Yeah.  Allura has some support for LDAP, so that's probably the right direction to go, long-term
[17:25] <lazypower> sarnold: that all feeds into actions being the path forward.
[17:25] <lazypower> do i take that as a vote pro script, nack on config?
[17:33] <marcoceppi> cory_fu: lazypower this sounds like it's best used with juju actions
[17:33] <marcoceppi> the password stuff
[17:33] <marcoceppi> I'd support a juju run to set password
[17:33]  * marcoceppi looks at charm
[17:33] <marcoceppi> It
[17:33] <marcoceppi> 's definitely not a blocker
[17:34] <lazypower> agreed
[17:34] <lazypower> i want to see more traction around this. i'm pretty sad that the conversation got derailed on the mailing list wrt a password field type. I think this warrants a follow up post to the thread
[17:35] <cory_fu> I can make a follow-up post.
[17:35] <cory_fu> And link to this discussion
[17:35] <lazypower> cory_fu: sounds good
[17:36] <cory_fu> Regarding the transient AttributeError, I was completely unable to reproduce it, nor come up with a reason why it might have happened or a way to prevent it in the future.  Would that be a blocker, or can we chalk it up to one of those things?
[17:37] <lazypower> if its missing, it looks like maybe pypi had a hiccup?
[17:37] <cory_fu> But how did the step that actually installed it not fail?  And how did it fix itself magically?
[17:37] <cory_fu> It makes no sense to me
[17:37] <lazypower> if it had a hiccup and pip install didn't exit 1 - it makes sense that retrying ti worked.
[17:38] <lazypower> i dont know if pip exits > 1 if an install fails, do you?
[17:38] <cory_fu> Re-running the relation-changed hook would not have installed pymongo.  That only happens in the install hook
[17:38] <lazypower> hmm
[17:38] <lazypower> well thats weird
[17:38] <cory_fu> Also, pymongo itself imported ok, it was only when accessing the MongoClient attribute that it barfed
[17:39] <cory_fu> I even tried looking at the pymongo source to come with an idea, and see nothing obvious
[17:39] <lazypower> i'm going to have to blame this one on khai
[17:39] <cory_fu> khai?
[17:40] <lazypower> marco wrote an RFC about khai being the root of all problems
[17:40] <cory_fu> What does he have against some random village in Pakistan?
[17:41] <marcoceppi> Khai is a person not a village
[17:41] <marcoceppi> though I feel bad for everyone in that village now
[17:42] <lazypower> marcoceppi: at some point you need to send me that RFC so i can mirror it and point people at it when i make that reference.
[17:43] <marcoceppi> lazypower: https://github.com/marcoceppi/547-khai
[17:43] <lazypower> YES!
[17:44] <marcoceppi> I need to update it, it's expired
[20:32] <tvansteenburgh1> HTTP 547, "Use in an abundantly conservative manor" https://github.com/marcoceppi/547-khai/blob/master/draft-547-http-547.nroff#L66
[20:32]  * tvansteenburgh1 imagines an abundantly conservative large country house, with much surrounding land.
[21:26] <alesage> trying to bootstrap a local env and finding that juju is trying to connect to mongodb at 37017 , my apt-get installed mongodb-server listening on 27017, something I'm doing wrong?
[21:27] <sarnold> alesage: juju supplies its own mongo, no?
[21:29] <alesage> sarnold, so I'm told, but juju bootstrap seems to want me to install one: http://pastebin.ubuntu.com/7738856
[21:30] <sarnold> alesage: ah, then I'll return to the background :) good luck
[21:31] <alesage> sarnold, thanks you gave me hope :P
[21:32] <sarnold> alesage: hooray! :)
[21:56] <lazypower> alesage: did you have the mongodb package instaleld prior to installing juju-local?
[21:57] <lazypower> sinzui: are we still providing support for running mongo in paralell with an existing mongodb install? i know this was a pain point in the past - not sure if it ever got resolved.
[21:57] <alesage> lazypower, don't think so
[21:57] <lazypower> alesage: initctl list | grep juju - can you pastebin the output of that command for me?
[21:58] <alesage> lazypower ok in process on another bootstrap attempt, one min
[21:59] <alesage> lazypower coming up blank fwiw
[21:59] <lazypower> dpkg -l | grep juju-local
[22:00] <alesage> lazypower, blank again, sensing a theme
[22:00] <lazypower> alesage: sudo apt-get install juju-local, then re-try the bootstrap with local provider
[22:01] <alesage> lazypower, attempting thx
[22:02] <alesage> lazypower, no errors thanks
[22:02] <alesage> "Starting Juju machine agent"
[22:02] <lazypower> alesage: np. Glad we got it sorted :)
[22:02] <lazypower> alesage: if you dont mind me asking, were you looking through the juju docs or did you just dive right into using juju?
[22:03] <alesage> lazypower, forgive the noobishness but I also have a 'local' env set up in .juju/environments, is this config 'parallel' to the local provider I've just installed??
[22:03] <alesage> lazypower, dove in with a howto from a colleague
[22:04] <lazypower> alesage: yep. local is an environment that deploys locally using LXC on your workstation. its intended for rapid deployment prototyping / charm development
[22:04] <lazypower> the idea is that you can export a bundle from your local environment, and move that to any public cloud that we support, such as hp-cloud, aws, joyent, etc.
[22:04] <alesage> lazypower, makes sense--just trying to clarify if a 'local' env named in my config would require that juju-local package to be installed?
[22:05] <lazypower> Correct, unless you changed the environment type
[22:05] <alesage> lazypower, ok thanks again
[22:05] <lazypower> as it were, if you feel like beign obscure between names that are meaningful to you - you could change it to type: ec2
[22:05] <lazypower> and plug in some AWS credentials
[22:06] <lazypower> and your 'local' environment is now an AWS provider based environment.
[22:06] <lazypower> which is a good point, i haven't asked about that in the past....
[22:08] <alesage> I see