| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 15:17:05 | dansmith | bauzas: you can call devstack functions if they're included, yeah, like initialize_database there is from devstack | |
| 15:19:09 | bauzas | dansmith: I think I got the idea from https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/from-mitaka/upgrade-nova | |
| 15:19:16 | johnthetubaguy | dansmith: should I be worried about the order of the list of CELLS we are iterating over being the same on all API workers? | |
| 15:19:16 | bauzas | I could source lib/placement | |
| 15:19:38 | dansmith | johnthetubaguy: from a sorting perspective? | |
| 15:19:46 | dansmith | er, instance sorting? | |
| 15:19:56 | johnthetubaguy | dansmith: yeah, I was thinking from a fetching a marker perspective | |
| 15:20:18 | bauzas | johnthetubaguy: you mean adding a new cell meanwhile we're iterating ? | |
| 15:20:29 | dansmith | johnthetubaguy: well, so the deal here is that this code is here to officially support only one cell for ocata, | |
| 15:20:39 | johnthetubaguy | dansmith: good point | |
| 15:20:52 | bauzas | johnthetubaguy: if so, I discussed on that yesterday with dansmith and we agreed on not being a problem for ocata | |
| 15:20:57 | dansmith | johnthetubaguy: but so that we can move to the third patch where we're creating in conductor (and thus potentially multiple cells). None of the naive sorting stuff is in here yet, so I think any concern for that is moot, | |
| 15:21:03 | dansmith | but this enables people to play with it | |
| 15:21:31 | johnthetubaguy | dansmith: in terms of staging things so we get someone, totally makes sense | |
| 15:21:40 | dansmith | johnthetubaguy: right | |
| 15:21:40 | johnthetubaguy | s/someone/somewhere | |
| 15:22:16 | dansmith | johnthetubaguy: but yes, following this, we'll want stable sorting of cells, reloading of the cells list, a naive sort approach, etc | |
| 15:22:55 | johnthetubaguy | dansmith: ack | |
| 15:23:26 | mriedem | oh great device tags is all fubar in the api now too huh | |
| 15:24:46 | dansmith | bauzas: johnthetubaguy: sfinucan: the patch after that, by the way, is just a tweak to the api_samples setup, and an approach sdague suggested, so it should be fairly easy to hit I think | |
| 15:24:58 | dansmith | to prevent api_samples from tripping over itself in the final patch | |
| 15:25:08 | bauzas | dansmith: yeah I just began to look at it | |
| 15:25:17 | dansmith | cool | |
| 15:26:26 | dansmith | mriedem: if you want an easy one to +W to make your vacation feel productive, this trivial one from sfinucan would be good: https://review.openstack.org/#/c/419479/5 | |
| 15:26:44 | amrith | thx andreykurilin | |
| 15:26:54 | amrith | please let me know once the novaclient patch is released | |
| 15:27:00 | amrith | that'll be the easiest way to test in the gate | |
| 15:27:04 | amrith | could we mark 7.0.0 as bad? | |
| 15:27:25 | mriedem | amrith: 7.0 isn't in g-r is it? | |
| 15:27:41 | mriedem | or u-c rather | |
| 15:27:43 | amrith | well, it is what we're getting now from pypi | |
| 15:27:50 | andreykurilin | mriedem: 7.0 is a version from u-c now :) | |
| 15:27:51 | mriedem | are you using upper-constraints? | |
| 15:28:01 | andreykurilin | also it is a min version of requirements | |
| 15:28:03 | mriedem | andreykurilin: ok, then i guess we should blacklist 7.0 in g-r | |
| 15:28:09 | mriedem | really? why? | |
| 15:28:10 | amrith | mriedem, yes | |
| 15:28:26 | diana_clarke | mriedem: it was merged into u-c on the 19th https://review.openstack.org/#/c/414170/ | |
| 15:28:39 | amrith | upper-constraints.txt:python-novaclient===7.0.0 | |
| 15:28:39 | amrith | projects.txt:openstack/python-novaclient | |
| 15:28:39 | amrith | global-requirements.txt:python-novaclient>=2.29.0,!=2.33.0 # Apache-2.0 | |
| 15:28:54 | andreykurilin | mriedem: I think today we will have everything for next release (7.0.1/7.1.0) and we will able to make everything together - blacklist and put right version | |
| 15:28:54 | amrith | mriedem, yes we're using u-c | |
| 15:29:22 | mriedem | i don't know why we'd require 7.0 as the minimum | |
| 15:29:49 | amrith | mriedem, andreykurilin it may be a good idea to have periodic jobs that test against the tip of master in nova client like we do with oslo. I'll propose such a periodic job | |
| 15:29:51 | mriedem | also the wifi here sucks so everything takes forever to load | |
| 15:30:16 | mriedem | amrith: and where do the results of those jobs go and who is going to be monitoring them? | |
| 15:30:41 | amrith | mriedem, I get an email when they fail | |
| 15:30:46 | amrith | let me find out how that is setup | |
| 15:30:55 | amrith | it is something that dims (I believe) setup a while back | |
| 15:30:56 | mriedem | ok | |
| 15:31:15 | amrith | in general, I'd think that is something that for trove, should be trove's to monitor | |
| 15:31:19 | mriedem | amrith: have you talked to the requirements team about getting a trove unit test job to run as part of changes like this? https://review.openstack.org/#/c/414170/ | |
| 15:31:32 | amrith | have not | |
| 15:31:34 | andreykurilin | mriedem: because all "right version" from min to max should be compatible. we have too much changes now to use 2.29 as a min (like it was previously) | |
| 15:31:39 | amrith | but it is a good idea as well | |
| 15:32:14 | andreykurilin | I mean it is a hard task to write a compatible code for 2.29 and 7.0 | |
| 15:32:28 | mriedem | andreykurilin: well yeah, and that's why we use semver for major changes | |
| 15:32:49 | mriedem | even with fixing the token thing, 7.0 probably breaks a bunch of things | |
| 15:33:26 | andreykurilin | mriedem: it breaks two things - token auth via python API (for CLI it was broken for a year) and list_extension | |
| 15:33:41 | andreykurilin | both of these things have fixes on review | |
| 15:34:00 | bauzas | 7.0.0 is breaking more than the token thing ? | |
| 15:34:00 | mriedem | well by 'break' i mean, intentional changes to remove functionality | |
| 15:34:12 | mriedem | which is why we released it with a major version bump | |
| 15:34:16 | bauzas | do we have a g-r change that blocks it ? | |
| 15:34:32 | mriedem | bauzas: the requirements changes aren't run against trove unit tests, | |
| 15:34:38 | mriedem | otherwise something might have been caught | |
| 15:34:45 | bauzas | and if we have a couple of fixes, let's name the next release 7.0.1 even if we add the osprofiler thing | |
| 15:34:47 | andreykurilin | mriedem: I think we done everything in backward compatible way (except usage of our inner variables) | |
| 15:35:23 | bauzas | mriedem: yeah, but as per andreykurilin 7.0.0 blew up more than just trove | |
| 15:35:38 | bauzas | mriedem: at least the tripleo folks and the murano folks AFAICS | |
| 15:35:39 | mriedem | bauzas: new features need to be a min version bump at least to 7.1.0 | |
| 15:35:57 | bauzas | I know | |
| 15:35:58 | andreykurilin | bauzas: one more thing that is broken by 7.0 - https://review.openstack.org/#/c/424570/ :) | |
| 15:36:22 | mriedem | on https://review.openstack.org/#/c/423808/ i would have made the min 6.0, and u-c 7.0 | |
| 15:36:22 | bauzas | I'm saying 7.0.0 is doomed so we would signal that there is a new release fixing it | |
| 15:36:57 | andreykurilin | ok, let's use 6.0 as a min, but not 2.29 like it was | |
| 15:36:58 | bauzas | yup :( | |
| 15:37:12 | mriedem | andreykurilin: do you want me to push that change quick? | |
| 15:37:24 | mriedem | >=6.0.0,!=7.0.0 | |
| 15:37:41 | andreykurilin | mriedem: no, please take a rest. you are on vacation | |
| 15:37:47 | andreykurilin | I'll do it | |
| 15:38:10 | mriedem | it's morning and i've got a caffiene headache but ok | |
| 15:38:29 | mriedem | *caffeine | |
| 15:38:36 | bauzas | mriedem: you okay if I'm tagging a 7.1.0 with the help of andreykurilin ? | |
| 15:38:50 | bauzas | once all the fixes are done of course | |
| 15:38:55 | mriedem | bauzas: that's fine | |
| 15:39:19 | mriedem | alex_xu: cdent: artom: gmann: where are we on the device tags thing? | |
| 15:39:20 | bauzas | mriedem: client libraries freeze is thursday as well ? | |
| 15:39:27 | mriedem | bauzas: yes client release freeze is thursday | |
| 15:39:34 | bauzas | ok | |
| 15:40:06 | cdent | mriedem: I don't know, haven't revisited since I lit the fire... | |
| 15:40:27 | mriedem | it's a time that i wish we could just fix the bugs in the api w/o the microversion | |
| 15:40:33 | artom | mriedem, nowhere as far as I can tell - what's the plan? We document before ocata FF and unfuck it in Pike? | |
| 15:41:03 | artom | If so I can submit the documentation patch | |
| 15:41:05 | mriedem | (a) this version works, but (b) x-y don't work, except z, so (c) we'll fix it all in microversion 2.50 | |
| 15:41:11 | artom | But I wasn't sure we had consensus on that | |
| 15:41:15 | robcresswell | diana_clarke: Thanks for the response on the horizon discussion, that was useful | |
| 15:41:49 | mriedem | artom: if we're not going to fix it with a microversion in ocata we can document it probably whenever before ocata rc1 | |
| 15:42:23 | artom | mriedem, do we have time to squeeze it in in 2 days? I can write the code... | |