[00:52] <flacoste> hazmat: jimbaker: bcsaller: if any of you is around, would one of you be available to help poor bigjools with the problems we are having making the maas provider work?
[00:53]  * bigjools makes puppy dog eyes
[00:55]  * SpamapS can try to help
[00:55] <SpamapS> I doubt I can offer quite the same level of code introspection as them.. but I *did* write a provider many moons ago
[00:56] <bigjools> heh
[00:57] <bigjools> SpamapS: ok thank you. my problem is that  the provisioning agent craps out when it tries to deploy stuff.  Let me try to pastebin a log.
[00:57] <bigjools> we are confused about system/instance/resource/ etcetc IDs.
[00:57] <bigjools> the current branch is here, FWIW: lp:~julian-edwards/juju/maas-system-id
[00:59] <flacoste> SpamapS: thanks
[01:04] <SpamapS> bigjools: I noticed that there was some stuff missing from other places in the code today too. Providers aren't nearly as self-contained as they should be
[01:04] <bigjools> SpamapS: :(
[01:09] <SpamapS> bigjools: pulling your branch now. What exactly can I help with?
[01:11] <bigjools> SpamapS: I am trying to get my prov agent log, one sec
[01:12] <SpamapS> bigjools: just an FYI, you need to add maas to juju/unit/address.py
[01:13] <SpamapS> bigjools: but I do not know if that is for sure your issue. Most likely not. ;)
[01:13] <bigjools> SpamapS: ok thanks
[01:14] <fwereade_> bigjools, based on the error robbiew forwarded earlier, I would look askance at MaasProvider.get_machines
[01:14] <bigjools> SpamapS: so here's a snippet of log: http://pastebin.ubuntu.com/893090/
[01:14] <bigjools> yeah basically the same as that email
[01:14] <bigjools> fwereade_: hi!
[01:14] <fwereade_> bigjools, the description was basically that it was trying to shut down machines that it shouldn't even know about, right?
[01:14] <fwereade_> bigjools, heyhey :)
[01:15] <fwereade_> bigjools, that implies that the PA is getting more machines than it should back from provider.get_machines
[01:15] <bigjools> fwereade_: well that AND the fact it was shutting down something that was not running (maas returns the 409 CONFLICT for that)
[01:15] <bigjools> fwereade_: ah that is useful, thanks
[01:15] <fwereade_> bigjools, it will only ever try to shut a machine down if the provider tells it it exists
[01:16] <flacoste> bigjools: could it be that get_nodes() doesn't limit itself to the nodes that have been acquired?
[01:16] <fwereade_> bigjools, of all those machines which exist, any which correspond to a machine state will be saved
[01:16] <fwereade_> flacoste, sounds very likely
[01:16] <bigjools> flacoste: yeah could be
[01:16] <bigjools> I need to debug this
[01:16] <fwereade_> flacoste, orchestra had to make that distinction
[01:16] <bigjools> on an internet connection that has some b/w
[01:18] <fwereade_> bigjools, best of luck
[01:18] <SpamapS> it does look like get_machines shows all machines
[01:18] <bigjools> ok I'll look into that, thanks for the advice guys!
[01:18] <fwereade_> bigjools, I'm afraid I have to sleep now
[01:19] <fwereade_> bigjools, a pleasure, glad to be of service :)
[01:20] <SpamapS> bigjools: each of the other providers uses something to filter out the list of all machines that can be seen w/ the service+creds to just the ones pertinent to this environment
[01:20] <bigjools> right
[01:20] <SpamapS> bigjools: for orchestra it was mgmt class, for ec2 the group is used
[01:20] <bigjools> I assumed it was just asking about all nodes passed
[01:21] <flacoste> bigjools: so in our cases, returning the nodes associated to the user is probably fine
[01:21] <flacoste> although
[01:22] <flacoste> we might need to introduce a new environment key
[01:22] <bigjools> flacoste: how so?
[01:22] <flacoste> (in case a user, wants to start two separate environments)
[01:22] <flacoste> juju bootstrap; juju bootstrap
[01:22] <flacoste> both with the same credentials
[01:22] <SpamapS> You need something to tag each node. One maas may host many envs for many users.
[01:23] <flacoste> SpamapS: we are multi-tenant already
[01:23] <flacoste> but not sure multi-env per user yet
[01:23] <SpamapS> the potential to break your juju environment just by manually starting a node is a bit high though
[01:23] <SpamapS> if nothing else, prefix the names
[01:24] <SpamapS> or allow an optional filter in the environment configuration
[01:24] <SpamapS> but anyway
[01:24] <bigjools> I need to understand what juju needs here, I am not sure yet.  But let me come back to that when the other stuff is working
[01:24] <SpamapS> sounds like the problem is in hand
[01:25] <SpamapS> Anyway, to test this hypothesis one should be able to try it out with a maas that only has juju nodes
[02:51] <hazmat> bigjools, ping
[02:51]  * hazmat backtracks
[02:53] <bigjools> hazmat: hey
[02:53] <hazmat> hi bigjools just backtracking through the logs
[02:53] <hazmat> it sounds like orchestra is returning something via the api that it shouldn't
[02:54] <bigjools> you mean maas?
[02:54] <bigjools> yeah - we think get get_machines call is returning the wrong things, it's not filtering properly
[02:54] <hazmat> bigjools, yup i mean the resource uri vs the node url seem to be two different concepts. anyways.. i'm around for  a few hrs.. if you need any further debugging
[02:55] <bigjools> hazmat: great, thanks!
[03:15]  * bigjools relocating
[09:26] <rogpeppe> mornin' all
[09:27] <rogpeppe> TheMue: sorry i didn't take any pictures or record anything at all from last night!
[09:27] <rogpeppe> TheMue: but it was interesting, and a good time was definitely had.
[09:30] <fwereade_> heya rogpeppe
[09:30] <rogpeppe> fwereade_: heya too
[09:31] <fwereade_> rogpeppe, TheMue: laura's off school and cath has to go out, I will be away for a couple of hours
[09:31] <roubi> hi
[09:32] <rogpeppe> fwereade_: lots of tunnels just after kings cross so communication will be patchy...
[09:32] <roubi> why i can't see
[09:32] <roubi> discussions
[09:32] <roubi> taking place in this channel
[09:33] <TheMue> rogpeppe: moin
[09:34] <TheMue> roubi: which kind of discussion do you expect?
[09:34] <roubi> questions that every body ask about juju
[09:35] <wrtp> fwereade_: lots of tunnels just after kings cross so communication will be patchy anyway...
[09:35] <TheMue> wrtp: so you're in the train?
[09:35] <wrtp> TheMue: i am
[09:35] <wrtp> TheMue: again!
[09:35] <TheMue> wrtp: ic ;)
[09:37] <wrtp> TheMue: i said hi to Eleanor and Erik for you BTW
[09:37] <TheMue> wrtp: great, thx
[09:38] <wrtp> TheMue: at least... i said hi to *an* Erik!
[09:38] <wrtp> TheMue: (the one that gave the talk)
[09:38] <TheMue> wrtp: that's exactly the right one
[09:38] <TheMue> ;)
[09:39] <wrtp> TheMue: i'm not sure he remembered your name though - they do *many* startup gatherings...
[09:41] <TheMue> wrtp: that's one of the problem when you so far only had electronical contact with nicknames
[09:41] <wrtp> TheMue: yeah
[10:12]  * wrtp can now run the environs/ec2 tests without accessing the internet. yay!
[10:13] <TheMue> wrtp: great
[13:05] <fwereade_> hazmat, ping, I'm getting a horrible feeling that we need to hit the "placement" key as well
[13:06] <fwereade_> hazmat, it really doesn't feel like an access setting ;) :(
[13:32] <niemeyer> Heya!
[13:43] <fwereade_> heya niemeyer
[13:44] <fwereade_> niemeyer, I think I'm missing some context on placement policies
[13:44] <fwereade_> niemeyer, why did they become env-level only, when we use to have deploy --placement?
[13:44] <fwereade_> used to have^^
[13:45] <niemeyer> fwereade_: They may be set both in the environment and in the service, right?
[13:46] <niemeyer> fwereade_: I mean, constraints can
[13:46] <fwereade_> niemeyer, *constraints* can
[13:46] <niemeyer> fwereade_: Yes, and that's the real placement.. --placement IIRC is a hack to allow re-use of machine 0
[13:47] <fwereade_> niemeyer, it seems that *actually* placement ought to be a constraint, but not one I'd fully appreciated
[13:47] <fwereade_> niemeyer, OK, this is another point of potential pain
[13:47] <fwereade_> niemeyer, do we wish to retain that hack in some form?
[13:48] <fwereade_> niemeyer, given that we currently have no other way to express it, my guess is "yes", but..?
[13:48] <niemeyer> fwereade_: What's the potential pain?
[13:49] <fwereade_> niemeyer, it *also* seems that they *cannot* be set on the service
[13:49] <fwereade_> niemeyer, but perhaps I'm blind there
[13:49] <fwereade_> niemeyer, that it's a non-access setting that currently lives in environments.yaml
[13:49] <niemeyer> fwereade_: Placement policy sounds orthogonal to constraints and to environment settings
[13:50] <niemeyer> fwereade_: Sorry, yes, not to environment settings
[13:50] <fwereade_> niemeyer, yeah, local policy overrides constraints
[13:50] <niemeyer> fwereade_: Why is it tricky?
[13:50] <fwereade_> niemeyer, which I think matches intuitive intent
[13:50] <niemeyer> fwereade_: Sounds like a normal setting that should go into set-env
[13:50] <fwereade_> niemeyer, yeah; it's just something else we have to warn people about :(
[13:51] <niemeyer> fwereade_: We need to warn them about only one thing
[13:51] <niemeyer> fwereade_: Settings in environments.yaml are being moved onto the environment itself
[13:51] <niemeyer> fwereade_: We don't need a separate warning for each setting
[13:52] <fwereade_> niemeyer, this is true, but the required actions are different for different settings
[13:52] <fwereade_> niemeyer, "default-series" and "placement" are both "use bootstrap/set-env"; the ec2 ones are "use constraints"
[13:53] <niemeyer> fwereade_: That's fine.. we can easily document the distinction in a wiki page, and have both the email note and the error from juju pointing out to it
[13:53] <niemeyer> fwereade_: We also don't have so much variation
[13:53] <fwereade_> niemeyer, ok, that sounds good then
[13:53] <niemeyer> fwereade_: Can we please call placement as "placement-policy" on the way to that?
[13:54] <fwereade_> niemeyer, sounds like a good idea to me
[13:54] <niemeyer> fwereade_: I might even call that as debug-placement-policy, but YMMV ;)
[13:59] <fwereade_> niemeyer, sorry, paralysed myself wishing we'd implemented it as deploy/add-unit --force-machine=0
[13:59] <fwereade_> niemeyer, I'm not quite sure that debug works myself
[14:00] <fwereade_> niemeyer, but then again I'm not sure I have the best perspective on how people are using it
[14:03] <niemeyer> fwereade_: This option was never intended to be visible/widely used
[14:05] <niemeyer> fwereade_: Some clever people may be using it to fine tune specific tests and deployments in good ways, but it spoils much of the reasoning why we have juju
[14:05] <fwereade_> niemeyer, I guess we would have got rather more blowback from making it harder to use back whenever it was it disappeared from the unit-adding commands
[14:06] <fwereade_> niemeyer, I'm not sure it does, it feels at least 50% like a reasonable temporary workaround to what remains one of juju's drawbacks
[14:06] <niemeyer> fwereade_: It's not a reasonable workaround at all, IMO, except in those very specific circumstances
[14:07] <fwereade_> niemeyer, I guess the question is "how do we quell the ire of those who *are* using it"
[14:07] <niemeyer> fwereade_: Having everything sitting on machine 0, next to ZooKeeper, in ways that can't ever be uninstalled...
[14:08] <fwereade_> niemeyer, this is true, it does suck
[14:08] <niemeyer> fwereade_: Hold on.. I wasn't suggesting removing it..
[14:08] <niemeyer> fwereade_: We need this behavior for the local provider case.. that's why we have it
[14:09] <fwereade_> niemeyer, well, the behaviour is fine for that; you seemed to be saying it was a mistake to have it available at all on ec2
[14:10] <niemeyer> fwereade_: That's not what I said.. the option is just not intended to be very visible or widely used
[14:10] <fwereade_> niemeyer, anyway, ok, understood
[14:10] <fwereade_> niemeyer, we just move it exactly like default-series
[14:11] <niemeyer> fwereade_: It's fine to have it in EC2.. bcsaller made some very good use of that while developing some of the local provider stuff
[14:11] <niemeyer> fwereade_: Since he was able to test the LXC deployments straight in EC2
[14:11] <fwereade_> niemeyer, cool, sorry misunderstanding :)
[14:11] <niemeyer> fwereade_: That's why I'd name it debug-placement-policy
[14:12] <niemeyer> fwereade_: This causes the environment to behave in very awkward ways if one doesn't know what's going on
[14:12] <niemeyer> fwereade_: But it's fine if you're really into it
[14:13] <fwereade_> niemeyer, the "debug" in there implies dev-only, rather than "what you should do for openstack" for example
[14:13] <fwereade_> niemeyer, which IIRC was a lot of the motivation for it initally(?)
[14:13] <niemeyer> fwereade_: You shouldn't do that for openstack, unless you're Adam :)
[14:13] <fwereade_> niemeyer, rabbitmq with mysql
[14:13] <fwereade_> niemeyer, haha
[14:15] <niemeyer> fwereade_: There's a sequence of events that requires using it in a precise way. This is much closer to "debugging" than to being a "juju feature"
[14:15] <fwereade_> niemeyer, I agree it's awkward; just fretting that it may have become a de facto feature
[14:16] <niemeyer> fwereade_: For Adam, it has :)
[14:16] <niemeyer> SpamapS, m_3: Is anybody else using the placement hack these days?
[14:18]  * rogpeppe is back on a proper internet connection again.
[14:20] <niemeyer> rogpeppe: welcome back to modernity
[14:21] <rogpeppe> niemeyer: actually i felt quite futuristic controlling ec2 instances from on a train :-)
[14:21] <niemeyer> rogpeppe: That's quite amazing indeed :)
[14:21] <rogpeppe> niemeyer: managed to push out two merge requests too. better when the signal was better, usually in a station.
[14:27] <rogpeppe> niemeyer, fwereade_, TheMue: https://codereview.appspot.com/5866049/ and https://codereview.appspot.com/5864047/ if you fancy taking a look.
[14:28]  * rogpeppe is very much enjoying having lbox do prerequisites properly!
[14:29] <m_3> niemeyer: not sure
[14:29] <m_3> doubt it
[14:29] <niemeyer> m_3: Cheers
[14:30] <niemeyer> fwereade_: ^
[14:30] <fwereade_> niemeyer, m_3: thanks :)
[14:30] <m_3> np
[14:34] <niemeyer> fwereade_, hazmat: Just had another round on https://codereview.appspot.com/5849054/
[14:44] <SpamapS> niemeyer: the placement hack has been unavailable to us since --placement was removed
[14:44] <SpamapS> Hey question..
[14:45] <SpamapS> if you remove default-image-id ... how do private clouds work?
[14:45] <niemeyer> SpamapS: It's actually been available all along.. but thanks, that answers the question as well
[14:48] <SpamapS> niemeyer: heh, ok.. I'll take your word on that. I never knew it was.
[14:50] <niemeyer> SpamapS: Adam said it was important for his use case, so we just moved it..
[14:50] <niemeyer> SpamapS: He said it was fine, as long as it was available
[14:51] <niemeyer> SpamapS: The question about private clouds is a good one
[14:51] <niemeyer> fwereade_, hazmat: ^
[14:51] <niemeyer> SpamapS: We need a proper way to map series > image in those as well
[14:53] <SpamapS> I suspect the simplest way will be to set image id on each deploy.
[14:53] <SpamapS> but thats ... tedious :-P
[14:53] <fwereade_> niemeyer, *that* is plausibly an env access setting, now I come to think of it
[14:54] <niemeyer> fwereade_: Yeah
[14:54] <fwereade_> niemeyer, and SpamapS' observation does make me all nervous about forcing automated image selection on people now
[14:55] <fwereade_> (again)
[14:56] <niemeyer> fwereade_: Do you have any suggestions that do not involve having "deploy cs:~fwereade/oneiric/mongodb" deploying it in Precise?
[14:57] <fwereade_> niemeyer, no, I don't
[14:59] <fwereade_> niemeyer, I would suggest that the people sophisticated enough to use custom image ids are demonstrably comfortable in less-comfortable environments
[14:59] <niemeyer> fwereade_, SpamapS: The proper way is likely to have e.g.
[14:59] <niemeyer> images:
[14:59] <niemeyer>     precise: <image id>
[14:59] <niemeyer>     oneiric: <image id>
[14:59] <niemeyer>     ...
[14:59] <fwereade_> niemeyer, arch? hvm?
[15:00] <niemeyer> fwereade_: arch is an issue.. hvm doesn't exist outside of ec2
[15:00] <fwereade_> niemeyer, true, but that's another way of saying "it exists"
[15:01] <fwereade_> niemeyer, it'll all be against the ec2 provider...
[15:01] <niemeyer> fwereade_: Yeah, you're right
[15:01] <niemeyer> hmm
[15:02] <fwereade_> niemeyer, IMO the cost of persisting the hack until 12.04.1 is outweighed by the benefit of offering an actual transition path for anyone who is using it
[15:02] <niemeyer> fwereade_: precise: {id: <id>, constraints: <matching constraint expression>}
[15:02] <niemeyer> fwereade_: ?
[15:03] <fwereade_> niemeyer, hmm, that could work, but it feels kinda icky
[15:03] <niemeyer> fwereade_: Forget "persisting the hack".. let's describe it in terms of having series not working
[15:03] <niemeyer> fwereade_: I don't care about the hack.. I care about series not working
[15:04] <fwereade_> niemeyer, ok
[15:04] <fwereade_> niemeyer, what I want is for everyone who needs it to run their own local uec-images :)
[15:04] <fwereade_> niemeyer, ie, same data format and url %s-able by series name
[15:05] <fwereade_> niemeyer, that makes it an env access setting, the isers are responsible for advertising sane images, and we're done
[15:05] <niemeyer> fwereade_: That's a plausible idea. We just have to reduce the burn of setting it up, and we also need to think about the fact that non-real-EC2 deployments don't have pretty pre-defined classes of machines
[15:06] <fwereade_> niemeyer, heh, I wish I could remember who told me that basically all openstack deployments reuse instance names (even if they don't perfectly match capabilities)
[15:06] <fwereade_> niemeyer
[15:07] <fwereade_> niemeyer, actually it's not just uec-images data: it *is* the capabilities of the instances, assumptions about what instance types can run what images are hardcoded :(
[15:08] <fwereade_> niemeyer, however I don't think even amazon publish that data in a usefully-consumable format
[15:08] <niemeyer> fwereade_: We do..
[15:09] <fwereade_> niemeyer, it's a tradeoff that seemed sensible given the constraints I was operating under
[15:09] <niemeyer> fwereade_: But we can't publish it for arbitrary deployments that have their own image ids and their own capabilities
[15:09] <fwereade_> niemeyer, oh wait, did I totally miss the meaning of "we do"?
[15:10] <niemeyer> fwereade_: seemed sensible? was operating under? I think you missed it :)
[15:10] <niemeyer> fwereade_: Canonical publishes details for images in EC2
[15:10] <fwereade_> niemeyer, if you're saying that we publish uec-images: yes, I know :p
[15:10] <niemeyer> fwereade_: No, we publish the data that you said Amazon doesn't
[15:11] <fwereade_> niemeyer, details of instance types?
[15:11] <fwereade_> niemeyer, which ones require HVM images, etc?
[15:12] <fwereade_> niemeyer, which one's it's OK to start with an i386 image
[15:12] <fwereade_> niemeyer, it's the fact that even if the *names* match, private "ec2"s might have (say) m1.smalls that are 64-bit only
[15:12] <niemeyer> fwereade_: Yes
[15:12] <niemeyer> fwereade_: http://uec-images.ubuntu.com/query/precise/server/daily.txt
[15:13] <fwereade_> niemeyer, I see lots of image data there in exactly the format I was asking for
[15:13] <niemeyer> fwereade_: You need to know whether the instance is amd64/i386/ebs/hvm..
[15:13] <fwereade_> niemeyer, I see nothing about instance types
[15:13] <fwereade_> niemeyer, yes
[15:14] <fwereade_> niemeyer, ebs we assume everywhere so I really have no option but to punt on that for now at least
[15:14] <niemeyer> fwereade_: This is still relevant as it gives us which ones are ebs or not
[15:15] <fwereade_> niemeyer, how is any of that information useful to me, as juju, running against a private cloud and attempting to determine whether or not it is appropriate for me to start a c1.medium with an i386 image?
[15:16] <niemeyer> fwereade_: The constraints part of the picture must be provided by the provider
[15:16] <niemeyer> fwereade_: This is already the case for the constraints mechanism you're implementing to exist at all
[15:16] <fwereade_> niemeyer, agreed
[15:17] <fwereade_> niemeyer, this information will indeed need to be exposed by the provider
[15:17] <niemeyer> fwereade_: This is solving the other half of the problem.. given you know what constraints a machine is under, what image?
[15:18] <niemeyer> fwereade_: I'll have lunch while I think a bit more about the issue :)
[15:18] <fwereade_> niemeyer, that is not a problem in need of a solution
[15:18] <fwereade_> niemeyer, we do that already
[15:18] <niemeyer> fwereade_: Is it not?  That's great.. so what's the answer to SpamapS question?
 if you remove default-image-id ... how do private clouds work?
