14:00:25 <johnthetubaguy> #startmeeting Nova
14:00:30 <openstack> Meeting started Thu Sep  3 14:00:25 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:33 <openstack> The meeting name has been set to 'nova'
14:00:39 <mriedem> hi
14:00:40 <alaski> o/
14:00:41 <alex_xu> o/
14:00:42 <rlrossit> o/
14:00:42 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/Nova
14:00:44 <n0ano> o/
14:00:47 <ctrath> o/
14:00:50 <edleafe> o/
14:00:53 <dansmith> o/
14:01:09 <sdague> o/
14:01:11 * bswartz lurks...
14:01:25 <jlvillal> o/
14:01:28 <bauzas> \o
14:01:49 <lxsli> o/
14:01:51 <johnthetubaguy> #topic Release Status
14:02:03 <johnthetubaguy> #info we have tagged liberty-3
14:02:31 <atuvenie> o/
14:02:31 <dansmith> I have a question about that
14:02:35 <abhishekk> o/
14:02:36 <johnthetubaguy> #info there have been two "technical" FFEs granted, because the changes were approved but not merged https://launchpad.net/nova/+milestone/liberty-rc1
14:02:48 <janonymous_> o/
14:02:59 <mnestratov|2> o\
14:03:01 <johnthetubaguy> a few things got pushed out
14:03:06 <claudiub> o/
14:03:15 <johnthetubaguy> dansmith: fire away?
14:03:47 <dansmith> johnthetubaguy: the date for l3 is to day, right? wouldn't we normally tag at the end of the day in the last timezone? I was surprised to wake up and see -2s going out already
14:04:03 <dansmith> s/to day/today/
14:04:32 <sdague> it usually happened whenever ttx could do it in the morning
14:04:42 <sdague> it used, to happen on tuesday in a branch
14:04:50 <dansmith> I thought it was actually the morning after the actual day
14:05:03 <johnthetubaguy> so we did push it some times
14:05:08 <sdague> no, it was always in the morning, so that there was a day of buffer if things went wrong
14:05:11 <johnthetubaguy> but that was only to wait for approve stuff to merge
14:05:13 <dims> o/
14:05:19 <dansmith> alright
14:05:23 <johnthetubaguy> but yeah, it was just a buffer for hard stops
14:05:27 <ndipanov> o/
14:05:36 <johnthetubaguy> now we can grant FFEs if we really need to
14:05:47 <dims> string freeze is today too right?
14:06:01 <mriedem> dims: should be
14:06:02 <johnthetubaguy> dims: its with the tag, I believe, so its now
14:06:14 <dims> cool
14:06:23 <johnthetubaguy> so I think we are soft dependency freeze and string freeze
14:06:32 <sdague> so, it would be really good to get someone who's responsible for i18n and putting in the string freeze to actually communicate about it
14:06:57 <johnthetubaguy> sdague: yes, let me ask the release team about that
14:07:07 <sdague> I feel like we end up with a longish freeze, no idea where the translations are at or when they are done, and no idea about what impact breaking that freeze for bugs has
14:07:12 <dansmith> would be really nice if we could actually land our requirements thing now: https://review.openstack.org/#/c/216968/16 :)
14:07:15 <johnthetubaguy> #action johnthetubaguy to get an answer about string freeze
14:07:25 <dansmith> with reqs frozen, there should be no more rebases of that right?
14:07:26 <mriedem> dansmith: never
14:07:37 <johnthetubaguy> dansmith: yeah, crap I totally missed that hadn't merged
14:07:38 <johnthetubaguy> grr
14:07:39 <mriedem> dansmith: it seems to auto-rebase
14:07:49 <dansmith> mriedem: I figured it was when new reqs land or something
14:07:54 <johnthetubaguy> oh
14:07:54 <mriedem> diffs between patches don't actually show changes to the reqs file
14:07:59 <dansmith> ah
14:07:59 <mriedem> just hte parent hash
14:08:04 <mriedem> so that's fun
14:08:12 <johnthetubaguy> thats super fun
14:08:13 <dansmith> well, we could land most of it in a separate patch then maybe
14:08:26 <mriedem> i could totally do the exact same sync myself
14:08:27 <dansmith> I can push that up if so
14:08:28 <mriedem> using the same tool
14:08:35 <mriedem> there is a tox job in the requirements repo for it
14:08:38 <mriedem> s/job/target/
14:08:53 <sdague> honestly, there is nothing in the requirements update that probably impacts us anyway, so the fact that it's not in L3 is probably not a big deal
14:09:00 <dansmith> huh/
14:09:00 <mriedem> sdague: there is
14:09:05 <sdague> mriedem: which?
14:09:08 <mriedem> min ovo version needed
14:09:11 <dansmith> yeah, we're technically broken on o.vo right now
14:09:11 <johnthetubaguy> ovo
14:09:12 <johnthetubaguy> yeah
14:09:14 <mriedem> for new code in nova that only works with ovo 0.9.0
14:09:27 <sdague> oh, code was landed before that bumped?
14:09:31 <sdague> that I didn't realize
14:09:35 <mriedem> yup
14:09:35 <johnthetubaguy> sdague: yup
14:10:04 <mriedem> i will remember to -2 all of dansmith's changes next release :)
14:10:13 <dims> haha
14:10:14 <johnthetubaguy> well, anyways, with all that fun, any more?
14:10:17 <dansmith> that code would have never merged if it waited on this though, so fixing the auto rebase thing would be good ...
14:10:32 <dansmith> johnthetubaguy: so I want to plug the objects bump work
14:10:39 <garyk> what is o.vo?
14:10:41 <johnthetubaguy> dansmith: oh totally
14:10:42 <dansmith> johnthetubaguy: begging for reviews, whenever you want that in here :)
14:10:48 <dansmith> because it's had none
14:11:01 <dansmith> and I'm going to be pissed if I did this *again* and it didn't land *again* because nobody reviewed it...
14:11:04 <dims> garyk: oslo.versionedobjects
14:11:10 <garyk> ok, thanks
14:11:22 <mriedem> dansmith: i've got the reqs sync running locally now, will get that up during the meeting
14:11:24 <johnthetubaguy> dansmith: with the tag done, you have my attention, at a minimum
14:11:39 <dansmith> johnthetubaguy: okay, patches are here: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/liberty-bump-object-and-rpcapi-versions,n,z
14:11:47 <johnthetubaguy> #topic Bugs
14:11:49 <dansmith> well, just mine of that set
14:11:57 <johnthetubaguy> so we have some meaty things in here for today
14:12:20 <johnthetubaguy> I guess first one is v2.0 on v2.1 status
14:12:28 <johnthetubaguy> #link https://bugs.launchpad.net/nova/+bug/1491511
14:12:28 <openstack> Launchpad bug 1491511 in OpenStack Compute (nova) "Behavior change with latest nova paste config" [Undecided,Confirmed]
14:12:56 <sdague> right, so that landed, and a few other groups noticed some things: infra, manilla, trove
14:13:03 <alex_xu> I tested the legacy v2 also, delete floating ip by ip address will return 404 also
14:13:14 <sdague> trying to get all the incompats stacked in that one bug
14:13:22 <johnthetubaguy> so the good news, we are now getting the testing we wanted
14:13:30 <johnthetubaguy> the bad news, is the API is a bit broken
14:13:37 <sdague> right, so we've got 3 incompats reported so far
14:13:55 <sdague> 1) DELETE ../os-floating-ips/GARBAGE is now 400 instead of 404
14:14:14 <johnthetubaguy> is there a point where we loose confidence, and revert back to /v2 by default, or should we really just keep pushing on this now?
14:14:18 <sdague> 2) device=None to attach_volume is now 400 instead of success
14:14:28 <sdague> 3) server names can no longer contain spaces
14:14:39 <johnthetubaguy> (i mean v2_legacy by default)
14:14:57 <dansmith> johnthetubaguy: I think if we don't plow ahead we'll never get this data
14:14:59 <sdague> I believe #1 is fine, and we leave it. It actually exposed a bug in infra's testing
14:15:01 <ndipanov> sdague, 2) seems like a bug - none should be valid I think
14:15:10 <edleafe> johnthetubaguy: keep pushing
14:15:10 <mordred> and we've fixed the testing
14:15:12 <mordred> and it's all good now
14:15:22 <mriedem> we at least have a novaclient fix for #2
14:15:26 <dims> +1 to keep pushing
14:15:27 <mriedem> which i plan on releasing today
14:15:30 <johnthetubaguy> dansmith: yeah, I think we have to keep pushing
14:15:37 <sdague> 2) we allow it, because nova only novaclient, but ruby fog assumes that's valid
14:15:54 <sdague> so we're going to break a lot of people if we keep the current behavior
14:15:54 <johnthetubaguy> seems like we need a server side and client side fix?
14:16:03 <johnthetubaguy> for (2) that is
14:16:03 <sdague> johnthetubaguy: yeh, I think we should fix both on #2
14:16:12 <sdague> dims has a patch up
14:16:14 <mriedem> 2 is fixed in novaclient, but yeah needs server side too
14:16:28 <johnthetubaguy> cool
14:16:30 <sdague> #3 ... ?
14:16:32 <dansmith> so I hadn't seen #3, but that seems like an obvious bug to me
14:16:42 <johnthetubaguy> do we have patches up for (3)?
14:17:24 <johnthetubaguy> I guess we have always allowed spaces, so that should continue, at least until some specific microversion that removes it, I assume?
14:17:39 <dansmith> why not spaces forever?
14:17:48 <sdague> https://bugs.launchpad.net/nova/+bug/1491511/comments/3
14:17:49 <openstack> Launchpad bug 1491511 in OpenStack Compute (nova) "Behavior change with latest nova paste config" [Undecided,Confirmed]
14:17:50 <dansmith> didn't we do this work recently to allow pile-o-poo as a server name?
14:17:51 <johnthetubaguy> true, I guess thats fine
14:18:02 <dansmith> seems silly to allow unicode characters and not spaces to me
14:18:05 <mriedem> name is display name
14:18:07 <johnthetubaguy> fair
14:18:10 <mriedem> it should include unicode etc
14:18:13 <dansmith> right
14:18:14 <dims> dansmith: ++
14:18:24 <edleafe> yes to spaces and poo
14:18:59 <johnthetubaguy> I guess we should check the v2.1 validation allows poo
14:19:23 <johnthetubaguy> who is driving this one, and making sure we reviews all this quickly?
14:19:28 <mriedem> i thought there was a tempest test for that but i might be thinking of image names
14:19:29 <sdague> ok, so agreed that we'll fix this one
14:19:35 <sdague> mriedem: it's image names
14:19:50 <alex_xu> I can help on patch
14:19:56 <sdague> alex_xu: great
14:20:06 <mriedem> if there are patches up for review can someone link here or -nova?
14:20:13 <alex_xu> so we should check all the 'name' field?
14:20:16 <sdague> mriedem: I don't think there is a patch yet
14:20:25 <johnthetubaguy> lets be sure to mark all these bugs as critial so its easy to find them
14:20:25 <sdague> alex_xu: yeh, just let spaces into any names
14:20:33 <mriedem> sdague: but for #2 - just restore dims' from yesterday?
14:20:37 <alex_xu> sdague: ok, got it
14:20:37 <sdague> johnthetubaguy: well, we were collecting them all in one bug
14:20:46 <sdague> but yet
14:20:48 <sdague> yeah
14:20:51 <johnthetubaguy> sdague: OK, that works I guess
14:20:54 <sdague> mriedem: yes, I did that an hour ago
14:21:02 <andreykurilin> e0ne already post a bug for issue with attach volume - https://bugs.launchpad.net/nova/+bug/1491842
14:21:03 <openstack> Launchpad bug 1491842 in OpenStack Compute (nova) "Can't attach volume without specifying device name" [High,Confirmed]
14:21:03 <bswartz> +1 for restoring dims patch
14:21:23 <andreykurilin> *post a bug report
14:21:40 <mriedem> #link patch for server side #2 https://review.openstack.org/#/c/219696/
14:21:50 <edleafe> alex_xu: I'll help with that if needed
14:21:59 <bauzas> can we track all of that thru the etherpad ?
14:22:15 <alex_xu> edleafe: yea, thanks!
14:22:17 <sdague> bauzas: we have bugs for these, we can keep track on that
14:22:28 <bauzas> sdague: fair enough
14:22:45 <johnthetubaguy> OK
14:22:51 <johnthetubaguy> so the next bug?
14:23:05 <sdague> yeh
14:23:10 <sdague> we seem to have an approach here
14:23:11 <johnthetubaguy> #link https://bugs.launchpad.net/python-novaclient/+bug/1491579
14:23:12 <openstack> Launchpad bug 1491579 in python-novaclient "against all sanity, nova needs to work around broken public clouds" [Critical,In progress] - Assigned to Sean Dague (sdague)
14:24:00 <sdague> right, so we assumed we could actually GET the version info for our API from nova
14:24:07 <dansmith> WAHT
14:24:14 <sdague> which apparently a lot of clouds deploy in various ways that don't make that possible
14:24:14 <dansmith> that's crazy talk
14:24:33 <dansmith> versions are like passwords
14:24:39 <dansmith> suuuuuper secret
14:24:39 <sdague> mordred has enough credentials on clouds to figure out it was pretty wide spread as well
14:25:14 <sdague> dhellmann chatted with dreamhost folks, and it might actually be something that's in the upstream chef cookbooks
14:25:20 <sdague> which is why it's all over the place
14:25:37 <mriedem> sweet
14:25:55 <mriedem> and those generally lag by 4 months
14:26:02 <sdague> anyway, there is a partial fix here - https://review.openstack.org/#/c/220111/ - though apparently I failed tests
14:26:05 <ndipanov> so the result of this is - novaclient is completely broken for public clouds?
14:26:15 <sdague> ndipanov: on some of them
14:26:18 <mordred> ndipanov: it works with vexxhost and unitedstack
14:26:37 <sdague> after that fix it works for everything except rax and one other
14:26:46 <mordred> auro
14:26:54 <mordred> oh. scuse me. runabove
14:26:56 <mordred> auro works with the fix
14:27:15 <sdague> and rax is probably work aroundable
14:27:18 <johnthetubaguy> I think alaski is looking on the rackspace side to see what could be with repose to make the right thing happen
14:27:18 <ndipanov> nice
14:27:37 <alaski> johnthetubaguy: yes, but it will take a bit of time to get a change rolled out
14:27:49 <johnthetubaguy> alaski: very true
14:27:51 <mordred> I'm going to contact the OVH/runabove folks (or, really, have ttx do it)
14:28:23 <sdague> ok, so I'll actually work on getting this into landing shape today, including the rax fix, which will go faster if I can get rax creds... hint hint
14:28:35 <sdague> otherwise someone's going to need to pair debug parts of this with me that does
14:29:02 <sdague> also, I think long term, we need to include these things in the defcore definition
14:29:07 <johnthetubaguy> sdague: yeah, lets try get that sorted somehow
14:29:11 <mriedem> mtreinish: is working on that right?
14:29:13 <sdague> and you are just not openstack if you don't do this
14:29:16 <johnthetubaguy> sdague: +1 for adding this in defcore
14:29:17 <mriedem> he's adding a version list test to tempest
14:29:17 <sdague> mriedem: yeh, starting
14:29:27 <sdague> yeh, rax fails nova version-list as well
14:29:51 <sdague> which should be a required accessable url, we'll get that into defcore
14:30:19 <johnthetubaguy> seems like a very good use of defcore
14:30:20 <sdague> anyway, I think we have a story at least
14:30:24 <mtreinish> mriedem: https://review.openstack.org/219873
14:30:28 <johnthetubaguy> cool
14:30:48 <johnthetubaguy> mriedem: any more on gate or stable branches that need raising
14:30:48 <mtreinish> mriedem: oomichi took it over and looks like he got it working
14:30:49 <sdague> yes, I'm just annoyed that we have to specify every url in the server we expect to work via defcore
14:31:02 <mriedem> johnthetubaguy: umm
14:31:08 <mriedem> johnthetubaguy: i have'nt had a chance to look today
14:31:10 <mriedem> so pass
14:31:33 <bauzas> mordred: lemme see if I can help for OVH/runabove
14:32:03 <johnthetubaguy> OK
14:32:08 <bauzas> mordred: one of the PoCs is piligrimstack on -fr chan
14:32:17 <johnthetubaguy> #topic Regular review reminders
14:32:17 <bauzas> oops pilgrimstack
14:32:24 <johnthetubaguy> so sub teams
14:32:34 <mordred> bauzas: oh! great. I was just about to ping pilgrimstack actually
14:32:39 <johnthetubaguy> now is a great time to be very clear about what bugs are critical for liberty
14:32:56 <ndipanov> do we want to have some kind of - "not horribly broken for most public OpenStack enpoints" test going forward?
14:33:06 <mordred> bauzas: could you just let him know what's up and that we've got fixes/workarounds for everyone _but_ them. if they could not _hang_ on trying to hit that endpoint, that would be stellar
14:33:14 <johnthetubaguy> #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
14:33:18 <mordred> opening it == good. rejecting with 401 works too if they have feelings
14:33:27 <bauzas> mordred: sure, just pinging him on #openstack-fr :)
14:33:28 <johnthetubaguy> thats the way to tell everyone, that and the priority, and release targetting
14:33:31 <mordred> bauzas: thanks!
14:33:41 <johnthetubaguy> #topic Open Discussion
14:34:14 <johnthetubaguy> OK, so one more thing from the release, currently stable/liberty will be created, and we open for mitaka once we tag RC1
14:34:44 <johnthetubaguy> we have the option of doing that a bit before RC1 if we want, but then we have to backport all bug fixes we want to that stable branch for a little while
14:34:50 <johnthetubaguy> and all that overhead
14:34:55 <johnthetubaguy> but just wanted to share that
14:34:57 <mriedem> do it after rc1
14:35:04 <garyk> johnthetubaguy: for blocked bp's without specs will those be reopened? or do we need to ping you offline
14:35:23 <sdague> ndipanov: so, the problem with that, is we need creds on those clouds
14:35:23 <mriedem> looks like rc1 should be around 9/21?
14:35:26 <johnthetubaguy> garyk: once mitaka is open, ping me
14:35:29 <sdague> which... we don't have
14:35:32 <garyk> ok
14:35:32 <electrocucaracha> Hi, I would like to discuss about this https://review.openstack.org/#/c/215414/ , this is my first meeting so
14:35:48 <sdague> I would love to have some creds where we could test novaclient for reals
14:35:56 <dansmith> sdague: say creds one more time
14:35:58 <dansmith> I dare you
14:36:03 <bauzas> +1 for waiting RC1
14:36:21 <johnthetubaguy> electrocucaracha: I see that patch has a -2 from mriedem because its a feature and not a bug
14:36:30 <bauzas> we should be focused on bugfixes anyway
14:36:32 <dansmith> and I agree with that assessment
14:36:38 <mriedem> johnthetubaguy: there are also 2 patches for the same thign
14:36:40 <mriedem> with different solutions
14:36:58 <johnthetubaguy> mriedem: yes, I am +1 the -2 because its a feature
14:36:59 <mriedem> the other: https://review.openstack.org/#/c/185129/
14:37:26 <mriedem> electrocucaracha: did you have a specific question?
14:37:54 <electrocucaracha> actually, what I can do? it's something that have to wait for the next release
14:37:59 <mriedem> yes
14:38:03 <mriedem> we're in feature freeze in liberty
14:38:12 <mriedem> i tihnk you need to work with the people that have the competing change
14:38:19 <mriedem> and work together on a design in a blueprint and probably spec
14:38:21 <mriedem> for mitaka
14:38:30 <johnthetubaguy> electrocucaracha: you can write the nova-spec now, and get in touch with the folks mentioned here: https://blueprints.launchpad.net/nova/+spec/boot-from-uefi to agree an approach
14:38:34 <mriedem> electrocucaracha: https://wiki.openstack.org/wiki/Blueprints
14:38:45 <johnthetubaguy> +1 what mriedem just said basically
14:38:59 <mriedem> i can smell the synergy to come
14:39:03 <johnthetubaguy> electrocucaracha: just reach out to us in #openstack-nova if you want help with any of that
14:39:32 <mrkz> I do have a question regarding that + libvirt nova-team, Is that team still doing meetings?, I ask because page in https://wiki.openstack.org/wiki/Meetings/Libvirt looks like needs a bit of love ?
14:39:37 <johnthetubaguy> electrocucaracha: we have some nova specific docs here, which may or may not help: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
14:40:02 <mriedem> mrkz: i thought danpb disbanded that
14:40:05 <johnthetubaguy> mrkz: I don't think they meet anymore, but others like danpb may know different
14:40:06 <mriedem> due to lack of attendance
14:40:16 <johnthetubaguy> yep, thats what I remembered
14:40:36 <johnthetubaguy> would be good if someone can update the wiki to make that cleaer
14:41:00 <johnthetubaguy> OK, so any more for any more?
14:41:11 <mriedem> i can update the wiki
14:41:13 <mriedem> let's leave
14:41:23 <electrocucaracha> woo I didn't know all of this documents, thanks a lot for the info, I'm sure that questions will come later
14:41:29 <johnthetubaguy> mriedem: cool, thank you
14:41:32 <johnthetubaguy> electrocucaracha: happy to help
14:41:45 <johnthetubaguy> cool, thanks all
14:42:01 <johnthetubaguy> have a good day/evening/etc
14:42:06 <johnthetubaguy> #endmeeting