Friday, 2023-01-13

opendevreviewMerged openstack/nova-specs master: Add maxphysaddr support for Libvirt  https://review.opendev.org/c/openstack/nova-specs/+/86103302:58
opendevreviewMerged openstack/placement master: Avoid rbac defaults conflict in functional tests  https://review.opendev.org/c/openstack/placement/+/86952506:24
*** blarnath is now known as d34dh0r5306:43
gibifyi there is a low frequency but seems to be new functional test failure on the nova gate https://bugs.launchpad.net/nova/+bug/200278208:50
gibialso I see multiple failures in varios nova jobs with keystone not having admin role defined08:57
gibiJan 13 03:22:30.365429 np0032719500 devstack@keystone.service[52368]: ERROR keystone.server.flask.application [None req-a8fb798b-0274-4f56-8a07-13659cf7afe4 None admin] Could not find role: admin.: keystone.exception.RoleNotFound: Could not find role: admin.08:57
gibiexample: https://zuul.opendev.org/t/openstack/build/8cec516802404c0a8af6a2724ac2b78b/log/controller/logs/screen-keystone.txt#114208:57
gibibut there are successful job runs there since so I'm not sure if it wasn't just a temporary gate block resolved since08:58
kashyapgibi: Morning, 'grenade-skip-level' and 'nova-ceph-multistore' jobs are failing for me (looks unrelated): https://review.opendev.org/c/openstack/nova/+/869950/09:08
kashyapOne is:09:09
kashyap---09:09
kashyapdpkg: error processing package pcp (--configure): installed pcp package post-installation script subprocess returned error exit status 109:09
kashyap---09:09
gibiyepp that is unrelated09:15
gibihttps://bugs.launchpad.net/devstack/+bug/194318409:16
kashyapAh, thanks for the link09:17
kashyapAnd the 'nova-ceph-multistore' job seems to crash/segfault Python due to this test:09:17
kashyaptempest.api.compute.admin.test_volume.AttachSCSIVolumeTestJSON.test_attach_scsi_disk_with_config_drive[id-777e468f-17ca-4da4-b93d-b7dbf56c0494]09:17
kashyapgibi: Wow, if 'pcp' has eeb unreliable for that long, I wonder if there's an alternative or if it's necessary at all09:18
fricklerit is only for stat collection, so mostly not necessary at all. I was also thinking we had disabled it by default, do you enable dstat in those job(s)?09:19
kashyapfrickler: I don't know off-hand if those jobs enable 'dstat', but I assume they do09:21
*** elodilles is now known as elodilles_pto09:58
opendevreviewSahid Orentino Ferdjaoui proposed openstack/nova master: compute: enhance compute evacuate instance to support target state  https://review.opendev.org/c/openstack/nova/+/85838310:29
opendevreviewSahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state  https://review.opendev.org/c/openstack/nova/+/85838410:29
opendevreviewAlexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1994983  https://review.opendev.org/c/openstack/nova/+/86341612:01
opendevreviewAlexey Stupnikov proposed openstack/nova master: Log some InstanceNotFound exceptions from libvirt  https://review.opendev.org/c/openstack/nova/+/86366512:02
lajoskatonaHi nova team, shall I ask about the CLI of migrate? The question is: "is there a chance to change the --wait option to wait for the migrate status instead of the server status in case of openstack server migrate .... --wait?"12:06
lajoskatonaThe logic is here: https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/compute/v2/server.py#L3016-L3022 and as I saw it was (the login I mean) copy-pasted from novaclient, but for that I can't find why it was decided to wait for the server status instead of the status of the migration12:08
lajoskatonaI see reason for both, as even if the migration failed the server can remain on the same host and we are happy as it is active.12:08
opendevreviewAlexey Stupnikov proposed openstack/nova stable/zed: Remove deleted projects from flavor access list  https://review.opendev.org/c/openstack/nova/+/87005312:09
lajoskatonaBut from the other perspective the user would be happy to see in this case that hey your migration failed (without extra check for the status of migration), as it can be misleading that the --wait returns happily but the migration failed12:10
sean-k-mooneylajoskatona: if i recall there is not a good way to find the miration object12:13
sean-k-mooneythe migrate and live migrate calls dont retrun the migration uuid if i recall so you would need ot have a hureistic to find it client side12:14
sean-k-mooneysomething like list the migrations or server events for the instnace and get the last one and hope that is the correct one for the currnt command12:15
sean-k-mooneyhttps://docs.openstack.org/api-ref/compute/?expanded=migrate-server-migrate-action-detail#migrate-server-migrate-action12:16
sean-k-mooneyif we had an api change to retrun the migration uuid form that and the live migrate endpoint then it would be easy for the client to wait on the migration status instead12:17
lajoskatonasean-k-mooney: thanks, sounds interesting and true as I start to remember the migration things. I check and play with it to understand fully.12:25
pslestangHy all, is that because the relation chain is not totally reviewed that I can not merge this patchset https://review.opendev.org/c/openstack/nova/+/867832 or do I miss something else? 13:20
sean-k-mooneyyes13:36
sean-k-mooneythe repoducer is not approved so the fix won be merged13:36
sean-k-mooneywhen the parent merges the top patch will be merged by zuul13:36
pslestangok understood, will some of you get some times to approve it?13:39
sean-k-mooneyya we will review it as normal i might have time to take a look later today13:46
sean-k-mooneythis code is incldued more or less in the follow up patch so i have glance over it already13:46
sean-k-mooneyso likely there will be no feedback but im doing some email stuff right now so dont want to swtich context13:47
kashyapMan, I'm in Gate-hell, these jobs are failing w/ unrelated errors :( - nova-live-migration, nova-multi-cell, nova-ovs-hybrid-plug, nova-grenade-multinode13:47
kashyapI wonder how many of these jobs really deserve to be "voting"13:48
sean-k-mooneyall of them13:51
sean-k-mooneythey are pretty stabel if there is currently an issue its new and we shoudl investigate that13:51
kashyapWell, that is the "ideal" scenario, assuming there's "unlimited bandwidth" from contributors.  I can't possibly keep investigating CI issues all day and week long13:56
sean-k-mooneyhttps://zuul.openstack.org/builds?job_name=nova-live-migration&job_name=nova-ovs-hybrid-plug&job_name=nova-multi-cell&job_name=nova-grenade-multinode&project=openstack%2Fnova&branch=master&skip=013:56
kashyapI don't know if all of them are deserving, we have to re-evaulate some jobs to see if they're still worth their salt.13:56
sean-k-mooneyi do look at those jobs and the ones that you listed are valuable13:57
kashyapWhat's annoing is all of these jobs passed in the previous run :-(13:57
sean-k-mooneythe grenade job failed on test_volume_backed_live_migration13:59
bauzaskashyap: lemme look then, change id ?13:59
* bauzas was working back on its power management series14:00
sean-k-mooneypresumable https://review.opendev.org/c/openstack/nova/+/86958714:00
kashyapbauzas: Thanks for the offer, I have already opened all the failing 4 jobs and seeing what's up one-by-one14:01
sean-k-mooneyor https://review.opendev.org/c/openstack/nova/+/86995014:01
bauzassean-k-mooney: ack, will look14:01
bauzasTGIF14:01
kashyapPreviously 'nova-ceph-multistore' was failing due to 'pcp' package unreliability14:01
kashyapbauzas: That's the patch: https://review.opendev.org/c/openstack/nova/+/869950/14:01
sean-k-mooneyya i saw that in one of the other failaure14:01
sean-k-mooneythat might be a mirror issue14:02
sean-k-mooneyso not related to the job but the cloud it ran on14:02
sean-k-mooneyi know that there was issues with one of the ci providers running out os log storage i think during the week14:02
kashyapHmm, it's a pity that we don't have a way to selectively run the failing jobs (while retaining the older one) - if nothing has changed in a patch14:02
sean-k-mooneywe intentially dont because that is dangours14:02
sean-k-mooneyits call the green check policy14:03
kashyapI know, the "danger" is introducing accidental regressions14:03
sean-k-mooneythe issue is that we use speculative execution in the gate14:03
sean-k-mooneyso running one job might mean you end up with each job testing diffent specultivly merged commits14:04
kashyapI wonder what's wrong with this: *if* a patch has not changed from previous iteration, and a job has failed due to unrelated failure, then allow to selectively re-run just that14:04
sean-k-mooneyif you made sure the same commits were preseved for the rerun that might be ok but that is not how zuul works14:04
bauzasyup 14:04
bauzasand honestly, I prefer this14:05
kashyapSure, the commit _is_ preserved14:05
sean-k-mooneythat not how zuul works14:05
bauzasif we have some jobs that are not ok, we can then make non-voting in case14:05
sean-k-mooneyzuul rebases the commit you submit on top of master to test it merged to the curent state of master14:05
sean-k-mooneykashyap: the grenade job failed becasue of rabbitmq 14:18
sean-k-mooney: ERROR oslo.messaging._drivers.impl_rabbit [None req-5a9299c4-d386-4e22-8cca-281e29799492 None None] Connection failed: [Errno 111] ECONNREFUSED (retrying in 19.0 seconds): ConnectionRefusedError: [Errno 111] ECONNREFUSED14:18
sean-k-mooneythe second compute node did not stack14:19
sean-k-mooneythis is the second time i have seen that in two days so that looks like a real issue in devstack14:19
kashyapsean-k-mooney: I see, thank you for looking.  Is that an accidental thing?14:19
sean-k-mooneyi have only seen that since yesterday14:19
kashyapHm, 2nd time 2 days14:19
kashyapBut it passed just a few hours ago.  Seems non-deterministic to me.14:19
sean-k-mooneyso i dont know if something changed this week that broke it14:20
sean-k-mooneyyes so it might depend on the provider what we shoudl do is check the conoterl and see if its running there14:20
kashyapI see nothing "green" on the controller - https://zuul.opendev.org/t/openstack/build/9c1b4d7afc4c457fa90ae4ceb128dded14:21
kashyapAlthough it says in _red_, "193 OK, 103 changed, 1 Failure"14:21
kashyapProbably it's just a miscolored thing14:21
sean-k-mooneylooks like its running fine on the contoler14:22
sean-k-mooneyalthouhg nova-compute is failing on the contoler too but that might be after/durign the upgrade14:23
sean-k-mooneyn-cpu is running fine  initally at least14:24
sean-k-mooneythis could jsut be an network connectiy issue between the vms14:24
kashyapYeah, thought so; the classic "network connectivity" :)14:25
sean-k-mooneygrenade is able to run many of the test 14:25
sean-k-mooneyhttps://zuul.opendev.org/t/openstack/build/9c1b4d7afc4c457fa90ae4ceb128dded/log/controller/logs/grenade.sh_log.txt14:25
sean-k-mooneyim not sure if it is a network connectivy test as it would not have got to grenade if it did not work before the upgrade14:26
sean-k-mooneywe run tempest twice for grenade14:26
sean-k-mooneybefore upgrade and after14:26
kashyapYeah, your logic makes sense, though - if it is able do upgrade tests via grenade, then the prob is elsewhere14:26
sean-k-mooneytempest.scenario.test_server_multinode.TestServerMultinode.test_schedule_to_all_nodes14:27
sean-k-mooneyis failing because the subnode is nolonger able to connect14:27
opendevreviewAlexey Stupnikov proposed openstack/nova master: Log some InstanceNotFound exceptions from libvirt  https://review.opendev.org/c/openstack/nova/+/86366514:27
kashyapsean-k-mooney: Thanks; I admire your ability to tirelessly look at CI failures 14:32
bauzassean-k-mooney: I briefly looked at kashyap's CI issues and it looked to me transient network issues14:33
sean-k-mooneywell i have swaped back to other thing but in generally all active contibutor are exepcted to help look at them14:33
dansmithsean-k-mooney: I saw one of those connection refused to rabbit things yesterday as well14:33
sean-k-mooneybauzas: i would agree but as i said this is the second tim i have seen the rabbit issues14:33
dansmithalong with several other failures that has me concerned14:33
sean-k-mooneyya14:33
bauzaslemme check the nodes14:33
sean-k-mooneyso i do think that something has regressed in grenade/devstack/job-defintiosn14:34
*** dasm|off is now known as dasm14:34
sean-k-mooneyit could be provider related but i think we have seen isseus on more the one provider14:34
dansmithon another note, sean-k-mooney bauzas I hope either of you can look at this soon: https://review.opendev.org/c/openstack/nova/+/86621814:35
bauzashttps://f4c3b65ecec7dfeb9b12-92114ee8da6f13c40794db32b7bbd824.ssl.cf5.rackcdn.com/869950/4/check/nova-grenade-multinode/9c1b4d7/zuul-info/inventory.yaml14:35
bauzasovh14:35
dansmithstill waiting on one devstack thing, but it's small, and a dependent placement thing as well14:35
bauzasdansmith: sure I can help 14:35
bauzasoh this14:35
bauzasI said I was looking at it14:35
sean-k-mooneydansmith: ya so i merged the placment fixture change last night14:35
dansmithoh sweet thanks14:36
bauzasalready half-reviewed gmann's patch14:36
sean-k-mooneybauzas: ack if you dont get to it by your end of day ill try and get to it before i sign off today14:36
kashyapsean-k-mooney: Yes, of course - I look at them (within reason).  I was just saying, can't drop all the other responsibilities and tend to it :( Just not enough hours14:36
dansmithbauzas: sorry, but thanks14:36
dansmithkashyap: well, someone has to :/14:36
kashyapdansmith: True, the mythical "someone"; it's the classic "tragedy of the commons" :/14:37
dansmithif we let it get out of control we'll never recover14:37
bauzassean-k-mooney: gmann: ok, so by now we only check functional tests using legacy RBAC14:37
bauzashttps://review.opendev.org/c/openstack/placement/+/869525/3/placement/tests/functional/fixtures/placement.py14:37
bauzasI'm OK with this14:37
bauzasbut will we have a FUP modifying our tests for using the new defaults ?14:38
dansmithbauzas: no, the main devstack job runs with old14:38
dansmithand a new devstack job with new14:38
dansmiththat's what I had him add, so we could command them still to be old while we transition14:39
sean-k-mooneywell bauzas  is askign about functional tests14:40
bauzasdansmith: ok, I understand it so placement won't yet support new defaults, only nova/neutron/cinder blah, right?14:40
sean-k-mooneyat some point we shoudl test with new placemnt defaults too14:40
bauzasthat's my point14:41
sean-k-mooneyalthogh i dont know if we want to just swap or add new tests14:41
bauzasI just wanna make sure what we will do 14:41
sean-k-mooneylargly for placment it wont matter much14:41
dansmithoh sorry I thought you meant you thought we weren't getting any old coverage14:41
sean-k-mooneyas we always talk to it as admin more or less now anyway14:41
dansmithright doesn't matter much for placement14:41
dansmithglance does have a functional job running on both, but mostly because they have specific functional tests for it and their functional tests are a lot more realistic than ours14:42
dansmithdo we even do policy checking in our functionals? maybe some of them?14:43
bauzaswe don't check policy in our tests AFAIK14:45
bauzasbutn,14:45
bauzaswe sometimes ask for the admin role14:45
bauzasso I guess that while nova will work with new defaults, we'll then call placement using old defaults, right?14:46
*** tosky_ is now known as tosky14:47
opendevreviewSofia Enriquez proposed openstack/nova master: WIP: Implement encryption on backingStore  https://review.opendev.org/c/openstack/nova/+/87001214:47
dansmithbauzas: I don't know that there's really much difference for placement14:48
dansmithadmin is still admin, and we don't use the user's token like we do when we call neutron, cinder, etc14:49
dansmithI've also seen this grenade failure where we fail on the old side waiting for compute to be registered in the catalog14:56
dansmithbauzas: gibi sean-k-mooney: it would be really good to get this in as soon as we can, it's seriously annoying debugging the other gate fails without it: https://review.opendev.org/c/openstack/nova/+/86990015:12
bauzasdansmith: gmann: sent new RBAC defaults patch to the gate15:14
bauzaslooking now at your CI fix15:14
dansmithbauzas: thanks15:14
dansmithbauzas: that 9900 patch avoids us spewing thousands of warnings on each run about that deprecated function,15:16
dansmithwhich makes reading other log dumps pretty hard15:16
bauzasdansmith: I don't see what you mean :p https://review.opendev.org/c/openstack/oslo.messaging/+/862419/4/oslo_messaging/rpc/client.py#389 15:17
bauzas(joking)15:17
dansmithmmhmm :)15:17
bauzasevery single instanciation raises a warning 15:17
bauzaslovely15:17
dansmithyeah, which we apparently do A LOT15:17
bauzasI wasn't expecting it15:18
bauzasbut I guess those are for tests15:18
dansmith15,664 times in just one n-api log run15:18
bauzashttps://review.opendev.org/c/openstack/nova/+/869900/6/nova/tests/fixtures/nova.py15:18
dansmithsearch RPC in here: https://391a5777f99d615e9bdd-6109476be9a7a65d8252c7a651ade8fd.ssl.cf1.rackcdn.com/863919/6/check/tempest-integrated-compute/6af4a31/controller/logs/screen-n-api.txt15:19
bauzaswoah15:19
dansmithwe log it even in production, tens of thousands of times15:19
dansmithand by "we" I mean "we on behalf of o.msg"15:19
sean-k-mooneyso any reason fro me to not +2w this15:19
bauzasoh wait15:19
sean-k-mooneyit looks ok to me15:19
bauzasthis isn't a singleton15:19
sean-k-mooneyit has the requiremtn bump15:19
* bauzas facepalmps15:19
dansmithhttps://imgur.com/a/0Vvw1ss15:20
sean-k-mooneyci will kick it back if it fails again on the recheck15:20
bauzassean-k-mooney: sent to the gate too, for the gosh sake we could merge it eventually15:20
dansmithnote the scroll bar showing all the matches15:20
bauzasdansmith: yeah, look at https://review.opendev.org/c/openstack/nova/+/869900/6/nova/rpc.py15:20
sean-k-mooneywhat was the nova-next failure15:20
dansmithyup15:20
bauzaseverytime we call get_client, we instantiate a RPCService15:20
dansmithyup15:20
bauzasI would have preferred this being a singleton, but meh noxw15:21
bauzasnow15:21
dansmithwell,15:21
* bauzas disappears for taxi reasons15:21
gmanndansmith: bauzas dansmith : for functional test testing placement new defaults. I will switch it once placement new defaults are merged, otherwise we need to add system scope token to make placement exiting defaults - https://review.opendev.org/c/openstack/placement/+/86561815:21
dansmithit can't always be because of cell stuff so we need to pool15:21
bauzasdansmith: ah true15:21
bauzasgmann: wfm15:22
* bauzas bbiab15:22
gmanndansmith: bauzas: sean-k-mooney: as you were on rbac things, can you check this which was missed in original change. keeping legacy admin for 'os-tenant-networks' policy  https://review.opendev.org/c/openstack/nova/+/86507115:23
sean-k-mooneyoh thats projec treader of gloabl admin15:25
sean-k-mooneywhere as the curren tbehavior woudl requrie you to have admin on the current project15:25
gmannyeah keeping legacy admin unimpacted 15:26
sean-k-mooneyi.e. admin implies member implies reader but the project reader will also check the project in your token matches15:26
sean-k-mooneyi guess we dont have any tempest tests covering that15:27
sean-k-mooneyor it would have blocked eitehr enablign the new default or where we broke it15:27
gmannsean-k-mooney: this ADMIN is just role:admin not just project  admin.  so rule is "role:admin or project-reader" where we do not check project_id for admin role token15:31
sean-k-mooneyyep that is what i was expecting15:45
opendevreviewSofia Enriquez proposed openstack/nova master: WIP: Implement encryption on backingStore  https://review.opendev.org/c/openstack/nova/+/87001216:47
sean-k-mooneyi guess sofia has got time to start on ^ again but that spec is not appvoed for this cycle17:03
sean-k-mooneyon a related note to the other warning it looks like we are spaming the functionl logs with an sqlachemy deprecation warning too17:15
sean-k-mooneyhttps://paste.opendev.org/show/bWlWeI8pWyiwWyvJ7NtC/ ^ dansmith 17:15
sean-k-mooneyim not seeign a nova line there17:16
sean-k-mooneyso i guess this needs to be fixed in oslo_db17:16
dansmithsean-k-mooney: yeah I've seen that too17:25
dansmithit's annoying, just less annoying :)17:25
sean-k-mooneyya os i just mentioned it on the oslo channel and look at code search17:26
sean-k-mooneyother then in some puppet code this is off everywhere17:26
sean-k-mooneyso i think oslo.db just need to drop the kwarg and do a release17:26
kashyapIs this Oslo DB error know issue in the  "nova-tox-functional-py38" job?17:27
sean-k-mooneyits just a log message17:27
sean-k-mooneyits not breakign anything17:27
kashyap{0} nova.tests.functional.libvirt.test_vgpu.VGPUTests.test_resize_servers_with_vgpu [6.373304s] ... FAILED()17:27
sean-k-mooneybut it makes runnign the test more annrying 17:27
kashyap(From here: https://zuul.opendev.org/t/openstack/build/a229b41daba64b6f8dfdeca8c839e9f7)17:27
sean-k-mooneythats a diffent oslo.db thing then i was talkign about17:28
* kashyap goes to buy two goats and three pigs to sacrifice (on Monday) to the Zuul gods 17:28
sean-k-mooneykashyap: that actully looks like a real bug17:29
kashyapAgain: it was not hit in the previous 3 runs :-(17:29
sean-k-mooneyim not sure why we woudl get a db conflict like that in a fucntional test17:29
kashyapsean-k-mooney: But I agree - it "looks" on the surface like a real bug, but I'm not confident if it's _really_ a DB conflict, or a PEBKAC in the test or ... env snafu17:30
sean-k-mooneyso there are two tracebacks there17:30
sean-k-mooneysqlite3.InterfaceError: Cursor needed to be reset because of commit/rollback and can no longer be fetched from.17:30
sean-k-mooneyand 17:30
sean-k-mooneyTraceback (most recent call last):17:30
sean-k-mooney  File "/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py38/lib/python3.8/site-packages/urllib3/connectionpool.py", line 440, in _make_request17:31
sean-k-mooney    httplib_response = conn.getresponse(buffering=True)17:31
sean-k-mooneyTypeError: getresponse() got an unexpected keyword argument 'buffering'17:31
sean-k-mooneyso it looks likethere si an issue wit urllib317:31
sean-k-mooneyas well17:31
kashyapRight, the first one is the cause of the 2nd one17:31
kashyap(If I'm parsin it correctly)17:31
sean-k-mooneyi dont see how urllib3 is for http requests not the db unless this is form parsing the db connection url17:32
sean-k-mooneyoh look urllib3 had a release 2 days ago...17:35
sean-k-mooneyhum ok but we have not change uc to allow it in 4 months17:37
kashyapYou mean upper-constraints?17:38
kashyapThanks for digging that.17:38
sean-k-mooneyya so there has been a release but i dont think its in use17:39
sean-k-mooneyupper-constraits is still clamping to an older one on master17:39
kashyapsean-k-mooney: As of now, just to show the "randomness" of the failures: all the jobs that failed in the previous run succeeded now -  nova-live-migration, nova-multi-cell, nova-ovs-hybrid-plug, and nova-grenade-multinode jobs17:39
kashyap(Except the new one above in the tox-functional-py38)17:39
kashyapsean-k-mooney: Should we bump it?17:40
kashyapDoes it make sense to do so?17:40
sean-k-mooneywe have automation to bump it 17:40
sean-k-mooneythat runs a set of jobs to check compatiablity with most of the projects17:40
kashyapOh, right; I forgot the bot; that's much safer17:41
* kashyap goes to make dinner; enough Zuul sleuthing for the night. Thanks, sean-k-mooney, as always!17:42
sean-k-mooneyit ran with urllib3-1.26.1217:45
sean-k-mooneywhich is what i have locally and that works17:45
sean-k-mooneymy guess isthe two exceptions are somehow related17:45
sean-k-mooneybut i can see show directly17:45
opendevreviewDan Smith proposed openstack/nova master: Persist existing node uuids locally  https://review.opendev.org/c/openstack/nova/+/86391818:51
opendevreviewDan Smith proposed openstack/nova master: Make resource tracker use UUIDs instead of names  https://review.opendev.org/c/openstack/nova/+/86391918:51
opendevreviewDan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup  https://review.opendev.org/c/openstack/nova/+/86392018:51
opendevreviewArtom Lifshitz proposed openstack/nova master: Microversion 2.94: FQDN in hostname  https://review.opendev.org/c/openstack/nova/+/86981220:07
gmannsean-k-mooney: bauzas: gibi: reminder for osc-placement gate fixes review https://review.opendev.org/q/I4e3e5732411639054baaa9211a29e2e2c8210ac020:37
sean-k-mooney[m]gmann im not sure that is what we should be doing21:34
sean-k-mooney[m]i was suggesting continng to use master on master and using the stable branch  release or stable21:35
gmannsean-k-mooney[m]: ok for stable. I was thinking we do the same way the Nova testing on master21:36
sean-k-mooney[m]im not sure what that iss of the top of my head but ill take a look21:37
gmannok. let me know and I can update those accordingly. 21:37
sean-k-mooney[m]i guess if it works as it says in the comment that is ok21:38
sean-k-mooney[m]i dont know how that works however21:38
sean-k-mooney[m]i would not expect that to be how  it works unless we are doing something special with tox siblings in the jobs21:39
sean-k-mooney[m]the tox ini does not hve the described behavior on its own21:39
clarkbsiblings only take effect if you set the project as a required project on the zuul job (that pulls in the git repo and the tox role uses it as a single to install it from source)21:39
sean-k-mooney[m]right so osc-placemnt would need to declarae placemnt as a required project21:40
sean-k-mooney[m]and we would need the tox siblings stuff to overried whats in the tox ini21:41
sean-k-mooney[m]and install placemtn form the git repo prepared by zuul21:41
sean-k-mooney[m]is that how we have the functional job configured in nova/osc-placement21:41
gmannif we change it to test with master only then we should have another job to test with the released version21:41
sean-k-mooney[m]well its testing with master only now21:42
gmannas comments says, we can test the master placement by replacing the deps line21:42
gmannyes, in osc-placement and released version in nova21:42
sean-k-mooney[m]so your propeosing change to using the released version21:42
sean-k-mooney[m]yep21:42
sean-k-mooney[m]so it would be nice for depends-on to work21:43
sean-k-mooney[m]and  in generall im fine with used the released verison21:43
sean-k-mooney[m]but im questioning if the tox job in osc-placment will give the depends on behavior today21:43
gmannWhile doing it for stable branch and I checked how Nova does I thought of doing the same for osc-placement also 21:43
sean-k-mooney[m]ok so we have the required projec tin the zuul.yaml21:45
sean-k-mooney[m]https://github.com/openstack/osc-placement/blob/master/.zuul.yaml21:45
gmannyeah21:45
sean-k-mooney[m]yep i know i was just checking if we were using the jobs from the default template or if we had already overriden it21:45
sean-k-mooney[m]since i did not see that in the patch you linked21:46
sean-k-mooney[m]i was expecting both in the same patch21:46
sean-k-mooney[m]ok this should be fine as is21:47
gmannack21:48
clarkbI'm not sure the comment is correct though since siblings will be used21:52
clarkbit will always be the latest version of the branch in the gate not the release21:53
dansmithcripes, we're never going to get the rpc spam thing landed23:22
dansmithseen this a few times now as well: https://zuul.opendev.org/t/openstack/build/f5aa5edd4d354c2685fc1f3e13d0ef7723:22
dansmithsaying one of the tempest workers crashed23:22
dansmithseems unlikely to me23:23
*** dasm is now known as dasm|off23:37

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