EugenMayer | is it possible to somehow manually | 00:16 |
---|---|---|
EugenMayer | (database manipulation) set the flavor id of an instance? | 00:16 |
opendevreview | anguoming proposed openstack/nova master: fix the bug of the log line has no request_id info at source host when live migration https://review.opendev.org/c/openstack/nova/+/834677 | 00:38 |
EugenMayer | well i just created a new flavor of the same (old size) and then changed the flavorid in the nova_api database to match the expected old flavor id. Interestingly i could not find the relation table from flavor<->instance. it's not in nova::instances nor in nova_api:: anyway - where is this relation stored? | 00:38 |
sean-k-mooney[m] | its not we embed a copy of the flavor in the instance_extra table | 00:39 |
sean-k-mooney[m] | i belive we store teh orginal flavor name in the instnace in the api db | 00:40 |
sean-k-mooney[m] | but the only supported way to change the flaovor is via a resize | 00:41 |
EugenMayer | well you cannot do that if terraform bricked it | 00:41 |
EugenMayer | if a flav has been deleted while still the relation exists, which happened, you can neither resize nor do anything with this instance | 00:41 |
sean-k-mooney[m] | you should be able to do it from the api | 00:41 |
EugenMayer | no it wont work - 409 | 00:41 |
EugenMayer | i tried it all via api before touching the database manually - for the obvious reasons | 00:42 |
sean-k-mooney[m] | you should be able to resize the instnace even if the flavor has been deleted | 00:42 |
EugenMayer | openstack server resize --flavor <newid> <serverid> will end up throwing a 409 if the current flavorid, which is referenced, does not exist | 00:42 |
EugenMayer | > you should be able to resize the instnace even if the flavor has been deleted | 00:43 |
sean-k-mooney[m] | hum that sound like a bug | 00:43 |
EugenMayer | this is not possible, i just did try exactly that. | 00:43 |
sean-k-mooney[m] | i dont knwo why we would need the old flavor to exist | 00:44 |
EugenMayer | thank you for the hint with instance_extra - that would be the better way to change the flavor there. I'am aware that the flavor must match the current instance specs if i do it on the db layer - all i want is fixing the actual relation so the API is operating again | 00:45 |
EugenMayer | it does not need it, it will just try to load the entity and resolve all it's relation and as a side effect an exception will be thrown, that the flavor entity cannot be loaded | 00:46 |
EugenMayer | and that exception most probably bubbles up and ends up canceling the request | 00:47 |
sean-k-mooney[m] | the request spec has referneces to the flavor too in the api db | 00:47 |
EugenMayer | i really see that the entire 'distributed system' and microservice architecture introduced a lot of issue here. We have a database nova_api defining ::flavor. It's PK is used as in FK in nova::instance_extra but without any constraint or anything else - since the databases 'are seperated' - which they are not at all. | 00:48 |
sean-k-mooney[m] | they are we store copies of the full flavor | 00:49 |
sean-k-mooney[m] | so the request spec has the serisalsed flavor embeded in it | 00:49 |
sean-k-mooney[m] | which is used for schduling | 00:49 |
sean-k-mooney[m] | nova is not a collection of microservice by the way | 00:50 |
sean-k-mooney[m] | its a single distbuted service with multiple components that work together | 00:50 |
EugenMayer | why did the databases have been designed this way? AFAICS there are relations from one entity in one database to a different database - this really is not how this should be designed right. so nova::instance_extra.flavor<->nova_api::flavor.flavorid | 00:52 |
sean-k-mooney[m] | that is not how it works | 00:53 |
sean-k-mooney[m] | when you boot an instance we make a copy of the flavor and store a copy in the instance table | 00:53 |
EugenMayer | in which instance table: | 00:53 |
sean-k-mooney[m] | flavor are imuntable and cant be change once created | 00:53 |
sean-k-mooney[m] | however flavor extra specs are mutable | 00:54 |
EugenMayer | nova::instances ? | 00:54 |
sean-k-mooney[m] | so we have to copy the flavor to make sure existing instnace are not change if you modify the extra specs | 00:54 |
EugenMayer | i guess you the then reference nova::instances.vcpus/memory_mb/disk_db and so on | 00:55 |
sean-k-mooney[m] | yes those are fixed and cannot be modified. | 00:56 |
EugenMayer | while i understand that flavors are immutable (and should be) and the actual fields are copied / flatted into nova::instances -there is still a relation from nova::instance_extra to nova_api:falvor | 00:56 |
sean-k-mooney[m] | yes and no | 00:57 |
EugenMayer | and if this relation is broken, which very well can happen since there is no constraint possible - you can no longer do anything with the instance. You can no longer apply any new flavor or resize it | 00:57 |
EugenMayer | so entire decoupling has been planned maybe, but it seems not have been implemented (yet) | 00:57 |
sean-k-mooney[m] | you shoudl be able to today | 00:57 |
sean-k-mooney[m] | if you cant its a bug | 00:57 |
EugenMayer | well then there is a bug in xena (not sure what today standard is, yoga or xena?) | 00:58 |
sean-k-mooney[m] | so you should be aware that flavors used to be defiend at the cell level with cells v1 | 00:58 |
sean-k-mooney[m] | and when we moved to cells v2 we change the relation ships such that flavor were defiend gloablly in the api db | 00:59 |
sean-k-mooney[m] | but we conintued to keep the copy in the cell db | 00:59 |
sean-k-mooney[m] | but the intnace has used the copy in the request spec for schduling and instance extra as the source of truth for a vm for many many years | 01:00 |
EugenMayer | i understand, but there seems to be some usage of the back-reference anyway - maybe unintended | 01:01 |
sean-k-mooney[m] | so when we do a resize this is where we get the current flavor https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4127 | 01:02 |
EugenMayer | it seems, nevertheless, not the right design. nova should never include the actual flavorid for an instance, rathere nova_api should hold the reference from instance_uuid to flavorid - the relation owner here is nova_api. An instance is (as you explain) able to live without it's flavor - sureley a flavor can live without an instance too. But not | 01:04 |
EugenMayer | the relation. Sure the relation should be deleted in either way (deletion of instance or deletion of flavor). Anyway | 01:04 |
sean-k-mooney[m] | well you talking about something that has been in place for the better part of the last decade | 01:05 |
EugenMayer | looking at the code, nothing check for current_flavor to be null or not, it is used below right away. So if it is null / cannot be loaded (and not loaded does not trigger an exception already) this code will go bananas anway | 01:05 |
sean-k-mooney[m] | we have desgin constratint the mean we cant eaisly change the db schema | 01:05 |
sean-k-mooney[m] | espically for some of our larger deploymnets | 01:06 |
sean-k-mooney[m] | well the instance flavor should always be loadable | 01:07 |
sean-k-mooney[m] | the flavor is not nullable | 01:08 |
sean-k-mooney[m] | https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L336 we load the flaovor form the copy in instnace extra | 01:09 |
EugenMayer | since github does not let me resolve those symbols i cannot see what get_flavor will do if the referenced flavor is not present in nova_api::flavor but i can tell you that this will not work for xena at least | 01:09 |
EugenMayer | this cannot be rigbth | 01:10 |
EugenMayer | current_flavor['name'] is accessed, this is not part of instance_extras | 01:10 |
EugenMayer | most probably the data is expanded using the nova_api::flavor table? | 01:11 |
sean-k-mooney[m] | where are you seeing current_flaovr[name] | 01:12 |
sean-k-mooney[m] | and no once the instance object is created and save to the db we dont use the flaovr form the api db any more | 01:12 |
sean-k-mooney[m] | we should be either using the one in the request spec or the one in instance extra | 01:12 |
EugenMayer | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4162 | 01:13 |
sean-k-mooney[m] | current_flavor is instance.get_flavor | 01:13 |
EugenMayer | :) | 01:13 |
sean-k-mooney[m] | which get the filed form the instnace object | 01:14 |
sean-k-mooney[m] | the instnace object as i pointed too loads the flavor form the instance_extra table in the cell db | 01:14 |
EugenMayer | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4142 proves that new_flavor must match the interface of current_flavor, while new_flavor https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4144 is a flavor entity .. and we can see | 01:15 |
EugenMayer | https://github.com/openstack/nova/blob/0d1dd103d1431400b04f5f3edcb0d48453a79151/nova/compute/flavors.py#L131 .. the comment of that message already tells at, it will use nova_apis database | 01:15 |
sean-k-mooney[m] | that method will yes but that is not what we are calling | 01:16 |
sean-k-mooney[m] | that is in the flavor api code | 01:16 |
sean-k-mooney[m] | that is just doing a lookup in the api db directly | 01:16 |
sean-k-mooney[m] | resize is not calling that | 01:16 |
sean-k-mooney[m] | well for the current_flavor | 01:17 |
sean-k-mooney[m] | it calls that for the new flavor that you are resizeing too | 01:17 |
EugenMayer | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4142 is telling us that whatever current_flavor is, it must match the same interface we load in https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4144 | 01:17 |
sean-k-mooney[m] | that is cold migrate | 01:18 |
sean-k-mooney[m] | resize is used for both flavor resize and cold migration | 01:18 |
EugenMayer | and the latter is a fully loaded flavor from the nova_api::flavor table. And this explains why https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4162 is the assumed, since 'name' is the field nova_api::flavor.name | 01:19 |
sean-k-mooney[m] | line 4142 is the cold migrate path | 01:19 |
sean-k-mooney[m] | 4144 is the resize and its loading the new flavor from the api db | 01:19 |
sean-k-mooney[m] | not the current flavor | 01:19 |
sean-k-mooney[m] | the new flavor must exist | 01:19 |
EugenMayer | maybe, but https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4162 accesses a field that could never have been loaded from nova::instance_extra | 01:19 |
sean-k-mooney[m] | why? | 01:20 |
EugenMayer | there is no such field? | 01:20 |
sean-k-mooney[m] | the flaovr is stored as a json blob in the instance extra table | 01:20 |
sean-k-mooney[m] | so name would be in the blob not a colum in that table | 01:21 |
EugenMayer | i see that instance_extra::flavor is a json serialized model of the flavor | 01:22 |
sean-k-mooney[m] | yes | 01:22 |
sean-k-mooney[m] | we serialse the ovo | 01:22 |
sean-k-mooney[m] | and store it in the flaovr column | 01:22 |
EugenMayer | and there is the name field indeed | 01:22 |
sean-k-mooney[m] | so other then the new flavor we shoudl not have a depency on the old flavor exising | 01:23 |
EugenMayer | so this is deserialized. I understand. Then there is something else trying to access the 'flavor' of the 'old flavor' which leads to an exception | 01:23 |
sean-k-mooney[m] | in the api db | 01:23 |
EugenMayer | i see the idea here, got you. But there must be still a expectation left | 01:24 |
sean-k-mooney[m] | there may be an in correct lookup using the id or some other reference | 01:24 |
EugenMayer | i guess you can easily try that. Create an instance with a flavor, then change the flavor id in nova_api::flavor and you should no longer be able to resize the instance | 01:24 |
sean-k-mooney[m] | we could test it in a functional test | 01:25 |
sean-k-mooney[m] | create a flavor , boot an instnace ,delete the flavor then try to resize | 01:25 |
EugenMayer | you should see, when using `openstack server resize` - 409 | 01:25 |
sean-k-mooney[m] | well we should see a 200 :) but we might see a 409 indeed | 01:26 |
sean-k-mooney[m] | that would be a bug which we should fix | 01:26 |
EugenMayer | I would have loved to see a 200 :) | 01:26 |
sean-k-mooney[m] | so looking at the functional test quickly im not seeing a test for resizing after flavor delete in test_server.py | 01:29 |
sean-k-mooney[m] | we can try creating one tomorrow/later today and see if we can repoduce | 01:30 |
sean-k-mooney[m] | do you have teh stack trace by the way | 01:31 |
sean-k-mooney[m] | i can try and take a look at it in the morning its 01:30 here so i was just heading to sleep but i can take another look once im online tomorrow | 01:32 |
EugenMayer | well that's the funny thing, noboday on the 'user side' ever knows which sub-system is responsible here | 01:32 |
EugenMayer | so grabbing a stacktrace is not as easy as you might think :) | 01:32 |
EugenMayer | it's 2:30 here, so i'am with you | 01:33 |
EugenMayer | sure, i'll be online tomorrow, just mention me. Happy to help if i can. Thank you for your effort! | 01:33 |
sean-k-mooney[m] | EugenMayer: ah your in europe then i tought you were across the pond. ok ya ill see if i can put up a DNM patch with a simple resize test tomorrow and we will see if i can trigger it | 01:34 |
EugenMayer | sure! Have a good night then, i'am off to bed :) | 01:34 |
opendevreview | anguoming proposed openstack/nova master: fix the bug of the log line has no request_id info at source host when live migration https://review.opendev.org/c/openstack/nova/+/834677 | 02:51 |
*** bhagyashris_ is now known as bhagyashris | 04:55 | |
opendevreview | melanie witt proposed openstack/nova master: block_device_info: Add swap to inline https://review.opendev.org/c/openstack/nova/+/826523 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: libvirt: Improve creating images INFO log https://review.opendev.org/c/openstack/nova/+/826524 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: libvirt: Remove defunct comment https://review.opendev.org/c/openstack/nova/+/826525 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: imagebackend: default by_name image_type to config correctly https://review.opendev.org/c/openstack/nova/+/826526 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: image_meta: Add ephemeral encryption properties https://review.opendev.org/c/openstack/nova/+/760454 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: BlockDeviceMapping: Add encryption fields https://review.opendev.org/c/openstack/nova/+/760453 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: BlockDeviceMapping: Add is_local property https://review.opendev.org/c/openstack/nova/+/764485 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: compute: Update bdms with ephemeral encryption details when requested https://review.opendev.org/c/openstack/nova/+/764486 | 06:57 |
opendevreview | melanie witt proposed openstack/nova master: virt: Add ephemeral encryption flag https://review.opendev.org/c/openstack/nova/+/760455 | 06:57 |
*** clarkb is now known as Guest106 | 07:31 | |
*** gibi_pto is now known as gibi | 07:56 | |
* gibi is back for two and a half days | 07:56 | |
EugenMayer | sean-k-mooney[m] are you awake already? :) | 08:23 |
EugenMayer | sean-k-mooney[m] i can still reproduce it: Service is unavailable at this time. (HTTP 409) (Request-ID: req-686ad3ee-d15b-4361-94c8-5775092c4746) | 08:24 |
EugenMayer | i see "POST /v2.1/servers/acbf9ae7-8433-4b2f-bf61-66327ca134aa/action HTTP/1.1" 409 88 52160 "-" "python-novaclient" in the nova-api logs,nova-api error logs do not show anything | 08:25 |
Uggla | gibi, hi o/ | 08:25 |
gibi | Uggla: o/ | 08:28 |
EugenMayer | sean-k-mooney[m] i see only warnings about deprecations in horizon.log - i found some logs on the compute from yesterday failing to contact rabbitmq which are most probably unrelated: https://gist.github.com/EugenMayer/cf06fadc52c66018f09a470fe0ed260f - that's about what i could find | 08:29 |
gibi | Uggla: thanks again fort the docs :) | 08:32 |
Uggla | gibi, you are welcome. | 08:34 |
bauzas | gibi: \o | 09:00 |
gibi | bauzas: o/ | 09:01 |
opendevreview | ribaudr proposed openstack/nova master: Fix unit tests when they are run with OS_DEBUG=True https://review.opendev.org/c/openstack/nova/+/833115 | 09:33 |
opendevreview | Stephen Finucane proposed openstack/nova master: doc: Remove useless contributor/api-2 doc https://review.opendev.org/c/openstack/nova/+/828599 | 09:58 |
opendevreview | Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | 10:59 |
opendevreview | Rajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219 | 10:59 |
opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | 10:59 |
EugenMayer | when an instance keeps in the 'spawning' phase - where can i check for the cause? | 11:05 |
kashyap | gibi: Hey, on git/main with a patch, I see this: https://cpaste.org/?37b24bb8794dcdca#9jFENZMo38Bxjskev5QkLoGncaKucSgpx1tBHhvVKAYd | 11:09 |
kashyap | gibi: Am I missing anything trivial? os_traits is installed in my virtualenv. | 11:10 |
gibi | you probably have old os_traits lib in the venv | 11:36 |
opendevreview | Elod Illes proposed openstack/nova stable/xena: [stable-only] Set nova-tox-functional-centos8-py36 non-voting https://review.opendev.org/c/openstack/nova/+/834854 | 11:37 |
gibi | kashyap: you need 2.7.0 from os-traits https://github.com/openstack/os-traits/commits/2.7.0 | 11:38 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248 | 12:42 |
kashyap | gibi: Darn lemme check | 12:45 |
kashyap | gibi: Hm, I do have it: | 12:46 |
kashyap | $> pip show os_traits | grep Version | 12:46 |
kashyap | Version: 2.7.0 | 12:46 |
gibi | that is strange | 12:46 |
gibi | https://paste.opendev.org/show/buddLlqeEzZc7ClpZWF3/ I can import that constant | 12:49 |
gibi | kashyap: could you try just import that constan in an interpreter started in that env? | 12:51 |
Uggla | I though a "reverify" comment would restart the CI... but it appears to not be the case. How to restart CI on a patches ? | 12:54 |
kashyap | gibi: Lemme try | 12:55 |
kashyap | gibi: Hmm, import of that constant does work just fine here. | 12:56 |
kashyap | gibi: I tell a lie; it's not git/main, but on top of the CPU APIs patch (that I rebased). I'll try on git/main and report back. (Bad me) | 12:57 |
kashyap | Hmm, same on git/master too. | 12:58 |
* kashyap just recreates the venv | 13:10 | |
kashyap | Okay, that fixed it. (Sorry for the noise. | 13:22 |
kashyap | ) | 13:22 |
artom | Uggla, it's 'recheck' | 13:32 |
artom | 'reverify' is only in our downstream CI | 13:32 |
artom | Trigger words can be configured in Zuul, IIUC | 13:32 |
opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Use improved guest CPU config APIs https://review.opendev.org/c/openstack/nova/+/762330 | 13:34 |
Uggla | artom, I tried "rebuild", "reverify".... ;) | 13:36 |
* artom noticed | 13:36 | |
artom | ;) | 13:36 |
Uggla | artom, thanks, it seems to be in the zull queue now. | 13:38 |
gibi | kashyap: no worries, then something was mixed in that env | 13:39 |
Uggla | zuul* | 13:39 |
*** dasm|off is now known as dasm | 13:58 | |
sean-k-mooney | Uggla: reverify in the long ago before times used to be use to tirgger just the gate pipeline rather then both gate and check. we removed it whith the green check policy dission about 8 years ago but downstream we trigger off both recheck and reverify for legacy reasons but ya as artom said recheck is what is used upstream when reqruied | 14:13 |
Uggla | sean-k-mooney, thx for the info. | 14:41 |
sean-k-mooney | gmann: bauzas since ye have already +2'd the followup care to review https://review.opendev.org/c/openstack/nova/+/828598/1 so that the docs pathes can proceed | 14:44 |
bauzas | sean-k-mooney: shit I missed the fact it was depending on this | 14:45 |
gmann | I had in list then missed somehow. thanks | 14:46 |
sean-k-mooney | no worreis this has been on my review list for a while | 14:46 |
sean-k-mooney | gibi: just looking at https://review.opendev.org/q/topic:any-traits-support the remaining patches are just using any traits right e.g. client supprot nova testing ectra. the feature is "complete" from the placmenet side in yoga? | 14:56 |
sean-k-mooney | just going through my review backlog but i had mentally check that off as complete | 14:57 |
gibi | sean-k-mooney: yes the feature is complete from placement perspective | 14:58 |
gibi | I have the placement client patch open, but that is not super important | 14:59 |
gibi | and I have the todo to check the sql performance and improve if needed | 14:59 |
opendevreview | Merged openstack/nova master: doc: Split up notifications document https://review.opendev.org/c/openstack/nova/+/828598 | 15:00 |
gibi | hm I missed that review ^^ but quickly checked and looks good to me too | 15:01 |
opendevreview | Merged openstack/nova master: doc: Remove useless contributor/api-2 doc https://review.opendev.org/c/openstack/nova/+/828599 | 15:13 |
opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration' https://review.opendev.org/c/openstack/nova/+/723572 | 15:15 |
opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest' https://review.opendev.org/c/openstack/nova/+/723573 | 15:16 |
*** Guest106 is now known as clarkb | 15:24 | |
outbrito | Morning folks! I'm trying to run tox @ master locally on my work laptop (ubuntu 20.04) and I'm getting a weird error: oslo_config.cfg.RequiredOptError: value required for option lock_path in group [DEFAULT] | 15:45 |
outbrito | Is that a known issue? | 15:45 |
sean-k-mooney | am i have seen that locally too | 15:47 |
sean-k-mooney | but not sure if we have a tacker for it | 15:47 |
dansmith | rebuild your venv? | 15:47 |
dansmith | tox -r | 15:47 |
outbrito | It was a brand new clone, but I'll try anyway | 15:47 |
dansmith | ack, usually random oslo things for me are due to a stale venv when reqs had changed, so that's the first thing I try | 15:49 |
sean-k-mooney | outbrito: is this actully causing test failures for you or just an warning/error message | 15:49 |
outbrito | 5 test failing | 15:50 |
outbrito | tests* | 15:50 |
sean-k-mooney | ok that actully the same as i saw on my mac book air tests yesterday also on a clean clone | 15:50 |
sean-k-mooney | let me see if i can repoduce on my normal system | 15:51 |
sean-k-mooney | i updated my ubuntu 20.04 server to 21.10 at the weekend but its running them now | 15:53 |
sean-k-mooney | so it wont be idential hum so i did get 1 failure with master | 15:54 |
sean-k-mooney | ill try in a clean clone | 15:54 |
sean-k-mooney | outbrito: what version of python did you run them under | 15:54 |
sean-k-mooney | 3.8 i assume? | 15:55 |
sean-k-mooney | just in case that matters | 15:55 |
opendevreview | Merged openstack/placement master: tests: Silence noisy tests https://review.opendev.org/c/openstack/placement/+/801101 | 15:57 |
outbrito | 3.9 | 15:58 |
outbrito | The only differences I see on requirements is Yappi vs. yappi and PyNaCl vs. pynacl | 16:00 |
gibi | hm with 20.04 + py38 + fresh master I could not reproduce the lock_path issue | 16:01 |
outbrito | The tests failing are these btw: | 16:03 |
outbrito | nova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate_mismatch | 16:04 |
outbrito | nova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate_legacy | 16:04 |
outbrito | nova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate | 16:04 |
outbrito | nova.tests.unit.virt.test_block_device.TestDriverBlockDeviceNewFlow.test_volume_attach_with_shared_targets | 16:04 |
outbrito | nova.tests.unit.virt.test_block_device.TestDriverBlockDevice.test_volume_attach_with_shared_targets | 16:04 |
outbrito | All related to volumes for that matter | 16:04 |
opendevreview | Merged openstack/placement master: tox: Remove psycopg2 warning filter https://review.opendev.org/c/openstack/placement/+/800911 | 16:04 |
sean-k-mooney | on a clean clone on 21.10 i did not have any failure under python 39 | 16:08 |
outbrito | py38 also broken for me | 16:10 |
outbrito | just to be sure, last commit is d2b2516 right? | 16:11 |
gibi | yepp | 16:11 |
gibi | I see that as head too | 16:11 |
gibi | but no luck reproducing the issue | 16:11 |
gibi | does it happen the same way for you each time you rerun these tests? | 16:12 |
gibi | or is it unstable? | 16:12 |
outbrito | consistent | 16:13 |
gibi | outbrito: do you also get a stack trace? If yes could you past it via https://paste.opendev.org/ (or similar) | 16:15 |
opendevreview | Merged openstack/placement master: setup: Replace dashes with underscores https://review.opendev.org/c/openstack/placement/+/801102 | 16:17 |
outbrito | https://paste.opendev.org/show/bZm6XstZ4MTPM7SPVuCR/ | 16:17 |
gibi | thanks | 16:21 |
gibi | outbrito: what is the os-brick version in your virtualenv? | 16:25 |
mfo | sean-k-mooney, hey o/ getting back to you exactly 1 month later :) sorry. i'd appreciate your comments/review when you have a chance (but it's not urgent, as you can see). | 16:40 |
mfo | we chatted [0] about an issue [1] that the libvirt driver in uefi mode ended up with the ovmf _secboot_ image, which doesn't boot on the pc machine type (required q35); so i proposed to skip the secboot image if on pc. [2,3] | 16:40 |
mfo | [0] https://pastebin.ubuntu.com/p/jVxcXvDW6h/ | 16:40 |
mfo | [1] https://bugs.launchpad.net/nova/+bug/1960758 | 16:40 |
mfo | [2] https://review.opendev.org/c/openstack/nova/+/828980 | 16:40 |
mfo | [3] https://review.opendev.org/c/openstack/nova/+/828979 | 16:40 |
mfo | essentially, i would get back to you with: | 16:40 |
mfo | 1) explain why the secboot image didn't "just work", 2) add unit tests, 3) ensure we only skip secboot image if there's another image to use. | 16:40 |
mfo | i've explained 1) with technical details/research in the bug's comments, and addressed 2) and 3) in the patches. | 16:40 |
mfo | thanks! | 16:40 |
sean-k-mooney | mfo: ack, in a downstream call currently so will review it after | 16:41 |
sean-k-mooney | mfo: in your opipion are the parces ready for review if so ill try and add them to my backlog for this week | 16:42 |
mfo | sean-k-mooney, yup, i think it's ready for review. | 16:42 |
gibi | outbrito: sorry I don't see what is happening on your side with those test and I will soon and my day. | 16:43 |
outbrito | no worries, i'll keep investigating. Thanks for looking into it | 16:59 |
outbrito | gibi, os-brick is at 5.2.0 btw | 17:00 |
melwitt | dansmith: I have a patch proposed to address a func test gate bug I see semi frequently and the patch is based on a NOTE by you in the CellDatabases func test fixture. if you might be interested in reviewing: https://review.opendev.org/c/openstack/nova/+/831084 | 18:44 |
dansmith | melwitt: yeah I remember that, looking | 18:53 |
opendevreview | Artom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic https://review.opendev.org/c/openstack/nova/+/833453 | 19:02 |
*** artom__ is now known as artom | 19:03 | |
dansmith | melwitt: commented, see what you think | 19:04 |
melwitt | cool thanks. looking | 19:05 |
opendevreview | Artom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic https://review.opendev.org/c/openstack/nova/+/833453 | 19:09 |
opendevreview | Artom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic https://review.opendev.org/c/openstack/nova/+/833453 | 19:16 |
opendevreview | Artom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic https://review.opendev.org/c/openstack/nova/+/833453 | 19:37 |
artom | "deprecated_since=versionutils.deprecated.WALLABY" | 19:58 |
artom | ... in a placement installed in a ussuri tox functional venv | 19:58 |
artom | *sigh* | 19:58 |
sean-k-mooney | that is likely down to how we install placment for the placment fixture in the tox env | 20:00 |
sean-k-mooney | if that is happenign in a clean checkout with new venv | 20:01 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/tox.ini#L119 | 20:01 |
sean-k-mooney | that should still be limited by upper constratis for the branch https://github.com/openstack/nova/blob/master/tox.ini#L29 | 20:01 |
sean-k-mooney | ah hehe | 20:02 |
sean-k-mooney | https://opendev.org/openstack/requirements/raw/branch/stable/ussuri/upper-constraints.txt | 20:02 |
sean-k-mooney | placement is not in upperconstrait for stable/ussuri | 20:02 |
sean-k-mooney | artom: so you will get whatever is on pypi | 20:02 |
sean-k-mooney | for the most part that should be ok as we are just using it for the fixture in this case | 20:03 |
artom | Unless it explicitly uses variables named after major releases :P | 20:03 |
sean-k-mooney | but that is why that happens its installing the latest pypi release of placement | 20:03 |
artom | Presumably this would fail in the upstream gate as well | 20:03 |
* artom checks | 20:03 | |
sean-k-mooney | proably we likely should cap it to the feature level | 20:04 |
sean-k-mooney | * minor release | 20:04 |
sean-k-mooney | actully placement is not release independ ot its the major verion | 20:04 |
sean-k-mooney | that woudl be pretty trival to do just update https://github.com/openstack/nova/blob/stable/ussuri/tox.ini#L91 | 20:05 |
sean-k-mooney | but we woudl need to do that with a stable only patch for each release | 20:05 |
sean-k-mooney | so ussuri is 3.0.0 so you need to set it to <4.0.0 | 20:06 |
sean-k-mooney | so """openstack-placement>=1.0.0,<4.0.0""" i think although im not sure if the , is needed | 20:06 |
sean-k-mooney | that shoudl fix it | 20:07 |
sean-k-mooney | or you coudl be explcit and say openstack-placement==3 | 20:07 |
sean-k-mooney | that will give you any 3.x.y but not 2.* or 4.* | 20:08 |
sean-k-mooney | artom: hopefully that makes sense | 20:08 |
sean-k-mooney | im goign to call it a day so chat to you tomorrow o/ | 20:09 |
artom | sean-k-mooney, yep, many thanks, very useful | 20:09 |
artom | Will also need to do it for victoria as well, since it doesn't understand WALLABY either | 20:10 |
clarkb | note I think ==3 means 3.0.0 not 3.x.y | 20:15 |
sean-k-mooney | im not sure about that but either way we can use min/max version or just pin to the majory with ==3 depending on the semantics of the syntax | 20:16 |
sean-k-mooney | i tought it woudl select the new 3.x.y | 20:16 |
sean-k-mooney | but im not sure | 20:16 |
clarkb | the ~= operator is for that or using * in the versions. missing identifiers seem to expand to .0 | 20:19 |
sean-k-mooney | ack | 20:19 |
sean-k-mooney | is ~= supprot new | 20:20 |
sean-k-mooney | im familar with it in other context but i did nto think it was supproted in the requirements specificaitons | 20:20 |
clarkb | it was defined in pep 440 somewhat new | 20:21 |
opendevreview | Artom Lifshitz proposed openstack/nova stable/victoria: [stable-only] Cap placement version in tox functional venv https://review.opendev.org/c/openstack/nova/+/834970 | 20:28 |
opendevreview | melanie witt proposed openstack/nova master: image_meta: Add ephemeral encryption properties https://review.opendev.org/c/openstack/nova/+/760454 | 23:37 |
opendevreview | melanie witt proposed openstack/nova master: BlockDeviceMapping: Add encryption fields https://review.opendev.org/c/openstack/nova/+/760453 | 23:37 |
opendevreview | melanie witt proposed openstack/nova master: BlockDeviceMapping: Add is_local property https://review.opendev.org/c/openstack/nova/+/764485 | 23:37 |
opendevreview | melanie witt proposed openstack/nova master: compute: Update bdms with ephemeral encryption details when requested https://review.opendev.org/c/openstack/nova/+/764486 | 23:37 |
opendevreview | melanie witt proposed openstack/nova master: virt: Add ephemeral encryption flag https://review.opendev.org/c/openstack/nova/+/760455 | 23:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!