| *** cloudchimp has quit IRC | 00:23 | |
| *** amyt has quit IRC | 00:31 | |
| *** grapex has quit IRC | 00:38 | |
| *** amyt has joined #openstack-meeting-alt | 00:50 | |
| *** rnirmal has quit IRC | 00:50 | |
| *** sacharya has joined #openstack-meeting-alt | 00:52 | |
| *** imsplitbit has quit IRC | 01:15 | |
| *** bdpayne has quit IRC | 01:26 | |
| *** cloudchimp has joined #openstack-meeting-alt | 02:07 | |
| *** amyt has quit IRC | 02:07 | |
| *** amyt has joined #openstack-meeting-alt | 02:08 | |
| *** cloudchimp has quit IRC | 02:12 | |
| *** amyt has quit IRC | 02:12 | |
| *** amyt has joined #openstack-meeting-alt | 02:13 | |
| *** sacharya1 has joined #openstack-meeting-alt | 02:19 | |
| *** amyt has quit IRC | 02:21 | |
| *** amyt has joined #openstack-meeting-alt | 02:21 | |
| *** sacharya has quit IRC | 02:22 | |
| *** cloudchimp has joined #openstack-meeting-alt | 02:27 | |
| *** bdpayne has joined #openstack-meeting-alt | 02:42 | |
| *** imsplitbit has joined #openstack-meeting-alt | 02:50 | |
| *** vipul is now known as vipul|away | 02:52 | |
| *** bdpayne has quit IRC | 03:02 | |
| *** vipul|away is now known as vipul | 03:08 | |
| *** cloudchimp has quit IRC | 03:43 | |
| *** yamahata_ has joined #openstack-meeting-alt | 03:49 | |
| *** imsplitbit has quit IRC | 03:49 | |
| *** bdpayne has joined #openstack-meeting-alt | 04:14 | |
| *** bdpayne has quit IRC | 04:46 | |
| *** bdpayne has joined #openstack-meeting-alt | 05:30 | |
| *** sacharya1 has quit IRC | 05:46 | |
| *** bdpayne has quit IRC | 06:08 | |
| *** bdpayne has joined #openstack-meeting-alt | 06:26 | |
| *** bdpayne has quit IRC | 07:18 | |
| *** amyt has quit IRC | 09:56 | |
| *** dhellmann has joined #openstack-meeting-alt | 11:34 | |
| *** dhellmann has quit IRC | 13:55 | |
| *** imsplitbit has joined #openstack-meeting-alt | 14:35 | |
| *** amyt has joined #openstack-meeting-alt | 15:02 | |
| *** dhellmann has joined #openstack-meeting-alt | 15:04 | |
| *** cloudchimp has joined #openstack-meeting-alt | 15:05 | |
| *** djohnstone has joined #openstack-meeting-alt | 15:18 | |
| *** sacharya has joined #openstack-meeting-alt | 15:23 | |
| *** grapex has joined #openstack-meeting-alt | 15:24 | |
| *** grapex has quit IRC | 15:25 | |
| *** grapex has joined #openstack-meeting-alt | 15:26 | |
| *** amyt has quit IRC | 15:30 | |
| *** amyt has joined #openstack-meeting-alt | 15:32 | |
| *** cp16net is now known as cp16net|away | 15:32 | |
| *** cp16net|away is now known as cp16net | 15:32 | |
| *** sacharya has quit IRC | 15:33 | |
| *** rnirmal has joined #openstack-meeting-alt | 15:33 | |
| *** cp16net is now known as cp16net|away | 15:45 | |
| *** esp has joined #openstack-meeting-alt | 15:49 | |
| *** amyt has quit IRC | 16:05 | |
| *** amyt has joined #openstack-meeting-alt | 16:05 | |
| *** cp16net|away is now known as cp16net | 16:12 | |
| *** bdpayne has joined #openstack-meeting-alt | 16:12 | |
| *** sacharya has joined #openstack-meeting-alt | 16:18 | |
| *** grapex has quit IRC | 16:32 | |
| *** grapex has joined #openstack-meeting-alt | 16:33 | |
| *** grapex has quit IRC | 16:35 | |
| *** grapex has joined #openstack-meeting-alt | 16:35 | |
| *** esp has joined #openstack-meeting-alt | 16:59 | |
| *** esp has left #openstack-meeting-alt | 17:00 | |
| *** heckj has joined #openstack-meeting-alt | 17:15 | |
| *** dhellmann is now known as dhellmann-afk | 17:46 | |
| *** cp16net is now known as cp16net|away | 18:56 | |
| *** cp16net|away is now known as cp16net | 18:56 | |
| *** imsplitbit has quit IRC | 19:06 | |
| *** sacharya has quit IRC | 19:08 | |
| *** sacharya has joined #openstack-meeting-alt | 19:14 | |
| *** cp16net is now known as cp16net|away | 19:33 | |
| *** cp16net|away is now known as cp16net | 19:42 | |
| *** imsplitbit has joined #openstack-meeting-alt | 20:12 | |
| *** dhellmann-afk is now known as dhellmann | 20:23 | |
| *** amyt has quit IRC | 20:36 | |
| *** amyt has joined #openstack-meeting-alt | 20:36 | |
| *** cp16net is now known as cp16net|away | 21:45 | |
| *** rnirmal has quit IRC | 21:47 | |
| *** yidclare has joined #openstack-meeting-alt | 21:53 | |
| *** esp has joined #openstack-meeting-alt | 21:58 | |
| *** hub_cap has joined #openstack-meeting-alt | 21:59 | |
| hub_cap | hai | 21:59 |
|---|---|---|
| *** SlickNik has joined #openstack-meeting-alt | 21:59 | |
| hub_cap | #startmeeting reddwarf | 22:00 |
| openstack | Meeting started Tue Feb 19 22:00:03 2013 UTC. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. | 22:00 |
| *** SlickNik has left #openstack-meeting-alt | 22:00 | |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 22:00 |
| *** openstack changes topic to " (Meeting topic: reddwarf)" | 22:00 | |
| vipul | sup | 22:00 |
| openstack | The meeting name has been set to 'reddwarf' | 22:00 |
| *** cp16net|away is now known as cp16net | 22:00 | |
| *** datsun180b has joined #openstack-meeting-alt | 22:00 | |
| *** robertmyers has joined #openstack-meeting-alt | 22:00 | |
| *** kagan has joined #openstack-meeting-alt | 22:00 | |
| *** jcru has joined #openstack-meeting-alt | 22:00 | |
| hub_cap | #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting | 22:00 |
| cp16net | work | 22:00 |
| hub_cap | #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-12-22.00.html | 22:00 |
| robertmyers | hello | 22:00 |
| *** demorris has joined #openstack-meeting-alt | 22:00 | |
| *** SlickNik has joined #openstack-meeting-alt | 22:00 | |
| hub_cap | ok time to chill for a sec to let people come in | 22:00 |
| SlickNik | woot | 22:01 |
| annashen | good afternoon | 22:01 |
| grapex | hai | 22:01 |
| * hub_cap creates some dummy BPs | 22:02 | |
| clarkb | before I forget I want to point out that the reason python-reddwarfclient dependencies pull in the old version is a pypi mirror somewhere has that version cached. you can recreate with `pip install -M -U python-reddwarfclient` | 22:02 |
| datsun180b | howdy | 22:02 |
| esp | nice. thx clarkb! | 22:02 |
| vipul | clarkb: how can we get jenkins to do this? | 22:03 |
| datsun180b | oh, thank you. did someone already ask you about that today? | 22:03 |
| hub_cap | whisper sweet nothings into jenkins ear vipul | 22:03 |
| clarkb | datsun180b: no not yet | 22:03 |
| clarkb | one work around is to pin the dependency on the 0.1.1 version in your pip-requires | 22:03 |
| clarkb | then when the mirrors stop caching the old stuff you can remove that pin | 22:03 |
| grapex | That seems doable | 22:03 |
| hub_cap | that makes sense | 22:04 |
| grapex | Currently we submit Reddwarf changes that we know will fail anyway until client gets merged in, so that wouldn't be much worse in the short term | 22:04 |
| hub_cap | okey lets get to the meeting topics | 22:04 |
| hub_cap | #topic Update to Action items | 22:04 |
| *** openstack changes topic to "Update to Action items (Meeting topic: reddwarf)" | 22:04 | |
| hub_cap | ive created 2 blueprints in each of our 3 repos just fyi. feel free to use them vipul & co | 22:05 |
| vipul | hub_cap: tnx | 22:05 |
| SlickNik | okay, thanks… | 22:05 |
| kagan | was one/two of those for percona ? | 22:05 |
| hub_cap | kagan: they just say dummybpX | 22:05 |
| hub_cap | feel fre to rename them | 22:05 |
| vipul | kagan: i see you're using your real name now | 22:05 |
| kagan | and that's how i find them? by name ? | 22:05 |
| kagan | yep | 22:05 |
| SlickNik | I've updated the wiki clarifying that we're implementing sec-groups as extensions to reddwarf. | 22:06 |
| hub_cap | https://blueprints.launchpad.net/reddwarf-integration | 22:06 |
| kagan | wasn't that different to begin with. more a decoration than a nick ... | 22:06 |
| hub_cap | u can see them there | 22:06 |
| SlickNik | #link https://wiki.openstack.org/wiki/Reddwarf-security-groups | 22:06 |
| kagan | ok | 22:06 |
| SlickNik | Was just in the process of updating the blueprint as well. | 22:06 |
| hub_cap | nice SlickNik, /aside, i love the new wiki format | 22:06 |
| vipul | #agreed | 22:07 |
| SlickNik | Yeah, I was wondering what happened and noticed that the wiki level'ed up. :) | 22:07 |
| hub_cap | it ate a mushroom | 22:07 |
| cp16net | word! | 22:07 |
| hub_cap | hmmmm next one, hub_cap needs to not be so lame..... i didnt accomplish this one | 22:07 |
| hub_cap | ps ive updated the rate-limits BP but forgot ot update quotas, ill do that during the meeting | 22:08 |
| hub_cap | SlickNik: i see youve added stevedore to the possibilities in that BP, have u looked @ yet? | 22:08 |
| SlickNik | I started looking into stevedore to see how we can use them for extensions, still figuring things out there. | 22:08 |
| hub_cap | the filter scheduler in cinder is a good starting point | 22:08 |
| esp | np. the rate limts one still needs to be blessed | 22:08 |
| hub_cap | all of the filters are extension points | 22:08 |
| SlickNik | So not complete, and will action myself to continue on that. | 22:08 |
| hub_cap | esp: ill bless it now | 22:08 |
| SlickNik | #action SlickNik still looking at stevedore for entry points to extensions/ https://github.com/dreamhost/stevedore | 22:09 |
| hub_cap | esp: done | 22:09 |
| esp | thx. I do have a question for you and the group on this but we can circle back on it after the agenda. | 22:09 |
| hub_cap | SlickNik: https://github.com/openstack/cinder/blob/master/cinder/openstack/common/scheduler/filter.py | 22:09 |
| hub_cap | thats where its imported | 22:09 |
| hub_cap | esp: okey | 22:10 |
| SlickNik | thx hub_cap | 22:10 |
| hub_cap | so as for teh api markdown. im starting it tomorrow. its my task now that im done w/ cinder multi volume | 22:10 |
| vipul | hub_cap: is this supposed to give us more of selective extensions? | 22:10 |
| vipul | as oppsoed to all/nothng | 22:10 |
| hub_cap | vipul: ya | 22:10 |
| hub_cap | u can define them in the egg | 22:11 |
| cp16net | if i havnt said it enough... great job hub_cap | 22:11 |
| hub_cap | lulz cp16net | 22:11 |
| hub_cap | if anyone is interested (https://github.com/openstack/cinder/commit/6c708d12f58eb20fce6733f1f6fd08d978570775) | 22:11 |
| SlickNik | vipul: yeah, that's the idea. | 22:11 |
| SlickNik | #info http://stevedore.readthedocs.org/en/latest/ | 22:11 |
| vipul | ooh multi volumes | 22:11 |
| vipul | shiny | 22:11 |
| SlickNik | nice! | 22:12 |
| hub_cap | yup vipul, and its done. so im working on the markdown for the api, as of tomrrow morning | 22:12 |
| hub_cap | i guess "as of tomorrow" doesnt make sense | 22:12 |
| vipul | what's the usecase fo multi-volumes in redwarf? | 22:12 |
| vipul | or is this just a tangentential thing | 22:12 |
| hub_cap | well.. | 22:13 |
| hub_cap | u can have different backends for different service types, high iops for users who need it, etc.. | 22:13 |
| hub_cap | somewhat tangental but its leveragable | 22:13 |
| hub_cap | SlickNik: hows that automated fandangled reddwarf client | 22:14 |
| vipul | k i shoulud probably read bp | 22:14 |
| SlickNik | I've acquired dkehn's vm-gate task, so I'm still looking at that and the python-reddwarfclient packaging tasks | 22:14 |
| hub_cap | sounds like a RPG | 22:14 |
| SlickNik | heh, well, still work in progress. | 22:14 |
| hub_cap | man, done w/ the action items!! | 22:14 |
| hub_cap | #topic Quotas / Limits Updates | 22:15 |
| *** openstack changes topic to "Quotas / Limits Updates (Meeting topic: reddwarf)" | 22:15 | |
| hub_cap | lets start w/ quotas | 22:15 |
| SlickNik | #action SlickNik looking into vm-gate and release of python-reddwarfclient | 22:15 |
| *** demorris has left #openstack-meeting-alt | 22:15 | |
| *** demorris has joined #openstack-meeting-alt | 22:15 | |
| vipul | Esmute ^^ | 22:16 |
| hub_cap | ps i will be proposing some /limits calls in teh markdown so yall can say yes/no to them once i push them for review | 22:16 |
| hub_cap | itll be a bit nicer than seeing htem in the BPs | 22:16 |
| Esmute | i have modified the rd client to update quota info for a tenant | 22:17 |
| vipul | wiki's a godo place for now too | 22:17 |
| demorris | hub_cap: where is the markdown going to live? I know you mentioned it earlier | 22:17 |
| Esmute | sure hub_cap.. ill review it with esp | 22:18 |
| Esmute | in the client, the /quotas will also give you the absolute limits... but that call is admin only | 22:19 |
| hub_cap | #link https://github.com/stackforge/database-api | 22:19 |
| hub_cap | demorris: ^ ^ | 22:19 |
| hub_cap | Esmute: ill be sure to add that to the api doc | 22:19 |
| Esmute | so i have a submitted a patch for the quota stuff.. will be adding an integration tests to it and resubmit some times today | 22:20 |
| grapex | hub_cap: Any update from Mike A. on his work for that repo? | 22:20 |
| vipul | hub_cap: what's the process for going from that repo to actual public facing docs | 22:20 |
| hub_cap | nope grapex :( but thats my fault for not asking | 22:20 |
| hub_cap | vipul: there is some magic stuff the doc team has built for that | 22:20 |
| hub_cap | not sure exactly | 22:20 |
| vipul | are we 'non-core' going to be able to leverage the same? | 22:21 |
| hub_cap | but id prefer starting at the repo instead of wiki, mainly cuz anyone can propose, and only core can commit | 22:21 |
| hub_cap | vipul: u are core :) | 22:21 |
| vipul | i mean reddwarf is not core | 22:21 |
| vipul | Also, tehre will be some APIs that are WIP, as part of a BP or something, how do we manage what gets into that repo.. should it be stuff already available | 22:22 |
| vipul | maybe this should be part of the api specs topic | 22:22 |
| hub_cap | vipul: ya we can talk about that in a few, but the thought is to ahve the api spec'd out in the next wk or two w/ everything | 22:23 |
| vipul | ok. | 22:23 |
| hub_cap | but ya lets chat it up during that, Esmute are u fin? | 22:23 |
| Esmute | fin? | 22:23 |
| Esmute | finished.. ahh ok | 22:23 |
| hub_cap | http://en.wiktionary.org/wiki/fin#French | 22:23 |
| Esmute | yes. | 22:23 |
| hub_cap | sweet, now rate limits esp | 22:24 |
| esp | k | 22:24 |
| hub_cap | ps looking forward to the quotas stuff Esmute | 22:24 |
| esp | well I just had one bit to clarify | 22:24 |
| esp | the current implementation in progress makes use of the same code as nova's limit controller | 22:24 |
| esp | #link http://api.openstack.org/api-ref.html | 22:25 |
| esp | it was mentioned (and we stumbled upon) usedlimits last week | 22:25 |
| hub_cap | yup | 22:25 |
| hub_cap | #link https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/used_limits.py | 22:26 |
| esp | is it cool to go with /limits for now? I'm not sure we have all the info from the absolute limits to do /userlimits | 22:26 |
| esp | sorry usedlimits | 22:26 |
| hub_cap | esp: it _is_ the same | 22:26 |
| hub_cap | the used limits extension just puts extra things into /limits | 22:26 |
| hub_cap | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/used_limits.py#L82 | 22:26 |
| vipul | esp: do you mean we don't ahve enough from the quotas impl to get those values? | 22:26 |
| esp | ok, for some reason I thought there was more info in usedlimits | 22:26 |
| esp | vipul: yeah | 22:27 |
| hub_cap | there is esp | 22:27 |
| hub_cap | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/used_limits.py#L56 | 22:27 |
| Esmute | with values are you refering too specifically? | 22:27 |
| vipul | esp: Esmute will provide that to you | 22:27 |
| hub_cap | but the extension just uses /limits | 22:27 |
| esp | k, sounds like I need to talk with Esmute :) | 22:28 |
| Esmute | i can provide quota limits and usages information | 22:28 |
| *** kmansel has joined #openstack-meeting-alt | 22:28 | |
| esp | thx | 22:28 |
| hub_cap | cool | 22:28 |
| Esmute | i can show you how and where to get them | 22:28 |
| vipul | hub_cap: we're not doing it as ext. right? | 22:28 |
| vipul | just part of the core call | 22:28 |
| hub_cap | ya i think so | 22:28 |
| hub_cap | it makes more sense | 22:28 |
| vipul | yea, might as well | 22:28 |
| esp | yeah it's right in there with the other core api calls at the moment | 22:28 |
| hub_cap | def. im assuming itll eventully meld together in nova | 22:28 |
| hub_cap | but they have more extensions than actual calls :P | 22:29 |
| hub_cap | esp: done? | 22:29 |
| vipul | esp: yea you should be good to go to implement that with Esmute's changes | 22:29 |
| esp | yes sir | 22:29 |
| hub_cap | awesome. ill be pinging both esp and Esmute this wk for api feedback | 22:29 |
| hub_cap | #topic Percona Image Updates | 22:30 |
| *** openstack changes topic to "Percona Image Updates (Meeting topic: reddwarf)" | 22:30 | |
| hub_cap | kagan: tag yer it | 22:30 |
| kagan | hi | 22:30 |
| kagan | so, we have it working, pretty much | 22:30 |
| hub_cap | very nice | 22:30 |
| kagan | it still runs slower (coming up) compared to Oracle's mysql | 22:30 |
| kagan | and also, there are some loose ends i'd like to go over before submitting to review | 22:30 |
| kagan | i think i'll have something checked in for review today | 22:31 |
| vipul | sweet! got the resize fixed? | 22:31 |
| hub_cap | NICE | 22:31 |
| kagan | we also have some int tests failing, but i think the tests are bad | 22:31 |
| hub_cap | tests are bad? | 22:31 |
| kagan | well, for example, the resize test | 22:32 |
| kagan | it "waits" for status to change from "resize" to "done" (or running or something like that) | 22:32 |
| kagan | but it seems that as part of regular flow, between resizing and up it goes through status "down" for a while. | 22:32 |
| hub_cap | so nova does those things | 22:32 |
| grapex | "down"? | 22:32 |
| grapex | Do you mean SHUTDOWN? | 22:32 |
| vipul | shutdown | 22:32 |
| kagan | yep | 22:33 |
| grapex | It shouldn't do that | 22:33 |
| hub_cap | if for some reason the percona image does something different, i seriuosly doubt that its a bad test :) | 22:33 |
| grapex | If it does, the code has been changed. | 22:33 |
| kagan | i'm not sure mysql doenst do that | 22:33 |
| kagan | it's just being done in 3 seconds or so | 22:33 |
| hub_cap | or it also could mean nova has changed | 22:33 |
| kagan | compared to 2 minutes with percona | 22:33 |
| cp16net | i thought i remember someone saying they added a mysql stop | 22:33 |
| grapex | The Reddwarf task ID is set to "resize", so during the entire resize operation it reports the status as "RESIZE" despite what the resources are doing. | 22:33 |
| kagan | so i think the test just doesn't' catch it | 22:33 |
| hub_cap | woah, 2 min for a restart... craaaazzyyyyy | 22:33 |
| kagan | you'd never guess why .... | 22:33 |
| *** flaper87 has joined #openstack-meeting-alt | 22:34 | |
| vipul | yea, i think the startup differences may be exposing these states | 22:34 |
| kagan | it's 4 executions fof "see" | 22:34 |
| *** flaper87 has left #openstack-meeting-alt | 22:34 | |
| vipul | 'sed' | 22:34 |
| kagan | of "see" | 22:34 |
| kagan | damn .. it "fixes" my typos ... | 22:34 |
| vipul | heh | 22:34 |
| hub_cap | kagan: so yer saying | 22:34 |
| * cp16net confused | 22:34 | |
| kagan | i write sed every time ... | 22:34 |
| hub_cap | thre is a race condition that we never saw w/ the oracle mysql | 22:34 |
| kagan | i think so. not sure. | 22:34 |
| hub_cap | since it boots up so quickly | 22:34 |
| kagan | it seems that this is regular flow | 22:34 |
| grapex | If this for the happy path? | 22:35 |
| hub_cap | but since the guest sees percona mysql as down for 2 minutes it reports the status as such | 22:35 |
| kagan | so i think mysql goes through "shutdown" for several seconds | 22:35 |
| kagan | i guess ... | 22:35 |
| hub_cap | kagan: a resize does restart mysql | 22:35 |
| hub_cap | it has to for the new settings | 22:35 |
| kagan | i know | 22:35 |
| hub_cap | but yer seeing a condition where the guest says its not in resize, but in shutdown | 22:35 |
| kagan | but the code in the test is weird there | 22:35 |
| cp16net | is this for create? | 22:35 |
| vipul | cp16net: resize | 22:35 |
| cp16net | oh ok | 22:36 |
| kagan | yes, for a while. then it comes up again | 22:36 |
| cp16net | so if you stop mysql it will report as shutdown | 22:36 |
| vipul | hub_cap: is it possible that the heartbeat thread see's it as down | 22:36 |
| hub_cap | correct | 22:36 |
| SlickNik | cp16net: the mysql stop was for the restart tests, not resize, IIRC. | 22:36 |
| hub_cap | thats what im getting at vipul | 22:36 |
| hub_cap | lets take this offline. it seems as if we have a potential race condition we need to account for in the guest | 22:36 |
| hub_cap | kagan: talk to grapex tomorrow about. it he can help | 22:37 |
| hub_cap | lol period misplacement | 22:37 |
| vipul | RECAP: resize restarts myslq.. since percona is slow to start up... heartbeat sets guest state as shutdown.. which invalidates the test | 22:37 |
| grapex | Probably the reference guest is behaving differently from Sneaky Pete. | 22:37 |
| hub_cap | yuup vipul | 22:37 |
| hub_cap | lets offline it and kagan and grapex can interface later | 22:37 |
| kagan | ok | 22:37 |
| hub_cap | but good work kagan looking forward | 22:37 |
| kagan | thanks | 22:38 |
| datsun180b | That's what I'm thinking, in the neighborhood of dbaas.py:658 | 22:38 |
| vipul | I think we should amend the test to look for either state | 22:38 |
| hub_cap | anything else wrt percona kagan? | 22:38 |
| hub_cap | vipul: or amend the guest to _not_ report shutdown during a resize | 22:38 |
| kagan | don't think so. any more questions ? | 22:38 |
| hub_cap | nope im good kagan | 22:38 |
| vipul | hub_cap: yea let's discuss that in #reddwarf later | 22:38 |
| hub_cap | exactly vipul | 22:38 |
| hub_cap | #topic Snapshots Blueprint Feedback | 22:38 |
| *** openstack changes topic to "Snapshots Blueprint Feedback (Meeting topic: reddwarf)" | 22:38 | |
| hub_cap | can someone linke the bp? | 22:39 |
| vipul | #action kagan to socialize fixing resize test or heartbeat thread for the ocrrect state | 22:39 |
| hub_cap | i know demorris and vipul have chatted on this | 22:39 |
| vipul | #link https://blueprints.launchpad.net/reddwarf/+spec/consistent-snapshots | 22:39 |
| hub_cap | vipul: thx for that action. good call | 22:39 |
| SlickNik | #link https://wiki.openstack.org/wiki/Snapshot-design | 22:39 |
| vipul | cool SlickNik beat me to the second link | 22:39 |
| hub_cap | hehe, i havent had a ton of time to read up on it yet | 22:40 |
| vipul | dkehn's done a good job outlining the fix.. | 22:40 |
| hub_cap | #action hub_cap read https://blueprints.launchpad.net/reddwarf/+spec/consistent-snapshots | 22:40 |
| vipul | like the wiki write up for it.. very consise | 22:40 |
| vipul | demorris added the API this morning | 22:40 |
| hub_cap | very nice on the pluggable interface design tho | 22:40 |
| demorris | yep, love the pluggable design piece | 22:40 |
| hub_cap | vipul: im assuming u havent had a ton of time to look into it? or have ya | 22:40 |
| hub_cap | <3<3 pluggable | 22:40 |
| SlickNik | Yea, I'm still making my way through it, but so far so good. | 22:41 |
| vipul | i have some.. but not completely | 22:41 |
| demorris | vipul: you had some comments on the use of a locationRef for the location of the snaps in Swift | 22:41 |
| vipul | however it looks a lot like what we had in our fok | 22:41 |
| vipul | fork | 22:41 |
| hub_cap | super | 22:41 |
| vipul | demorris: yes, i don't know if location of the snapshot.. where it's stored should be exposed | 22:41 |
| vipul | so if you expose it.. it means you would likely have to expose the swift endpoint.. | 22:42 |
| grapex | vipul: Agreed. | 22:42 |
| demorris | would you expect a snapshot to be portable? | 22:42 |
| vipul | and you may not be using swift as a location | 22:42 |
| vipul | BUT... | 22:42 |
| vipul | if we put the snapshot in the user's tenant's container.. then they'd see it anyway | 22:42 |
| hub_cap | and probably delete it on accident :P | 22:43 |
| vipul | demorris: not by the user.. that's up for discussion i guess | 22:43 |
| vipul | demorris mentioned that delete would have to be reconciled by reddwarf | 22:43 |
| grapex | hub_cap: Not if we name the container "PLZ_NO_DELETE" | 22:43 |
| SlickNik | lol@grapex | 22:43 |
| hub_cap | grapex: thats the plan!! hidden_dont_look_here | 22:43 |
| demorris | vipul: well i saw that in the DB design | 22:43 |
| vipul | too bad swift doesn't have hidden containers | 22:44 |
| vipul | and nova doesn't have hidden instances | 22:44 |
| demorris | there was a "deleted" column | 22:44 |
| vipul | demorris.. that would be for user api delete | 22:44 |
| demorris | that said 0 or 1, seemed to indicate it was there to store information on if the snap went missing in Swift | 22:44 |
| vipul | not behind the scenes delete.. so we could account for both if we need to | 22:44 |
| hub_cap | vipul: vishy has already said he would welcome "managed vms" in nova | 22:44 |
| demorris | vipul: i see | 22:44 |
| vipul | hub_cap: yea we need to file the BP on that one | 22:45 |
| vipul | So.. i'm open to either implemenation.. location visible or not | 22:45 |
| hub_cap | yup ive mentioned it at like 3 summits :P but never worked on it | 22:45 |
| SlickNik | "managed vms"? | 22:45 |
| vipul | or 'hidden vms' | 22:45 |
| hub_cap | vms that a user cannot modify but are on their account | 22:45 |
| hub_cap | i dont like hidden | 22:45 |
| vipul | so we can create them on behalf of customer and they don't see them on a 'nova list' | 22:45 |
| SlickNik | ah, I see. | 22:46 |
| hub_cap | they should be able to see them imho, but not touch them | 22:46 |
| hub_cap | if im payin for em, i wanna be able to see em | 22:46 |
| hub_cap | :D | 22:46 |
| vipul | hub_cap: yea i could live with that | 22:46 |
| demorris | I guess my thought was that a user "may" want to get at their snapshot directly in Swift, if they wanted to port it somewhere either within the DC or out somewhere else | 22:46 |
| vipul | demorris: but we may consider encrypting or something.. not sure if they'd be useful... | 22:46 |
| demorris | so providing a locationRef, simplifies knowing where it is | 22:46 |
| vipul | demorris: but we do need to think about portability | 22:46 |
| hub_cap | ya cuz the system wont know about it w/o some sort of import_snapshot | 22:47 |
| hub_cap | to link up the moved snap from somewhere else in the DC as per your point demorris | 22:47 |
| demorris | yeah, I would think you want to have optional encryption, and potentially for a user to specify their keys (if you go that route)…then they have the keys so if its encrypted they can decrypt | 22:47 |
| cp16net | can i download my snapshot and run it in my dc? | 22:47 |
| vipul | demorris: yea that would work well.. just another set of APIs though | 22:47 |
| hub_cap | cp16net: thast what morris wants, and i think thas a good idea | 22:47 |
| hub_cap | id say lets go easy route for v1 | 22:48 |
| vipul | hub_cap: so we need to scope this down | 22:48 |
| cp16net | makes things very portable | 22:48 |
| demorris | I think that should be supported, we don't want to lock data in | 22:48 |
| vipul | i think maybe for v1 we take out portability? | 22:48 |
| hub_cap | ya i can live w/ that | 22:48 |
| hub_cap | snaps themselves will be a lot of work | 22:48 |
| demorris | well I would say we are not taking it out, but it would be making it harder | 22:48 |
| hub_cap | seems like a addd on | 22:48 |
| grapex | Make it optional but not required by the spec? | 22:48 |
| vipul | we can still leave location in... and they may be able to delete behind our back | 22:48 |
| hub_cap | hell vipul htey can do that w/o a location :) | 22:49 |
| vipul | heh yea | 22:49 |
| demorris | yeah, if you use the customers Swift account, the chance of accidental deletion is always there | 22:49 |
| hub_cap | so lets think aobut it this way | 22:49 |
| hub_cap | _adding_ to the api doesnt require version updates | 22:49 |
| hub_cap | _removing_ does | 22:49 |
| hub_cap | if we are unsure for now, lets leave it out and add it on as we flesh out the details | 22:49 |
| vipul | right.. hide location for now then | 22:49 |
| demorris | k | 22:49 |
| SlickNik | sounds good. | 22:50 |
| cp16net | thats true for many things tho demorris | 22:50 |
| hub_cap | i do think its a good idea tho | 22:50 |
| hub_cap | but a bit too much implication-wise for now | 22:50 |
| *** jcru is now known as jcru|away | 22:50 | |
| *** jcru|away is now known as jcru | 22:50 | |
| vipul | another thought | 22:50 |
| cp16net | would be really nice for off 'site' backup | 22:50 |
| vipul | what if the user that makes a call to Reddwarf doesn't ahve Swift role | 22:50 |
| hub_cap | cp16net: def | 22:50 |
| hub_cap | vipul: snapshots fail w/ a useful error message :) | 22:51 |
| vipul | hub_cap: alright.. that would work | 22:51 |
| hub_cap | we should do a HEAD on the container we decide to use b4 we do a snap | 22:51 |
| hub_cap | from the api/taskmanager | 22:51 |
| cp16net | how about http code 418? | 22:51 |
| hub_cap | itll validate the container exists | 22:51 |
| hub_cap | is that teapot cp16net? | 22:51 |
| cp16net | "i'm a teapot" | 22:51 |
| vipul | cp16net: lol | 22:51 |
| cp16net | :) | 22:51 |
| * hub_cap shakes head at cp16net | 22:51 | |
| hub_cap | ok do we feel good wrt snapshots for now? | 22:52 |
| demorris | how do y'all expect restoring snapshots to work? My take is that any restore of a snapshot goes into a new instance…not an existing instance. To remove the chance of a customer blowing away portions of data on their instance… | 22:52 |
| vipul | #action vipul to update snapshots design to call out swift role required, and behind the back deletes | 22:52 |
| vipul | demorris: that's my thought as well, only supported on 'create' | 22:52 |
| hub_cap | demorris: that sounds reasonable, vipul and co, thoughts? | 22:52 |
| demorris | i.e. we support create instance from snapshot | 22:53 |
| demorris | but not import to existing instance | 22:53 |
| vipul | yep, no other form of restore | 22:53 |
| hub_cap | #agreed | 22:53 |
| hub_cap | demorris: i think i saw that in the api, correct? | 22:53 |
| SlickNik | I think that's reasonable for a v1. | 22:53 |
| demorris | hub_cap: correct | 22:53 |
| demorris | any issues around the "statusDetails" in the API? | 22:53 |
| vipul | demorris: it makes some sense, since a DELETED could have happned in multiple ways | 22:54 |
| demorris | it was called notes in the DB design, I changed it…that can be used to display any details on the status…FAILED, DELETED, RUNNING, etc… | 22:54 |
| vipul | but.. i don't know if we _need_ to have it | 22:54 |
| vipul | and if we have it, does it belong in API response | 22:54 |
| vipul | do we have precedence for it in other 'statuses'? | 22:55 |
| demorris | would be hard to have it in the response since its async | 22:55 |
| vipul | i guess service_statuses does | 22:55 |
| cp16net | how will the customer be able to see that the isntance they just created is tied to the snapshot or does that matter? | 22:55 |
| hub_cap | i htink our precedence is that we have terrible responses if async things fail | 22:55 |
| hub_cap | maybe we shouldnt try to shoehorn that into snaps | 22:55 |
| vipul | cp16net: I don't know that matters.. since it's only a point in time that they are linked | 22:56 |
| hub_cap | and make it inependent to work for any async/status | 22:56 |
| demorris | i will ALWAYS be pro fields like this, because it allows us to actually tell the user what happened | 22:56 |
| cp16net | ok just curious | 22:56 |
| demorris | instead of having them scratch their head and hit submit a few more times :) | 22:56 |
| hub_cap | demorris: sure but wouldnt u be pro "give me a way to do it for any async call" | 22:56 |
| grapex | I agree... I really hate how the resize status stuff works. There's no way to know if the job failed except if the flavor doesn't change. | 22:56 |
| hub_cap | it shoudl be generic enough to use for any of the cast's | 22:56 |
| hub_cap | id say lets put a note that we need to make that generic and file a separate BP | 22:57 |
| demorris | yes, but I don't want y'all to take on the overhead of building out an async model right now | 22:57 |
| hub_cap | demorris: id rather build that then hack it and have to change it | 22:57 |
| demorris | hub_cap: can you build it in a week? | 22:57 |
| vipul | hub_cap: so i'm hearing that we leave it out of the snapshots impl | 22:57 |
| demorris | :) | 22:57 |
| hub_cap | demorris: of course not | 22:57 |
| vipul | and come back around | 22:57 |
| grapex | demorris: Where did you want statusDetails to appear again? | 22:57 |
| hub_cap | vipul: i think so, its a great idea but i feel like itd be a hack on snapshots and wont go anywhere | 22:58 |
| demorris | grapex: check List snapshots in the spec | 22:58 |
| SlickNik | grapex: in the API responses, methinks. | 22:58 |
| vipul | hub_cap: Yes, i am good with that.. | 22:58 |
| vipul | since it seems to encompass more than snapshots | 22:58 |
| hub_cap | correct vipul | 22:58 |
| hub_cap | so the main reason im against | 22:59 |
| grapex | I think having status details per snapshot is ok- | 22:59 |
| vipul | #action hub_cap, grapex to file blueprint on detailed status messages for async operations | 22:59 |
| hub_cap | is that if we have to alter in any way we have to rev the api | 22:59 |
| grapex | because like I think has been mentioned, we could query swift and see if the underlying object was deleted as well as provide status on the back up process | 22:59 |
| robertmyers | respond with 202 accepted | 22:59 |
| vipul | #action vipul to remove status Detail from snapshots API/impl | 22:59 |
| robertmyers | with a link to the status url | 23:00 |
| grapex | So we already have task description in the Reddwarf API | 23:00 |
| *** esp has quit IRC | 23:00 | |
| *** esp has joined #openstack-meeting-alt | 23:00 | |
| grapex | the MGMT api returns it. But all we can really do is show things like if something went wrong in the build process | 23:00 |
| grapex | Like for resizes, we can't make use of it for various reasons - it can't represent a unique thread of execution in the scheme of things, just a resource | 23:01 |
| hub_cap | grapex: i agree its someting we need, we should focus resources on it. its been a pain point for a VERY long time | 23:01 |
| grapex | so for the snapshots resource, when you provision it I can see we could add info there. | 23:02 |
| cp16net | #AGREE | 23:02 |
| * hub_cap hears grapex feverishly typing | 23:02 | |
| grapex | If we need to store status during operations like restore or something else I can't think of atm it won't work, because once the resource is prov'd status's duty is just to report the state of the resource and not the success of some job | 23:02 |
| grapex | I'm just saying, having a statusDetails are ok, because we do it provisioning Reddwarf instances now. | 23:03 |
| grapex | It only works for the provisioning process. | 23:03 |
| * vipul wishes we had phone meetings | 23:03 | |
| hub_cap | vipul: bah | 23:04 |
| demorris | demorris: agrees | 23:04 |
| grapex | hub_cap: Well they say that brevity is the location from which originates the quickness of the mind. | 23:04 |
| hub_cap | wishes everyone could type 120wpm | 23:04 |
| vipul | lol | 23:04 |
| demorris | i get lost in here too easily | 23:04 |
| vipul | ok i think this needs further discussioni | 23:04 |
| vipul | i'm lost as well | 23:04 |
| hub_cap | #agreed | 23:04 |
| vipul | i'm going to try to set up a phone meeting | 23:04 |
| vipul | for this week | 23:04 |
| hub_cap | #action continue discussion on statusDetails | 23:05 |
| vipul | to go over snapshot details | 23:05 |
| hub_cap | okey | 23:05 |
| demorris | what I heard was we are going to remove statusDetails in favor of a more defined model for checking on details of async calls | 23:05 |
| grapex | I agree generally with hub_caps point, I'm just not sure it applies to *this* feature. Anyway, lets table it for now. | 23:05 |
| hub_cap | demorris: correct, i think :) | 23:06 |
| vipul | yea this seems like a wider topic than snapshots.. so we could go either way... figure out a way to get this implemented for snapshots | 23:06 |
| hub_cap | yup | 23:06 |
| demorris | we can still have it in the database and then optionally add it to the API as we learn more…additive okay, contract changes bad | 23:06 |
| hub_cap | demorris: correct | 23:06 |
| hub_cap | id rather go w/ less for now and add stuff | 23:06 |
| vipul | ok... btw.. someone was going to post a state diagram for RD states | 23:07 |
| vipul | robermeyers ^? | 23:07 |
| vipul | robertmeyers | 23:07 |
| robertmyers | not I | 23:07 |
| hub_cap | #link http://s3-2.kiva.org/img/w800/196261.jpg | 23:07 |
| grapex | LOL! | 23:07 |
| cp16net | lol | 23:07 |
| vipul | heh | 23:07 |
| grapex | That's what I was thinking | 23:07 |
| cp16net | is that bubble gum? | 23:07 |
| jcru | vipul: I wasn't able to find one | 23:08 |
| hub_cap | cp16net: im sad for u | 23:08 |
| hub_cap | flying spaghetti monster | 23:08 |
| SlickNik | FSM | 23:08 |
| vipul | jcru: ah ok, there is a lot of shit going in there... | 23:08 |
| jcru | hah | 23:08 |
| esp | hub_cap: I had spaghetti for lunch! | 23:08 |
| hub_cap | esp: flying? | 23:08 |
| vipul | with eyes? | 23:09 |
| hub_cap | so we need to do that, i agree. ill start it if no one else is on it | 23:09 |
| esp | no, but a lot of it did end up on my shirt. | 23:09 |
| hub_cap | haha | 23:09 |
| demorris | done with snaps? | 23:09 |
| jcru | hub_cap: I can work on it | 23:09 |
| hub_cap | demorris: aye | 23:09 |
| vipul | hub_cap: probably makes sense someone from rax | 23:09 |
| hub_cap | jcru: cool | 23:09 |
| SlickNik | FSM = Flying Spaghetti Monster = Finite State Machine... | 23:09 |
| hub_cap | #action jcru to work on a FSM (finite state machine) | 23:09 |
| hub_cap | lol i thought the same thing SlickNik just now | 23:09 |
| jcru | lol | 23:09 |
| hub_cap | u beat me to it | 23:09 |
| hub_cap | moving on? | 23:10 |
| vipul | yea, i'll set up a follow up meeting (if we still tink it's necessary) | 23:10 |
| hub_cap | ill keep the next section short since not much has happened | 23:10 |
| hub_cap | vipul: i say lets try to discuss in chat | 23:10 |
| hub_cap | and if it no workie lets talk about it | 23:10 |
| hub_cap | ill chat w/ the team here | 23:10 |
| cp16net | were you talking about something like this? https://github.com/cp16net/reddwarf-integration/blob/6f672c3201e00f1b3241e25ce9c33b5881a24ec6/tests/graphics/reddwarf-overview.gv.jpeg | 23:10 |
| vipul | hub_cap: kk | 23:10 |
| vipul | cp16net: that's more of a component diagram | 23:11 |
| hub_cap | cp16net: more like resize->stopped | 23:11 |
| hub_cap | bad example of course :P | 23:11 |
| vipul | right.. what states should instance be in when we do resize.. or whatever | 23:11 |
| cp16net | roger | 23:11 |
| hub_cap | but we coudl build w/ viz | 23:12 |
| hub_cap | #topic API Spec General Update | 23:12 |
| *** openstack changes topic to "API Spec General Update (Meeting topic: reddwarf)" | 23:12 | |
| hub_cap | so im working on this starting tomorrow. will set up all the docs we have + snaps, limits, and anything else that is already in flight or in a BP | 23:12 |
| hub_cap | ill push as a work in progress review to gerrit so that everyone can see | 23:12 |
| demorris | hub_cap: there is probably stuff that is not in BP's that need to be in the spec | 23:13 |
| vipul | ok, i think i need some info on what goes there.. | 23:13 |
| hub_cap | demorris: def | 23:13 |
| vipul | stuff that's part of BP process goes into this repo? | 23:13 |
| vipul | or just the actual implemented v1.x api | 23:13 |
| hub_cap | https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md | 23:13 |
| hub_cap | vipul: essentially we need to (as a collective group) define the api | 23:14 |
| hub_cap | and then each developer will implement pieces of it | 23:14 |
| demorris | one I think that is not there is maintenance windows | 23:14 |
| grapex | hub_cap: How do these .md files relate to the docbook files? | 23:14 |
| hub_cap | and of course we will find small things that need changing | 23:14 |
| hub_cap | grapex: im not sure exactly | 23:14 |
| vipul | hub_cap: i think similar question.. are we going to be visible in api.openstack.org | 23:15 |
| hub_cap | but thats the way the api guys are working on it _today_ | 23:15 |
| vipul | if not there, then where | 23:15 |
| hub_cap | vipul: we can work that out i think | 23:15 |
| hub_cap | maybe stackforge can host a api.stackforge.org | 23:15 |
| grapex | hub_cap: Cool, I don't mind .md files. | 23:15 |
| hub_cap | to mirror what openstack is doing wrt the api docs | 23:16 |
| vipul | also do we need to wadl in addition to md? | 23:16 |
| cp16net | 404 | 23:16 |
| vipul | or is there some auto generation happening | 23:16 |
| hub_cap | cp16net: lol likely | 23:16 |
| demorris | hub_cap: I will add a BP for this - As a Reddwarf User, I need to the ability to manage MySQL version updates, so that I can minimize unplanned downtime and plan accordingly for my production application environments. | 23:16 |
| hub_cap | vipul: the auto gen will hapeen from the wadl | 23:16 |
| hub_cap | demorris: plz do | 23:16 |
| demorris | essentially we add an attribute for - "maintenanceWindow":"2012-03-28T21:30Z/2012-03-28T22:00Z" | 23:16 |
| hub_cap | so yes we will need to impl the wadl as a part of all this, but the markdown is the fastest way to get things working | 23:16 |
| hub_cap | and i thnk thats why the teams have done this | 23:17 |
| hub_cap | get it up, get it reviewed | 23:17 |
| hub_cap | wait im wrong | 23:17 |
| hub_cap | the wadl are autogen'd now via that fancy fandangled python api | 23:17 |
| demorris | it ties in to the versions-types BP i submitted | 23:17 |
| hub_cap | honestly its in flux, and these are good questions that need answering, and i dont have the answer | 23:18 |
| vipul | demorris: do you report oracles vs percona in type? | 23:18 |
| hub_cap | but we need something that only a few people can commit to, in the repo, and markdown works very well w/ github | 23:18 |
| hub_cap | so im assumign thats why they went that route | 23:18 |
| hub_cap | vipul: i think thats part of the BP | 23:18 |
| vipul | hub_cap: ok, i think once you put in a framework things will fall into place | 23:18 |
| *** robertmyers has left #openstack-meeting-alt | 23:19 | |
| hub_cap | or at least shake out a bit more vipul ;) | 23:19 |
| demorris | yeah, check here - https://wiki.openstack.org/wiki/Reddwarf-versions-types | 23:19 |
| vipul | both good things | 23:19 |
| hub_cap | but its good to get something up to chat about / implement | 23:19 |
| hub_cap | def | 23:19 |
| demorris | there is a name / version attribute that lets you distinguish | 23:19 |
| grapex | hub_cap: Does the wadl live with the doc repo? | 23:20 |
| demorris | a name would be a DB type + Major Version (Percona / Maria / MySQL , etc.) | 23:20 |
| grapex | Or is it an artifact of some build process? | 23:20 |
| hub_cap | grapex: best of my knowledge the wadl is generated | 23:20 |
| *** imsplitbit has quit IRC | 23:20 | |
| hub_cap | but i cant answer definitively | 23:20 |
| vipul | demorris: Ok, making sense now | 23:20 |
| demorris | vipul: we can tweak if needed | 23:20 |
| vipul | i think Percona should be a separate type, agree? | 23:21 |
| demorris | Yeah, it would be like "Percona 5.5" | 23:21 |
| vipul | Ok, cool. | 23:21 |
| demorris | or whatever it is you are using, will be up to provider to specify | 23:21 |
| demorris | then versions is used for minor versions | 23:21 |
| hub_cap | im assuming we have migrated topics | 23:21 |
| vipul | heh | 23:22 |
| vipul | yes | 23:22 |
| demorris | whoops | 23:22 |
| demorris | back on API spec | 23:22 |
| demorris | another BP coming will be my.cnf's | 23:22 |
| vipul | lots of interesting things to discuss.. can't contain ourselves | 23:22 |
| demorris | expect to see that in the next week | 23:22 |
| vipul | w00t demorris | 23:22 |
| demorris | and hub_cap will roll that in the API spec | 23:22 |
| demorris | will be lots to review and discuss | 23:22 |
| demorris | but all good things! | 23:23 |
| hub_cap | #topic open discussion | 23:23 |
| *** openstack changes topic to "open discussion (Meeting topic: reddwarf)" | 23:23 | |
| demorris | #forwardprogress | 23:23 |
| vipul | #agreed | 23:23 |
| hub_cap | demorris: http 501 | 23:23 |
| vipul | still waiting on that vm-gate review to _get reviewed_ | 23:23 |
| hub_cap | sweet tho, progress!! | 23:23 |
| vipul | hub_cap we want to gate both rd-int and rd repos with that correct? | 23:24 |
| demorris | alright, I need to run, thanks guys, i just might start showing up at these more often! | 23:24 |
| hub_cap | vipul: def | 23:24 |
| hub_cap | demorris: <3 for participating | 23:24 |
| demorris | hub_cap: :) | 23:24 |
| SlickNik | Yeah, I noticed that there are some whitespace issues like extra tabs/spaces that I'm going to clean up with that vm-gate review. I'll re-ping Openstack CI folks once I'm done with that. | 23:25 |
| vipul | Oh another though.. us core reviewers have been slacking | 23:25 |
| hub_cap | #agreed | 23:25 |
| vipul | there's a ton of stuff.. let's try to get it pushed through | 23:25 |
| hub_cap | me especially | 23:25 |
| hub_cap | other teams have done review days | 23:25 |
| hub_cap | and other other teams have done 1 hr per day | 23:25 |
| *** sacharya has quit IRC | 23:26 | |
| vipul | we probably should try to get something like that in our schedule | 23:26 |
| grapex | Me too... I've been busy with some stuff here lately and haven't been paying close enough attention. Sorry if this impeded anyone. | 23:26 |
| hub_cap | other thing to note, if u have a work in progress, mark it as such via that fancy button | 23:26 |
| SlickNik | Same here, got busy with stuff and the emails kept piling. Will pay closer attn. to stuff in the pipeline. | 23:26 |
| hub_cap | https://review.openstack.org/#/c/21989/ <-- example | 23:26 |
| hub_cap | it will make it easier for us to not let WIP's slip in | 23:27 |
| vipul | esp ^ | 23:27 |
| grapex | It'd be nice if watched changes kept the work in progress items at the top of the list. | 23:27 |
| hub_cap | it labels them tho at least | 23:28 |
| grapex | True. | 23:28 |
| hub_cap | like [work in progress] | 23:28 |
| vipul | there deosn't seem to be an ordering | 23:28 |
| hub_cap | esp: WIP your commit | 23:28 |
| grapex | I shouldn't complain, Gerrit's been a very enjoyable experience. | 23:28 |
| vipul | just what you looked at last goes to top | 23:28 |
| hub_cap | there is vipul | 23:28 |
| hub_cap | its the order at what u looked at | 23:28 |
| hub_cap | exactly | 23:28 |
| SlickNik | yep | 23:28 |
| *** demorris has quit IRC | 23:28 | |
| hub_cap | grapex: def its nice | 23:28 |
| hub_cap | https://review.openstack.org/#/q/is:watched+status:open,n,z | 23:28 |
| hub_cap | there is a good bit of changes to be pushed thru. lets get awn it | 23:29 |
| vipul | yep | 23:29 |
| vipul | only 30 mins over | 23:29 |
| vipul | :) | 23:29 |
| vipul | i think we can wrap it up? | 23:29 |
| *** amyt has quit IRC | 23:30 | |
| SlickNik | Nothing else from my side. | 23:30 |
| SlickNik | I think that's a go. | 23:30 |
| *** amyt has joined #openstack-meeting-alt | 23:30 | |
| hub_cap | okey let wrap | 23:30 |
| hub_cap | #endmeeting | 23:31 |
| *** openstack changes topic to "OpenStack meetings (alternate) || Development in #openstack-dev || Help in #openstack" | 23:31 | |
| openstack | Meeting ended Tue Feb 19 23:31:02 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 23:31 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-19-22.00.html | 23:31 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-19-22.00.txt | 23:31 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-19-22.00.log.html | 23:31 |
| *** esp has left #openstack-meeting-alt | 23:32 | |
| *** hub_cap has left #openstack-meeting-alt | 23:33 | |
| *** djohnstone has quit IRC | 23:33 | |
| *** cloudchimp has quit IRC | 23:34 | |
| *** jcru has quit IRC | 23:35 | |
| *** kagan has quit IRC | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
