#ubuntu-ensemble 2011-08-01 <SpamapS> jcastro: hahahahah no I made that for the Cloud Days presentation like 3 months ago. ;) <jcastro> SpamapS: I didn't know about it before <jcastro> I am going to steal it <SpamapS> jcastro: the one on the wiki is svg ... make sure to steal *that* :) <jcastro> We should ask someone on design to prettyfy it <SpamapS> yeah that would be cool <SpamapS> I'm hesitant to make the marketing assets more polished than ensemble itself tho ;) <jcastro> well, I see people are using it and reporting the annoyances <jcastro> robert collins just filed a few <niemeyer> Good morning all <niemeyer> fwereade: Morning <_mup_> ensemble/trunk r288 committed by djennings@example.org <_mup_> Merged fix-status-scope branch from Clint [r=bcsaller,fwereade] <_mup_> Fixes ensemble status to work with multiple scope filters as per the <_mup_> help documentation. Tests were also adapted to reflect the arguments <_mup_> one should expect from argparse. <kim0> Morning all <niemeyer> kim0: Morning! <kim0> niemeyer: hey .. oh you're up so early :) <niemeyer> kim0: Yeah, I'm actually about to step back to try to sleep some more <kim0> have some nice rest then <niemeyer> Just couldn't sleep for a while, and decided to get up and do something useful <niemeyer> Thanks, see you soon :) <kim0> :) <fwereade> niemeyer: hey! totally missed you, don't expect people on IRC at this time :p <fwereade> nice w/e? <fwereade> and hey kim0 ;) <kim0> fwereade: Hey Morning o/ :) <raphink> I think one should expect people on IRC at about any time <raphink> given there's people who live all around the globe (and even have internet access) <fwereade> I have a recollection that "fix released" currently means "merged into trunk" rather than actually "released" -- can anyone confirm? <fwereade> if so I can mark a couple of bugs "fix released", and tidy up kanban a little <kim0> raphink: yeah pretty much :) <noodles775> Hi! Does anyone know if m_3 's psql branch is near ready for inclusion in principia ? https://bugs.launchpad.net/principia/+bug/803841 <_mup_> Bug #803841: Formula needed (postgresql) <new-formula> <Ensemble Formulas:In Progress by mark-mims> < https://launchpad.net/bugs/803841 > <kim0> SpamapS: oh nice work on the graphic at http://askubuntu.com/questions/55179/what-is-the-purpose-of-the-bootstrapping-instance-ensemble :) <kim0> wonder if that should be added to the bootstrapping section of the user-tutorial <hazmat> g'morning <fwereade> hazmat: heyhey <hazmat> fwereade, how's your day so far? * hazmat tries to figure out if there's a way to see what the service-config settings are for a service <fwereade> hazmat: ah, not too bad... I think I may have actually just run out of work for the moment, I was about to take a look at some reviews <fwereade> once I get confirmation from andres that cobbler-launch-machine works for him I'll have anothe 3 branches to propose <hazmat> fwereade, nice re cobbler, that's awesome <fwereade> and you; nice weekend? <fwereade> hazmat: there are a few more things we need to think about but I've been concentrating on getting parity with the spike branch <hazmat> fwereade, quiet weekend, don't remember much of it ;-) spent some time cutting a computer case with with a rotary blade so it could fit some 5x3 drive enclosures, also picked up a 4g hotspot device till my new internet connection is setup (my old isp sucked and 'accidentally' dropped me when i made an unrelated request). <hazmat> fwereade, do you have a local cobbler instance for testing or is it based on extraction from the spike w/ mocking? <fwereade> my local cobbler is, er, partially working <fwereade> most stuff I can test directly, but actually completing a netboot install of oneiric has had a long series of hilarious and bizarre problems <fwereade> I might grid my lions and have another go shortly but it's a dispiriting prospect ;) <fwereade> btw, hazmat, I was going to take a look at lp:~hazmat/ensemble/security-groups, but I'm a bit confused about its status <fwereade> it claims to depend on lp:~hazmat/ensemble/security-connection... which lp thinks exists, but bzr doesn't <hazmat> fwereade, it depends on lp:~hazmat/ensemble/security-connection-redux <hazmat> fwereade, i'm not sure what happened to security-connection branch, but lp doesn't like it.. the revisions are the same though <fwereade> hazmat: heh, ok, thanks :) * hazmat pokes at fwereade fds testing work * fwereade wishes to make clear he has no idea what he's doing, and really appreciates fixes and explanations ;) <hazmat> fwereade, i'm curious to see if we manually run the gc how the numbers change <fwereade> hazmat: good idea <hazmat> fwereade, alternatively to scanning all fds, it might have been easier to just scan the /proc/pid/fd <hazmat> oh.. that's what's its doing <hazmat> 'self' <fwereade> hazmat: that's what I do, is there some code lying around still doing things the dumb way? <fwereade> hey, I don't think I fixed ... er ... the branch it was originally flagged on, whatever it was <hazmat> fwereade, yeah my mistake, looks fine, i hadn't seen the 'self' syntax before <fwereade> (and it turns out I did fix lp:~fwereade/ensemble/storage-file-objects :)) <fwereade> hazmat: cool :) <hazmat> one other issue, if a test fails and had temp files/dirs they stick around post test run <hazmat> not related to the branch, just a general test issue <fwereade> hazmat: I view that as a feature, myself: when a test fails I really like to be able to look at the problematic temp files ;) <hazmat> fwereade, so this is actually pointing out alot of failures in things that are okay <hazmat> fwereade, the addCleanup calls from lib/mocker.py run after teardown <hazmat> which take care of self.makeDir, self.makeFile afaicr * hazmat double checks <fwereade> hazmat: gaah! nice catch :D <hazmat> mocker isn't deferred aware so the ordering is a little odd at times <fwereade> hazmat: I assumed teardown happened in tearDown, but you know what they say about assumptions :) <fwereade> (they make an ass of u and mptions... hmm, doesn't quite work like that) <hazmat> fwereade, i made a one line change to fix it against spurious tests, in the modified _run, if methodName=="tearDown": self.addCleanup(self._diff_fds) <hazmat> spurious failures that is <fwereade> hazmat: awesome, how much nicer does it come out? <hazmat> fwereade, not catching normal operations, reduces the problem almost entirely afaics <fwereade> hazmat: and I guess we're pretty safe from having further cleanups added at that point <hazmat> fwereade, doing a full run now <fwereade> hazmat, brb <fwereade> b <m_3> noodles775: currently the basic pg formula works. authentication is wide open and there's no replication. <hazmat> hmm, trial has an addCleanup that masks mocker's addCleanup <noodles775> k, thanks m_3. <m_3> noodles775: I should get the acls working before inclusion into principia <RoAkSoAx> fwereade: howdy!! <fwereade> RoAkSoAx: heyhey! <fwereade> RoAkSoAx: nice weekend? <noodles775> m_3: Yep, sounds sane :) I've subscribed to the bug so I'll know when I can try it. Thanks mor working on it! <RoAkSoAx> fwereade: yeah!! busy though!! how was yours? <fwereade> RoAkSoAx: nice, very peaceful, cath and laura were still in the UK for most of it <m_3> noodles775: awesome, I'll keep it updated <RoAkSoAx> fwereade: cool ;) <RoAkSoAx> fwereade: anywas, what's your latest branch? <fwereade> RoAkSoAx: hmm :) <fwereade> RoAkSoAx: shadow-trunk is not yet updated with either lp:~fwereade/ensemble/cobbler-kill-machine or lp:~fwereade/ensemble/bootstrap-verify-storage <fwereade> but maybe best to skip bootstrap-verify-storage for now: I think it's good, but it could interact with launch-machine (which is merged) <fwereade> and I'd like to be sure of cobbler-launch-machine's status <RoAkSoAx> fwereade: ok <RoAkSoAx> fwereade: i'll work on top of shadow-trunk first then <fwereade> RoAkSoAx: awesome <fwereade> RoAkSoAx: if it looks healthy, I'll merge in 2 more and make 3 merge proposals <RoAkSoAx> fwereade: awesome! <fwereade> RoAkSoAx: it actually works? <fwereade> hazmat: I'm sorry, but I'm really confused about your security-* pipeline: would you please tell me exactly what order I should be looking at them in? I'm driving myself slightly insane <RoAkSoAx> fwereade: havent started yet <RoAkSoAx> will let you know as soon as I do <RoAkSoAx> fwereade: im updating all the cobbler-side pieces first <fwereade> hazmat: don't worry, I think I've figured it out <niemeyer> Good morning! <niemeyer> Hmm.. funny to say that twice in the same day <niemeyer> Aram, Aram2: Morning to both of you <Aram2> hi :-). <Aram2> I'm having some issues running the tests. http://pastebin.com/GPkiK7uZ * niemeyer looks <Aram2> I assume it doesn't parse ~/.ensemble/environments.yaml ? <niemeyer> Aram2: Hmmm <niemeyer> Aram2: That's strange.. have you touched any code? <Aram2> no. <Aram2> latest rev from bzr. <niemeyer> Aram2: Let me try to run this test <niemeyer> Aram2: In theory, this test should be mocked <niemeyer> Aram2: Sorry, I actually mean that this part of the logic should be mocked <Aram2> I see. <niemeyer> Aram2: Test passes here <niemeyer> Hmm * niemeyer reads the test <Aram2> how can I run only this tests and not all? <niemeyer> Aram2: Just take that last string at the end of your paste and put it after ./test <Aram2> also, I am using bzr branch lp:ensemble , I assume this is the branch I am interested about. <Aram2> ah, ok. <niemeyer> Aram2: It is indeed <Aram2> yeah, test fails. <Aram2> ensemble works though. <niemeyer> Aram2: Phew.. that's actually good <niemeyer> Aram2: If it passed it'd mean the failure would come from the interaction between tests, and would be harder to debug :-) <niemeyer> Aram2: Hah <niemeyer> Aram2: This test is actually broken, nevermind <Aram2> heh. <niemeyer> Aram2: It's just that pretty much all of us have the environment set up <niemeyer> Aram2: The real env, I mean <niemeyer> Aram2: Not ~/.ensemble <Aram2> aha. <niemeyer> Aram2: Many EC2 tools depend on the AWS_ACCESS_KEY_ID variable <niemeyer> Aram2: and it's partner (AWS_SECRET_ACCESS_KEY) <niemeyer> Aram2: Our tests should not depend on it to run, though <Aram2> yeah... <niemeyer> Aram2: For the moment, you can just disable this test <_mup_> Bug #819329 was filed: Tests depend on AWS_ACCESS_KEY_ID being set <Ensemble:Confirmed> < https://launchpad.net/bugs/819329 > <hazmat> niemeyer, good afternoon ;-) <niemeyer> hazmat: Hey! * hazmat hands off review queue crown to fwereade * fwereade peers at it, and tries to put it on his foot <niemeyer> :-) <jcastro> robbiew: heya do you have those 5 reasons narrowed down? I need them for a slide <robbiew> yeah...but they aren't "blessed" yet <robbiew> need to run them by sabdfl with jono * jcastro nods <robbiew> they are in the Messaging whatever <jcastro> ok <robbiew> one of the bazillion ensemble google docs <niemeyer> :) <niemeyer> Aram2: How's it going overall, btw? Have you started doing any coding, or still at the understanding phase? <Aram2> Aram2: I have been busy a little bit... I have played with ensemble, read he current code and now I'm trying to make Go and Python work together nicely in some way. <Aram2> it would be nice if you could call one from the other but unfortunately you can' <Aram2> t :-). <niemeyer> Aram2: Right, agreed <niemeyer> Aram2: Note that for this experiment, you don't really have to make them play together <niemeyer> Aram2: The question is more how it'd look like if some pieces were ported over <Aram2> yeah. <_mup_> ensemble/states-with-principals r302 committed by djennings@example.org <_mup_> use constant for otp identity key in domain state dict, machine state tracks otp data reference. <fwereade> niemeyer, hazmat: security-otp-principal <fwereade> intended only to narrow the window of opportunity for a potential attacker, rather than anything stronger? <hazmat> fwereade, i'm in progress on a reply on the mp, the nutshell is your assessment is correct, there is a window till the otp is consumed that an attacker can gain access to the persistent principal credentials if they can get ahold of the otp prinicipal/data enroute. <fwereade> hazmat: thanks <fwereade> is there any way to review "approve so long as you file a bug about this shortcoming when you merge it"? :p <niemeyer> It would be mitigated by encryption, though <fwereade> niemeyer: sorry, what's encrypted? <niemeyer> fwereade: Nothing.. <niemeyer> fwereade: It would :) <fwereade> niemeyer: ah :) <niemeyer> For now this is already good progress on top of what we do now <hazmat> fwereade, atm i don't see a good way to manage that risk alternatively without a dedicated security agent.. we effectively create the structure with acls referencing the intended principal credentials within the cli which need to get past through at least one other process (which creates the intended connected client/agent) before they get to their destination <fwereade> niemeyer: absolutely, I don't want to reject it, just to make sure that we track the fact that it's a potential issue <niemeyer> fwereade: I know, I'm just explaining as well, rather than attempting to change your feeling about it :) <hazmat> niemeyer, encryption of the otp data? the decrypt key needs to be passed as well <fwereade> shall I file a bug then, and we can worry about it later? <hazmat> niemeyer, fwereade i'm totally open to alternate ideas on this <fwereade> hazmat, niemeyer: I think that at some stage in the future a security agent may be a good way around this (we could implement something that really did delete all unhashed records of the otp when it was first accessed) but for now I'm happy with it <niemeyer> hazmat: No, encrypt of the channel used to communicate back with zk with the key <niemeyer> hazmat: I think what you have is good progress already <hazmat> niemeyer, fwereade its unclear to me if alternate solutions would work well without such an interception gap without implementing a new zk auth mechanism <niemeyer> hazmat: We can easily hack ZK to implement real OTPs, or other mechanisms in the future <hazmat> niemeyer, sounds good <fwereade> cool, I'll approve and file <niemeyer> fwereade: Agreed <_mup_> Bug #819379 was filed: otp mechanism is vulnerable to interception <Ensemble:New> < https://launchpad.net/bugs/819379 > <hazmat> fwereade, thanks for the reviews! <fwereade> hazmat: a pleasure :) <SpamapS> kim0: thats an older graphic, though updated with new understanding. :) <robbiew> m_3: call time? <m_3> robbiew: yup * hazmat enjoys googling for ensemble bugs <niemeyer> Lunch time.. biab <fwereade> need to pop out for a little while, bbs * niemeyer pops back <RoAkSoAx> fwereade: so now the orchestra config should provide a storage-url? <fwereade> RoAkSoAx: yes <fwereade> it seemed foolish to assume it was *necessarily* on the same server as cobbler itself <RoAkSoAx> fwereade: what's the formatting? http://W.X.Y.Z/abc? <fwereade> RoAkSoAx: yep <RoAkSoAx> fwereade: well kind of but given that the cobbler server was the "orchestra" server it made sense to keep it there <fwereade> RoAkSoAx: fair point :) <RoAkSoAx> fwereade: yes cause the idea is to make orchestra automatically configure the webdav server <RoAkSoAx> fwereade: and have it up and running post installation and ready to serve ensemble <RoAkSoAx> fwereade: let's do this, if no storage-url is provided, then assume a default, which would be the <orchestra-server/webdav> <niemeyer> RoAkSoAx: Agreed, at least defaulting to it sounds like a good plan <fwereade> RoAkSoAx: then we can trim that back :) <fwereade> sure, happy to add that <RoAkSoAx> niemeyer: indeed <RoAkSoAx> fwereade: yeah! that will allow us more flexibility in case someone would like to chagne the storage somewhere else <fwereade> RoAkSoAx: ...but still nothassle people by asking them to configure it until they need it <fwereade> perfect <fwereade> cheers :) <RoAkSoAx> fwereade: indeed <daker> m_3, what's the status of the postgres formula ? <fwereade> I think it's the end of my day now; RoAkSoAx, I'll probably be back on later to merge that change through the plumbing and into shadow-trunk (and everywhere else it needs to be) <RoAkSoAx> fwereade: btw.. AFAIK, a "name" on a cobbler system cannot be changed <RoAkSoAx> fwereade: cool I'll continue my testing <RoAkSoAx> fwereade: and the changes on setting the provider-state using the UID doesn't really seem relevant because , as far as I can see, to be able to edit a system, you need to obtain the name of the UID <RoAkSoAx> so at the end it seems to be the same <m_3> daker: in progress... eta few hours <daker> ok <m_3> daker: have machine-based acls working (pg_hba) * negronjl is away: out to lunch * niemeyer finds his way through the maze of branches creates by fwereade ;-) <niemeyer> s/creates/created <fwereade> RoAkSoAx: belatedly: I just changed a system name, to prove I could <fwereade> RoAkSoAx: there's a rename button in the system list <fwereade> RoAkSoAx: I think you *can't* change a name while something else is holding a reference to it though <RoAkSoAx> fwereade: yeah maybe <RoAkSoAx> fwereade: btw... <RoAkSoAx> fwereade: the way how you obtaining the keys for clout-init user-data is broken <RoAkSoAx> as it makes clout-init to fail <fwereade> RoAkSoAx: bah :( <fwereade> RoAkSoAx: I thought I was doing it just the same as in EC2, didn't expect *that* of all things to be a problem <RoAkSoAx> fwereade: http://paste.ubuntu.com/656595/ <fwereade> goodness me <SpamapS> negronjl: does redis support master<->master replication? <fwereade> I guess it's travelling a very different path to the one it takes on EC2 <_mup_> ensemble/webdav-storage-prereq r318 committed by djennings@example.org <_mup_> Merged generic-state-ops. <niemeyer> Please ignore this.. just a temp branch for review <niemeyer> fwereade: Hmm <fwereade> niemeyer: Hmm? <fwereade> (sorry, irresistible symetry) <niemeyer> fwereade: Sorry, just double checking <_mup_> ensemble/webdav-storage-prereq r318 committed by djennings@example.org <_mup_> Merged generic-state-ops. <fwereade> niemeyer: I'm fretting that I've done something unforgivably dumb now :/ <niemeyer> fwereade: No, I'm just a bit stuck on webdav-storage <niemeyer> fwereade: I can't find the proper review base <fwereade> niemeyer: is that one of the ones with 2 parents? <niemeyer> fwereade: I get a 600 lines diff on it, including things I already reviewed <fwereade> I seem to recall it requires cobbler-instance-ids as well <niemeyer> fwereade: Yes, but I'm taking that into account <niemeyer> fwereade: Yeah.. I'm merging both of these to form a base <niemeyer> There's still more, apparently <fwereade> niemeyer: hmm, not that I recall... <fwereade> niemeyer: I'm being called, bbs, I'll see if I can see what I've done <niemeyer> fwereade: Hmmm.. part of the diff is within one of the pre-req branches, actually <niemeyer> fwereade: Maybe it's just the diff that is bogus.. <niemeyer> fwereade: Let me try something else <niemeyer> fwereade: Alright, I think I got it <niemeyer> fwereade: Don't move too fast.. I'll review it quickly before the diff disappears.. ;) <fwereade> niemeyer: back, shout if I can help at all <niemeyer> fwereade: Super, thanks <niemeyer> robbiew: ping <negronjl> SpamapS: no. afaik redis only supports master-slave <SpamapS> negronjl: I wonder if we can take the redis-master and redis-slave formulas and just make a 'redis' formula.. <negronjl> SpamapS: i'll give that a shot <SpamapS> negronjl: also can redis slaves be promoted to masters? <SpamapS> negronjl: if thats the case (and not too complicated) then it might make sense to have them work in a ring. <negronjl> SpamapS: afaik. yes. still reading a bit about redis <robbiew> jcastro: ping <jcastro> robbiew: pong <fwereade> ok, I think that really is it for me for now :) <fwereade> nn all <hazmat> niemeyer, the extra security work integrated into domain object creation (service, unit, machine) seems to have some impacts on total test run time, about 25-30% increases, for tests that heavily use the api.. the setup/teardown deltas are under 2%, its just the extra cost of manipulating the additional nodes afaics <niemeyer> hazmat: Hmm <niemeyer> hazmat: If you're comfortable the API is the right one, we can move forward with this no matter what <niemeyer> hazmat: and worry about optimization down the road <niemeyer> hazmat: We can do tricks like disabling the auth steps under controlled scenarios <niemeyer> hazmat: But I'd be happier to run them all the time until we're sure they are good <hazmat> niemeyer, yeah.. i tried seeing what i can do about optimization now, but i'm not seeing any quick gains, i've got most of the api encapsulated into a class, that i could switch toggle by test <hazmat> which might get things a bit closer <hazmat> niemeyer, sounds good re goodness * niemeyer steps out for watching a movie.. <_mup_> Bug #819562 was filed: ensemble.formula.tests.test_bundle fails on buildds <Ensemble:New> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/819562 > <_mup_> Bug #819563 was filed: ensemble.formula.tests.test_bundle.BundleTest.test_executable_extraction fails on buildds <Ensemble:New> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/819563 > #ubuntu-ensemble 2011-08-02 <pullies> hi, i'm trying out ensemble but when running `ensemble status` i get an Invalid SSH key message <pullies> i have specified authorized-keys-path in my environment (that's what let me run bootstrap in the first place) <pullies> this is when using the ppa, btw. <pullies> any advice? <niemeyer> pullies: Hey there <niemeyer> pullies: Hmmm <niemeyer> pullies: What's the content of the file you're pointing at with the authorized-keys-path? <niemeyer> pullies: It usually gets that automatically from your ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub files <niemeyer> pullies: Did you have these when you were seeing the error earlier? <RoAkSoAx_> niemeyer: who creates id_{dsa|.pub <RoAkSoAx_> niemeyer: who creates id_{dsa|rsa}.pub <RoAkSoAx_> in the zookeeper? <niemeyer> RoAkSoAx_: deploy does <niemeyer> RoAkSoAx_: It serializes with the environment <RoAkSoAx_> niemeyer: ok cool, cause I was encountering situations on which the zookeeper complaint about the keys but there were no keys <RoAkSoAx_> niemeyer: err was looking for keys, but there were no keys <niemeyer> RoAkSoAx_: Ok.. pullies was just reporting a similar issue above <niemeyer> RoAkSoAx_: Maybe that's the problem <niemeyer> pullies: Have you deployed something? That could be the issue <niemeyer> We should handle that bootstrapping phase better in that sense <RoAkSoAx_> niemeyer: but in my cause, after bootstrapping the zookeeper dones't have any .pub keys created <hazmat> g'morning <fwereade> heya hazmat :) <pullies> sorry, i disappeared for the night, as you could probably tell. ;-) i have deployed nothing. <pullies> -----BEGIN RSA PRIVATE KEY----- <pullies> (a base64 encoded string which i won't paste here) <pullies> -----END RSA PRIVATE KEY----- * hazmat has to give an ensemble presentation tonight, but his laptop does a kernel panic everytime it sleeps <hazmat> sadness <fwereade> did something about how we handle $PYTHONPATH change? <hazmat> fwereade, no.. not in a very long time <fwereade> hazmat: ok, I'm doing something dumb then :) <hazmat> fwereade, there is a new bug open about pythonpath being set for hooks which it probably shouldn't be <hazmat> fwereade, what's the sympton? <fwereade> I set PYTHONPATH, run bin/ensemble, and it still picks up the system version <hazmat> fwereade, a system version (ppa install) of ensemble? <fwereade> hazmat: yep <hazmat> fwereade, is it ppa or a manual installation via sudo setup.py install? <fwereade> ppa <hazmat> fwereade, i'd suggest first removing the package <hazmat> PYTHONPATH=$PWD python -c "import ensemble; print ensemble" <hazmat> is a quick verification of the import path for ensemble <hazmat> er.. PYTHONPATH=$PWD:$PYTHONPATH is probably better <hazmat> for real usage <fwereade> hazmat: that appears to work <fwereade> hazmat: anyway, don't worry, all I really needed was verification that it we me being stupid ;) <hazmat> fwereade, path problems hit all of us one time or another.. * fwereade is reassured ;) <hazmat> fwereade, btw, when your the second reviewer on a branch, you should adjust the merge proposal status (at the top) if both the reviews are approve, then approved, else work in progress. * hazmat dog walks, bbiab <fwereade> hazmat: cool, thanks <fwereade> hazmat: I think I may have thought it happened by magic :p <pullies> sorry, a little context would probably help. last night i reported an error that `ensemble status` gives an Invalid SSH key message when i specify my authorized-keys-path in environment <hazmat> pullies, so you have the path to your ssh key in 'authorized-keys-path' in the provider section of the environment? <hazmat> pullies, and yes the context helps ;-) <pullies> hazmat, i have a path to my ssh key in environments.sample.authorized-keys-path <hazmat> pullies, looking at the code, it looks like the path is a misnomer :-( it wants the name of a file in the .ssh directory <pullies> AHA <hazmat> pullies, if your up for it please file a bug that this is misleading/confusing regarding the name and usage of this setting <pullies> hazmat, where's the bug tracker? <pullies> launchpad? <hazmat> http://launchpad.net/ensemble <hazmat> pullies, your going to need to shutdown and bootstrap again, we need the ssh key active for doing any connection from the cli to the ensemble setup <hazmat> pullies, so your saying you where able to bootstrap with an invalid key? <hazmat> s/where/were <hazmat> that's also a problem/bug <hazmat> if so <pullies> hazmat, running the instance was successful. i believe connecting to it was not <pullies> this launchpad dashboard is confusingly worded about openid <pullies> :-) <hazmat> pullies, suggestions welcome on #launchpad ;-) <hazmat> pullies, thanks for filing a bug, i'm heading out for a few minutes, let us know how it goes <pullies> still the same error message <pullies> i'm assuming "the ssh directory" is ~/.ssh <pullies> ? <_mup_> Bug #819803 was filed: authorized-keys-path is actually a filename, not a path. <Ensemble:New> < https://launchpad.net/bugs/819803 > <pullies> hazmat, it's possible that ssh access hasn't been enabled for the security group, poking around at ec2 docs. can you confirm that this is a necessary precondition that ensemble doesn't take care of? <hazmat> pullies, ensemble does indeed take care of ec2 security groups <hazmat> pullies, it takes a minute or two for the instance to be up and responding <hazmat> pullies, actually it does look like it will try either a full path or a name <pullies> i've skipped the ensemble part. <hazmat> pullies, it looks like you would get a LookupError <pullies> i'm trying to use the keypair itself <hazmat> not an invalid ssh key error, if it couldn't find the key <pullies> to make sure i can login <pullies> and i can't. <pullies> ssh -i ~/.ssh/mykey.pem djennings@example.org <pullies> that should succeed, yes? <pullies> ssh -v is telling me that it reads the rsa private key <pullies> "authentications that can continue: public key" is issued twice <pullies> i'm a bit confused why i can't ssh directly in <hazmat> pullies, the ssh key is specified for ensemble is the public key, not the private key <hazmat> pullies, do you have an id_[dsa|rsa].pub in ~/.ssh ? <pullies> amazon only gave me a .pem file to download <hazmat> pullies, ensemble doesn't use that <hazmat> pullies, try ssh-keygen -t rsa <pullies> will generate a local key and try that <pullies> :-) duh. <pullies> thanks <hazmat> pullies, you can remove the authorized-keys-path as well, ensemble picks up default keys automatically if none are specified <fwereade> difference between orchestra and ec2: we can't easily tell whether an orchestra machine is running <fwereade> so get_zookeeper_machines is problematic on orchestra <fwereade> because it can't verify the sanity of the state it gets from FileStorage <fwereade> in orchestra, should we be (say) trashing state in shutdown, or should we figure out some way to query the machines and thereby match ec2 better? <hazmat> fwereade, orchestra doesn't know if machines it setup are running? <hazmat> i thought it was doing a tftp/dhcp setup, maybe that's not exposed via the api? <fwereade> hazmat: nope, you can theoretically query power status <fwereade> but that's acted weird for me <fwereade> and that still doesn't tell us whether they're actually running, or if something went wrong part way through install (for example) <hazmat> fwereade, it looks like the examples specify remote power management but not status <fwereade> the api includes a "status" command, which AFAICT acts like an "off" command <hazmat> fwereade, that seems like an upstream bug if that's the case <hazmat> fwereade, not having any orchestra/cobbler experience, i'm not sure what the options are. but if the zk pointer file is invalid, the whole thing basically breaks down. <niemeyer> Hey guys! <fwereade> hazmat: I'm assuming for now that it's something I'm doing wrong, I tend to defer to RoAkSoAx_ for the final word on these things <hazmat> niemeyer, top of the morning <fwereade> heya niemeyer <fwereade> hazmat: it's fine if provider-state is borked, on ec2, because we can check machine status <fwereade> hazmat: we bootstrap if there's no state, or if the state is nonsensical => probably already shut down <hazmat> fwereade, well on ec2 we always intersect the two provider state against machine status, becuase we need the ip resolution <niemeyer> hazmat: balance to you my friend <fwereade> hazmat: maybe that's the intent, I'm just telling you what I could infer from the code :) <hazmat> fwereade, yup, indeed that's the case.. orchestra is a different beast a bit <pullies> hazmat, now this is progress <pullies> 2011-08-02 09:48:45,857 ERROR SSH forwarding error: Agent admitted failure to sign using the key. Permission denied (publickey). <niemeyer> hazmat, fwereade Got the conversation mid-way through, but it sounds sensible to trash state on shutdown <niemeyer> I'd rather rename shutdown to destroy-environment, but that's another topic <hazmat> pullies, if you modify/change the key, you'll need to ensemble shutdown && ensemble bootstrap <pullies> this is after doing that <pullies> and i've removed the path from environments.yaml <niemeyer> pullies: Have you run deploy already? <hazmat> pullies, so if you do ec2-describe-instances do you see the instance running (the security group should match the environment name prefixed with 'ensemble-') <fwereade> niemeyer: cool, that feels like it would make life easier on my side and do no harm to ec2 <niemeyer> Well, I guess it doesn't really matter actually <niemeyer> fwereade: Agreed <hazmat> niemeyer, yeah.. failure to connect precludes deploy <niemeyer> hazmat: I was thinking that the key is serialized with the env, which happens at deploy <niemeyer> hazmat: But that's something else.. we need a key there to connect to zk in the first place <hazmat> pullies, you should be able to ssh into the machine using directly using ssh ubuntu@ec2-host-name <hazmat> niemeyer, the public key is sent at launch time via cloud-init <hazmat> niemeyer, its not stored in zk <pullies> hazmat, the dashboard shows the machine. <niemeyer> hazmat: It is stored in zk during deploy <hazmat> niemeyer, the environment is yes <niemeyer> hazmat: Otherwise how would it be in cloud-init for the other machines <niemeyer> hazmat: The keys <hazmat> niemeyer, totally <hazmat> but not for the bootstrap <niemeyer> hazmat: Yes, I guess that's what I said above? <hazmat> yup <hazmat> :-) <hazmat> pullies, so what'd i'd like to verify is from the cli you can log into that machine via ssh, if you didn't rename the ssh key, it should just pick up the private side of the same default <hazmat> ssh will try a few from what it finds in ~/.ssh <pullies> i generated the key twice. it's possible something is cached in either my client or theirs. will have to log out and try again <pullies> will attempt it tonight <pullies> thanks for the help. will definitely focus on the ssh portion, i don't think it's ensemble at this point <niemeyer> statik: Morning <statik> morning niemeyer <RoAkSoAx_> fwereade: howdy!! <fwereade> RoAkSoAx_: heyhey! <fwereade> ow's it going? <RoAkSoAx_> fwereade: pretty good, you? <fwereade> RoAkSoAx_: pretty good thanks :) <fwereade> RoAkSoAx_: and I got netboot 9% working on my cobbler, too <fwereade> shadow-trunk is up to date, and might even work for you now ;) <RoAkSoAx_> fwereade: cool, where are you stuck? <fwereade> er, that should have been a 99% up there :) <fwereade> the ubuntu-orchestra-client install <RoAkSoAx_> fwereade: cool, I'm actually pulling your branch to test now <RoAkSoAx_> fwereade: you mean the variable? <RoAkSoAx_> on the preseed? <fwereade> (1) it asks for an rsyslog server, and then cannot fails with "cannot stat /var/something/puppet" <RoAkSoAx_> fwereade: show me the line in the preseed <fwereade> RoAkSoAx_: yeah, I remember you telling me to "just comment it out for now" a while ago, so that's what I did <fwereade> can't copy from VM, but it's the pkgsel one as copied from your mail <RoAkSoAx_> fwereade: is the creation of the cloud-init data fixed? <fwereade> RoAkSoAx_: I *think* so <fwereade> RoAkSoAx_: I now generate something that actually looks like a working EC2 one <RoAkSoAx_> fwereade: ok, gonna test now then ;) <fwereade> RoAkSoAx_: the precise details of how I screwed it up the first time are far to embarrassing to relate :p <fwereade> RoAkSoAx_: sweet, tyvm <RoAkSoAx_> fwereade: hehe its all good <fwereade> RoAkSoAx_: hm, I seem to be getting "204 No Content"s from webdav, which I wasn't before, but it all works (apart from the error, heh) <RoAkSoAx_> fwereade: on the orchestra server, what's in /var/lib/webdav <fwereade> RoAkSoAx_: the right stuff <RoAkSoAx_> fwereade: formulas dir and provider-state? <fwereade> RoAkSoAx_: no but yes (I haven't got a formulas dir at the moment, but the right content was written to provider-state) <RoAkSoAx_> fwereade: mkdir -p /var/lib/webdav/formulas && chown -R www-data:www-data /var/lib/webdav/formulas <RoAkSoAx_> fwereade: ok, so bootstrapping works, ensemble status doesn't <fwereade> awesome! I haven't even thought about what status does, so that's the progress I wanted :) <RoAkSoAx_> fwereade: ok, in orchestra means that was related to having @property def _machines: <fwereade> RoAkSoAx_: indeed, and my understanding was that that was something you wanted to defer until the sprint <RoAkSoAx_> fwereade: but anywa,s what's the last thing merged there and what was left to "separate" from the old bootstrap-orchestra branch? <RoAkSoAx_> fwereade: i wanna have it working though <fwereade> RoAkSoAx_: sounds good to me <fwereade> RoAkSoAx_: were we going with "stick it into ks_meta" for now? <fwereade> last thing merged into shadow-trunk is cobbler-launch-machine <RoAkSoAx_> fwereade: so what;'s missing, the shutdown stuff? <fwereade> cobbler-kill-machine is WIP <fwereade> bootstrap-verify-storage is an unrelated bug I picked up lest I spin my wheels on monday, and that should be good soon <RoAkSoAx_> fwereade: alright, so I;ll re-read your branch and try to identify what'[s missing from the things I wanted to do <fwereade> RoAkSoAx_: I plan to make one more change -- to treat 204 as success (as I think is correct: processed successfully, doesn't feel it needs to return any content) <RoAkSoAx_> fwereade: I haven't seen that, where did you see that? <RoAkSoAx_> ort in what situation <fwereade> I seem to be getting that every time I PUT provider-state to webdav <RoAkSoAx_> fwereade: i haven't seen anything <RoAkSoAx_> fwereade: make sure the formulas dir is there and restart apache2 and see if it keeps throwing that error <RoAkSoAx_> fwereade: is the default storage-url also in? <fwereade> well, it's not an error, it seems like a perfectly legitimate response: "yep, cool, I've handled your request and I have nothing more to tell you, but here's a fresh etag maybe" <fwereade> but twisted getPage seems to consider "not 200" == "something happened, raise an exception" <fwereade> I'll bounce apache anyway, but I think what'll fix it is deleting provider-state, I'll let you know in 5 <RoAkSoAx_> fwereade: nah nothing will delete provider-state <RoAkSoAx_> fwereade: you'd have to do it manually in orther to be able to bootstrap again <fwereade> RoAkSoAx_: what I'm doing is setting it to {} on shutdown <fwereade> RoAkSoAx_: and, yes, if I overwrite I get 204, if I trash it manually I get 200 <fwereade> RoAkSoAx_: overwrite is perfectly reaonable behaviour, I'll just make sure ensemble understands that <RoAkSoAx_> fwereade: i don't think we would need to delete provider-state on shutdown <RoAkSoAx_> fwereade: remember that we are dealing with physical hw <RoAkSoAx_> and it is expensive <RoAkSoAx_> to be installing every time we want a zookeeper <RoAkSoAx_> when we already have one <fwereade> hm, I thought that ensemble shutdown was intended to wipe out the whole environment -- inverse of bootstrap <RoAkSoAx> fwereade: that's one of the things I'm also planning to address. <fwereade> that's what it seems to do on EC2 anyway :) <RoAkSoAx> fwereade: yes, on ec2 is non-expensive because you can fire up instances or destroy them on demand <fwereade> RoAkSoAx: heh, ok <RoAkSoAx> fwereade: but in real hardware is not the same approach <fwereade> RoAkSoAx: I've been working under the assumption that I should mirror ec2 behaviour as closely as possible <fwereade> RoAkSoAx: at least for now ;) <RoAkSoAx> fwereade: yes, but I think things like that <RoAkSoAx> can be avoided for now <RoAkSoAx> fwereade: I mean, wiping out provider-state is a super minor change <RoAkSoAx> and I don't think it is necessary <fwereade> RoAkSoAx: well, keeping a zookeeper around is quite a major difference, it seems to me :) <fwereade> RoAkSoAx: well... it's very convenient for me :) <RoAkSoAx> fwereade: indeed, but again, we are dealing with real hardware in this case <RoAkSoAx> fwereade: sysadmins *wont* install zookeepers every week to deploy environments but rather, they would keep once zookeeper up and running at all times <RoAkSoAx> fwereade: it is expensive in many ways, 1: downtime 2. network bandwidth wasted 3. hardware is useless 4. reinstallations at all times are expensive <RoAkSoAx> fwereade: why this works on ec2? simply becuase i can fire up/destroy instances on demand and costs 2 cents? <RoAkSoAx> fwereade: were there's a prebuilt image <fwereade> RoAkSoAx: heh, got you, it's the system install cost not the zookeeper install cost (right?) <RoAkSoAx> fwereade: yes <fwereade> RoAkSoAx: ...but we still pay the system install cost for every other machine, right? <RoAkSoAx> fwereade: right, *but* the idea is now to figure out a way of *re-using* the machines instead <fwereade> RoAkSoAx: and if we have a local mirror it's not going to be *that* big a difference is it? <fwereade> RoAkSoAx: ha -- I see :) <fwereade> RoAkSoAx: that goal has escaped me <fwereade> RoAkSoAx: sorry :) <RoAkSoAx> fwereade: hehe but yeah having a mirror is still big difference when deploying a services <RoAkSoAx> cause it still uses bandwdith <RoAkSoAx> and multiplyed by lots of servers <RoAkSoAx> it is huge <RoAkSoAx> fwereade: but yes, that's another thing that I was gonna bring up during the sprint <fwereade> RoAkSoAx: you make a lot of sense * RoAkSoAx better starts writing down all this stuff otherwise he'll forget :) <fwereade> RoAkSoAx: it just doesn't precisely fit with what I'd understood our goals to be -- I thought we were aiming for parity with ec2 for now, and figuring out the tricky stuff at the sprint * fwereade would appreciate that :) <RoAkSoAx> fwereade: yeah we can do that if you want too <RoAkSoAx> fwereade: dealing with VM's is as inexpensive as ec2 <niemeyer> I seem to remember the wiki sent us to the right page after authenticating <niemeyer> It doesn't look like that's the case anymore <fwereade> RoAkSoAx: well, that's my justification for what I've been doing <RoAkSoAx> fwereade: but right now, what I was persnally looking for is having it bootstrapping, deploying, etc, working (not really exactly the same as ec2, but close), so that during the sprint we could address these issues and differences with ec2 <fwereade> RoAkSoAx: I feel it's currently useful, towards that goal, even if things change as the plans firm up <RoAkSoAx> fwereade: you don't need to justify as we didn't set any boundaries about stuff liuke these when we started <fwereade> RoAkSoAx: that's my idea too, with the added condition of "on my local VM network" <RoAkSoAx> fwereade: but my concern is that you might end up writing code that might be later dismissed :) <fwereade> RoAkSoAx: deleting code is one of the great joys in life ;) <RoAkSoAx> fwereade: hehehe alright <RoAkSoAx> fwereade: again I don't mind you doing that, seriously, just giving you a broad view of what I have in my mind at the moment :) <fwereade> RoAkSoAx: cool, I was worried I was going off into the weeds :) <fwereade> RoAkSoAx: good to resync ;) <RoAkSoAx> fwereade: nah.. either way, this things are gonna have to be discussed next week so my thoights my change given input from others <RoAkSoAx> these* <fwereade> RoAkSoAx: cool -- anyway, I'll handle 204s on .put() and propose launch-machine and bootstrap-verify-storage <RoAkSoAx> fwereade: cool <fwereade> RoAkSoAx: and that'll probably be my day, but I might be able to check in later when cath's gone to bed <fwereade> RoAkSoAx: I'll make sure shadow-trunk is up to date with whatever I've proposed <RoAkSoAx> i'll work on reviwing what would be missing from shadow-trunk in comparison to bootstrap's branch <fwereade> fantastic <niemeyer> <RoAkSoAx_> fwereade: i don't think we would need to delete provider-state on shutdown <niemeyer> <RoAkSoAx_> fwereade: remember that we are dealing with physical hw <niemeyer> <RoAkSoAx_> and it is expensive <niemeyer> RoAkSoAx: destroy-environment should really destroy it.. <niemeyer> RoAkSoAx: I agree with you that physical hardware may make the admin act differently <niemeyer> RoAkSoAx: E.g. not destroying the environment <niemeyer> RoAkSoAx: It should be possible to terminate services and take them off the machines so that we can reuse not only the bootstrap machine but all of them <fwereade> everyone: I need to be away sharpish, I'm afraid <niemeyer> RoAkSoAx: But that's about _using_ the env <niemeyer> RoAkSoAx: Without destroying it <niemeyer> RoAkSoAx: Having ensemble destroy-environment not destroying it for reuse would be awkward <fwereade> but I have a couple of new mps, and I would appreciate reviews from one and all, eithet on those or on their various prerequisites :) <fwereade> enjoy your afternoons :) <niemeyer> I'm stepping out as well, but for lunch.. biab <RoAkSoAx> niemeyer: right, but from my point of view, destroy an environment should destroy everything, but leave the information from the zookeeper, so next time someone will like to bootstrap, it can detect "hey there's already a zookeeper, if it is sleeping, let's wake it up, if it is awake, let's use it" <RoAkSoAx> niemeyer: and that way we save ourselves from reinstalling a machine again <niemeyer> RoAkSoAx: zk is part of the environment <niemeyer> RoAkSoAx: It's actually a key part of it <niemeyer> RoAkSoAx: If one wants to save the time to redeploy zk, just don't destroy the environment <niemeyer> RoAkSoAx: It's a "doctor, it hurts!" case :) <_mup_> ensemble/states-with-principals r303 committed by djennings@example.org <_mup_> statebase retry topology change respects change functions which yield control. <niemeyer> bcsaller: How's it going with the local dev stuff? <bcsaller> niemeyer: I'm working on trying to add flexability to how machine assignment is done in deploy/add_unit. Those both use state.service.assign_to_unassigned_machine which clearly isn't always what we want. <bcsaller> niemeyer: but specifying machines in deploy/add-unit is a little at odd with the co-location spec. Its a different axis to plot unit placement on <niemeyer> bcsaller: Don't worry about co-location for the moment.. <niemeyer> bcsaller: This is really a different angle of the problem <bcsaller> just keeping it in mind <niemeyer> bcsaller: Cool, that's nice <niemeyer> bcsaller: Hmm.. but we do have specific assignment, rigth? <niemeyer> bcsaller: assign_to_unassigned is just one method we have <bcsaller> its the only one used <bcsaller> in the cli <bcsaller> so really it becomes about providing access to other means for placement (as a starting point) <bcsaller> I know there is a desire down the road to say things like `ensemble add-unit -n <num> service` <bcsaller> but if deploy and add-unit grow syntax to support machine assignment I want it to be future friendly <niemeyer> bcsaller: Have you seen assign_to_machine? <bcsaller> yes <bcsaller> niemeyer: I think the issue comes in at the cli level to be clear <niemeyer> bcsaller: That's why I don't get the problem you're describing.. sure, we have assign_to_unassigned_mchine, which is the hard one.. <niemeyer> bcsaller: We also have an explicit one <niemeyer> bcsaller: Which is easy to use <bcsaller> niemeyer: its literally an issue of cli syntax I'm talking about, not a coding hurdle <niemeyer> bcsaller: Ahh, ok <bcsaller> I don't want to blindly add new syntax that isn't friendly to the other efforts we have in mind <niemeyer> bcsaller: 100% with you <niemeyer> bcsaller: Hmmm <niemeyer> bcsaller: Here is an idea.. <SpamapS> How is this at all relevant to local dev? <SpamapS> There's only one machine in local dev. <niemeyer> bcsaller: Let's introduce a command named "set-devel-flag" <niemeyer> SpamapS: Let's cover this in a moment.. <SpamapS> Which would be "available" because it can add containers. <niemeyer> bcsaller: Or even better, "set-devel" <bcsaller> SpamapS: thats an important part of the change, but now the cli tools only look for unassigned machines so its a little more pervasive <niemeyer> bcsaller: Takes a json blob <niemeyer> bcsaller: and stores it in zookeeper, within the topology in a "devel" key <SpamapS> So to me, the current way, "find me an available machine" should just find you machine 0 .. your local machine. For EC2, since they can't do containers, they are unavailable as soon as they have 1 thing on them. <niemeyer> bcsaller: So we can experiment with different settings <niemeyer> SpamapS: Don't worry about it.. we're just splitting development in logical steps <niemeyer> SpamapS: We'll eventually give you the feature you want. <niemeyer> bcsaller: Or maybe it should really be "set-flag" <niemeyer> bcsaller: So that we can use that later <niemeyer> bcsaller: (rather than being specific to "development") <niemeyer> bcsaller: This way you can create an alternative path within the logic by consulting specific flags <niemeyer> bcsaller: Without altering the standard operation <niemeyer> bcsaller: Thoughts? <bcsaller> niemeyer: we could easily add arguments to deploy/add-unit that were conceptually --placement <strategy_or_plan> where it could be a machine id or the name of an available planner which could choose local, reuse, etc <bcsaller> as a counter proposal <niemeyer> bcsaller: Yes, we could, .. we'd also have to worry about getting it right.. you already spent a day thinking about it and didn't get to a good plan, so my suggestion is to get unblocked and <bcsaller> std ops through the code paths would all have to check those flags, which is fine, we want something like that anyway <niemeyer> bcsaller: have the actual goal in mind for the moment.. we can worry about neat placement strategies down the road <niemeyer> bcsaller: The problem we have at hand right now doesn't depend ont his <bcsaller> I don't need to build those now, that wasn't the point <niemeyer> bcsaller: That's my point! ;-0 <bcsaller> +1 <bcsaller> I find that syntax better than talking about setting development flags in a json bucket, but under the hook it will play out much the same from the internals of those tools <niemeyer> bcsaller: So every time you do deploy wordpress/mysql/etc, you'll have --placement ? <cole> roadmap question: I get that ~/.ensemble/environments.yaml can be very easily modified to scale an app. is there a framework for allowing this to be done based on some performance threshold? like memory consumed or cpu utilization / overall cluster throughput etcâ¦ ?? <niemeyer> bcsaller: In local development there can't be anything besides --placement=local <niemeyer> bcsaller: So where do you store the fact placement _has_ to be local? <bcsaller> niemeyer: it would just default to doing with it does, "unassigned" which points to the existing method <bcsaller> `local` is a method that says return machine<0> <niemeyer> bcsaller: Ok.. that sounds good as well.. can you please describe the semantics end-to-end? <niemeyer> cole: We'll be with you in a sec <bcsaller> `ensemble deploy --placement local mysql` <bcsaller> `ensemble deploy --placement local wordpress` <bcsaller> would place two units and assigned them to the machine returned by the policy, in this case machine 0 which is the local box <bcsaller> internally this would replace the code in deploy and add unit that maps/find machines and does unit assignment with a callout to policy by name. If that option is an int, the machine is is resolved and used with a different policy function doing specific assignment <bcsaller> add-unit -n <num> --placement xxx could still be strange, with a policy it could work, with a machine id... ? <bcsaller> but that doesn't seem to be a blocker to me <hazmat> niemeyer, bcsaller unrelated to current discussion, i was looking over the co-location stuff on the ML, and was wondering if this isn't easier with the relation qualification co-located or a new relation type container, the distinguishing characteristic is that the physical placement, its odd indeed for a local co-located service to talk to an opposite end remote service. its more of a local either p2p relations between those units deployed in the s <hazmat> ame container, or a bus/ring container relation containing only the local units. <hazmat> bcsaller, that sounds good if default placement policy can derive from provider <niemeyer> bcsaller: We don't have to address specific assignment for the moment <hazmat> thus obviating the need for specifying it in hte common case <niemeyer> bcsaller: I want to avoid the "I want this in machine X" feature for now <niemeyer> bcsaller: Because it blocks other characteristics we're intrested on <bcsaller> niemeyer: I prefer that as well <niemeyer> hazmat: Sorry, I'll be with you soon.. let me unroll the stack of questions <niemeyer> bcsaller: Ok <bcsaller> niemeyer: a couple of named policies that map cli stuff to the service assignment code then is pretty simple and seems future aware <niemeyer> bcsaller: So --placement local sounds fine to bootstrap.. the local provider can somehow determine the default policy down the road <bcsaller> hazmat: it makes total sense that providers can carry code for specific policies <hazmat> cole, its definitely something we're thinking about, but its probably a ways out, we're currently working out how to get things like default service monitoring onto systems. in future with monitoring, and a remote api for ensemble, a user could provide scaling logic, its probably a while till ensemble provides it as a generic feature. <hazmat> bcsaller, not that they should per se have code, ideally it could be generic, just that they specify a default named policy <niemeyer> bcsaller: The point was more that we need to tweak default policy according to backend <bcsaller> ok <niemeyer> bcsaller: We don't want --placement switches on every single call on a local dev <cole> hazmat: thanks! I figured as much. I think we might be able to help in that area. project looks
{'channel': 'ubuntu-ensemble', 'month': 8}