21:40:28 <vishy> #startmeeting 21:40:29 <openstack> Meeting started Thu Aug 2 21:40:28 2012 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:40:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:40:35 <russellb> i guess we should jump on both reviews this week, and then sync up again next week on how it looks 21:40:51 <russellb> see what things people are finding 21:40:53 <jog0> vishy: if cells or baremetal lands is it possible to get integration tests for them as well? 21:41:04 <vishy> #info late start: first part of the meeting is in: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-17.00.log.html 21:41:19 <vishy> #topic Blueprints and Reviews 21:41:32 <markmc> #action jk0, sdague and nati_ueno to help vishy with disabling server create extensions 21:41:32 <vishy> #info please help with reviews on baremetal and cells 21:41:47 <mikal> One other big review is the storwize stuff 21:41:48 <markmc> #action lzyeval to help with XML support in extensions 21:41:57 <mikal> I want to check how people feel about the paramiko dependancy 21:42:06 <markmc> #action mikal to help smoser with config-drive blueprint 21:42:16 <vishy> #link https://review.openstack.org/#/c/10707/ 21:42:22 <russellb> #action russellb to help ewindisch with trusted-messaging blueprint 21:42:28 <markmc> #action general-host-aggregates needs review 21:42:34 <vishy> #link https://review.openstack.org/#/c/10726/ 21:42:53 <markmc> #action cells and baremetal patches need review 21:43:01 <jog0> mikal: I have had trouble with paramiko and eventlet in the recent past 21:43:05 <vishy> well those links are going to be out of order considering the actions but oh well :) 21:43:23 <markmc> mikal, it's already a dependency, no? 21:43:28 <mikal> jog0: the san driver already uses paramiko 21:43:31 <vishy> #topic Release Quality 21:43:37 <mikal> But I want to make sure packagers know about it 21:43:46 <russellb> quality: we should have some of that 21:43:47 <vishy> this is a more general topic which i expect to revisit later 21:44:05 <vishy> i think most of the concerns will happen post f-3 21:44:23 <markmc> mikal, looks fine for fedora anyway, already a dep of our openstack-nova package 21:44:31 <Ravikumar_hp> Vishy: Folsom - for Nova when is feature freeze day ? Is it at end of Folsom-3 ? 21:44:43 <vishy> #help we need help with bugs and documentation 21:44:50 <vishy> Ravikumar_hp: yes no features after f-3 21:44:52 <markmc> vishy, if only we were on top of our bug triaging 21:44:56 <russellb> yes, folsom-3 is the freeze, and it's august 16th 21:45:10 <markmc> vishy, I suspect folks would love to help if we had a properly prioritize list of issues 21:45:10 * russellb plans to switch focus to bugs as much as possible after f-3 21:45:32 <vishy> russellb: I hope the rest of nova-core follows suit 21:45:44 <russellb> same 21:45:51 <vishy> so the main gap aside from bugs and docs is upgrading 21:46:12 <vishy> I've recruited dtroyer to help create an upgrade test, so we should have something pretty soon 21:46:28 <vishy> once we get the code bootstrapped, we will be looking for help to make it awesome 21:46:33 * comstud is here now 21:46:43 <markmc> upgrade test would be coolness 21:46:51 <vishy> the first version is going to be a simple upgrade script so that we at least know what an upgrade looks like 21:46:57 <markmc> this is a shut everything down, upgrade and restart upgrade right? 21:47:08 <vishy> and that we can throw into jenkins 21:47:10 <vishy> yes 21:47:18 <vishy> live upgrades is way out of scope right now 21:47:24 <markmc> yep 21:47:25 <russellb> someday! 21:47:27 <sdague> vishy: is this going to be something in devstack, or a new thing? 21:47:42 <vishy> but I'd like to get a framework in place to test it so that we can see how far away we are from folsom -> grizzly 21:47:52 <vishy> sdague: separate, but the first version will use devstack 21:48:06 <comstud> vishy: if we need to circle back around to cells quickly, I'm available for questions! 21:48:13 <markmc> vishy, any particular things you think we may have broken? DB migrations, config migration, ... ? 21:48:56 <vishy> sdague: high level view: a) devstack stable/essex b) run the system c) kill services d) download devstack trunk e) run magic upgrade script d) restart services e) run exercises 21:48:59 <lzyeval> marckmc: I've witnessed DB migration problems 21:49:07 <vishy> second version do stuff before the upgrade 21:49:20 <vishy> markmc: I'm most worried about config changes in projects 21:49:28 <markmc> vishy, ok 21:49:33 <vishy> markmc: and dependency changes 21:49:36 <russellb> arbitrary config changes that breack backwards compat really bug me 21:50:00 <vishy> markmc: I'd like the script to handle converting deprecated config options as well 21:50:01 <markmc> agreed - for the config options people actually use :) 21:50:04 <russellb> hopefully there's not too much of that 21:50:09 <markmc> vishy, cool 21:50:11 <russellb> markmc: heh, fair point 21:50:13 <vishy> markmc: like switching to the new driver options from sdague 21:50:20 <markmc> yep 21:50:26 <markmc> the rootwrap_config one too 21:50:41 <markmc> andrewbogott's notification driver stuff too 21:50:42 <vishy> i willl make an announcement on the ml once we have something very basic in place so others can help 21:51:05 <russellb> i wonder if we should have a "config checker" that people can run against their configs and see if they are using deprecated stuff 21:51:12 <vishy> we can push bug and docs discussion to next meeting, after we make it through f3 21:51:32 <vishy> running out of time but quick check 21:51:45 <vishy> #topic Other Issues 21:51:59 <vishy> just wanted space for people to mention stuff that are issues for the release 21:52:05 <sdague> vishy: look forward to the upgrade testing work, will definitely help dtroyer out with that once he gets the first pass out 21:52:05 <markmc> vishy, wanted to mention http://wiki.openstack.org/APIChangeGuidelines 21:52:09 <vishy> mostly end user /operator issues that make nova painful 21:52:26 <eglynn> vishy: what's the background on the Quota Handling issue mentioned on the agenda? 21:52:26 <vishy> markmc: cool anything to say other than the link? 21:52:26 <markmc> any API changes that we approve, it would be good to add them to the examples section 21:52:30 <markmc> even subtle stuff 21:52:41 * markmc has added a bunch there already 21:52:59 <vishy> eglynn: so these are all the things that i see as pain points. Quota handling is not consistent across projects so it is not user friendly 21:53:23 <eglynn> vishy: (I've grabbed a few quota-related bugs recently, so I've got my head in that code right now ...) 21:53:24 <vishy> #info add any approved api changes as examples to http://wiki.openstack.org/APIChangeGuidelines 21:53:32 <ewindisch> vishy: if we proceed with the membership services / matchmaker blueprints, we may need to consider moving some of the database stuff into openstack-common. 21:53:47 <vishy> eglynn: it is more of a future concern. I don't think we can do anything about it before folsom 21:53:54 <eglynn> vishy: k 21:54:14 <vishy> i guess the question is: Is there anything in that list that is important enough to us that we should put effort into it before feature freeze 21:54:32 <markmc> eglynn, seen the per-user quotas patch? https://review.openstack.org/#/c/8388/ 21:54:44 <vishy> so everyone think about that and get back to me 21:54:45 <eglynn> markmc: yep 21:54:57 <vishy> since we're running out of time to discuss it in detail, we can revisit on the ML 21:55:31 <vishy> #action think about end-user / deployer issues that are important enough to work on in the next couple of weeks 21:55:47 <vishy> #info examples are rbac handling, quota handling, adminness 21:55:56 <vishy> there is one issue there that i think is important 21:56:07 <vishy> our is_admin in the context is set based on a specifically named role 21:56:20 <maoy> i'd like to see Error in vm state appear less often 21:56:23 <vishy> it should be switchted to a policy check 21:56:33 <vishy> maoy: agreed 21:56:55 <vishy> I will report a bug about the hard-coded adminness if there isn't one already 21:57:08 <vishy> ok final topic 21:57:31 <vishy> #action vishy to report a bug on hard-coded admin role so it can be switched to a policy check 21:57:42 <vishy> #topic Meeting Times 21:57:51 <vishy> Question a) Weekly meetings 21:57:57 <ewindisch> +1 21:58:05 <mikal> +1 21:58:07 <vishy> #startvote Should we have a weekly Meeting? Yes, No 21:58:08 <openstack> Begin voting on: Should we have a weekly Meeting? Valid vote options are Yes, No. 21:58:09 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 21:58:11 <russellb> i didn't like the idea but have found this one useful 21:58:20 <comstud> #vote yes 21:58:22 <mikal> #vote yes 21:58:22 <sdague> #vote Yes 21:58:23 <markmc> #vote yes 21:58:25 <russellb> #vote yes 21:58:26 <jog0> #vote yes 21:58:26 <mikal> They can be really short... 21:58:26 <eglynn> #vote yes 21:58:27 <ewindisch> I think it is a good idea toward the end of the cycle, at any rate. 21:58:27 <dprince> #vote yes 21:58:29 <ewindisch> #vote yes 21:58:36 <vishy> i wonder if the Yes vs. yes matters 21:58:41 <comstud> #vote Yes 21:58:42 <comstud> :) 21:58:43 <markmc> #vote YES 21:58:49 <russellb> #vote yEs 21:58:51 <sdague> :) 21:58:53 <vishy> #endvote 21:58:54 <openstack> Voted on "Should we have a weekly Meeting?" Results are 21:58:55 <openstack> Yes (9): markmc, jog0, eglynn, russellb, sdague, comstud, mikal, dprince, ewindisch 21:58:55 <maoy> #vote LIKE 21:58:58 <sdague> unit testing in progress! 21:59:09 <vishy> ok next vote 21:59:27 <vishy> #vote Same time every week? same, alternate 21:59:39 <anniec> #vote yes 21:59:41 <russellb> i think the people that don't like the time the most probably aren't here :) 21:59:42 <maoy> #vote same 21:59:43 <andrewbogott> #vote same 21:59:44 <ewindisch> #vote alternative 21:59:49 <vishy> #startvote Same time every week? same, alternate 21:59:50 <openstack> Begin voting on: Same time every week? Valid vote options are same, alternate. 21:59:51 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 21:59:51 <dprince> #vote alternate 21:59:52 <maoy> good pt russellb 21:59:54 <mikal> #vote same 21:59:57 <markmc> russellb, good point 21:59:58 <jk0> #vote same 21:59:59 <comstud> #vote same 22:00:01 <jog0> #vote same 22:00:02 <ewindisch> #vote alternative 22:00:02 <openstack> ewindisch: alternative is not a valid option. Valid options are same, alternate. 22:00:03 <markmc> #vote alternate 22:00:05 <andrewbogott> #vote same 22:00:06 <eglynn> #vote alternative 22:00:06 <openstack> eglynn: alternative is not a valid option. Valid options are same, alternate. 22:00:08 <vishy> alternate means alternating between two different times 22:00:10 <eglynn> #vote alternate 22:00:11 <russellb> #vote move vote to ML 22:00:12 <openstack> russellb: move vote to ML is not a valid option. Valid options are same, alternate. 22:00:12 <ewindisch> #vote alternate 22:00:20 <anniec> #vote same 22:00:20 <russellb> lol. 22:00:21 <comstud> haha 22:00:23 <comstud> d9d 22:00:28 <sdague> :) 22:00:34 <vishy> russellb: I don't know how we will ever reach a decision on the ml I guess with a poll 22:00:37 <russellb> #vote alternate 22:00:45 <vishy> ? 22:00:46 * russellb nods 22:01:03 <vishy> #endvote 22:01:04 <openstack> Voted on "Same time every week?" Results are 22:01:05 <openstack> alternate (5): dprince, markmc, eglynn, russellb, ewindisch 22:01:06 <openstack> same (6): jog0, jk0, comstud, mikal, andrewbogott, anniec 22:01:11 <russellb> those that couldn't make it proxy vote alternate 22:01:12 <vishy> so it is roughly split 22:01:13 <markmc> ooh, closely run 22:01:13 <mikal> Same clearly wins 22:01:23 <vishy> who wants to send a poll to the ml? 22:01:23 <markmc> heh 22:01:32 <markmc> mikal, it's 7am for you, right? 22:01:39 <vishy> lets pick a single time and an alternate and send to the ml 22:01:41 <ewindisch> How many of same are on the east coast ? ;-) 22:01:49 <mikal> markmc: yep 22:02:08 <vishy> eu people, when is a better UTC time for you? 22:02:22 <eglynn> slightly earlier timeslot would be good for GMT 22:02:29 <vishy> would 1400 work better? 22:02:38 <mikal> Ewww, that's midnight my time 22:02:49 <markmc> right 22:03:00 <russellb> mikal: can't win 'em all 22:03:03 <mikal> :( 22:03:03 <vishy> 1400 is 7am here 22:03:04 <eglynn> how about 20:00 UTC? 22:03:18 <vishy> that works for me but not for mikal :) 22:03:23 <mikal> russellb: I can't help it that I live on the bottom of the planet 22:03:32 <russellb> mikal: well, sure you can 22:03:33 <eglynn> 6am, yep that would be awkward 22:03:34 <mikal> vishy: I'll get up at 6am if I need to 22:03:46 <mikal> vishy: that's easier than midnight for me 22:04:05 <vishy> ok so one time is 20:00 22:04:16 <markmc> dunno about others, but I could do 6am utc 22:04:19 <markmc> what's that west coast? 22:04:20 <russellb> ironically a discussion about time has taken us over the meeting time. 22:04:21 <vishy> and if we alternate we go 1400 and 2100 ? 22:04:40 <dprince> +1 22:04:48 <mikal> Sure, that seems fair 22:04:52 <russellb> works for me 22:04:54 <markmc> cool 22:05:01 <mikal> You'd just have to say nice things about me when I'm not there 22:05:02 <dprince> I think alternating is good because it'll bring more people in. 22:05:04 <ewindisch> alternating would just cause confusion and kill attendance, imho 22:05:18 <vishy> markmc: 11pm here and 1am for midwest 22:05:21 <vishy> not so wonderful 22:05:33 <ewindisch> 2am for EST... 22:05:36 <sdague> markmc: and 2am est 22:05:37 <vishy> ok who knows how to make a poll? 22:05:41 <markmc> yeah, forgot about east coast :) 22:05:42 <markmc> doh 22:05:54 <vishy> can we poll between single 2000 meeting and 1400 / 2100 ? 22:05:58 <mikal> Google docs perhaps? 22:06:07 <mikal> A google spreadsheet form is quick and easy 22:06:18 <russellb> yeah gdocs works reasonably well for that 22:06:18 <vishy> mikal: can you send a poll to the ml? 22:06:21 <markmc> vishy, how about vote again now with a real alternate time 22:06:24 <mikal> (And you don't have to have an account) 22:06:31 <vishy> markmc: sure, revote 22:06:38 <mikal> vishy: I am happy to send a poll 22:07:39 <vishy> #startvote Meeting time single @ UTC 2100 or double, alternating between UTC 1400 and UTC 2100 ? single, double 22:07:40 <openstack> Begin voting on: Meeting time single @ UTC 2100 or double, alternating between UTC 1400 and UTC 2100 ? Valid vote options are single, double. 22:07:41 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 22:07:59 <russellb> #vote double 22:08:02 <markmc> #vote double 22:08:02 <ewindisch> wait, I thought it was single @ UTC 2000 ? 22:08:03 <mikal> vishy: I want to vote "don't care" 22:08:10 <vishy> ewindisch: sorry it is 22:08:12 <ewindisch> #vote single 22:08:13 <dprince> #vote double 22:08:15 <jk0> #vote single 22:08:16 <pixelbeat> #vote double 22:08:17 <sdague> #vote single 22:08:29 <vishy> #info previous vote was actually for UTC 2000 single time 22:08:36 <markmc> mikal, but you're the one in the weird timezone :) 22:08:39 <jog0> #single 22:08:40 <eglynn> #vote single 22:08:40 <russellb> mmm, double double 22:08:45 <vishy> #vote double 22:08:56 <mikal> markmc: heh, I don't mind missing every second meeting if it means more people can come 22:09:01 <vishy> jog0: you have to use #vote 22:09:13 <jog0> #vote single 22:09:17 <vishy> #endvote 22:09:18 <openstack> Voted on "Meeting time single @ UTC 2100 or double, alternating between UTC 1400 and UTC 2100 ?" Results are 22:09:19 <openstack> double (5): dprince, markmc, russellb, pixelbeat, vishy 22:09:20 <openstack> single (5): jog0, eglynn, jk0, sdague, ewindisch 22:09:25 <vishy> totally even 22:09:25 <dansmith> heh 22:09:26 <markmc> hah 22:09:26 <vishy> to the ml! 22:09:27 <russellb> >_< 22:09:37 <mikal> vishy: I'll send you an email about the poll 22:09:41 <vishy> #action mikal to take the vote to the ml 22:09:48 <markmc> we should just alternate between double and single, then 22:09:49 <vishy> ok we're done 22:10:00 <russellb> yay 22:10:01 <pixelbeat> lol 22:10:02 <vishy> next meeting will be determined based on the poll 22:10:06 <markmc> vishy, nicely done, thanks 22:10:07 <vishy> #endmeeting