[15:18]  * niemeyer => lunch
[15:19] <fwereade_> niemeyer, SpamapS: if I have my way, private clouds will work as follows
[15:20] <fwereade_> niemeyer, SpamapS: (1) they have to publish uec-images format image data just like uec-images, and must specify the url in the env access settings
[15:21] <fwereade_> niemeyer, SpamapS: (2) they have to [somehow] publish instance-type data in a format we can interpret
[15:22] <fwereade_> niemeyer, SpamapS: if we remove default-image-id now, we utterly crush any current efforts to play with juju in private openstack clouds (right?)
[15:23] <fwereade_> niemeyer, SpamapS: if we focus on it, we *can* come up with a sensible way to import the required information by 12.04.1, and we can IMO bear the risk of sophisticated users telling juju to do bad things in the meantime
[15:25] <fwereade_> niemeyer, SpamapS: it now seems clear that default-instance-type and default-image-id are both critically important for this use case -- without d-i-t you're forced to use the ec2 instance types, and without d-i-i you're completely helpless
[15:27] <fwereade_> niemeyer, SpamapS: is this approaching the tipping point at which we say "ok, we really actually cannot break this now, however much we'd like to"?
[15:45] <niemeyer> fwereade_: What's the suggested behavior of "cs:~fwereade/precise/mongodb" vs. "cs:~fwereade/oneiric/mongodb"?
[15:57] <hazmat> eek.. du -hs machine-agent.log
[15:57] <hazmat> 163G    machine-agent.log
[15:58] <niemeyer> hazmat: Holy crap
[15:58] <niemeyer> rogpeppe: You have a couple of (trivial) reviews
[15:58] <hazmat> niemeyer, yeah.. zk client debug loggin is a bit verbose ;-)
[16:00] <hazmat> i can dev/null it, the alternative is attach a pipe, and filter/rate-limit messages into python logging
[16:00] <rogpeppe> niemeyer: thanks a lot
[16:00] <hazmat> it seems like it goes into a tail spin of errors/warnings when it has trouble connecting
[16:04] <fwereade_> niemeyer, look up an appropriate image at a url based on series; use other constraints to pick an appropriate image from that data source
[16:04] <niemeyer> hazmat: Sounds fine to dev/null it
[16:05] <niemeyer> fwereade_: I mean for 12.04
[16:05] <fwereade_> niemeyer, we loudly and anrgily warn that default-image-id is deprecated every time we parse env.yaml
[16:06] <niemeyer> fwereade_: Sorry, I mean what's the plan for supporting multiple series in 12.04
[16:06] <fwereade_> niemeyer, in private clouds, we don't have one
[16:06] <fwereade_> niemeyer, for everyone else, they just have to stop using those keys
[16:06] <fwereade_> niemeyer, well, that one specific key
[16:07] <niemeyer> fwereade_: Ok, I can buy into that as an intermediate step
[16:07] <rogpeppe> niemeyer: thanks for the LGTM on https://codereview.appspot.com/5857049/. it's got https://codereview.appspot.com/5864047/ as a prerequisite BTW in case you'd overlooked that one.
[16:08] <fwereade_> niemeyer, cool
[16:08] <fwereade_> niemeyer, I'm certainly not advocating that it should live on in 12.04.1
[16:09] <fwereade_> niemeyer, however, since d-i-i was the driver for a lot of this, we should check response sanity for the other keys
[16:09] <niemeyer> rogpeppe: I didn't overlook it.. just didn't get there
[16:09] <rogpeppe> niemeyer: np
[16:10] <fwereade_> niemeyer, d-i-t is I think helpful in the private cloud use case; aws users can just retire it when they feel ready
[16:11] <niemeyer> fwereade_: I think d-i-t is --constraints, isn't it?
[16:11] <niemeyer> fwereade_: If it is still useful after constraints, we're doing something wrong
[16:11] <fwereade_> niemeyer, it is, but it makes aws-specific assumptions about the nature of the instance types it exposes
[16:11] <niemeyer> fwereade_: Really? Why?
[16:12] <niemeyer> fwereade_: I thought we had non-AWS needs in mind the whole time
[16:12] <fwereade_> niemeyer, I am only aware of one place that publishes that information, and it's a github project that I'm reluctant to pull and parse at runtime
[16:12] <niemeyer> fwereade_: Which means constraints is broken
[16:13] <niemeyer> fwereade_: It must be finished
[16:13] <niemeyer> fwereade_: default-instance-type is a constraint like any other
[16:13] <niemeyer> fwereade_: cpu=N arch=X etc
[16:14] <fwereade_> niemeyer, default-instance-type is a bad name: what it really is is force-instance-type
[16:14] <niemeyer> fwereade_: Huh!?
[16:14] <fwereade_> niemeyer, that is the effect it has always had
[16:14] <niemeyer> fwereade_: "default" in there should really be *default*
[16:14] <niemeyer> fwereade_: Because there's no other way to select the instance type
[16:15] <niemeyer> fwereade_: Constraints should entirely obsolete the need for default-instance-type
[16:15] <niemeyer> fwereade_: Or we're doing something wrong
[16:16] <fwereade_> niemeyer, the wrong thing that we are doing is encoding assumptions about AWS in the environment
[16:16] <niemeyer> fwereade_: Such as?
[16:17] <fwereade_> niemeyer, cc2.8xlarge requires an HVM image
[16:17] <niemeyer> fwereade_: We don't have that in the environmen, do we?
[16:17] <fwereade_> niemeyer, t1.micros can be started with i386 and amd64 images
[16:17] <fwereade_> niemeyer, are you aware of any other place to get that information?
[16:17] <niemeyer> fwereade_: Sorry.. we're using "environment" in different ways
[16:18] <niemeyer> fwereade_: It's not an environment setting
[16:18] <fwereade_> niemeyer, developing the infrastructure to distribute it ourselves seemed a touch overambitious for a small compnent of a feature I had |1 month to do
[16:18] <niemeyer> fwereade_: EC2 knowing that in Amazon a t1.micro is i386 sounds quite ok
[16:18] <fwereade_> niemeyer, hence hardcoded assumptions like the above
[16:18] <fwereade_> niemeyer, right
[16:18] <fwereade_> niemeyer, can we make that assumption about instance types available in private clouds?
[16:19] <niemeyer> fwereade_: No.. didn't we go over that already?
[16:19] <fwereade_> niemeyer, a consequence of that is that constraints are "broken", as you put it, in certain private-cloud situations
[16:19] <niemeyer> fwereade_: This has to be provided by the provider
[16:19] <hazmat> even private openstack environments they typically do have something mapping to the instance types from ec2, but the definitions are more ad hoc user defined. there is a way via the native api to query out those capabilities.
[16:20] <hazmat> this discussion sounds familiar
[16:20] <fwereade_> hazmat, that is good to know
[16:21] <fwereade_> niemeyer, hazmat: does anything like that exist for AWS (apart from that github project)?
[16:21] <hazmat> fwereade_, but the mapping is not always complete for ec2 types
[16:21] <hazmat> fwereade_, just that project the boto author did as far as machine parsable ones
[16:21] <hazmat> fwereade_, we could see if smoser/someone could set that up on cloud-images
 fwereade_: EC2 knowing that in Amazon a t1.micro is i386 sounds quite ok
