| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 14:53:24 | pkoniszewski | mdbooth: that's right | |
| 14:53:51 | pkoniszewski | mdbooth: but the pre_live_migration bit is correct | |
| 14:54:40 | mdbooth | Yeah. I didn't see a problem there, btw. | |
| 14:55:55 | mdbooth | I think it's probably futile to try to prevent calling save on the instance object on such a wide ranging function. Perhaps we should just concede it will happen and deal with it? | |
| 14:56:33 | mdbooth | Well, for live migration we *know* it happens, because we do it in compute manager. | |
| 14:57:21 | openstackgerrit | Radomir Dopieralski proposed openstack/python-novaclient: ListExtResource given in place of ListExtManager https://review.openstack.org/424570 | |
| 14:58:26 | andreykurilin | bauzas: and yes, it will be cool, if you propose a new novaclient's release. Not sure about right version- 7.0.1 (since it fixes several issues from 7.0.0) or 7.1.0 (since it contains a bit feauture - support of osprofiler) | |
| 14:59:41 | andreykurilin | bauzas johnthetubaguy: it is another high priority fix - https://review.openstack.org/#/c/424570 . just +10, -1 with release notes | |
| 15:00:55 | openstackgerrit | Vladik Romanovsky proposed openstack/nova: libvirt: set vlan tag for macvtap on SR-IOV VFs https://review.openstack.org/421186 | |
| 15:03:45 | dansmith | johnthetubaguy: thanks.. it's going to be a hard push to get this in by thurs, but I'm still trying | |
| 15:05:33 | mriedem | dansmith: don't forget to breath | |
| 15:05:56 | dansmith | mriedem: hoo hoo heee, hoo hoo heee | |
| 15:06:02 | mriedem | exactly | |
| 15:08:47 | andreykurilin | johnthetubaguy: Can you put +2 again to https://review.openstack.org/424256 ?) | |
| 15:12:38 | bauzas | dansmith: who's core in grenade ? | |
| 15:12:53 | dansmith | bauzas: me, sdague and dtroyer | |
| 15:13:05 | bauzas | dansmith: I'm firing a patch for making sure we run the placement-engine in Ocata when upgrading, which is not the case | |
| 15:13:12 | dansmith | ack | |
| 15:13:19 | bauzas | dansmith: http://logs.openstack.org/61/417961/20/check/gate-grenade-dsvm-neutron-ubuntu-xenial/35a48ec/logs/new/local.conf.txt.gz | |
| 15:13:33 | bauzas | dansmith: there is no enabled service that runs the placement engine | |
| 15:13:45 | bauzas | hence the grenade failure on my change | |
| 15:14:01 | dansmith | ack part deux | |
| 15:14:19 | bauzas | so I'm thinking of updating https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/from-newton/upgrade-nova | |
| 15:14:40 | bauzas | dansmith: but any idea how I would do that ? | |
| 15:14:59 | bauzas | is the above pre calling devstack ? | |
| 15:15:16 | diana_clarke | bauzas: dansmith beat me to it, but for those following along from home, you can see the core here: https://review.openstack.org/#/admin/groups/188,members | |
| 15:15:31 | diana_clarke | s/core/cores | |
| 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 | bauzas | I could source lib/placement | |
| 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: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 | johnthetubaguy | s/someone/somewhere | |
| 15:21:40 | dansmith | johnthetubaguy: right | |
| 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 | global-requirements.txt:python-novaclient>=2.29.0,!=2.33.0 # Apache-2.0 | |
| 15:28:39 | amrith | projects.txt:openstack/python-novaclient | |
| 15:28:39 | amrith | upper-constraints.txt:python-novaclient===7.0.0 | |
| 15:28:54 | amrith | mriedem, yes we're using u-c | |
| 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: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 | mriedem | well by 'break' i mean, intentional changes to remove functionality | |
| 15:34:00 | bauzas | 7.0.0 is breaking more than the token thing ? | |
| 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 | |