14:01:13 <johnthetubaguy> #startmeeting nova
14:01:14 <openstack> Meeting started Thu Oct  1 14:01:13 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:16 <jaypipes> ................o.../
14:01:17 <openstack> The meeting name has been set to 'nova'
14:01:18 <scottda> hi
14:01:18 <lxsli> \o
14:01:19 <dims> \o/
14:01:20 <rlrossit> o/
14:01:20 <bauzas> \..........................o
14:01:20 <ctrath> o/
14:01:23 <claudiub> \o/
14:01:25 <jaypipes> bauzas: :P
14:01:25 <alaski> o/
14:01:26 <dansmith> o/
14:01:27 <garyk> hello
14:01:29 <abhishekk> o/
14:01:29 <jlvillal> o/
14:01:30 <jroll> some long arms in here
14:01:33 <ndipanov> o\
14:01:36 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/Nova
14:01:36 <mriedem> o/
14:01:41 <edleafe> \o
14:01:45 <raildo> \o
14:01:46 <johnthetubaguy> #topic Liberty Status
14:01:53 <johnthetubaguy> hello everyone
14:02:00 <johnthetubaguy> so we have RC1 out and being tested
14:02:19 <johnthetubaguy> we are waiting for RC2 to open, to include more translations, and a few stragglers
14:02:35 <johnthetubaguy> nothing serious enough to make us release another RC before the one we needed for translation updates
14:02:45 <johnthetubaguy> #link https://bugs.launchpad.net/nova/+bugs?field.tag=liberty-rc-potential
14:02:50 <johnthetubaguy> thats the watch list
14:02:58 <johnthetubaguy> any questions?
14:03:36 <johnthetubaguy> OK, well keep eyes peeled for problems, now is the time to find them and fix them
14:03:40 <johnthetubaguy> #topic Mitaka Status
14:03:48 <johnthetubaguy> #info master is open for mitaka
14:03:58 <johnthetubaguy> so the design summit sessions
14:04:04 <dguitarbite> hello
14:04:08 <johnthetubaguy> #info Deadline for session ideas: Tuesday 6th October, 23.59 UTC
14:04:17 <johnthetubaguy> #info Link for submissions: http://goo.gl/forms/D2Qk8XGhZ6
14:04:40 <johnthetubaguy> #info notes for those who can't get to google https://etherpad.openstack.org/p/mitaka-nova-summit-suggestions
14:04:48 <johnthetubaguy> OK...
14:05:06 <johnthetubaguy> does that date work OK for folks, there was my ML post about why I chose that date
14:05:29 <johnthetubaguy> basically to give us time to choose before the final lock down of sessions the following thursday
14:05:41 <bauzas> +1
14:05:50 <johnthetubaguy> so attempting to get folks to break the specs into catagories
14:05:55 <edleafe> makes sense
14:06:06 <johnthetubaguy> the idea being we make sure we don't miss any super important specs
14:06:07 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
14:06:12 <johnthetubaguy> thats where thats happening ^
14:06:22 <dansmith> I've been using that,
14:06:25 <dansmith> and it's been quite helpful
14:06:35 <dansmith> I made it through a large chunk of the specs on that page this week
14:06:42 <johnthetubaguy> the urgent thing is looking for anything thats are really important, and will need in person discussion I guess
14:06:49 <johnthetubaguy> sweet, glad thats starting to help
14:07:04 <johnthetubaguy> I basically started by adding the ones that haven been around a little while
14:07:13 <sdague> that's a nice break down there
14:07:17 <johnthetubaguy> stuff from this month mostly hasn't made it on there yet, but thats for later
14:07:38 <johnthetubaguy> so do add your own spec in there, if you fancy, as it gives us a helping hand
14:07:59 <bauzas> johnthetubaguy: oh we can ?
14:08:02 <johnthetubaguy> we said at the midcycle about looking at spec review priorities
14:08:03 <bauzas> johnthetubaguy: cool
14:08:08 <jaypipes> gah, sawtooth comb in my browser...
14:08:22 <garyk> what should we do about spec less bp's?
14:08:38 <johnthetubaguy> so thats next on the agenda
14:09:03 <johnthetubaguy> #info please ping folks via email or IRC to get your -2 removed, once your spec and/or blueprint is approved
14:09:24 <johnthetubaguy> so if you look on that etherpad we also have spec-less blueprints listed
14:09:43 <johnthetubaguy> now I am thinking we use that etherpad to collect those too, does that work for people?
14:10:22 <mriedem> yeah
14:10:33 <mriedem> should speed things up if we can just agree in the etherpad to approve rather than the nova meeting
14:10:53 <mriedem> or vote in the whiteboard of the bp or something like that
14:11:01 <bauzas> okay, so prio etherpad is for prio specs/bugs + quick hit bugs, and mitaka specs etherpad is for any other spec ?
14:11:05 <johnthetubaguy> yeah, then we can just ack them in the meeting
14:11:19 <johnthetubaguy> bauzas: thats the next bit, one sec
14:11:23 <bauzas> k
14:11:29 <johnthetubaguy> so this is just specs and blueprints for now, in that etherpad
14:11:49 <johnthetubaguy> so the first three vmware ones, I am going to approve those, is anyone against that?
14:12:08 <dansmith> I haven't looked at them yet, are they on the page now?
14:12:13 <johnthetubaguy> well, I will do the approve tomorrow morning, so vote in there if there is an issue I guess
14:12:18 <johnthetubaguy> yeah, they are in there
14:12:31 <dansmith> yeah, lemme run through them after the meeting
14:12:38 <garyk> all of the aforemenioned are totally self contained within the driver
14:12:56 <johnthetubaguy> the first one I am not sure I understand, but yeah
14:13:07 <johnthetubaguy> so for next time, lets try vote on the etherpad before the meeting
14:13:16 <johnthetubaguy> so this is just a wave through and discuss dissagreement thing
14:13:20 <garyk> which one? the opaque network support?
14:13:41 <johnthetubaguy> yeah, not sure I understand what its again
14:13:49 <garyk> i mentioedn that one at the vancouver summit and it has been in review since. it is a painpoint for out liberty neutron driver :(
14:14:00 <jaypipes> it's to support NSXv limitations, AFAIR...
14:14:07 <garyk> johnthetubaguy: it is just the name os a network type support by the VC
14:14:23 <garyk> jaypipes: no, that is not nsxv that is the new nsx version
14:14:36 <jaypipes> garyk: ok
14:14:37 <garyk> jaypipes: that was the pian poin in kilo :(
14:14:55 <jaypipes> garyk: yeah, I wasn't happy with the vnic index and other things...
14:14:58 <johnthetubaguy> so I don't quite get how thats exposed to the user from the blueprint
14:15:04 <markus_z> Will this etherpad be closed later on? IOW, until which date can I add a blueprint to that?
14:15:05 <jaypipes> anyway, don't want to go on tangent.
14:15:07 <garyk> jaypipes: yes, i recall.
14:15:21 <johnthetubaguy> markus_z: at spec freeze I suspect, which is probably mitaka-1
14:15:30 <garyk> johnthetubaguy: it is not exposed to the user
14:15:39 <garyk> it is just how the internal plugin configures tings
14:15:52 <garyk> until now the configuration file would have 'br-int'
14:15:55 <garyk> we no longer need that
14:16:24 <garyk> kind of the VC also has the notion now of an OVS bridge and that is an opaque type
14:16:33 <johnthetubaguy> garyk: it feels like a tiny spec for that first one would be good
14:16:43 <markus_z> johnthetubaguy: Ah, ok. Do I have to ping cores to have a look at it or will this be regularly looked at?
14:16:49 <johnthetubaguy> garyk: the support provider network port group?
14:16:57 <johnthetubaguy> markus_z: should be looked at without pings
14:17:03 <markus_z> ok, thanks
14:17:07 <johnthetubaguy> garyk: I think that needs a blueprint opening?
14:17:09 <mriedem> we're getting off in the weeds on the vmware specless bps here....can we table that?
14:17:18 <johnthetubaguy> garyk: if you add one, I think I can happy with that
14:17:19 <garyk> johnthetubaguy: yes, agree. i need to open one
14:17:20 <mriedem> or do it in the nova channel later
14:17:31 <johnthetubaguy> mriedem: yes, was just hoping to be quick
14:17:37 <johnthetubaguy> lets stop with that now
14:17:39 <mriedem> 1 is fine, half a dozen is too many for the meeting
14:17:56 <garyk> give me a finger and i'll take a hand
14:18:03 <mriedem> pull my finger
14:18:07 <johnthetubaguy> yeah, agreed a plan for next time to avoid all this
14:18:11 <johnthetubaguy> thats the main bit
14:18:19 <johnthetubaguy> didn't want to leave them blocked another week though
14:18:36 <johnthetubaguy> #topic Regular Reminders
14:18:41 <johnthetubaguy> so this is the bit bauzas was asking about
14:18:53 <johnthetubaguy> I created the mitaka etherpad of doom
14:18:55 <johnthetubaguy> #link https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
14:19:00 <ndipanov> johnthetubaguy, can I add my spec to that etherpad?
14:19:03 <johnthetubaguy> same idea as before really
14:19:04 <bauzas> sorry, was confused :)
14:19:18 <johnthetubaguy> ndipanov: feel free to add it to the spec etherpad, yes
14:19:25 <johnthetubaguy> bauzas: no worries
14:19:49 <johnthetubaguy> anyways, I copied across the trivial patches, and added a few sub groups that have patches up already
14:19:54 <johnthetubaguy> but its there
14:19:59 <johnthetubaguy> #topic Bugs
14:20:14 <markus_z> Unfortunately I was busy with other work and don't have a good overview right now, sorry.
14:20:34 <markus_z> The two crits have patches for stable/liberty but ttx -2 for RC opening
14:20:54 <johnthetubaguy> yeah, they didn't seem bad enough to open the RC early
14:21:01 <bauzas> we're currently monitoring if any regressions
14:21:06 <markus_z> ~8 reviews on the trivial bug list
14:21:18 <johnthetubaguy> right, anything bug that we want to talk about
14:21:18 <bauzas> there is one bug that's planned to discussed during open discussion
14:21:23 <markus_z> That's all I can say for now
14:21:29 <rsritesh> HI
14:21:29 <mriedem> there was the novaclient legacy bdm bug
14:21:31 <johnthetubaguy> there was a nasty one sdague and melwitt were looking at
14:21:36 <mriedem> yeah that
14:21:38 <bauzas> right, that one too
14:21:42 <markus_z> link?
14:21:46 <mriedem> we should probably do a patch release for that
14:21:46 <sdague> that we just landed
14:21:58 <sdague> mriedem: yeh, I've already talked with ttx on it
14:22:11 <mriedem> sdague: well it's just client so we an do a release right?
14:22:14 <mriedem> patch version release
14:22:16 <bauzas> I just wonder if https://bugs.launchpad.net/nova/+bug/1500688 is a regression but let's leave that for later
14:22:16 <openstack> Launchpad bug 1500688 in OpenStack Compute (nova) "VNC URL of instance unavailable in CLI" [Undecided,New]
14:22:16 <sdague> because we can't do liberty -> master upgrade testing until it's fixed
14:22:32 <sdague> bauzas: it's definitely not good, it should be fixed
14:22:43 <mriedem> markus_z: https://bugs.launchpad.net/python-novaclient/+bug/1501435
14:22:43 <openstack> Launchpad bug 1501435 in python-novaclient "osc 1.7 no longer can boot a server from volume" [Critical,Fix committed] - Assigned to John Garbutt (johngarbutt)
14:22:43 <bauzas> sdague: agreed
14:22:47 <bauzas> that's MHO
14:22:47 <johnthetubaguy> so I think we need to release off the stable branch and master, so with might need to bump the major version on master
14:23:07 <mriedem> master release version will depend on what's changed
14:23:10 <mriedem> i can look at that after the meeting
14:23:27 <johnthetubaguy> mriedem: yeah, just thinking we need to release of stable as well
14:23:36 <johnthetubaguy> so might have to ignore the rules there
14:23:44 <bauzas> the stable patches for the bdm stuff have been approved AFAIR
14:23:50 <mriedem> stable should be a patch version release
14:23:55 <mriedem> master can be a minor version
14:23:58 <jroll> johnthetubaguy: wouldn't you do a patch release on stable and minor release on master? (rephrased, why major)
14:24:00 <mriedem> i'll look after the meeting
14:24:00 <sdague> right, we need a release on both
14:24:10 <mriedem> if we backported something to stable that requires a minor version bump, we f'ed up
14:24:10 <sdague> mriedem: great
14:24:15 <johnthetubaguy> jroll: thats my assumption, yeah
14:24:28 <johnthetubaguy> mriedem: oh crud, thats true, but maybe thats not allowed?
14:24:30 <sdague> mriedem: it should be patch only I think, it's pretty minor
14:24:32 <jroll> yeah ok
14:24:34 <mriedem> #action mriedem to checkout novaclient releases for stable/liberty and master
14:24:35 <johnthetubaguy> anyways, something for later
14:24:41 <johnthetubaguy> yeah, thank you!
14:24:53 <rsritesh> Hi..all I have one review to discuss...pending since long time..don't know how can I forward thsi
14:24:54 <johnthetubaguy> mriedem: stable all cool?
14:24:56 <bauzas> anyone can put action items ?
14:25:08 <mriedem> i think stable is ok
14:25:22 <mriedem> some odd ebtables juno-only nova-net failure showed up yesterday
14:25:23 <johnthetubaguy> rsritesh: lets put that in open discussion, after the items we have there
14:25:25 <mriedem> not sure what that is yet
14:25:35 <johnthetubaguy> yuck
14:25:45 <mriedem> might be related to the ebtables failure we're seeing on master now
14:26:00 <johnthetubaguy> interesting, new test combo maybe
14:26:06 <johnthetubaguy> anyways...
14:26:07 <mriedem> no, not in juno
14:26:12 <mriedem> could be kernel updates on trusty...
14:26:14 <mriedem> https://bugs.launchpad.net/nova/+bug/1501366
14:26:14 <openstack> Launchpad bug 1501366 in OpenStack Compute (nova) "libvirtError: Error while building firewall: Some rules could not be created for interface" [High,Confirmed]
14:26:16 <johnthetubaguy> #topic Open Discussion
14:26:33 <johnthetubaguy> mriedem: oh, true...
14:26:41 <garyk> at the summit will there br driver sessions?
14:26:49 <johnthetubaguy> so we have an item here form abhishekk
14:26:52 <abhishekk> hi
14:26:56 <johnthetubaguy> https://bugs.launchpad.net/nova/+bug/1416132
14:26:56 <openstack> Launchpad bug 1416132 in OpenStack Compute (nova) "_get_instance_disk_info fails to read files from NFS due to permissions" [High,In progress] - Assigned to Eric Harney (eharney)
14:27:03 <johnthetubaguy> garyk: one sec, will get back to that
14:27:27 <abhishekk> this is reported by eric and required to be fixed for cinder feature (NFS clone and snapshot)
14:27:27 <johnthetubaguy> abhishekk: what did you want to ask about thi?
14:27:39 <abhishekk> nikola has suggested 2 ways to fix this bug IMHO neither of which are easy
14:28:01 <abhishekk> I just want all members to have a look and give their opinion on the bug
14:28:07 <johnthetubaguy> ndipanov ^
14:28:36 <abhishekk> In between Eric also posted one solution but it is not a good way to fix
14:28:41 <abhishekk> yes ndipanov
14:28:52 <garyk> abhishekk: can you please post that review
14:28:57 * mriedem defers to ndipanov
14:28:58 <abhishekk> yes
14:29:09 <abhishekk> https://review.openstack.org/#/c/149037/
14:29:51 <johnthetubaguy> honestly, I wonder about attaching BDM to the instance object, dansmith is that totally crazy?
14:30:07 <johnthetubaguy> like a lazy load field think
14:30:07 <dansmith> johnthetubaguy: we currently have the opposite, right?
14:30:19 <ndipanov> I think it's not _that_ hard
14:30:26 <dansmith> johnthetubaguy: we can make a lazy-load property, but I don't think we want it as a field because it makes it a circular dependency
14:30:37 <abhishekk> johnthetubaguy: yes lazy loading
14:31:02 <abhishekk> cinder review: https://review.openstack.org/#/c/147186/
14:31:09 <ndipanov> well we can try that but I think that's gonna have a notice-able impact on the RT performance
14:31:13 <johnthetubaguy> dansmith: oh right...
14:32:19 <ndipanov> we need select * from instance left join bdm on instance.uuid
14:32:23 <johnthetubaguy> there was someone talking about DB optimisation patches to remove excessive fetching/saving of BDMs during boot, it just feels like this could be adding lots more
14:32:44 <ndipanov> it would add N queries to every RT run
14:32:48 <ndipanov> N = number of instances
14:32:52 <ndipanov> on the host
14:32:58 <johnthetubaguy> that sounds a bit nuts
14:33:01 <ndipanov> it is
14:33:01 <abhishekk> ndipanov: yes you are right
14:33:24 <johnthetubaguy> OK, so this feels like a good discussion for #openstack-nova, shall we take this offline?
14:33:33 <ndipanov> we need the join query really
14:33:34 <ndipanov> ok
14:33:36 * jroll imagines that code running in an ironic env with hundreds of instances D:
14:33:51 <abhishekk> ok, I will ping on openstack-nova
14:34:06 <bauzas> so re: https://bugs.launchpad.net/nova/+bug/1500688
14:34:06 <openstack> Launchpad bug 1500688 in OpenStack Compute (nova) "VNC URL of instance unavailable in CLI" [Undecided,New]
14:34:11 <johnthetubaguy> cool, I have a feeling there are lots of poeple in the meeting who can't add too much
14:34:16 <dansmith> we can hide that in a single query and rpc call wtithout much trouble
14:35:18 <markus_z> bauzas: Could you confirm that bug? I tried to get more info in that bug report.
14:35:35 <bauzas> markus_z: so, the story is that it has been changed in API v2.6
14:35:43 <bauzas> https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst#26
14:35:54 <bauzas> but the client is not getting that
14:36:13 <bauzas> mriedem: you had a question on the client behaviour?
14:36:21 <markus_z> ohh, I remember
14:36:33 <mriedem> i was just saying the CLI shouldn't send 2.latest
14:36:42 <mriedem> it should send the latest version it's implemented to handle
14:36:42 <sdague> right, so novaclient needs code to interpret the results
14:36:45 <johnthetubaguy> maybe always requesting the latest was a bad move...
14:36:46 <mriedem> which is 2.4 right now i think
14:36:51 <sdague> mriedem: no, it's 2.11
14:36:57 <mriedem> sdague: in the client i mean
14:37:08 <sdague> mriedem: right, in the client I thought someone implemented 2.11
14:37:10 <johnthetubaguy> yeah, I think the client should maybe request a high watermark?
14:37:11 <bauzas> https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L23
14:37:21 <mriedem> sdague: ok, well then 2.5-2.10 are not available
14:37:22 <bauzas> I can see a MAX_VERSION
14:37:29 <sdague> mriedem: right, that's the crux
14:37:30 <johnthetubaguy> ah...
14:37:42 <bauzas> does that mean it's not respected when calling by the CLI ?
14:37:49 <johnthetubaguy> we are missing some functional testing here I guess
14:37:56 <sdague> yes, we are missing testing
14:38:05 <sdague> and there is a hole in the microversion support
14:38:05 <mriedem> well you can workaround the bug by explicitly passing v2.1 or something <2.6
14:38:10 <markus_z> Ah, that's the reason Horizon is able to get the VNC console, but the CLI isn't.
14:38:16 <sdague> markus_z: yes
14:38:28 <bauzas> nevermind https://github.com/openstack/python-novaclient/blob/master/novaclient/shell.py#L54
14:38:41 <mriedem> yeah, i think that's a bad idea
14:38:45 <johnthetubaguy> maybe it should be max API version per CLI call? or is that just silly?
14:38:56 <sdague> it should be max api
14:39:06 <johnthetubaguy> so you just upgrade one call to a new version, rather than all calls
14:39:07 <sdague> however, it would still be broken
14:39:25 <mriedem> imo the default should be the highest lower-bound that is supported, which i tihnk is 2.4 now
14:39:32 <sdague> honestly, I think that's going to be a mess
14:39:33 <mriedem> regardless of if 2.11 is implemented
14:39:41 <sdague> because it won't let lower bounds ever move
14:39:55 <mriedem> once you add 2.5 support you change the default to 2.5
14:39:56 <mriedem> and so on
14:39:58 <sdague> it's going to cause a ton of fallout down the road that is going to be really hard to address
14:40:26 <mriedem> so on the server side the changes are incremental,
14:40:31 <mriedem> but on the client side it's willy nilly
14:40:33 <edleafe> changing APIs always messes up clients
14:40:39 <johnthetubaguy> yeah, feels like we need incremental on the client side
14:40:40 <sdague> we should just be stricter on saying "you can't add 2.x to max until we're sure everything in 2.x-1 are handled
14:40:43 <edleafe> at least we have a sane way of addressing it
14:40:44 <sdague> that's the mistake we made
14:40:47 <mriedem> sdague: right
14:40:49 <mriedem> agree with that
14:40:55 <sdague> so lets just backfill that
14:41:11 <sdague> and be aware in the future
14:41:24 <mriedem> so what should DEFAULT_OS_COMPUTE_API_VERSION be today? 2.11?
14:41:30 <johnthetubaguy> so to support 2.13 you must also add 2.12 support?
14:41:35 <sdague> johnthetubaguy: yes
14:41:41 <johnthetubaguy> sdague: I guess thats OK
14:41:46 <mriedem> yeah, +1 to that
14:41:59 <johnthetubaguy> mriedem: feels like we should move that 2.4 while we fix thing up?
14:42:02 <alaski> how do we test that?
14:42:21 <sdague> we require tests on the boundary conditions to be submitted
14:42:30 <sdague> the issue where is there are no tests for the vnc stuff either
14:42:37 <sdague> no functional tests
14:42:54 <mriedem> yeah when i added 2.4 support there is a functional test for 2.1 and a test for 2.4
14:42:56 <edleafe> what about requiring a client bug be created with each microversion?
14:42:59 <mriedem> just like on the server side
14:43:00 <markus_z> I'm wondering that the old APIs got directly removed. Is that the usual approach? I thought they will be marked as deprecated but still functional.
14:43:11 <markus_z> *be
14:43:19 <johnthetubaguy> markus_z: we keep them for ever, basically
14:43:19 <mriedem> edleafe: it should really just be part of the nova spec
14:43:33 <alaski> mriedem: okay, so it's clear from the changed code that a version is skipped?
14:43:36 <edleafe> mriedem: sure, but I mean as a way of tracking
14:43:55 <sdague> markus_z: the resource is gone if you request that version, which is what the code is currently doing
14:44:21 <mriedem> alaski: i guess if we change DEFAULT_OS_COMPUTE_API_VERSION for each impl, and someone skips some versions, then it'd be clear
14:44:24 <mriedem> but we'd need to test that i'd think
14:44:28 <mriedem> unit test would be easy
14:44:47 <mriedem> like what we do in the nova objects version tests
14:45:04 <alaski> okay.  I haven't looked at microversions in the client, just wondered if it would be clear, and testable
14:45:05 <mriedem> 'this is the last known max value, did they try skipping a version?'
14:45:12 <johnthetubaguy> OK, is anyone in particular able to take that one, so I can give you an action?
14:45:15 <bauzas> I'm a bit unclear, but why can't we default the max boundary to the same max boundary defined by novaclient?
14:45:33 <sdague> bauzas: we can, and we should
14:45:33 <markus_z> sdague: Ah, ok, I thought it will just return the result from the new API.
14:45:34 <mriedem> i'm not sure what max boundary we're talking about
14:45:38 <sdague> this bug would still be there
14:45:49 <mriedem> is there something besides this? https://github.com/openstack/python-novaclient/blob/master/novaclient/shell.py#L54
14:46:09 <mriedem> johnthetubaguy: i could take an action on this
14:46:15 <garyk> id this something that we need to document - say people are starting to use liberty and their existing clients break.
14:46:28 <johnthetubaguy> I was looking at this I guess: https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L23
14:46:29 <garyk> that would be really problematic
14:46:35 <bauzas> sdague: sure, we also need to gracefully change the API resource to call by the client if the server is >=2.6 IIUC
14:46:45 <sdague> bauzas: yes
14:46:50 * markus_z has the same thought as garyk
14:47:02 <mriedem> johnthetubaguy: oh hrm
14:47:04 <johnthetubaguy> garyk: yeah, I think we need to fix this urgently too
14:47:22 <johnthetubaguy> mriedem: honestly, no idea what they both do, I haven't dug enough
14:47:22 <edleafe> IMO the client "knows" the latest it can support. It shouldn't get that from the API
14:47:29 <bauzas> garyk: yup, I think this bug is High at least
14:47:30 <mriedem> so https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L23 and https://github.com/openstack/python-novaclient/blob/master/novaclient/shell.py#L54 need to be tied together
14:47:40 <bauzas> garyk: and would need a RC2 backport
14:47:41 <johnthetubaguy> yeah
14:47:51 <bauzas> mriedem: that's MHO
14:47:56 <sdague> right, the bug was that the client jumped to 2.11, but didn't handle the 2.6 switch
14:48:00 <mriedem> i still don't think 2.11 as the default is right
14:48:06 <johnthetubaguy> bauzas: this is a client issue, its a client backport, but yeah
14:48:09 <mriedem> 2.11 as max is probably ok to opt into
14:48:14 <bauzas> johnthetubaguy: oh correct :)
14:48:20 <mriedem> but i'd think default is 2.4
14:48:35 <johnthetubaguy> mriedem: yeah, lets move this back to something we know works, then try add the gaps?
14:48:44 <johnthetubaguy> that should work I think
14:48:45 <sdague> johnthetubaguy: +1
14:48:45 <mriedem> that's what i was thinking, keep it simple
14:48:54 <sdague> especially as it will need to backport
14:49:05 <johnthetubaguy> we can backport the nuke it, and move forward then
14:49:06 <jroll> mriedem: fwiw, in ironic we decided not to have cli as max by default after much debate
14:49:06 <mriedem> and we can backport a thing to stable/liberty and get it into the upcoming patch release which we know is happening b/c of the legacy bdm bug
14:49:22 <mriedem> jroll: geez thanks for telling us!
14:49:23 <sdague> mriedem: we need the bdm release ASAP
14:49:29 <mriedem> sdague: ok
14:49:35 <mriedem> can work both today separately
14:49:37 <jroll> mriedem: read the ML harder :P
14:49:49 <edleafe> in the client, isn't API_MAX_VERSION = x saying that the client can correctly handle any version up to and including x?
14:49:51 <sdague> jroll: yes, but nova's in a different boat with multi cloud support
14:50:00 <sdague> edleafe: it should mean that
14:50:08 <sdague> that's the bug
14:50:08 <jroll> sdague: totally. just putting that data point out there, it isn't unprecedented
14:50:23 <edleafe> sdague: that was my understanding; just checking
14:50:25 <bauzas> right, the resolution of the bug is to add support for 2.6 that's it
14:50:34 <mriedem> #action mriedem to sort out novaclient default/max api version mess and backport things
14:50:38 <bauzas> support in the client I mean
14:50:43 <mriedem> bauzas: well, 2.6-2.10
14:50:45 <sdague> bauzas: any, related, any other potential issues in there
14:50:46 * jroll still of the opinion users should always explicitly pass a version, it's only one more env variable
14:50:54 <johnthetubaguy> jroll: this is just the CLI at least, when you use it as an SDK you have to be explicit with versions
14:50:56 <mriedem> bauzas: the immediate tactical fix though is to not default to 2.11
14:51:08 <jroll> johnthetubaguy: yep
14:51:09 <bauzas> mriedem: agreed, there is a workaround
14:51:11 <mriedem> bauzas: and then we backport that
14:51:20 <sdague> jroll: we disagree on that one, I don't think users should have to set any env vars
14:51:28 <sdague> the cloud they are talking to knows what it can do
14:51:28 <bauzas> mriedem: WFM
14:51:55 <jroll> sdague: oh, I know :)
14:52:00 <johnthetubaguy> well, I like us trying to make it work
14:52:14 <johnthetubaguy> I think we have a plan, we should cover the other two things before we run out of time
14:52:15 <sdague> yeh, this isn't hard to fix, it just got missed
14:52:32 <johnthetubaguy> sdague: mriedem: you folks are both on the case here I guess?
14:52:42 <sdague> I think mriedem's on lead, I'll help review
14:53:01 <johnthetubaguy> #action mriedem to look into the max API version in python-novaclient
14:53:04 <johnthetubaguy> cools
14:53:14 <johnthetubaguy> so garyk you had a question about driver sessions
14:53:46 <johnthetubaguy> so the question for me is, what do you want to debate in the session? do you have a list of specs that can't get agreement on, for example?
14:54:01 <bauzas> mriedem: FWIW triaged https://bugs.launchpad.net/python-novaclient/+bug/1500688
14:54:01 <openstack> Launchpad bug 1500688 in python-novaclient "VNC URL of instance unavailable in CLI" [High,Confirmed]
14:54:15 <garyk> johnthetubaguy: i feel that most of the time a lot of people have no idea what is going on in the various drivers and the sub teams can and should share the data.
14:54:23 <garyk> it would be a good platformt o share ideas and information
14:54:43 <garyk> at least enable one to give better clarity to the internals and help reviewrs undersyand things a bit better
14:54:47 <mriedem> is a 40 minute session every 6 months going to fix that?
14:55:01 <mriedem> maybe a weekly meeting would be better if there are topics to discuss
14:55:03 <sdague> it feels like a monthly email might be more useful
14:55:08 <mriedem> yeah, something
14:55:10 <dansmith> yeah, I think I'm done with driver sessions at summits
14:55:14 <garyk> sdague: that sounds like a good idea
14:55:19 <johnthetubaguy> garyk: so here is the thing, I am giving priority to things that need in person discussion
14:55:36 <johnthetubaguy> yeah, the monthly email is a good one
14:55:40 <garyk> johnthetubaguy: ok. understood. lets leave the drivers out
14:55:48 <garyk> not saying that in a bad way.
14:56:07 <johnthetubaguy> cools
14:56:11 <mriedem> you could also do a thing like sdague's old friday google hangout sessions
14:56:13 <mriedem> for show and tell
14:56:23 <markus_z> I liked those
14:56:24 <mriedem> which would be good for education
14:56:26 <johnthetubaguy> honestly, thats almost something for the main conference track, and folks can watch the video afterwards
14:56:26 <garyk> mriedem: that sounds like a nice idea.
14:56:32 <mriedem> like, wtf are vmware opague networks?
14:56:40 <bauzas> mriedem: ++ for resuming friday talks :)
14:56:40 <raildo> mriedem, ++
14:56:57 <johnthetubaguy> cool, some top ideas there
14:57:08 <garyk> mriedem: problem here is that is so internal in the driver and its hard to make changes like this and it causes cross project issues -
14:57:16 <raildo> and will be easy for new nova guys, understand more about the nova new features :)
14:57:27 <johnthetubaguy> there was one more person waiting about a stuck review
14:57:28 <garyk> liberty nova and stable liberty (due to the fact that we were asked to BP is) will not support liberty neutron
14:57:32 <garyk> that is a huge problem
14:57:46 <johnthetubaguy> raildo: sharing more info is good, the specs are part of that process too
14:57:59 <mriedem> garyk: it came up late w/o a blueprint so it wasn't tracked, so part of the problem is just communication and process
14:58:04 <mriedem> and there are ideas for improving that
14:58:07 <raildo> johnthetubaguy, sure
14:58:10 <johnthetubaguy> rsritesh: did you have something?
14:58:13 <garyk> mriedem: ok.
14:58:14 <rsritesh> https://bugs.launchpad.net/python-novaclient/+bug/1500688
14:58:14 <openstack> Launchpad bug 1500688 in python-novaclient "VNC URL of instance unavailable in CLI" [High,Confirmed]
14:58:17 <rsritesh> yes this
14:58:18 <rsritesh> one
14:58:24 <rsritesh> https://blueprints.launchpad.net/python-novaclient/+spec/enhance-commands-for-usability
14:58:28 <garyk> that would be a very good session to have at the summit. but not sure if it is on the table
14:58:37 <rsritesh> i have written code for that feature
14:58:39 <mriedem> rsritesh: so we just talked about that bug for like 15 minutes right?
14:58:40 <johnthetubaguy> garyk: which session?
14:58:46 <bauzas> rsritesh: we just discussed about 1500688 :)
14:58:47 <garyk> talk about how to improve the process
14:58:55 <garyk> what mriedem wrote above
14:59:17 <rsritesh> sorry
14:59:17 <rsritesh> https://review.openstack.org/#/c/190111/
14:59:21 <rsritesh> wrong ping
14:59:21 <mriedem> garyk: maybe friday meetup style if there are tihngs, we did talk about some of this at the last meetup (which i know you weren't able to attend)
14:59:28 <rsritesh> https://blueprints.launchpad.net/python-novaclient/+spec/enhance-commands-for-usability
14:59:31 <rsritesh> https://review.openstack.org/#/c/190111/
14:59:38 <rsritesh> the above is one is mine
15:00:13 <johnthetubaguy> garyk: OK, gotcha, we do usually have one of those
15:00:14 <sdague> yeh, that's a pretty drastic ux change
15:00:31 <sdague> which I'm quite concerned is going to break folks
15:01:05 <bauzas> rsritesh: we usually have some contrib repository that handles meta commands
15:01:18 <bauzas> rsritesh: like the host-migrate CLI
15:01:23 <mriedem> we are over time
15:01:27 <mriedem> let's move to -nova
15:01:28 <bauzas> right
15:01:31 <johnthetubaguy> ah, we are totally over
15:01:36 <johnthetubaguy> sorry, didn't see that
15:01:38 <johnthetubaguy> anyways, thanks all
15:01:44 <edleafe> thanks!
15:01:46 <johnthetubaguy> #endmeeting