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