[16:22] <fwereade_> hazmat, it's not just serving it; it's updating it etc
[16:22] <hazmat> but we'd also need to start distinguishing in the ec2 provider on how to query capabiiltiies based on impl (ostack/aws)
[16:22] <niemeyer> fwereade_: We can also offer a document
[16:22] <fwereade_> hazmat, it feels like a pretty serious responsibility to take on
[16:22] <niemeyer> fwereade_: Similar to uec-images
[16:22] <hazmat> fwereade_, really? https://github.com/garnaat/missingcloud setting up a cron job?
[16:23] <niemeyer> fwereade_: You mean, providing data about which instance types exist?
[16:23] <hazmat> fwereade_, oh its hand written you mean?
[16:23] <fwereade_> niemeyer, as I said, I rejected that option as being unrealistic in the time we had available
[16:23] <TheMue> niemeyer: todays watches of service and unit are build with callbacks. any already existing concept on how to handle it in go? or shall i use the idea of a watcher like rog and i already outlined a few days ago?
[16:23] <fwereade_> niemeyer, perhaps I was wrong there
[16:23] <niemeyer> fwereade_: Which option? Sorry.. it feels like there are wires being crossed all the time
[16:23] <niemeyer> fwereade_: I'm a bit lost
[16:23] <fwereade_> niemeyer, yeah, I'm losing track a bit
[16:24] <fwereade_> niemeyer, I feel that it is inappropriate to depend on someone else's AWS data in an automated way
[16:24] <niemeyer> fwereade_: We can publish that information
[16:25] <fwereade_> niemeyer, and that taking on the responsibility of publishing it ourselves would be excessively painful
[16:25] <fwereade_> niemeyer, and that even if that were not the case (I guess it isn't)
[16:25] <niemeyer> fwereade_: Why?
[16:25] <niemeyer> fwereade_: Canonical published the whole *operating system* that people are using
[16:25] <niemeyer> fwereade_: I can't see how publishing which instance types are availalbe is a problem
[16:26] <fwereade_> niemeyer, that my prospects of getting all that set up and out of my hair in the course of december 2011 was unrealistic
[16:26] <fwereade_> niemeyer, if we provide it we have to keep up with the amazon announcements and always remember to update
[16:26] <niemeyer> fwereade_: Yep
[16:27] <niemeyer> fwereade_: Changes in instance types are nowhere close to frequent
[16:27] <fwereade_> niemeyer, which IMO makes it only less likely that it will be something that we will remember to do in a timely way
[16:28] <fwereade_> niemeyer, and makes a certain juju-update-dependent lag in access to latest instances acceptable
[16:28] <niemeyer> fwereade_: Nothing too bad happens if it takes an entire month to be updated, really
[16:29] <niemeyer> fwereade_: This is a non-issue in the context of things we've been talking about.. let's see what are the actual issues we have to decide now
[16:31] <TheMue> niemeyer: e.g. my watch question above. *scnr*
[16:31] <TheMue> niemeyer: ;)
[16:31] <fwereade_> niemeyer: basically, given that we cannot discard d-i-i -- and that doing so was the primary motivation for dropping a sudden format change on our users -- can we perhaps entirely avoid inflicting an env.yaml change on them until sometime after 12.04?
[16:32] <fwereade_> niemeyer, by keeping d-i-i for a while we'recommitting to another change down the line
[16:33] <fwereade_> niemeyer, by making d-i-i and d-i-t act as though "default" meant "force", we can preserve existing behaviour for everyone, and make constraints accessible to all who can give up those keys
[16:33] <niemeyer> fwereade_: Sorry, this whole conversation is flying well above my head
[16:33] <niemeyer> fwereade_: default is default, not force
[16:34] <niemeyer> fwereade_: constraints are broken, as you describe
[16:34] <niemeyer> fwereade_: You're asking to not change environment, but I don't know what you mean by that
[16:34] <niemeyer> fwereade_: We need a call
[16:34] <fwereade_> niemeyer, sounds good
[16:35] <niemeyer> TheMue: Not a good time, sorry
[16:35] <TheMue> niemeyer: yeah, ic, followed your discussion with one eye
[16:35] <TheMue> niemeyer: will port state/auth first
[16:35] <fwereade_> niemeyer, invited on g+
[16:37] <niemeyer> fwereade_: Uh oh
[16:44] <niemeyer> Uh oh.. again
[18:05] <rogpeppe> fwereade_, niemeyer: do you know anything about the way that admin_identity is used to make acls, by any chance? i'm seeing an "invalid acl" error, which i'm presuming is from StateHierarchy.initialize.
[18:05] <rogpeppe> jimbaker: ^
[18:06] <rogpeppe> i don't see any traceback
[18:07] <rogpeppe> this is how juju-admin initialize is being invoked:
[18:07] <rogpeppe> juju-admin initialize --instance-id='$(curl http://169.254.169.254/1.0/meta-data/instance-id)'  --admin-identity=sham --provider-type='ec2'
[18:07] <rogpeppe> i'm wondering if admin-identity needs to be in a particular format
[18:08] <rogpeppe> ah, got it!
[18:09] <rogpeppe> wonderful how explaining things to people so often solves the problem...
[18:09] <rogpeppe> (not that it's solved for definite yet - waiting for the machine to boot now)
[18:15] <rogpeppe> dammit, i was wrong.
[18:18] <rogpeppe> i think i've seen it now though...
[18:24] <niemeyer> Ok.. off the call with fwereade_, talking to mthaddon about store now
[18:28] <rogpeppe> dammit, i wrote that function once and can't find it! anyone know of a way to grep through all files in all branches in a bzr history? the bzr-grep plugin doesn't seem to do it.
[18:30] <niemeyer> hazmat: It'd be good to have a call at some point today/tomorrow with you, fwereade_, and myself, to sync up on that conversation
[18:31] <niemeyer> hazmat: Mainly clarification of the whole series/etc conversation
[18:31] <hazmat> niemeyer, i'm game for it now if you'd like
[18:31] <niemeyer> hazmat: fwereade_ just stepped out for some family time after about 2h of phone call
[18:32] <niemeyer> hazmat: We both need a break before diving into it again
[18:32] <rogpeppe> ah, found bzr-search and found my code!
[18:32] <hazmat> niemeyer, ic fair enough, i hadn't realized, i'm around whenever you guys are ready
[18:32] <hazmat> niemeyer, also the unit-stop spec could use a review, just pushed the latest
[18:34] <niemeyer> hazmat: Aweomse, will have a look
[18:35] <hazmat> niemeyer, i liked awsum ;-)
[18:35] <hazmat> and thanks
[18:35] <niemeyer> hazmat: Me too.. I also found funny the way it was ignored :)
[18:36] <niemeyer> hazmat: Like "OMG, stop the bikeshed!" :)
[18:40] <hazmat> hmm.. where oh where do we sync settings
[18:42] <hazmat> ah there it is.. deploy
[19:10]  * niemeyer perceived fwereade_ seems to have been hit by the network bug in Precise too
[19:12] <niemeyer> [niemeyer@gopher ~]% ps auxw | grep chromium-browser | wc -l
[19:12] <niemeyer> 10
[19:12] <niemeyer> [niemeyer@gopher ~]% killall chromium-browser
[19:12] <niemeyer> chromium-browser: no process found
[19:12] <niemeyer> Why oh why
[19:13]  * niemeyer invokes awk powers to do a trivial action.. poor normal users
[19:20] <rogpeppe> all tests pass. woop woop.
[19:20] <rogpeppe> we have lift off
[19:25] <rogpeppe> niemeyer: a happy note to end the day on: https://codereview.appspot.com/5868051
[19:25]  * rogpeppe is off for the day. see y'all tomorrow.
[19:41] <niemeyer> rogpeppe: Neat!
[19:42] <niemeyer> hazmat: I'm on the stop spec, btw
[20:08] <niemeyer> hazmat: Delivered
[20:09] <niemeyer> jimbaker: Any progress on the specs?
[20:09] <niemeyer> jimbaker: and in their implementation?
[20:12] <niemeyer> rogpeppe: Uh oh. I'm wondering if having pre-req support is a good idea. I'm starting to feel like we're getting tiny changes that are completely independent being piled up on unrelated changes.
[20:31] <niemeyer> Now I'm getting two messages when I post a message in Rietveld.. eventual consistency is rocking our world :)
[20:32] <fwereade_> niemeyer, hazmat: so, it turns out discussion of instance types and environment key deprecation is an excellent family insomnia cure; who would have guessed?
[20:32] <fwereade_> niemeyer, hazmat: that is to say I have time for a chat :)
[20:32] <niemeyer> fwereade_: Hehe :)
[20:32] <niemeyer> fwereade_: I'm game as well
[20:32] <niemeyer> hazmat?
[20:40] <jimbaker> niemeyer, i've been working on two branches re impl, relation-id and relation-hook-context (to manage the contexts associated with using -r in the relation hook commands spec)
[20:41] <niemeyer> jimbaker: I was just reading that spec, actually
[20:41] <jimbaker> niemeyer, i'm going to do another round on the spec for relation-ids (what was called relation-info)
[20:41] <jimbaker> niemeyer, good, i hope it's in the direction you like
[20:41] <niemeyer> jimbaker: Is there anything else being said in addition to "relation-get needs to support the -r <relation id> argument"?
[20:45] <jimbaker> niemeyer,not so much. most of the spec in relation-hook-commands-spec is to describe various scenarios through an example; and to address such details as the specifics of the caching of the relation hook contexts that are read in -r
[20:45] <jimbaker> read in with -r
[20:45] <jimbaker> and how the order they are written out
[20:47] <niemeyer> jimbaker: Cool
[20:48] <niemeyer> jimbaker: I don't think the ordering is important, btw
[20:48] <jimbaker> niemeyer, sounds reasonable
[20:49] <jimbaker> niemeyer, the ideal scenario is that uses a ZK multi
[20:49] <jimbaker> in which case, it goes away
[20:50] <jimbaker> however, one counterpoint is that does make it easier to test against log output corresponding to relation changes, if any
[20:50] <jimbaker> so perhaps just an impl detail
[20:51] <niemeyer> jimbaker: Right
[20:56] <hazmat> niemeyer, i was just chatting with jim and looking over the wip impl. he's out at the moment though,
[20:56] <hazmat> niemeyer, fwereade_ i'm up for the chat
[20:57] <jimbaker> hazmat, i'm around right now
[20:57] <niemeyer> hazmat: He seems alive and kicking :)
[20:57] <hazmat> jimbaker, doh.. yeah i had written that message before i went away myself
[20:57] <jimbaker> and was just chatting with niemeyer re the relation-hook-commands spec
[20:58] <fwereade_> hazmat, niemeyer: heyhey
[21:00] <hazmat> fwereade_, niemeyer  g+ invites out
[21:01] <niemeyer> hazmat: Just give me a couple and will be with you
[21:07] <niemeyer> jimbaker: Review delivered
[22:41] <fwereade_> hazmat, would you follow up the warning thread with a precise and reassuring explanation of what you're planning re env settings? I fear missing some nuance ;)
[22:42] <fwereade_> hazmat, and am a touch sleepy ;)
[22:49] <hazmat> fwereade_, ack, and get some sleep
[23:34] <hazmat> niemeyer, incidentally i noticed there's an lbox bug on milestone selection, it always selects the newest milestone afaics, instead of the oldest open milestone