| TheMue | morning | 09:33 |
|---|---|---|
| wrtp | TheMue: yo! | 09:39 |
| niemeyer | Hello all! | 12:48 |
| andrewsmedina | niemeyer: hi | 12:53 |
| niemeyer | andrewsmedina: Heya | 12:54 |
| === chuck_ is now known as zul | ||
| === chuck_ is now known as zul | ||
| niemeyer | TheMue: ping | 14:29 |
| TheMue | niemeyer: pong | 14:30 |
| niemeyer | TheMue: Heya | 14:30 |
| TheMue | niemeyer: hi | 14:30 |
| niemeyer | TheMue: How're things going there? Good progress on the watchers stuff? | 14:30 |
| TheMue | niemeyer: now yes, had two hard days hunting a bug | 14:31 |
| niemeyer | TheMue: Oh? | 14:31 |
| TheMue | niemeyer: yeah, didn't wanted as i wanted it to do | 14:32 |
| niemeyer | TheMue: Cool.. glad you're unblocked | 14:33 |
| TheMue | niemeyer: first i had to find out that a watch of GetW() won't fire later if a non-existing node is created (like the watch of ExistsW()) | 14:33 |
| niemeyer | TheMue: Yeah, it fails immediately I believe | 14:34 |
| niemeyer | TheMue: So the watch is never established | 14:34 |
| mthaddon | niemeyer: have you seen there are some questions outstanding on the charmstore RT? | 14:36 |
| niemeyer | mthaddon: Nope | 14:36 |
| niemeyer | mthaddon: I missed those | 14:36 |
| TheMue | niemeyer: and in the tests i had to put those changes i'm watching in a goroutine. you'll see, i'll check in today | 14:36 |
| niemeyer | mthaddon: I'm working on stats, btw | 14:36 |
| niemeyer | mthaddon: Almost ready, but need some reviews | 14:36 |
| mthaddon | niemeyer: ok, thx - if you could take a look and get back to me (via the RT or here) on the questions when you get a chance that'd be great | 14:43 |
| niemeyer | mthaddon: Definitely | 14:44 |
| niemeyer | mthaddon: Done | 15:07 |
| niemeyer | I'm stepping out for lunch, biab | 15:07 |
| flacoste | hi SpamapS, are you uploading a new juju version before final freeze (today)? the archive version still doesn't support constraints | 15:43 |
| hazmat | fwereade_, i'm looking over the orchestra constraints branch,d o you have a moment to chat regrading | 15:46 |
| fwereade_ | hazmat, ofc | 15:46 |
| hazmat | mostly i'm curious how reliable the cobbler profile data and arch data is | 15:46 |
| fwereade_ | hazmat, it's installed as part of orchestra and so should be solid; but it is true that I have no way of dealing with an installation that someone's messed around with enough | 15:48 |
| fwereade_ | hazmat, OTOH setting up distros/profiles is a bit headachey and IMO one of the really nice things about orchestra is that it does that for you so you don't have to worry about it | 15:50 |
| flacoste | fwereade_, hazmat: shouldn't we just remove the orchestra provider, now that we have maas? | 15:50 |
| flacoste | Daviey: wdyt? ^^^ | 15:50 |
| flacoste | Daviey: what's the plan with the packages in the archives? | 15:51 |
| flacoste | leave it universe? | 15:51 |
| hazmat | flacoste, from a juju perspective, maas for 12.04 has significantly less features | 15:53 |
| flacoste | hazmat: really, how so? | 15:53 |
| hazmat | flacoste, because it can only address machines by name | 15:53 |
| hazmat | ie. poor constraints support | 15:53 |
| fwereade_ | flacoste, I expect we will want to retire the orchestra provider sooner rather than later though | 15:53 |
| Daviey | hmm | 15:57 |
| Daviey | What can the juju prover for orchetra do? | 15:57 |
| Daviey | There isn't a problem leaving it in i guess | 15:58 |
| Daviey | I mean, it's not exposed to the user, right? | 15:58 |
| flacoste | hazmat: but you still have to implement the orchestra constraints support, dropping it would means less maintenance :-) | 15:59 |
| hazmat | it can use a specified orchestra class as a constraint | 15:59 |
| hazmat | flacoste, the orchestra class support for constraints is already in | 15:59 |
| hazmat | there's additional branch in review which i'm looking at that adds arch/series | 15:59 |
| fwereade_ | hazmat, sadly, it *doesn't* add arch, mainly because I am an idiot :( | 16:01 |
| fwereade_ | hazmat, it matches existing arch | 16:01 |
| fwereade_ | hazmat, that branch is a result of me suddenly realising that ubuntu-series is critical, and totally unaddressed in orchestra | 16:02 |
| Daviey | fwereade_: *please* tell me you aren't doing development for the orchestra provider at the moment. | 16:03 |
| flacoste | Daviey, hazmat, fwereade_: yeah, that's my point about reducing maintenance | 16:04 |
| flacoste | :-) | 16:04 |
| flacoste | not doing work is great! | 16:05 |
| flacoste | the zen of non-doing | 16:05 |
| hazmat | Daviey, flacoste having a useable baremetal solution that works with juju's expectation of a provider is important | 16:05 |
| hazmat | even without cosntraints, right now neither maas nor orchestra does that because their ignoring series | 16:06 |
| hazmat | which is critical to being able to deploy a charm as intended because the charm tied to a series | 16:06 |
| flacoste | right, but maas only support precise | 16:06 |
| hazmat | and we have zero precise charms atm | 16:07 |
| hazmat | that's supposed to change this week | 16:07 |
| hazmat | but come 12.10 we either expect folks to move core infrastructure pieces off an LTS release for a newer version of maas? | 16:08 |
| fwereade_ | Daviey, sorry to say I am, simply because we have this provider that (1) still exists and (2) doesn't work right | 16:08 |
| Daviey | fwereade_: wow.. if it doesn't ork.. drop it. | 16:09 |
| Daviey | Really.. It's a *total* waste of time working o Orchestra. | 16:09 |
| Daviey | Would it help if i removed orchestra fro the archive? | 16:10 |
| flacoste | fwereade_: i agree | 16:10 |
| flacoste | Daviey: we are getting the following error when bootstrapping: | 16:10 |
| flacoste | SSH authorized/public key not found. | 16:10 |
| flacoste | 2012-04-12 12:09:14,139 ERROR SSH authorized/public key not found. | 16:10 |
| fwereade_ | Daviey, flacoste: I would personally have no problem with that, but it feels like this is a very late stage to be doing this | 16:10 |
| hazmat | woah.. it does work | 16:10 |
| Daviey | flacoste: fixed | 16:11 |
| flacoste | Daviey: how did you fix that? | 16:11 |
| flacoste | i see | 16:11 |
| flacoste | you just created an ssh key | 16:11 |
| Daviey | right | 16:11 |
| flacoste | Daviey: pgraner says hold on your fire :-) | 16:12 |
| flacoste | but thanks! | 16:12 |
| * Daviey lets go of the fire. | 16:12 | |
| flacoste | Daviey: +1 to dropping orchestra from the archive :-) | 16:12 |
| flacoste | Daviey: better to be honest to our users about what's happening here | 16:12 |
| flacoste | hazmat: yes, it's expected that people who want to use 12.10 will use more recent version of juju and maas | 16:13 |
| fwereade_ | Daviey, flacoste: my understanding from Budapest was that we'd *maybe* drop orchestra if we had maas doing everything we wanted by 12.04; when I came back to the python to resurrect the constraints work a couple of weeks ago, it was still around and maas was still a little up in the air | 16:13 |
| fwereade_ | Daviey, flacoste: I guess I should have made a bunch of noise about it then | 16:13 |
| flacoste | Daviey: Invalid host for SSH forwarding: ssh: Could not resolve hostname node-00e081d1b147.local: Name or service not known | 16:13 |
| Daviey | flacoste: that just means it's not switched on/installed. | 16:14 |
| flacoste | Daviey: did we set it up with IPMI? | 16:15 |
| fwereade_ | Daviey, flacoste: I think I may have been unclear: the specific thing that doesn't work with orchestra is series selection (that is, deploying oneiric/foobar may or may not get an oneiric machine on which to run fobar) | 16:17 |
| flacoste | fwereade_: right, but that's still work that has to happen for an unsupported piece of software | 16:18 |
| flacoste | i'd say remove it from juju and leave the community to support it if they need it | 16:18 |
| hazmat | please don't remove orchestra from the archive.. for 12.04 its the only bare-metal provider that will work well with juju both for constraints and soon series. | 16:19 |
| hazmat | i understand that orchestra is dead, but maas doesn't fufill the needs of users who want to use it with juju at the moment imo | 16:20 |
| hazmat | future dev will resolve that i'm sure, but that's not about 12.04. | 16:20 |
| flacoste | hazmat: maas works well enough for precise | 16:25 |
| flacoste | keeping orchestra around just confuses thing | 16:25 |
| fwereade_ | Daviey, flacoste: that's a decision I would have been comfortable supporting *if* we'd had a public discussion about it a month or so ago, and determined that maas was in a position to entirely replace it; but (1) we didn't, and (2) it isn't | 16:25 |
| flacoste | i'd rather handle flak for going without 1 and 2 | 16:26 |
| flacoste | than handle the confusion for the next 5 years | 16:26 |
| fwereade_ | flacoste, ok, it works well enough for precise; but it seems to me to be bad form to entirely drop the ability to provision pre-precise machines | 16:27 |
| flacoste | why? | 16:27 |
| flacoste | they can stick with 11.10 if they like it | 16:27 |
| Daviey | this is flippin' crazy | 16:28 |
| fwereade_ | flacoste, largely because I imagine people to have been using it to deploy pre-precise machines and I'm not sure a supposed upgrade should take features away from people | 16:28 |
| flacoste | fwereade_: we remove features all the time | 16:29 |
| flacoste | especially ones that have few users | 16:30 |
| flacoste | otherwise you just grow a pile of unmaintainable mess | 16:30 |
| flacoste | it's not like we are forcing upgrades on anyone here | 16:30 |
| fwereade_ | flacoste, fair point; I think there's a disconnect somewhere between this and the "we have users now, we can't just keep breaking their installations on upgrade" attitude I have recently developed | 16:32 |
| fwereade_ | flacoste, does anyone have any numbers on what providers people are using? | 16:33 |
| flacoste | fwereade_: you should know this better than I :-) | 16:33 |
| flacoste | maybe jorge would know | 16:33 |
| fwereade_ | flacoste, my main worry is that *anyone* wanting to use juju for bare metal will have been using orchestra, and that if we trash that and offer only a less-featureful alternative we'll be chasing them away | 16:34 |
| flacoste | fwereade_: it's not less featureful | 16:35 |
| flacoste | stop that | 16:35 |
| flacoste | these "more" features don't exist yet | 16:35 |
| flacoste | constraints -> that's not a feature they can use | 16:35 |
| flacoste | it requires more development to support | 16:35 |
| flacoste | it's more featureful than the existing setup | 16:35 |
| fwereade_ | flacoste, depending on exactly what machines you have set to use juju, it could be argued either way | 16:36 |
| fwereade_ | s/to use/to be used by/ | 16:36 |
| fwereade_ | flacoste, if you currently have a couple of dozen oneiric machines running oneiric charms, it's fine; and (1) that's what any users will have been using, and (2) maas can't do that | 16:37 |
| hazmat | constraints support for orchestra is already in trunk | 16:38 |
| niemeyer | wrtp: ping | 16:38 |
| wrtp | niemeyer: pong | 16:39 |
| niemeyer | wrtp: Heya | 16:39 |
| niemeyer | wrtp: How're things going there? | 16:39 |
| fwereade_ | flacoste, hazmat: indeed, and has been for a while; this is more a bug than a feature, because I just wasn't handling every applicable constraint correctly | 16:39 |
| wrtp | niemeyer: pretty slow getting back up to speed yesterday, but more or less back in the groove now, doing the tests for the ssh forwarding stuff | 16:39 |
| wrtp | niemeyer: not entirely convinced that my approach to testing error paths was the correct one. i think perhaps i *should* try to provoke all the desired misbehaviours from ssh. | 16:40 |
| wrtp | niemeyer: am intending to get around to looking at your reviews soon! | 16:41 |
| wrtp | niemeyer: how about you? | 16:42 |
| niemeyer | wrtp: Super | 16:45 |
| niemeyer | wrtp: I'm good as well.. have been a bit slow early this week too, but also getting up to speed | 16:46 |
| niemeyer | wrtp: Happy about the stats stuff that's coming into the store | 16:46 |
| wrtp | niemeyer: cool. it'll be nice to see some feedback. | 16:47 |
| wrtp | niemeyer: (from the store traffic, that is) | 16:47 |
| wrtp | niemeyer: are we still planning a meeting on mondays? | 16:47 |
| niemeyer | wrtp: Yeah | 16:48 |
| niemeyer | wrtp: We've lacked the last couple of meetings | 16:48 |
| niemeyer | wrtp: But we should definitely do them from now on | 16:48 |
| wrtp | niemeyer: sounds good. | 16:48 |
| wrtp | niemeyer: perhaps we could do them when you first come on line (given you're in the latest time zone)? i usually have to finish fairly promptly on monday evenings. | 16:49 |
| fwereade_ | wrtp, +1 | 16:50 |
| niemeyer | wrtp: Isn't the timing we agreed to good?he timing we've agreed to sounds | 16:51 |
| niemeyer | Erm | 16:51 |
| niemeyer | wrtp: Isn't the timing we agreed to good? | 16:51 |
| wrtp | niemeyer: i don't remember agreeing to a timing... | 16:52 |
| wrtp | niemeyer: perhaps i'm missing a calendar entry | 16:52 |
| niemeyer | wrtp: 14UTC was the one we settled on | 16:53 |
| wrtp | niemeyer: that sounds fine to me. | 16:54 |
| wrtp | niemeyer: i'll put an entry in my calendar | 16:56 |
| niemeyer | wrtp: Cheers | 16:57 |
| wrtp | niemeyer, fwereade_: i've made a calendar for us and added the meetings to it. i dunno if that's the best way to do it. | 17:08 |
| niemeyer | wrtp: We can try it out and see | 17:10 |
| wrtp | niemeyer: at least it makes it easy for us to amend the dates and times easily and be reminded of the change... | 17:11 |
| hazmat | bcsaller, ping | 17:55 |
| bcsaller | hazmat: hey | 17:55 |
| hazmat | bcsaller, are we ready to get the last subs branches in.. | 17:55 |
| bcsaller | you approved it yesterday | 17:56 |
| hazmat | bcsaller, right.. but is it merged? | 17:56 |
| bcsaller | yes | 17:56 |
| hazmat | sweet! | 17:56 |
| bcsaller | :) | 17:56 |
| wrtp | niemeyer, fwereade: i'm off. see you tomorrow. | 18:02 |
| niemeyer | wrtp: Have a good EOD | 18:03 |
| wrtp | niemeyer: will do, ta! | 18:03 |
| hazmat | bcsaller, the change to lxc broke the tests | 18:15 |
| hazmat | actually the env.defaults thing that i thought got removed.. | 18:15 |
| bcsaller | ugh, those didn't run on my last try (and yes that should have been removed), checking | 18:16 |
| hazmat | bcsaller, i'm on it | 18:21 |
| hazmat | i'm rolling up the fix into my next merge | 18:22 |
| hazmat | its a one liner | 18:22 |
| bcsaller | hazmat: thanks | 18:23 |
| hazmat | bcsaller, i was realizing though that the subordinate state change from last week is still going to cause issue with extant envs because of the topology change, even with the transparent upgrade... actually because of the transparent upgrade | 18:24 |
| hazmat | because there are older agents running around | 18:24 |
| bcsaller | w/o that upgrade code... | 18:25 |
| hazmat | its actually worse than not upgrading it | 18:25 |
| bcsaller | hmm | 18:25 |
| hazmat | because all of the agents are going to fail simulatenously without any user warning | 18:25 |
| hazmat | i think we need to disable that migration | 18:25 |
| hazmat | its changing the topology format, so really nothing run older code is going to survive. | 18:26 |
| hazmat | its better to just error out on the cli b4 that happens | 18:26 |
| hazmat | bcsaller, thoughts? | 18:27 |
| bcsaller | its odd, because even as far back as reviewing the spec we thought this was a good idea. I'm trying to think how'd we make migration like this work at all if this is the case now | 18:27 |
| bcsaller | would we force the agents to restart? | 18:28 |
| hazmat | bcsaller, they won't get the new code. restart doesn't help | 18:28 |
| hazmat | without consistent code versioning and a notion of code/db upgrade as an explicit op, incompatible state changes are hosers | 18:28 |
| bcsaller | I guess it could support returning the topo in the requested version as the data is still there, but that wouldn't work in all cases | 18:29 |
| bcsaller | and would still require eating this atleast once to get there | 18:30 |
| hazmat | bcsaller, we've got maybe 30m to resolve this, afaics the only thing to do is to disable the transparent topo migration | 18:30 |
| bcsaller | then thats what we should do I guess | 18:31 |
| hazmat | bcsaller, do you see any alternative? | 18:31 |
| bcsaller | no, some of its a data reorg and some of its new data | 18:32 |
| bcsaller | the new data doesn't leave us a choice | 18:32 |
| bcsaller | or we could just forward from 1 on read for now (for v2 clients) | 18:33 |
| bcsaller | but that new data has to live in there | 18:33 |
| hazmat | new data isn't a problem by itself dependin on the struct (ie a new key in a dict is fine), its the struct change that kills it. | 18:34 |
| bcsaller | then v2 clients will just refuse to connect to v1 topos for now | 18:35 |
| bcsaller | hazmat: so rather than call migrate you just raid incompat version. Do you want to make that change? | 18:37 |
| hazmat | bcsaller, done | 18:39 |
| bcsaller | cool. It seemed like a good plan at the time :-/ | 18:39 |
| hazmat | bcsaller, jimbaker, fwereade_ all changes are in, pls consider trunk frozen | 19:00 |
| niemeyer | Woohay! | 19:13 |
| flacoste | hazmat: so juju is now complaining on juju deploy mysql | 19:22 |
| flacoste | about series constraints not being implemented | 19:22 |
| flacoste | Error processing 'cs:precise/mysql': entry not found | 19:22 |
| flacoste | and Bad 'ubuntu-series' constraint 'oneiric': MAAS currently only provisions machines running precise | 19:22 |
| flacoste | if i try to do oneiric/mysql | 19:22 |
| flacoste | what's my work-around until there is a precise mysql charm? | 19:23 |
| jimbaker | hazmat, awesome news! | 19:24 |
| hazmat | flacoste, with maas.. you'd have to pull the charm down to local disk | 19:35 |
| hazmat | and put in a charm repo under a precise series | 19:35 |
| hazmat | the precise version of that charm does not exist in the store | 19:36 |
| flacoste | hazmat: that's what i'm doing now | 19:39 |
| niemeyer | hazmat: Are you querying the cs automatically to feed the web UI in any way? | 19:46 |
| hazmat | niemeyer, not atm. i'm planning to update the ui to mark items not in the charm store when looking at the official series | 19:53 |
| hazmat | niemeyer, it pre-dates the charm store, and there is no query on the charm store outside of querying the thing you want directly by name afaik | 19:54 |
| niemeyer | hazmat: Cool, no worries.. I'm happy to extend with stuff that makes things simpler on the other end | 19:55 |
| niemeyer | hazmat: I'm asking mainly due to stats | 19:55 |
| niemeyer | hazmat: Please don't add any automatic querying without syncing up | 19:55 |
| niemeyer | hazmat: In case you need/want to query one of the existing APIs, I'll hand you a parameter so it's not counted as a legitimate request | 19:56 |
| hazmat | niemeyer, cool, sounds good | 19:57 |
| hazmat | niemeyer, if you have a url to grab stats that would be nice to pull in | 19:57 |
| niemeyer | hazmat: I will have, many of those actually | 19:57 |
| niemeyer | hazmat: Per charm, etc | 19:58 |
| === jelmer_ is now known as jelmer | ||
| SpamapS | jimbaker: https://code.launchpad.net/~jimbaker/juju/relation-hook-commands-spec/+merge/97733 .. you should land this in docs :) | 22:47 |
| * SpamapS is trying to close out the florence milestone | 22:47 | |
| jimbaker | SpamapS, sounds good | 22:53 |
| SpamapS | jimbaker: there are 4 open, Approved bugs left in florence, all for lp:juju/docs, all for you :) | 22:58 |
| jimbaker | SpamapS, yeah, i was planning on combining those together in a more cohesive whole, but it's probably best to do that as a second step | 22:59 |
| SpamapS | jimbaker: I'll push them off to the galapagos milestone if you're not ready to commit them just yet. | 23:06 |
| jimbaker | SpamapS, that probably makes sense | 23:30 |
| SpamapS | Blueprints: | 23:33 |
| SpamapS | 1 Implemented | 23:33 |
| SpamapS | Bugs: | 23:33 |
| SpamapS | 108 Fix Released | 23:33 |
| SpamapS | Kapil and William tie for most assigned at 27 :) | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!