13:59:24 #startmeeting nova 13:59:25 Meeting started Thu Jan 14 13:59:24 2016 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:29 The meeting name has been set to 'nova' 13:59:49 \o 13:59:54 o/ 13:59:54 o/ 14:00:13 \o 14:00:17 o/ 14:00:19 o/ 14:00:25 hi 14:00:30 o/ 14:00:32 Hi 14:00:35 Everyone 14:00:37 hi 14:00:39 -_- 14:00:40 hi all 14:00:41 o/ 14:00:43 hi 14:00:54 so lets get going now its time 14:01:01 #topic Release Status 14:01:12 #info Jan 21: Nova non-priority feature freeze 14:01:20 #info Jan 19-21: mitaka-2 14:01:34 so this afternoon, I am thinking of kicking out all blueprints that don't yet have any code up for review 14:01:55 o/ 14:02:13 we already have more blueprint code that we can possibly merge, so its good to try and concentrate 14:02:30 +1 14:02:31 #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking 14:02:49 I was thinking to work on Legacy to DVR - TBD 14:02:52 lets keep our review focus up, to get the most into this release as possible, the above should help us with that 14:03:05 if it ok with team 14:03:09 o/ 14:03:12 o/ 14:03:19 navinrio: lets leave that till the Open Discussion section 14:03:26 so as a heads up 14:03:29 ok 14:03:44 the mitaka-2 release will happen independently of the feature freeze 14:04:10 there will be some simple exception process, in some etherpad, post the freeze, but the midcycle is likely to extend that beyond the usual one week 14:04:22 but we can discuss that later on 14:04:25 o/ 14:04:33 any questions with the process things, while we are here? 14:04:47 #topic Bugs 14:05:07 so our bug folks don't seem to be in channel today 14:05:35 #help volunteers for 1 week of bug skimming duty? https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty 14:05:48 #link https://etherpad.openstack.org/p/stable-tracker 14:06:03 #link http://status.openstack.org/elastic-recheck/index.html 14:06:15 ............o/ ... o-|-< 14:06:17 any things folks want to raise around these? 14:06:46 nothing really critical unless I missed 14:07:03 johnthetubaguy : the dhcp timeout is concerning 14:07:23 dims: thats just a new signature for an old friend though, as I understand it? 14:07:25 dims: the dhcp issue has been around for a long time 14:07:34 I agree it would be good to figure out 14:07:37 thats basically the same as the ssh timeout thingy 14:07:38 sdague : johnthetubaguy : ack 14:07:48 johnthetubaguy: well, it's a subset 14:07:53 but yeah, who fixes that for good needs some kind of reward 14:07:59 sdague: oh, thats even better 14:08:19 bounty! 14:08:30 johnthetubaguy: I came across this: https://bugs.launchpad.net/nova/+bug/1533678 14:08:32 Launchpad bug 1533678 in OpenStack Compute (nova) "Jenkins py34 gate failing with 'wmi is not defined' error" [Undecided,New] 14:08:49 dane-fichter : that should have gotten fixed already 14:08:53 dims: python3.4 is still failing a lot 14:09:06 dane-fichter: hmm, we use that for hyper-v but should only run on windows, AFAIK, and probably fixed 14:09:10 sdague : last 3 were on the same review 14:09:18 ok 14:09:28 cool, moving on 14:09:32 sdague : legitimate failures i checked 14:09:43 #topic Open Discussion 14:09:48 we have a few agenda items 14:09:58 PaulMurray: any midcycle details to share? 14:10:03 dims: oh, it was recheck grinded .... :( 14:10:09 #link https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprint 14:10:18 #link https://etherpad.openstack.org/p/mitaka-nova-midcycle 14:10:39 if you are there, please do start adding ideas 14:11:07 I know some folks are only making it for one day (mdbooth I think), so we can try schedule things, to suit where possible 14:11:09 johnthetubaguy, only what's on the pages 14:11:23 PaulMurray: cool 14:11:25 johnthetubaguy, I might add a page 14:11:37 for people to say when they arrive, leave where they 14:11:48 stay - in public - does that sound useful 14:11:49 ? 14:12:10 there is a TC related discussion https://review.openstack.org/#/c/256440/ but I think that was on last week too 14:12:23 PaulMurray: yeah, very possibly, if folks want to 14:12:38 thomasem: you wanted to talk about LXC? 14:12:39 red like a tomato 14:12:49 johnthetubaguy: I did, and that review concerns me a bit. 14:13:20 We're trying to get the experimental lxc gate tests to a reliable state at the moment 14:13:30 we have details of what we're doing laid out here: https://etherpad.openstack.org/p/lxc_driver_devstack_gate 14:14:08 Pretty much trying to stabilize the Libvirt/LXC driver from a testing perspective so we can get at least with a non-voting gate test, and hopefully a voting one soon after. 14:14:36 Right now the experimental job is failing consistently, and we've identified the tests that I think are the problem. 14:15:03 cool, good to see progress on that 14:15:33 any more topics folks want to raise? 14:15:37 or any questions? 14:15:42 johnthetubaguy: I added some 14:15:48 me too 14:15:49 navinrio: I think you had a question? 14:15:55 unit tests w/ constraints 14:15:57 I was going to see what y'all thought about skipping those to give us breathing room while I find the problems there. All of the tests that are failing (save for the expected ones like disk config which doesn't apply to raw fs images) are working fine in my local devstack, but the devstack-gate's devstack configuration is different. I'm comparing and going line-by-line to figure out at what point it breaks 14:16:09 sorry, johnthetubaguy I wasn't quite done :P 14:16:11 just typing 14:16:20 thomasem: ah, no worries 14:16:23 it's 8 tests that are having trouble with the devstack gate configuration 14:16:29 and so that's what I'm in the process of debugging right now 14:16:38 thomasem: I like the idea of something testing LXC, assuming that includes booting an instance 14:16:50 I believe dimtruck has or will soon have a regex change up to skip those tests 14:16:52 yes, that's tested 14:16:56 getting a green thing, then working through it makes sense 14:16:59 the ones that are failing are anything that does a stop on it 14:17:06 yep that's what I'm thinking 14:17:18 a patch will be up this morning...testing in local gate first...it worked 14:17:20 there's something weird going on with Libvirt there 14:18:04 Sounds good, johnthetubaguy 14:18:09 thomasem: lets try that, and see where we go, cools 14:18:29 so mriedem had a question about volume multi-attach on the ML: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084031.html 14:18:39 as he is not here, might make sense to reply there 14:18:53 unless folks had things they wanted to discuss here? 14:19:03 its a tricky upgrade one, in summary 14:19:12 johnthetubaguy: I have one thing, but it can wait 14:19:31 o/ 14:19:55 i just wanted to raise https://blueprints.launchpad.net/nova/+spec/flavor-with-volume 14:19:57 OK... 14:20:05 tpatzig: you have a blueprint on the agenda 14:20:13 yes 14:20:29 tpatzig: its not approved for mitaka, so is unlikely to make our feature freeze next week 14:20:33 currently i'm writing the spec, just wanted to see if it makes sense and is worth... 14:21:04 does not necesarily be in mitaka 14:21:23 tpatzig: if you want a flavor that says "this must be boot from volume", that seems like a good idea 14:21:44 yes, exactly without ephemerals 14:21:59 tpatzig: +1 14:22:01 tpatzig: I don't really think Nova should restrict the volume sizes though, but its worth documenting the use case in a spec, so we understand it 14:22:32 the volume size should be purely a cinder quota/limits thing, in my head, but I am willing to say I could well be missing something 14:22:53 sdague: I see your things now :) 14:23:04 sdague: Unit tests with constraints - https://review.openstack.org/#/c/267096/ 14:23:38 oh, I see, this is use constraints everywhere 14:23:39 right, so originally I had patches up for us to go the direction neutron went, with things like py27-constraints environments 14:23:46 i did not had any size limits in my mind so far. just providing a volume size in the flavor will create the cinder volume if the quotas allow 14:24:13 however both mriedem and danpb disliked that approach, because we have to retrain the world how to run tests that match the gate. Which I think is a valid point. 14:24:13 johnthetubaguy: it's only about restricting any kind of ephermal disk 14:24:29 tpatzig: I think we probably want the user to pass in the volume they already created, ideally, but lets talk more in the spec review, with use cases infront of us 14:24:47 mkoderer: yes, that the feature I am wanting us to have, but haven't had time to build yet 14:24:57 johnthetubaguy: cool 14:25:03 yeah, not sure asking to create a volume sounds good for me 14:25:12 this does however mean we're going to have to now convince the rest of folks that we should use the same names, so it would be helpful to get nova people to +1 - https://review.openstack.org/#/c/267149/ 14:25:25 which is the governance change to make this all happen 14:25:43 the net result: unit tests should get randomly broken by upstream library releases less often 14:25:44 johnthetubaguy:ok, makes sense. the idea with the flavor option is to create a new cinder volume, not for existing ones 14:25:45 sdague: oh, we should totally agree on the names, good point 14:25:51 tpatzig: ok so let's work on a spec for n-release :) 14:26:09 sdague: totally agreed thats an important step 14:26:30 #help please review this governance change around unit tests: https://review.openstack.org/#/c/267149/ 14:26:38 mkoderer: +1 14:26:46 sdague: nice change 14:27:00 sdague: this feels easier now we dropped run_tests.sh 14:27:07 johnthetubaguy: yeh, agree 14:27:14 that only took 3 years :) 14:27:20 heh 14:27:39 well it made me move over to tox, but anyways, lol 14:27:48 that's all on that topic, let me know when you are ready for project_id discussion 14:28:33 so the above seems OK to me, but I could well be missing something that dansmith and mridem are seeing 14:28:38 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/083976.html 14:28:42 lets talk project ids 14:28:52 sdague: do we need the non constraints job in order to test updating the constraints? 14:29:04 alaski: no 14:29:20 okay, then +1 from me 14:29:21 ok, project_ids 14:29:57 there is an intractable problem with supporting urls with and without project_id as long as the definition of project_id is completely wide open 14:30:12 which I explained in that email 14:30:13 johnthetubaguy: we dropped run_tests.sh ?? it still exists in git AFAICT 14:30:22 lol 14:30:40 danpb, try running it 14:30:54 lol 14:31:22 so, mostly, I need feedback on what kind of constraint we find acceptable that has a low likelihood of breaking people 14:31:23 sdague: so I think for projects ids you hit a good comprimise 14:31:41 it certainly looks like it works for me, in the rackspace sense of me 14:32:19 there are about 1000 tests which will have to be updated to get it to pass, because we use 'fake' and 'openstack' as project_id in our tests, so before I start grinding through that I wanted to have some confidence [0-9a-f]+ is ok 14:32:41 oh, I remember you saying now, yeah 14:33:11 so, I'll take this as an ACK on that regex, and move forward 14:33:16 it does worry me, that we can't have top level resources that are valid hex, but it seems a small price to pay 14:33:34 johnthetubaguy: right, well we don't have any today 14:33:48 and this limitation is only in effect as long as we support both at once 14:33:58 we can always add os- if there is one 14:34:03 right 14:34:22 that regex should work for all operators who have spoken up about it, but is there a fallback if someone comes forward later and is broken? 14:34:33 alaski: my feeling is we fix it in post 14:34:59 I love that phrase 14:35:11 that's probably going to piss off someone 14:35:20 either amend the regex, or configure optional project_id off? 14:35:27 alaski: right 14:35:32 something something please everyone all the time something something 14:35:33 we could go for each route having a "supports project_id also" option, then have two regex-es so we tell if its a valid route, before then checking for the project id, but that feels like overkill for now 14:35:41 _if_ we wanted to be slower, could we install something that will warn people that their url is going to not work? 14:35:47 yeah, seems we have an out 14:35:58 or are you saying there'll be a flag that will fix them in the first round for sure? 14:36:20 so, honestly, I don't believe there will be any deployments that will get hit with this 14:36:37 because they have to be really old, and really hack keystone 14:37:12 we'll put in the release notes this is a restriction, make it prominent 14:37:21 and keep an eye on bugs filed in 14:37:35 sorry if I'm being dense, 14:37:39 then react to that if there are any (I'll bet a beer there will never be) 14:37:40 they'll only get bit if they upgrade, and if they are that old what's the odds of them upgrading without thinking hard about it? 14:37:50 not much 14:37:53 so safe 14:38:14 whatever, I guess I'll stop being cautious 14:38:22 cdent: very likely, as long as there's an out if the upgrade will break them 14:38:43 that's what I want to clarify 14:38:45 right, and I think the out is us patching later. 14:38:47 that the first breakage is soft 14:38:49 dansmith: you thinking an option to stop support both, if they hit the issue? 14:39:17 johnthetubaguy: I want to soft break them first, with a fix_it_this_time=True flag so they have at least a cycle to figure out what they're going to do 14:39:28 I know that we think nobody will be in this situation, 14:39:37 dansmith: gotcha, you add the conf as already deprecated maybe? 14:39:57 but we know someone converting from some system to keystone could have this arrangement and breaking our oldest users doesn't seem like a good idea 14:40:12 dansmith: if they update their service catalog to drop the project_id, there is no problem 14:40:33 apart form all the hard-coded scripts 14:40:40 right 14:40:43 sdague: as long as they have nothing else that depends on it, like a load balancer, or any number of other things ... 14:40:54 I'm just saying, 14:40:57 sdague: is it easy to add the config? or hard? 14:41:02 or a rate limiter like repose... 14:41:21 the reason I'd like to not add a config, is people will start using it that aren't us 14:41:22 alaski: yeah... unless you want an excuse to remove it 14:41:28 this seems like a pretty serious grenade to just throw in and require people to make that kind of change to account for it in one cycle 14:41:47 and the reality is that it's going to be 12 months before anyone shows up with this 14:41:57 if anyone ever does 14:42:00 johnthetubaguy: there have been many reasons already, and it's still there :) 14:42:05 sdague: but if we add it as deprecated "if you need this call us" kind of thing, it feels better 14:42:07 which I don' think they will 14:42:09 * mriedem_away joins fashionably late 14:42:12 alaski: true :'( 14:42:15 johnthetubaguy: and when do we delete it? 14:42:35 sdague: next release, at least they have an edge thats soft, if they follow orders 14:42:48 anyone that far behind tends not to 14:43:14 in reality, if you've hacked the system enough to have this behavior, you've got custom patches on keystone 14:43:29 that's not true, right? 14:43:29 I feel like a map to "you are going to have to patch nova as well" should be fine 14:43:38 dansmith: was it LDAP or something? 14:43:40 just importing stuff into the db will get you here right? 14:43:52 maybe 14:43:53 oh, right, that 14:43:59 yeah, it sounded like keystone allowed this 14:44:02 i remember hearing LDAP come up as a possible case for breakage 14:44:05 alaski: it did 14:44:23 anyway, 14:44:46 I need not take a hard line on this.. it seems like a big grenade to me, but if the deployer types (john and laski) aren't concerned then that's fine 14:44:59 but if they are, I think we should be really cautious here 14:45:19 I have concerns 14:45:23 I am tempted to add a config for one release, to soften the blow 14:45:41 ok, if a config for a different regex will get us concensus, I'm fine with that 14:46:00 already deprecated config, yes? 14:46:02 what does that mean? 14:46:04 yes 14:46:05 lets add it as deprecated 14:46:22 "different regex" ? 14:46:28 * dansmith notes that he is uncaffeinated 14:46:32 dansmith: let the operator define the validation regex for project_id 14:46:45 dansmith: yeah, I'm working on that... (caffeinating) 14:47:01 sdague: okay, I thought maybe you mean something else 14:47:08 jaypipes: +1 14:47:25 sdague: that would make it more palatable to me 14:47:44 alaski: ok 14:47:53 yeah, same here I think 14:48:00 Ok, so any more for any more? 14:48:04 quick request for review https://review.openstack.org/259528 and the related patches. 14:48:16 they are for implementing an approved non priority bp 14:48:19 thanks 14:48:52 so quick reminder about the feature freeze next week 14:48:53 thanks all 14:48:57 #endmeeting