Wednesday, 2022-03-23

EugenMayeris it possible to somehow manually 00:16
EugenMayer(database manipulation) set the flavor id of an instance?00:16
opendevreviewanguoming 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/+/83467700:38
EugenMayerwell 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 table00:39
sean-k-mooney[m]i belive we store teh orginal flavor name in the instnace in the api db00:40
sean-k-mooney[m]but the only supported way to change the flaovor is via a resize00:41
EugenMayerwell you cannot do that if terraform bricked it00:41
EugenMayerif a flav has been deleted while still the relation exists, which happened, you can neither resize nor do anything with this instance00:41
sean-k-mooney[m]you should be able to do it from the api00:41
EugenMayerno it wont work - 40900:41
EugenMayeri tried it all via api before touching the database manually - for the obvious reasons00:42
sean-k-mooney[m]you should be able to resize the instnace even if the flavor has been deleted00:42
EugenMayeropenstack server resize --flavor <newid> <serverid> will end up throwing a 409 if the current flavorid, which is referenced, does not exist00:42
EugenMayer> you should be able to resize the instnace even if the flavor has been deleted00:43
sean-k-mooney[m]hum that sound like a bug00:43
EugenMayerthis 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 exist00:44
EugenMayerthank 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 again00:45
EugenMayerit 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 loaded00:46
EugenMayerand that exception most probably bubbles up and ends up canceling the request00:47
sean-k-mooney[m]the request spec has referneces to the flavor too in the api db00:47
EugenMayeri 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 flavor00:49
sean-k-mooney[m]so the request spec has the serisalsed flavor embeded in it00:49
sean-k-mooney[m]which is used for schduling00:49
sean-k-mooney[m]nova is not a  collection of microservice by the way00:50
sean-k-mooney[m]its a single distbuted service with multiple components that work together00:50
EugenMayerwhy 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.flavorid00:52
sean-k-mooney[m]that is not how it works00:53
sean-k-mooney[m]when you boot an instance we make a copy of the flavor and store a copy in the instance table00:53
EugenMayerin which instance table:00:53
sean-k-mooney[m]flavor are imuntable and cant be change once created00:53
sean-k-mooney[m]however flavor extra specs are mutable00:54
EugenMayernova::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 specs00:54
EugenMayeri guess you the then reference nova::instances.vcpus/memory_mb/disk_db and so on00:55
sean-k-mooney[m]yes those are fixed and cannot be modified.00:56
EugenMayerwhile 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:falvor00:56
sean-k-mooney[m]yes and no00:57
EugenMayerand 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 it00:57
EugenMayerso 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 today00:57
sean-k-mooney[m]if you cant its a bug00:57
EugenMayerwell 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 v100: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 db00:59
sean-k-mooney[m]but we conintued to keep the copy in the cell db00: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 years01:00
EugenMayeri understand, but there seems to be some usage of the back-reference anyway - maybe unintended01: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#L412701:02
EugenMayerit 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 not01:04
EugenMayerthe 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 decade01:05
EugenMayerlooking 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 anway01:05
sean-k-mooney[m]we have desgin constratint the mean we cant eaisly change the db schema01:05
sean-k-mooney[m]espically for some of our larger deploymnets01:06
sean-k-mooney[m]well the instance flavor should always be loadable01:07
sean-k-mooney[m]the flavor is not nullable01: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 extra01:09
EugenMayersince 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 least01:09
EugenMayerthis cannot be rigbth01:10
EugenMayercurrent_flavor['name'] is accessed, this is not part of instance_extras01:10
EugenMayermost 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 more01:12
sean-k-mooney[m]we should be either using the one in the request spec or the one in instance extra01:12
EugenMayerhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L416201:13
sean-k-mooney[m]current_flavor is instance.get_flavor01:13
EugenMayer:)01:13
sean-k-mooney[m]which get the filed form the instnace object01:14
sean-k-mooney[m]the instnace object as i pointed too loads the flavor form the instance_extra table in the cell db01:14
EugenMayerhttps://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 see01:15
EugenMayerhttps://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 calling01:16
sean-k-mooney[m]that is in the flavor api code01:16
sean-k-mooney[m]that is just doing a lookup in the api db directly01:16
sean-k-mooney[m]resize is not calling that01:16
sean-k-mooney[m]well for the current_flavor01:17
sean-k-mooney[m]it calls that for the new flavor that you are resizeing too01:17
EugenMayerhttps://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#L414401:17
sean-k-mooney[m]that is cold migrate01:18
sean-k-mooney[m]resize is used for both flavor resize and cold migration01:18
EugenMayerand 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.name01:19
sean-k-mooney[m]line 4142 is the cold migrate path01:19
sean-k-mooney[m]4144 is the resize and its loading the new flavor from the api db01:19
sean-k-mooney[m]not the current flavor01:19
sean-k-mooney[m]the new flavor must exist01:19
EugenMayermaybe, 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_extra01:19
sean-k-mooney[m]why?01:20
EugenMayerthere is no such field?01:20
sean-k-mooney[m]the flaovr is stored as a json blob in the instance extra table01:20
sean-k-mooney[m]so name would be in the blob not a colum in that table01:21
EugenMayeri see that instance_extra::flavor is a json serialized model of the flavor01:22
sean-k-mooney[m]yes01:22
sean-k-mooney[m]we serialse the ovo01:22
sean-k-mooney[m]and store it in the flaovr column01:22
EugenMayerand there is the name field indeed01:22
sean-k-mooney[m]so other then the new flavor we shoudl not have a depency on the old flavor exising01:23
EugenMayerso this is deserialized. I understand. Then there is something else trying to access the 'flavor' of the 'old flavor' which leads to an exception01:23
sean-k-mooney[m]in the api db01:23
EugenMayeri see the idea here, got you. But there must be still a expectation left01:24
sean-k-mooney[m]there may be an in correct lookup using the id or some other reference01:24
EugenMayeri 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 instance01:24
sean-k-mooney[m]we could test it in a functional test01:25
sean-k-mooney[m]create a flavor , boot an instnace ,delete the flavor then try to resize01:25
EugenMayeryou should see, when using `openstack server resize` - 40901:25
sean-k-mooney[m]well we should see a 200 :) but we might see a 409 indeed01:26
sean-k-mooney[m]that would be a bug which we should fix01:26
EugenMayerI 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.py01:29
sean-k-mooney[m]we can try creating one tomorrow/later today and see if we can repoduce01:30
sean-k-mooney[m]do you have teh stack trace by the way01: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 tomorrow01:32
EugenMayerwell that's the funny thing, noboday on the 'user side' ever knows which sub-system is responsible here01:32
EugenMayerso grabbing a stacktrace is not as easy as you might think :)01:32
EugenMayerit's 2:30 here, so i'am with you 01:33
EugenMayersure, 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 it01:34
EugenMayersure! Have a good night then, i'am off to bed :)01:34
opendevreviewanguoming 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/+/83467702:51
*** bhagyashris_ is now known as bhagyashris04:55
opendevreviewmelanie witt proposed openstack/nova master: block_device_info: Add swap to inline  https://review.opendev.org/c/openstack/nova/+/82652306:57
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Improve creating images INFO log  https://review.opendev.org/c/openstack/nova/+/82652406:57
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Remove defunct comment  https://review.opendev.org/c/openstack/nova/+/82652506:57
opendevreviewmelanie witt proposed openstack/nova master: imagebackend: default by_name image_type to config correctly  https://review.opendev.org/c/openstack/nova/+/82652606:57
opendevreviewmelanie witt proposed openstack/nova master: image_meta: Add ephemeral encryption properties  https://review.opendev.org/c/openstack/nova/+/76045406:57
opendevreviewmelanie witt proposed openstack/nova master: BlockDeviceMapping: Add encryption fields  https://review.opendev.org/c/openstack/nova/+/76045306:57
opendevreviewmelanie witt proposed openstack/nova master: BlockDeviceMapping: Add is_local property  https://review.opendev.org/c/openstack/nova/+/76448506:57
opendevreviewmelanie witt proposed openstack/nova master: compute: Update bdms with ephemeral encryption details when requested  https://review.opendev.org/c/openstack/nova/+/76448606:57
opendevreviewmelanie witt proposed openstack/nova master: virt: Add ephemeral encryption flag  https://review.opendev.org/c/openstack/nova/+/76045506:57
*** clarkb is now known as Guest10607:31
*** gibi_pto is now known as gibi07:56
* gibi is back for two and a half days07:56
EugenMayersean-k-mooney[m] are you awake already? :)08:23
EugenMayersean-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
EugenMayeri 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 anything08:25
Ugglagibi, hi o/08:25
gibiUggla: o/08:28
EugenMayersean-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 find08:29
gibiUggla: thanks again fort the docs :)08:32
Ugglagibi, you are welcome.08:34
bauzasgibi: \o09:00
gibibauzas: o/09:01
opendevreviewribaudr proposed openstack/nova master: Fix unit tests when they are run with OS_DEBUG=True  https://review.opendev.org/c/openstack/nova/+/83311509:33
opendevreviewStephen Finucane proposed openstack/nova master: doc: Remove useless contributor/api-2 doc  https://review.opendev.org/c/openstack/nova/+/82859909:58
opendevreviewRajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild  https://review.opendev.org/c/openstack/nova/+/82036810:59
opendevreviewRajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild  https://review.opendev.org/c/openstack/nova/+/83121910:59
opendevreviewRajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances  https://review.opendev.org/c/openstack/nova/+/83088310:59
EugenMayerwhen an instance keeps in the 'spawning' phase - where can i check for the cause?11:05
kashyapgibi: Hey, on git/main with a patch, I see this: https://cpaste.org/?37b24bb8794dcdca#9jFENZMo38Bxjskev5QkLoGncaKucSgpx1tBHhvVKAYd11:09
kashyapgibi: Am I missing anything trivial? os_traits is installed in my virtualenv.11:10
gibiyou probably have old os_traits lib in the venv11:36
opendevreviewElod Illes proposed openstack/nova stable/xena: [stable-only] Set nova-tox-functional-centos8-py36 non-voting  https://review.opendev.org/c/openstack/nova/+/83485411:37
gibikashyap: you need 2.7.0 from os-traits https://github.com/openstack/os-traits/commits/2.7.011:38
opendevreviewBalazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile  https://review.opendev.org/c/openstack/nova/+/82924812:42
kashyapgibi: Darn lemme check12:45
kashyapgibi: Hm, I do have it:12:46
kashyap$> pip show os_traits | grep Version12:46
kashyapVersion: 2.7.012:46
gibithat is strange12:46
gibihttps://paste.opendev.org/show/buddLlqeEzZc7ClpZWF3/ I can import that constant12:49
gibikashyap: could you try just import that constan in an interpreter started in that env?12:51
UgglaI 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
kashyapgibi: Lemme try12:55
kashyapgibi: Hmm, import of that constant does work just fine here.12:56
kashyapgibi: 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
kashyapHmm, same on git/master too.12:58
* kashyap just recreates the venv13:10
kashyapOkay, that fixed it.  (Sorry for the noise.13:22
kashyap)13:22
artomUggla, it's 'recheck'13:32
artom'reverify' is only in our downstream CI13:32
artomTrigger words can be configured in Zuul, IIUC13:32
opendevreviewKashyap Chamarthy proposed openstack/nova master: libvirt: Use improved guest CPU config APIs  https://review.opendev.org/c/openstack/nova/+/76233013:34
Ugglaartom, I tried "rebuild", "reverify".... ;)13:36
* artom noticed13:36
artom;)13:36
Ugglaartom, thanks, it seems to be in the zull queue now.13:38
gibikashyap: no worries, then something was mixed in that env13:39
Ugglazuul*13:39
*** dasm|off is now known as dasm13:58
sean-k-mooneyUggla: 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 reqruied14:13
Ugglasean-k-mooney, thx for the info.14:41
sean-k-mooneygmann: 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 proceed14:44
bauzassean-k-mooney: shit I missed the fact it was depending on this14:45
gmannI had in list then missed somehow. thanks 14:46
sean-k-mooneyno worreis this has been on my review list for a while14:46
sean-k-mooneygibi: 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-mooneyjust going through my review backlog but i had mentally check that off as complete14:57
gibisean-k-mooney: yes the feature is complete from placement perspective14:58
gibiI have the placement client patch open, but that is not super important14:59
gibiand I have the todo to check the sql performance and improve if needed14:59
opendevreviewMerged openstack/nova master: doc: Split up notifications document  https://review.opendev.org/c/openstack/nova/+/82859815:00
gibihm I missed that review ^^ but quickly checked and looks good to me too15:01
opendevreviewMerged openstack/nova master: doc: Remove useless contributor/api-2 doc  https://review.opendev.org/c/openstack/nova/+/82859915:13
opendevreviewStephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration'  https://review.opendev.org/c/openstack/nova/+/72357215:15
opendevreviewStephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest'  https://review.opendev.org/c/openstack/nova/+/72357315:16
*** Guest106 is now known as clarkb15:24
outbritoMorning 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
outbritoIs that a known issue?15:45
sean-k-mooneyam i have seen that locally too15:47
sean-k-mooneybut not sure if we have a tacker for it15:47
dansmithrebuild your venv?15:47
dansmithtox -r15:47
outbritoIt was a brand new clone, but I'll try anyway15:47
dansmithack, usually random oslo things for me are due to a stale venv when reqs had changed, so that's the first thing I try15:49
sean-k-mooneyoutbrito: is this actully causing test failures for you or just an warning/error message15:49
outbrito5 test failing15:50
outbritotests*15:50
sean-k-mooneyok that actully the same as i saw on my mac book air tests yesterday also on a clean clone15:50
sean-k-mooneylet me see if i can repoduce on my normal system15:51
sean-k-mooneyi updated my ubuntu 20.04 server to 21.10 at the weekend but its running them now15:53
sean-k-mooneyso it wont be idential hum so i did get 1 failure with master15:54
sean-k-mooneyill try in a clean clone15:54
sean-k-mooneyoutbrito: what version of python did you run them under15:54
sean-k-mooney3.8 i assume?15:55
sean-k-mooneyjust in case that matters15:55
opendevreviewMerged openstack/placement master: tests: Silence noisy tests  https://review.opendev.org/c/openstack/placement/+/80110115:57
outbrito3.915:58
outbritoThe only differences I see on requirements is Yappi vs. yappi and PyNaCl vs. pynacl16:00
gibihm with 20.04 + py38 + fresh master I could not reproduce the lock_path issue16:01
outbritoThe tests failing are these btw:16:03
outbritonova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate_mismatch16:04
outbritonova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate_legacy16:04
outbritonova.tests.unit.compute.test_compute_mgr.ComputeManagerUnitTestCase.test_detach_volume_evacuate16:04
outbritonova.tests.unit.virt.test_block_device.TestDriverBlockDeviceNewFlow.test_volume_attach_with_shared_targets16:04
outbritonova.tests.unit.virt.test_block_device.TestDriverBlockDevice.test_volume_attach_with_shared_targets16:04
outbritoAll related to volumes for that matter16:04
opendevreviewMerged openstack/placement master: tox: Remove psycopg2 warning filter  https://review.opendev.org/c/openstack/placement/+/80091116:04
sean-k-mooneyon a clean clone on 21.10 i did not have any failure under python 3916:08
outbritopy38 also broken for me16:10
outbritojust to be sure, last commit is d2b2516 right?16:11
gibiyepp16:11
gibiI see that as head too16:11
gibibut no luck reproducing the issue16:11
gibidoes it happen the same way for you each time you rerun these tests?16:12
gibior is it unstable?16:12
outbritoconsistent16:13
gibioutbrito: do you also get a stack trace? If yes could you past it via https://paste.opendev.org/ (or similar)16:15
opendevreviewMerged openstack/placement master: setup: Replace dashes with underscores  https://review.opendev.org/c/openstack/placement/+/80110216:17
outbritohttps://paste.opendev.org/show/bZm6XstZ4MTPM7SPVuCR/16:17
gibithanks16:21
gibioutbrito: what is the os-brick version in your virtualenv?16:25
mfosean-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
mfowe 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/196075816:40
mfo[2] https://review.opendev.org/c/openstack/nova/+/82898016:40
mfo[3] https://review.opendev.org/c/openstack/nova/+/82897916:40
mfoessentially, i would get back to you with:16:40
mfo1) 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
mfoi've explained 1) with technical details/research in the bug's comments, and addressed 2) and 3) in the patches.16:40
mfothanks!16:40
sean-k-mooneymfo: ack, in a downstream call currently so will review it after16:41
sean-k-mooneymfo: in your opipion are the parces ready for review if so ill try and add them to my backlog for this week16:42
mfosean-k-mooney, yup, i think it's ready for review. 16:42
gibioutbrito: sorry I don't see what is happening on your side with those test and I will soon and my day.16:43
outbritono worries, i'll keep investigating. Thanks for looking into it16:59
outbritogibi, os-brick is at 5.2.0 btw17:00
melwittdansmith: 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/+/83108418:44
dansmithmelwitt: yeah I remember that, looking18:53
opendevreviewArtom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic  https://review.opendev.org/c/openstack/nova/+/83345319:02
*** artom__ is now known as artom19:03
dansmithmelwitt: commented, see what you think19:04
melwittcool thanks. looking19:05
opendevreviewArtom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic  https://review.opendev.org/c/openstack/nova/+/83345319:09
opendevreviewArtom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic  https://review.opendev.org/c/openstack/nova/+/83345319:16
opendevreviewArtom Lifshitz proposed openstack/nova master: Add whitebox-devstack-multinode job to periodic  https://review.opendev.org/c/openstack/nova/+/83345319:37
artom"deprecated_since=versionutils.deprecated.WALLABY"19:58
artom... in a placement installed in a ussuri tox functional venv19:58
artom*sigh*19:58
sean-k-mooneythat is likely down to how we install placment for the placment fixture in the tox env20:00
sean-k-mooneyif that is happenign in a clean checkout with new venv20:01
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/tox.ini#L11920:01
sean-k-mooneythat should still be limited by upper constratis for the branch https://github.com/openstack/nova/blob/master/tox.ini#L2920:01
sean-k-mooneyah hehe20:02
sean-k-mooneyhttps://opendev.org/openstack/requirements/raw/branch/stable/ussuri/upper-constraints.txt20:02
sean-k-mooneyplacement is not in upperconstrait for stable/ussuri20:02
sean-k-mooneyartom: so you will get whatever is on pypi20:02
sean-k-mooneyfor the most part that should be ok as we are just using it for the fixture in this case20:03
artomUnless it explicitly uses variables named after major releases :P20:03
sean-k-mooneybut that is why that happens its installing the latest pypi release of placement20:03
artomPresumably this would fail in the upstream gate as well20:03
* artom checks20:03
sean-k-mooneyproably we likely should cap it to the feature level 20:04
sean-k-mooney* minor release20:04
sean-k-mooneyactully placement is not release independ ot its the major verion20:04
sean-k-mooneythat woudl be pretty trival to do just update https://github.com/openstack/nova/blob/stable/ussuri/tox.ini#L9120:05
sean-k-mooneybut we woudl need to do that with a stable only patch for each release20:05
sean-k-mooneyso ussuri is 3.0.0 so you need to set it to <4.0.020:06
sean-k-mooneyso """openstack-placement>=1.0.0,<4.0.0""" i think although im not sure if the , is needed20:06
sean-k-mooneythat shoudl fix it20:07
sean-k-mooneyor you coudl be explcit and say openstack-placement==320:07
sean-k-mooneythat will give you any 3.x.y but not 2.* or 4.*20:08
sean-k-mooneyartom: hopefully that makes sense20:08
sean-k-mooneyim goign to call it a day so chat to you tomorrow o/20:09
artomsean-k-mooney, yep, many thanks, very useful20:09
artomWill also need to do it for victoria as well, since it doesn't understand WALLABY either20:10
clarkbnote I think ==3 means 3.0.0 not 3.x.y20:15
sean-k-mooneyim 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 syntax20:16
sean-k-mooneyi tought it woudl select the new 3.x.y20:16
sean-k-mooneybut im not sure20:16
clarkbthe ~= operator is for that or using * in the versions. missing identifiers seem to expand to .020:19
sean-k-mooneyack20:19
sean-k-mooneyis ~= supprot new20:20
sean-k-mooneyim familar with it in other context but i did nto think it was supproted in the requirements specificaitons20:20
clarkbit was defined in pep 440 somewhat new20:21
opendevreviewArtom Lifshitz proposed openstack/nova stable/victoria: [stable-only] Cap placement version in tox functional venv  https://review.opendev.org/c/openstack/nova/+/83497020:28
opendevreviewmelanie witt proposed openstack/nova master: image_meta: Add ephemeral encryption properties  https://review.opendev.org/c/openstack/nova/+/76045423:37
opendevreviewmelanie witt proposed openstack/nova master: BlockDeviceMapping: Add encryption fields  https://review.opendev.org/c/openstack/nova/+/76045323:37
opendevreviewmelanie witt proposed openstack/nova master: BlockDeviceMapping: Add is_local property  https://review.opendev.org/c/openstack/nova/+/76448523:37
opendevreviewmelanie witt proposed openstack/nova master: compute: Update bdms with ephemeral encryption details when requested  https://review.opendev.org/c/openstack/nova/+/76448623:37
opendevreviewmelanie witt proposed openstack/nova master: virt: Add ephemeral encryption flag  https://review.opendev.org/c/openstack/nova/+/76045523:37

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!