12:00:04 <alex_xu> #startmeeting nova api
12:00:05 <openstack> Meeting started Tue Sep  8 12:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:08 <openstack> The meeting name has been set to 'nova_api'
12:00:13 <alex_xu> who is here today?
12:00:18 <edleafe> o/
12:00:25 <gmann_> o/
12:00:47 <johnthetubaguy> o/
12:00:56 <alex_xu> hello everyone
12:01:05 <alex_xu> let's start the meeting
12:01:07 <alex_xu> #topic actions from last meeting
12:01:17 <alex_xu> sdague to write up test plan for v2.x nova, alex_xu and gmann_ will work on patches
12:01:33 <alex_xu> actually sdague did all the things :)
12:01:41 <gmann_> yea
12:01:41 <alex_xu> #link https://review.openstack.org/#/c/219370/
12:01:46 <alex_xu> #link https://review.openstack.org/#/c/219347/
12:02:09 <alex_xu> all of that are merged
12:02:18 <alex_xu> there is last one from gmann_
12:02:25 <alex_xu> #link https://review.openstack.org/#/c/219553/
12:02:44 <alex_xu> I think this is all for gate
12:03:04 <gmann_> #link https://review.openstack.org/#/c/219555/
12:03:33 <alex_xu> gmann_: thanks
12:03:59 <alex_xu> I guess this is all for v2 api on gate
12:04:27 <alex_xu> sdague: ^ are you around? is there anything more on gate for v2 api?
12:04:30 <gmann_> alex_xu: sdague : do we need v21 compatible job as experimental on tempest as discussed on https://review.openstack.org/#/c/219370/
12:04:56 <johnthetubaguy> v21 compatible is now the default run right?
12:05:06 <johnthetubaguy> given the paste-api.ini changes
12:05:08 <gmann_> johnthetubaguy: v21 is default
12:05:09 <alex_xu> yea
12:05:19 <johnthetubaguy> hmm, so whats on the v21 jobs?
12:05:37 <gmann_> johnthetubaguy: /v21 service catalog
12:05:46 <johnthetubaguy> check-tempest-dsvm-full vs check-tempest-dsvm-nova-v21-full
12:05:53 <gmann_> and each job for /v2 and v21 compatible
12:05:58 <sdague> o/
12:06:05 <johnthetubaguy> I thought the first would fire at /v2.0 and the second fires at /v2.1?
12:06:19 <gmann_> johnthetubaguy: check-tempest-dsvm-nova-v21-full will be removed in https://review.openstack.org/#/c/219553/
12:06:22 <johnthetubaguy> what we are missing now are tests for leagacy_v2 code I thought?
12:06:37 <alex_xu> yea, I think so
12:06:47 <sdague> johnthetubaguy: so check-tempest-dsvm-full is now pointing at /v2.1
12:06:52 <gmann_> johnthetubaguy: for legacy v2 code we have one new job
12:06:59 <sdague> because devstack compute SC entry is now pointing at /v2.1
12:07:09 <sdague> there is a compute_legacy SC entry
12:07:17 <gmann_> gate-tempest-dsvm-nova-v20-api
12:07:17 <johnthetubaguy> sdague: OK, gotcha
12:07:17 <sdague> which is the /v2.0 endpoint
12:07:23 <sdague> there are 2 jobs testing it
12:08:05 <alex_xu> what is for v2.1 legacy compat mode?
12:08:07 <sdague> gate-tempest-dsvm-nova-v20-api
12:08:19 <johnthetubaguy> ah, they on the experimental queue I guess
12:08:20 <sdague> which is v2.0 on v2.1
12:08:25 <sdague> gate-tempest-dsvm-nova-v20-api-legacy
12:08:29 <sdague> v2.0 on old v2.0
12:08:37 <sdague> johnthetubaguy: no, they are in check queue, non-voting
12:08:38 <alex_xu> ah, yea
12:08:44 <gmann_> johnthetubaguy: they are on check pipeline
12:08:45 <johnthetubaguy> ah, so thats nice and simple, cool
12:08:45 <sdague> they only run the compute api tempest tests
12:09:00 <alex_xu> so we are good, right?
12:09:03 <johnthetubaguy> sdague: ah, so I am looking at runs that are too old, thinking about it
12:09:12 <johnthetubaguy> alex_xu: sounds perfect to me
12:09:12 <sdague> johnthetubaguy: yeh, they landed late last week
12:09:24 <sdague> my intent is to look at the stats on those today
12:09:33 <sdague> and if the pass rate is high enough, make them voting
12:09:41 <johnthetubaguy> sweet
12:09:43 <alex_xu> cool
12:09:47 <gmann_> sdague: do we need v21 comap job as experimental on tempest?
12:10:02 <gmann_> sdague: +1 to make them voting
12:10:10 <sdague> gmann_: yeh, we should probably put both those jobs in tempest experimental as well
12:10:24 <gmann_> sdague:  yea
12:10:26 <sdague> gmann_: you want to post the patch for that?
12:10:37 <gmann_> sdague: yea, i can post tomorrow early
12:11:37 <alex_xu> #action gmann_ post patch put v2.1 compat and v2 legacy jobs as experimental
12:11:44 <gmann_> alex_xu: thanks
12:11:52 <alex_xu> gmann_: np
12:11:58 <alex_xu> let's move on
12:12:01 <alex_xu> edleafe will update https://review.openstack.org/#/c/217727/
12:12:11 <alex_xu> for this, let's jump to next topic directly
12:12:20 <alex_xu> #topic v2.0 on v2.1
12:12:30 <alex_xu> There are some patches we need discussion, and all  of them are about whether fix it for v2.1. Let's talk about them one by one
12:12:40 <alex_xu> #link https://review.openstack.org/#/c/217727/
12:12:59 <alex_xu> I prefer fix it for v2.1 also. Otherwise when user switch to v2.1 the functionality of support out-of-tree filters is broken.
12:13:13 <alex_xu> ken'ichi change his mind also, he removed -1
12:13:35 <edleafe> I haven't caught up on the discussion on that patchset yet.
12:13:47 <edleafe> I'm recovering from a long US weekend. :)
12:13:50 <sdague> right, I thought we were generally agreed to let through scheduler filters
12:13:57 <alex_xu> edleafe: the argument is more about whether we fix it in the v2.1 API
12:14:06 <gmann_> alex_xu: oh, so we are not going with runtime discovery for hint?
12:14:30 <gmann_> sdague: for v2.1 also
12:14:32 <sdague> gmann_: we still need to get to discovery, but if we don't let this through it means that rax won't use v2.1
12:14:36 <sdague> which I'd like to avoid
12:14:39 <alex_xu> gmann_: we need think that more.
12:14:47 <sdague> they need custom scheduler filters
12:15:13 <johnthetubaguy> we certainly need some for the v2.0 compatibility mode
12:15:19 <gmann_> sdague:  humm, yea that true
12:15:34 <sdague> yeh, but I also think that it's fine to be pragmatic on this one
12:15:35 <johnthetubaguy> we could just hack the validation logic, but thats pretty aweful
12:15:40 <alex_xu> to discover which hints enabled in the deployement, shouldn't be done by the json-schema. I think that is capabilites discovery. json-schema is part of our api contract
12:16:05 <sdague> laski brought it up a bunch of times as a real issue, and I'm fine with that
12:16:21 <gmann_> ohk
12:16:26 <sdague> so I'm conceptually +2 on https://review.openstack.org/#/c/217727/ - though I haven't reviewed the patch in detail
12:16:37 <johnthetubaguy> yeah, so we need a "proper" way to do all this, but we don't have one right now, so it feels like 217727 is the best way forward
12:16:54 <sdague> agreed, especially if it means we'll get v2.1 deployed at RAX
12:17:09 <sdague> I'm happy with that trade off
12:17:09 <alex_xu> cool, looks like we get agreement
12:17:18 <edleafe> +1 from me conceptually
12:17:25 <alex_xu> let's move on
12:17:27 <alex_xu> #link https://bugs.launchpad.net/nova/+bug/1491511
12:17:28 <openstack> Launchpad bug 1491511 in OpenStack Compute (nova) "Behavior change with latest nova paste config" [Critical,In progress] - Assigned to Alex Xu (xuhj)
12:17:37 <gmann_> ok, for now looks good solution.
12:17:40 <alex_xu> We have three patches for this bug.
12:17:46 <alex_xu> #link https://review.openstack.org/#/c/220386/
12:17:51 <alex_xu> I think this is need fix for v2.1, otherwise the cell functionality is broken.
12:17:52 <sdague> right, so this is the catch all of issues we are finding
12:18:12 <johnthetubaguy> (I have a new one, but its a separate issue)
12:18:18 <sdague> #info https://review.openstack.org/#/c/220386/ - fixes for cell names - merged
12:18:31 <gmann_> sdague: i was just wondering if server name can be used as hostname like for DNS entry etc?
12:18:36 <alex_xu> so we are goodfor this?
12:18:47 <alex_xu> #link https://review.openstack.org/220279
12:18:52 <sdague> gmann_: that's the next one
12:18:52 <alex_xu> gmann_: you are talk about this ^
12:19:23 <sdague> yeh, so it does get coerced into a hostname in dnsmasq some times
12:19:32 <gmann_> sdague: yea
12:19:38 <sdague> however, in v2.0 there was no checking
12:19:45 <johnthetubaguy> yeah, it does, but its primarily a display name
12:19:47 <alex_xu> yea
12:19:54 <alex_xu> so we are good for this in v2.1?
12:19:57 <sdague> and the v2.1 schema doesn't guaruntee a working hostname
12:20:02 <johnthetubaguy> (updating the name doesn't change the hostname, for example, at least not usually)
12:20:08 <gmann_> johnthetubaguy: yea agree it is for display name
12:20:32 <sdague> so I think there should be a follow on bug to make a function that tries to make a safe dns name out of it
12:20:46 <sdague> for when it gets written to dnsmasq
12:20:58 <alex_xu> sdague: I remember there is code take care of it
12:21:01 <johnthetubaguy> sdague: I think thats a good way to go (there is some stuff that trims the name somewhere, for windows)
12:21:09 <sdague> alex_xu: not that I found
12:21:19 <sdague> the only thing I found was it lowercasing things
12:21:27 * alex_xu find the link
12:21:34 <johnthetubaguy> hmm, maybe its inside the xenapi driver, oh dear
12:21:36 <sdague> but it wasn't handling spaces or special characters
12:21:55 <johnthetubaguy> so seems like we need to just deal with spaces
12:21:59 <alex_xu> #link https://github.com/openstack/nova/blob/master/nova/compute/api.py#L640
12:22:07 <gmann_> sdague: so you mean we allow server name as display name with relaxing much restriction on that and later something should make that a dns name out of it?
12:22:16 <sdague> johnthetubaguy: there are a lot of other invalid characters in hostnames as well
12:22:22 <johnthetubaguy> sdague: +1
12:22:48 <alex_xu> #link https://github.com/openstack/nova/blob/master/nova/utils.py#L774
12:22:53 <sdague> The Internet standards (Requests for Comments) for protocols mandate that component hostname labels may contain only the ASCII letters 'a' through 'z' (in a case-insensitive manner), the digits '0' through '9', and the hyphen ('-'). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hos
12:22:53 <sdague> tname labels to start with digits. No other symbols, punctuation characters, or white space are permitted.
12:23:53 <johnthetubaguy> so I guess the consensus is merge the relax, and follow up with the above fix
12:24:11 <sdague> alex_xu: that regex looks wrong, but lets take that offline
12:24:17 <sdague> I'd like to see lots of unit tests for that
12:24:18 <alex_xu> sdague: ok
12:24:25 <johnthetubaguy> +1 for the unit tests
12:24:28 <gmann_> johnthetubaguy: +1
12:24:43 <alex_xu> #link #link https://review.openstack.org/220791
12:24:49 <alex_xu> Another part of relax validation for server name, actually I found some api allow leading/trailing spaces in the name.
12:25:11 <alex_xu> not sure we want to fix this, as the leading/trailing spaces is useless use-case
12:25:15 <sdague> alex_xu: also, sanitize hostname is getting called in a weird place
12:25:37 <alex_xu> sdague: actually it convert from the name
12:25:50 <sdague> right, but it's changing the db entry
12:26:19 <alex_xu> emm...yea, I didn't notice that
12:26:22 <alex_xu> agree with you
12:26:37 <sdague> so, how about we open a new bug for getting the hostname bit right
12:26:48 <alex_xu> +1
12:26:54 <sdague> alex_xu: can you open that bug?
12:26:58 <alex_xu> sure
12:27:09 <alex_xu> #action alex_xu open a bug for fix the hostname
12:27:14 <sdague> thanks
12:27:18 <alex_xu> np
12:27:40 <alex_xu> so back to https://review.openstack.org/220791
12:27:55 <alex_xu> whether we need fix ^
12:28:05 <sdague> alex_xu: that one I'm less sure, johnthetubaguy ?
12:28:16 <sdague> alex_xu: what was the v2.0 behavior here?
12:28:58 <johnthetubaguy> yeah, we should match v2.0 I feel, although I haven't checked what that is
12:29:15 <johnthetubaguy> seems like we should strip the whitespace though, if we allow it
12:29:15 <gmann_> sdague: it was mix in v2.0, some resource allow and strip and some does not strip only allow
12:29:17 <alex_xu> sdague:  a little mess if you see the commit message, server and flavor allow leading/trailing spaces and strip spaces and not allow all spaces string, other api with name didn't strip and allow all spaces string
12:29:38 <gmann_> alex_xu: yea
12:29:45 <johnthetubaguy> so I would go for allow and strip for all of them, would that work?
12:30:08 <gmann_> johnthetubaguy: sdague: alex_xu : but do we need to do that for v2.1 also or only for v21 compatible mode?
12:30:15 <alex_xu> johnthetubaguy: that means we fix the server and flavor, but still strict for other apis
12:30:39 <johnthetubaguy> alex_xu: how are the APIs restricted? you mean trailing whitespace is always ignored now?
12:30:41 <alex_xu> gmann_: yea, that also a question
12:30:44 <sdague> alex_xu: so if we allow and strip, do we need to go and clean up the data in the db for matching?
12:30:51 <sdague> for the stuff that wasn't stripped before
12:30:57 <alex_xu> johnthetubaguy: some of apis not, like aggregates
12:31:04 <johnthetubaguy> sdague: I am tempted to say no for that
12:31:08 <sdague> I think allow and strip is probably right
12:31:13 <johnthetubaguy> alex_xu: I think I am OK with that
12:31:32 <alex_xu> so this is ok for v2.1?
12:31:48 <johnthetubaguy> I am tempted to say yes, but it doesn't feel very clear cut
12:31:54 <gmann_> alex_xu: i feel we should have clean way for v2.1 means do not allow
12:32:31 <johnthetubaguy> so for the compat, we defiantly need strip and accept
12:32:38 <sdague> how bad would it be to allow in v2.0 compat mode and be strict in v2.1
12:32:43 <sdague> in terms of code?
12:33:09 <alex_xu> this patch can answer you https://review.openstack.org/221129
12:33:12 <johnthetubaguy> so yeah, maintain our strictness for v2.1, I am happier with that approach
12:33:17 <gmann_> sdague: you might need 2 set of schema looks like but may be sone common place change for name format
12:33:46 <sdague> alex_xu: so it's not just validation right, it's also a transform to do the strip
12:34:14 <alex_xu> sdague: indeed, we still need python code to strip
12:34:14 <sdague> we'll still need the transform right?
12:34:31 <johnthetubaguy> I guess we can always to the strip, and the schema stops that doing anything in some cases
12:34:34 <sdague> can that be done as a decorator to transform
12:34:44 <alex_xu> I think not
12:34:45 <sdague> johnthetubaguy: oh, that's true
12:35:09 <johnthetubaguy> sdague: yeah, it just came to me, and suddenly felt more palatable
12:35:17 <sdague> alex_xu: yeh, so conceptual +2 on kenichi's patch, I'll review after meeting
12:35:25 <alex_xu> sdague: cool
12:35:31 <sdague> also, he needs to not put these things in WF-1 :)
12:35:53 <alex_xu> emm...that only can catch him tomorrow
12:36:16 <sdague> #action everyone review kenichi's json schema for 2.0 patch - https://review.openstack.org/221129 as a way to enforce differently for v2.0
12:36:23 <alex_xu> at line 76 there is terrible regexp also https://review.openstack.org/#/c/220791/1/nova/api/validation/parameter_types.py
12:36:53 <sdague> yep
12:37:05 * alex_xu hate regexp
12:37:21 <sdague> honestly, these things are getting to the point where they should probably be enforced with a gramar and not regex
12:37:21 * edleafe loves good regexp
12:37:43 <alex_xu> to be clear https://review.openstack.org/220279 fix for v2 and v2.1, https://review.openstack.org/220791 only for v2?
12:37:49 <johnthetubaguy> sdague: its getting dam close
12:37:57 * bauzas waves very late
12:37:58 <alex_xu> sdague: yea
12:38:21 * bauzas scrolls back
12:38:26 * alex_xu waves to bauzas
12:38:50 <gmann_> sdague: yea
12:39:05 <sdague> anyway, that's for next cycle
12:39:24 <sdague> ok, so we seem clear on all these patches in concept?
12:39:36 <sdague> now it's just getting them into shape and landed, right
12:39:46 <gmann_> sdague: yea
12:39:51 <alex_xu> cool
12:40:11 <alex_xu> let's move...
12:40:13 <sdague> alex_xu: if you remove your -1 on this - https://review.openstack.org/#/c/220279 - I'll approve
12:40:38 <alex_xu> sdague: done!
12:41:04 <johnthetubaguy> did we have a previous patch that bauzas was -1 one on, about the scheduler hints?
12:41:28 <bauzas> johnthetubaguy: I left -1 just for a placeholder until we have a convo
12:41:42 <sdague> yeh, as we went through that already, lets cycle on -nova after
12:41:48 <alex_xu> we already have convo for that...
12:41:48 <bauzas> johnthetubaguy: but looking at the discussion above, is there a consensus yet ?
12:41:59 <bauzas> okay, move on to -nova then
12:42:08 <alex_xu> #link https://bugs.launchpad.net/python-novaclient/+bug/1491325
12:42:09 <openstack> Launchpad bug 1491325 in OpenStack Compute (nova) "nova api v2.1 does not allow to use autodetection of volume device path" [Critical,Fix committed] - Assigned to Davanum Srinivas (DIMS) (dims-v)
12:42:09 <bauzas> when the meeting is ended
12:42:13 <alex_xu> this already fixed
12:42:23 <alex_xu> so we are good for this?
12:42:26 <sdague> alex_xu: right, we fixed it in both nova and novaclient
12:42:35 <alex_xu> sdague: cool
12:42:45 <sdague> I responded with a long email to gmann_ on the list this morning about why we did it they way we did
12:42:58 <sdague> hopefully that has enough detail
12:43:02 <gmann_> sdague: ohk, i will read your reply, i was on vacation today
12:43:09 <gmann_> sdague: Thanks :)
12:43:14 * alex_xu will read the email
12:43:25 <alex_xu> I think that is all for v2 on v2.1.
12:43:37 <johnthetubaguy> so I have a python-novaclient bug
12:43:40 <johnthetubaguy> its a bit related
12:43:48 <johnthetubaguy> its described here: https://review.openstack.org/#/c/221222/
12:44:00 <johnthetubaguy> https://launchpad.net/bugs/1493207
12:44:01 <openstack> Launchpad bug 1493205 in OpenStack Dashboard (Horizon) "duplicate for #1493207 Create Keypair failed on latest DevStack" [Undecided,New] - Assigned to Chung Chih, Hung (lyanchih)
12:44:01 <sdague> right, the fact that the API isn't defaulting to v2.0 if not specified?
12:44:04 <bauzas> did we discussed of https://bugs.launchpad.net/nova/+bug/1492925 ?
12:44:05 <openstack> Launchpad bug 1492925 in OpenStack Compute (nova) "Lack of API schema definition for different cell filter" [Undecided,In progress] - Assigned to Ken'ichi Ohmichi (oomichi)
12:44:28 <sdague> bauzas: yeh, we hit the cells bit already
12:44:31 <bauzas> johnthetubaguy: my bad, you're first
12:44:41 <alex_xu> we said the novaclient default to latest
12:44:46 <bauzas> sdague: coolness, thanks
12:44:46 <sdague> alex_xu: the CLI
12:44:47 <johnthetubaguy> so python-novaclient seems to default in a broken way
12:45:07 <johnthetubaguy> the client defaults to find the max version, but not sending version headers
12:45:08 <sdague> the API should default back to oldest
12:45:09 <alex_xu> sdague: oops, that bug about api?
12:45:14 <sdague> alex_xu: yeh
12:45:25 <johnthetubaguy> it should really default to the min version
12:45:28 <alex_xu> I remember I coding like that
12:45:41 <alex_xu> johnthetubaguy: agree
12:45:52 <sdague> johnthetubaguy: yeh, so it seems like it was just only 1/2 implemented
12:46:07 <sdague> also, that should be easy enough to test with the functional tests once it's right
12:46:15 <johnthetubaguy> so the unit tests would have found this
12:46:23 <alex_xu> yea
12:46:26 <johnthetubaguy> but they were written so it was avoided
12:46:30 <alex_xu> johnthetubaguy: do you need me take care that patch?
12:46:31 <sdague> heh
12:46:45 <johnthetubaguy> this reproduces the failure: https://review.openstack.org/#/c/221222/2/novaclient/tests/unit/v2/test_keypairs.py,cm
12:47:42 <johnthetubaguy> been fighting to find a fix
12:48:31 <alex_xu> cool
12:49:05 <alex_xu> so that's all?
12:49:10 <johnthetubaguy> anyways, seems like we have consensus on the correct behaviour
12:49:18 <alex_xu> yea
12:49:24 <johnthetubaguy> I might need a hand with the patch if this next attempt doesn't work
12:49:43 <alex_xu> johnthetubaguy: yea, I can help
12:49:47 <edleafe> me too
12:50:15 <johnthetubaguy> OK, cool, just know I need to get back to reviews again
12:50:29 <sdague> ok, so is there a way to target python-novaclient bugs?
12:50:30 <johnthetubaguy> thats all, thanks for the offers
12:50:37 <sdague> it was duped, so the new bug is - https://bugs.launchpad.net/python-novaclient/+bug/1493205
12:50:39 <openstack> Launchpad bug 1493205 in python-novaclient "Create Keypair failed on latest DevStack" [Undecided,New]
12:50:41 <alex_xu> ok, so johnthetubaguy you can free to catch me or edleafe when you need a hand
12:50:47 <johnthetubaguy> sdague: good point, I guess not
12:51:20 <sdague> ok, well so be it
12:51:31 <sdague> I marked it critical so hopefully it doesn't get lost
12:51:44 <alex_xu> sdague: cool, thanks
12:52:10 <alex_xu> anything more for v2.1?
12:52:39 <alex_xu> ok, so let's move on
12:52:47 <alex_xu> #topic Removal of v3 naming from source tree
12:53:09 <alex_xu> edleafe: sorry I didn't follow that, any patch you still have?
12:53:29 <edleafe> yes - looks like https://review.openstack.org/#/c/214290/ needs a rebase
12:53:38 <edleafe> I can take care of that after the meeting
12:53:44 <johnthetubaguy> edleafe: if you could take a look at this for me, that would be cool: https://review.openstack.org/#/c/221222/
12:53:55 <edleafe> and a few small things for https://review.openstack.org/#/c/214311
12:54:15 <edleafe> johnthetubaguy: will do
12:54:38 * edleafe will need to make coffee first
12:55:19 <johnthetubaguy> edleafe: agreed, I just -1ed my patch with why I don't like it, but it does seem to pass unit tests now
12:55:24 <alex_xu> https://review.openstack.org/#/c/214311 looks like more important, it correct some log message, they are user faced thing
12:56:14 <alex_xu> so just for this we just need update patch and review, right?
12:56:16 <sdague> edleafe: yeh, I think the -1 on 214311 should be easy fix
12:56:21 <johnthetubaguy> so the above patch is currently breaking horrizon
12:56:30 <johnthetubaguy> and probably lots of other users
12:56:44 <gmann_> johnthetubaguy: which one?
12:56:45 <johnthetubaguy> I mean: https://review.openstack.org/#/c/221222 when I say above
12:57:00 <gmann_> ohk
12:57:02 <bauzas> johnthetubaguy: +1 this is the far most critical
12:57:09 <alex_xu> yea
12:57:30 <sdague> johnthetubaguy: yeh I've got some paper work to do today, but I'll take a look at that patch
12:57:43 <sdague> and see if I can sort out a working rev
12:57:50 <johnthetubaguy> cool, just wanted to make sure we all understood the impact there
12:57:58 <sdague> and make mriedem do more novaclient releases
12:58:07 <johnthetubaguy> I did give horizon folks I was talking to a hack, if needed
12:58:20 <sdague> right, we should fix it, it's going to break other people as well
12:58:23 <johnthetubaguy> but we have to fix it either way
12:58:30 <johnthetubaguy> sdague: yeah, +1
12:58:41 <alex_xu> agree
12:58:45 <sdague> so... next cycle, can we release novaclient every monday?
12:58:56 <sdague> because part of this issue is we had 4 months of changes all drop at once
12:59:13 <alex_xu> 4 months...
12:59:14 <gmann_> sdague: nice point to catch those early
12:59:15 <johnthetubaguy> sdague: yeah, or every other, that would totally make sense
12:59:16 <edleafe> +1 to more frequent releases
12:59:18 <sdague> and I'd much rather flush out issues faster
12:59:32 <sdague> I think a weekly release for a library should be fine
12:59:34 <johnthetubaguy> sdague: I mean we should have done every milestone at a minimum, but it just didn't happen
12:59:38 <sdague> yep
12:59:55 <alex_xu> jump to open directly, avoid somebody need help
12:59:57 <alex_xu> #topic open
13:00:02 <bauzas> I had a question
13:00:05 <bauzas> but 20 secs left
13:00:11 <bauzas> so moving on to -nova instead
13:00:14 <alex_xu> yea...
13:00:19 <johnthetubaguy> honestly, I was waiting for the microversion support to drop really, and that was recent, we should do time bound releases there
13:00:23 <alex_xu> so...thanks all!
13:00:32 <edleafe> thanks alex_xu!
13:00:33 <sdague> thanks alex_xu
13:00:35 <alex_xu> #endmeeting