Tuesday, 2020-03-31

*** mlavalle has quit IRC00:00
*** tetsuro_ has joined #openstack-nova00:00
openstackgerritsean mooney proposed openstack/nova master: [WIP] cyborg evacuate support  https://review.opendev.org/71532600:00
*** kevinz has joined #openstack-nova00:03
*** tetsuro has quit IRC00:03
*** nweinber has joined #openstack-nova00:11
*** nweinber has quit IRC00:15
*** factor has quit IRC00:19
*** factor has joined #openstack-nova00:20
openstackgerritGhanshyam Mann proposed openstack/nova master: Correct limits policy check_str  https://review.opendev.org/71567200:26
openstackgerritGhanshyam Mann proposed openstack/nova master: Combine the limits policies in single place  https://review.opendev.org/71567800:27
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing limits policies  https://review.opendev.org/71567400:27
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in limits policy  https://review.opendev.org/71568000:27
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in limits policies  https://review.opendev.org/71576000:32
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576100:32
*** tetsuro has joined #openstack-nova00:37
*** tetsuro_ has quit IRC00:40
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies  https://review.opendev.org/70164800:40
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy  https://review.opendev.org/70164900:42
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing hypervisors policies  https://review.opendev.org/71502900:42
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in os-hypervisors  https://review.opendev.org/71503600:42
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in os-hypervisors policies  https://review.opendev.org/71507100:48
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in os-hypervisors policy  https://review.opendev.org/71507400:49
openstackgerritGhanshyam Mann proposed openstack/nova master: Correct limits policy check_str  https://review.opendev.org/71567200:49
openstackgerritGhanshyam Mann proposed openstack/nova master: Combine the limits policies in single place  https://review.opendev.org/71567800:50
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing limits policies  https://review.opendev.org/71567400:50
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in limits policy  https://review.opendev.org/71568000:50
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in limits policies  https://review.opendev.org/71576000:50
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576100:50
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in limits policies  https://review.opendev.org/71576000:51
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576100:51
*** tetsuro_ has joined #openstack-nova00:52
*** tetsuro_ has quit IRC00:57
*** macz_ has joined #openstack-nova01:00
*** TxGirlGeek has quit IRC01:04
*** macz_ has quit IRC01:05
*** tetsuro_ has joined #openstack-nova01:05
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in lock server policy  https://review.opendev.org/71611401:09
*** tetsuro_ has quit IRC01:10
*** Liang__ has joined #openstack-nova01:12
*** luyao has joined #openstack-nova01:24
*** zhanglong has joined #openstack-nova01:28
*** sapd1_y has joined #openstack-nova01:29
*** sapd1 has quit IRC01:31
openstackgerritwangjiajing proposed openstack/nova stable/rocky: Perfect unit test of 'test_no_migrations_have_downgrade'.  https://review.opendev.org/71611801:40
brinzhang_gmann: do you know what the dot in update-dot-volume-attachment-req.json file name?01:46
brinzhang_I cannot understand 'dot' what does it mean :(01:46
gmannbrinzhang_: 'delete_on_termination'01:59
brinzhang_gmann: maybe, but look like not easy to know02:03
*** spatel has joined #openstack-nova02:03
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in lock server policies  https://review.opendev.org/71612202:15
*** bnemec has quit IRC02:19
*** sapd1 has joined #openstack-nova02:20
*** sapd1_y has quit IRC02:21
*** bnemec has joined #openstack-nova02:28
*** zhenguo_ has joined #openstack-nova02:33
*** macz_ has joined #openstack-nova02:49
openstackgerritMerged openstack/nova master: Enable and use COMPUTE_ACCELERATORS trait.  https://review.opendev.org/69955402:52
*** macz_ has quit IRC02:53
*** hongbin has joined #openstack-nova03:00
*** hongbin has quit IRC03:05
*** mkrai has joined #openstack-nova03:10
*** psachin has joined #openstack-nova03:29
*** threestrands has joined #openstack-nova03:39
*** toabctl has joined #openstack-nova03:39
*** ociuhandu has joined #openstack-nova03:43
*** ociuhandu has quit IRC03:48
*** toabctl has quit IRC04:03
*** toabctl has joined #openstack-nova04:07
*** ccamacho has quit IRC04:08
*** spatel has quit IRC04:11
*** eharney has quit IRC04:19
*** artom has quit IRC04:31
*** eharney has joined #openstack-nova04:31
*** evrardjp has quit IRC04:36
*** evrardjp has joined #openstack-nova04:36
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing migrate server policies  https://review.opendev.org/71612804:36
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing migrate server policies  https://review.opendev.org/71612804:39
*** udesale has joined #openstack-nova04:42
*** zhenguo_ has quit IRC04:42
*** ratailor has joined #openstack-nova04:45
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in migrate server  https://review.opendev.org/71613004:47
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in migrate server policies  https://review.opendev.org/71613204:53
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in migrate server policy  https://review.opendev.org/71613404:57
*** tetsuro_ has joined #openstack-nova05:04
*** tetsuro has quit IRC05:07
*** dave-mccowan has joined #openstack-nova05:15
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing migrations policies  https://review.opendev.org/71613605:17
*** Liang__ is now known as LiangFang05:18
*** links has joined #openstack-nova05:29
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in list migrations  https://review.opendev.org/71614105:31
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing migrations policies  https://review.opendev.org/71613605:31
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in list migrations  https://review.opendev.org/71614105:31
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in migrations policies  https://review.opendev.org/71614505:38
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in migrations policy  https://review.opendev.org/71614705:41
*** mkrai has quit IRC05:48
*** mkrai has joined #openstack-nova05:48
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576106:12
*** dpawlik has joined #openstack-nova06:20
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing pause server policies  https://review.opendev.org/71616106:20
*** dpawlik has quit IRC06:28
openstackgerritGhanshyam Mann proposed openstack/nova master: Fix unpause server policy to be admin_or_owner  https://review.opendev.org/71616506:31
*** sapd1_y has joined #openstack-nova06:35
*** sapd1 has quit IRC06:38
*** vishalmanchanda has joined #openstack-nova06:39
*** dklyle has quit IRC06:41
openstackgerritAndreas Jaeger proposed openstack/os-vif master: Update hacking for Python3  https://review.opendev.org/71565106:45
*** dpawlik has joined #openstack-nova06:47
*** xek has joined #openstack-nova06:49
openstackgerritAndreas Jaeger proposed openstack/nova-specs master: Update hacking for Python3  https://review.opendev.org/71565006:50
*** slaweq has joined #openstack-nova07:00
*** nightmare_unreal has joined #openstack-nova07:03
*** mkrai has quit IRC07:13
*** mkrai has joined #openstack-nova07:14
*** tetsuro_ has quit IRC07:15
*** rpittau|afk is now known as rpittau07:17
*** tesseract has joined #openstack-nova07:22
*** ociuhandu has joined #openstack-nova07:24
*** maciejjozefczyk has joined #openstack-nova07:24
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in lock server policies  https://review.opendev.org/71612207:25
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing lock server policies  https://review.opendev.org/71605707:28
*** iurygregory has quit IRC07:28
*** ociuhandu has quit IRC07:29
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in lock server policy  https://review.opendev.org/71611407:29
*** tosky has joined #openstack-nova07:29
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in lock server policies  https://review.opendev.org/71612207:29
*** iurygregory has joined #openstack-nova07:29
*** sapd1 has joined #openstack-nova07:31
*** sapd1_y has quit IRC07:33
openstackgerritGhanshyam Mann proposed openstack/nova master: Add test coverage of existing pause server policies  https://review.opendev.org/71616107:36
openstackgerritSundar Nadathur proposed openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls.  https://review.opendev.org/70422707:40
openstackgerritSundar Nadathur proposed openstack/nova master: Block unsupported instance operations with accelerators.  https://review.opendev.org/67472607:40
openstackgerritSundar Nadathur proposed openstack/nova master: Add cyborg tempest job.  https://review.opendev.org/67099907:40
openstackgerritSundar Nadathur proposed openstack/nova master: Add release notes for Cyborg-Nova integration.  https://review.opendev.org/71618507:40
openstackgerritSundar Nadathur proposed openstack/nova master: Delete ARQs by UUID if Cyborg ARQ bind fails.  https://review.opendev.org/71618607:40
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in pause server policy  https://review.opendev.org/71618707:41
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in pause server policies  https://review.opendev.org/71619107:48
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in migrations policies  https://review.opendev.org/71614507:54
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in migrations policy  https://review.opendev.org/71614707:54
*** ociuhandu has joined #openstack-nova07:55
*** ralonsoh has joined #openstack-nova08:02
*** tetsuro has joined #openstack-nova08:07
brinzhang_gibi: hi08:11
gibibrinzhang_: hi08:12
gibion a meeting, so expect a slower response08:12
brinzhang_gibi: Now I have time to update the bp/destroy-instance-with-datavolume https://review.opendev.org/#/c/711194/9//COMMIT_MSG@16, with this releasenote name, what have so suggestion?08:13
brinzhang_gibi: no problem, just a quick question :)08:13
gibimaybe update-delete-on-termination-for-attached-volume08:16
brinzhang_gibi: I think dansmith's mean is mainly to say separate the update and swap volume policies08:17
brinzhang_In https://review.opendev.org/#/c/693828/21, we are already have a releasenote fot this change08:18
*** yaawang has quit IRC08:23
gibiahh08:24
*** yaawang has joined #openstack-nova08:25
brinzhang_how about separate-upodate-and-swap-volume-policy-for-attachment ?08:25
gibisounds go (except s/upodate/update/)08:26
brinzhang_ok, I will create it.08:26
*** threestrands has quit IRC08:26
gibithanks08:28
brinzhang_gibi: thanks too.08:28
*** zhanglong has quit IRC08:33
openstackgerritBrin Zhang proposed openstack/nova master: Allow PUT volume attachments API to modify delete_on_termination  https://review.opendev.org/69382808:34
openstackgerritBrin Zhang proposed openstack/nova master: Separate update and swap volume policies  https://review.opendev.org/71119408:34
*** martinkennelly has joined #openstack-nova08:37
brinzhang_damsmith, gmann, gibi: updated the bp/destroy-instance-with-datavolume patch, and there is a question asked by gmann https://review.opendev.org/#/c/693828/21/nova/api/openstack/compute/volumes.py@475, wait dansmith to check, if need to change, that you can update that change to the latest pach08:38
*** avolkov has joined #openstack-nova08:39
*** jangutter has joined #openstack-nova08:41
*** hrw has left #openstack-nova08:41
*** jangutter has quit IRC08:41
*** derekh has joined #openstack-nova08:42
*** jangutter has joined #openstack-nova08:42
*** Luzi has joined #openstack-nova08:44
*** zhanglong has joined #openstack-nova08:48
*** ociuhandu has quit IRC08:49
*** ociuhandu has joined #openstack-nova08:50
*** lpetrut has joined #openstack-nova08:53
*** rcernin has quit IRC08:54
*** priteau has joined #openstack-nova08:59
*** dtantsur|afk is now known as dtantsur09:00
gibibrinzhang_: ack09:04
gibiI'm reviewing the patch now09:04
brinzhang_gibi: cool, thanks~09:06
*** LiangFang has quit IRC09:16
openstackgerritLuyao Zhong proposed openstack/nova master: partial support for live migration with specific resources  https://review.opendev.org/71536209:21
openstackgerritLuyao Zhong proposed openstack/nova master: support live migration with vpmem  https://review.opendev.org/68785609:21
*** zhanglong has quit IRC09:21
*** zhanglong has joined #openstack-nova09:22
luyaostephenfin: Hi, stephenfin , thanks for reviewing the first patch,  I hope the second patch for vpmem live migration also looks good to you. :) https://review.opendev.org/#/c/68785609:23
*** sapd1_y has joined #openstack-nova09:25
luyaostephenfin: I haven'ted add release notes for the notification body change in patch https://review.opendev.org/#/c/715362/, if it's better to have I'll add. Thanks for gibi's comments. :)09:26
gibiluyao: don't worry about that I think we never did reno for such change09:27
luyaogibi: OK, get it. :)09:27
*** sapd1 has quit IRC09:28
*** sapd1 has joined #openstack-nova09:31
*** sapd1_y has quit IRC09:33
*** priteau has quit IRC09:41
*** sapd1_y has joined #openstack-nova09:41
*** sapd1 has quit IRC09:43
*** zhanglong has quit IRC09:45
*** ociuhandu has quit IRC09:46
*** sapd1 has joined #openstack-nova09:47
*** sapd1_y has quit IRC09:48
*** tetsuro has quit IRC09:50
openstackgerritStephen Finucane proposed openstack/nova master: api: Add microversion 2.85, extra spec validation  https://review.opendev.org/70843609:53
openstackgerritStephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs  https://review.opendev.org/71003709:53
openstackgerritStephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs  https://review.opendev.org/71622209:53
*** ociuhandu has joined #openstack-nova09:58
*** rcernin has joined #openstack-nova09:59
*** tesseract has quit IRC10:03
openstackgerritStephen Finucane proposed openstack/os-vif master: trivial: Remove some rules from flake8 ignore list  https://review.opendev.org/71622310:07
*** ccamacho has joined #openstack-nova10:07
*** tesseract has joined #openstack-nova10:08
*** yaawang has quit IRC10:08
nightmare_unrealhow to deal with this error msg :  This test uses methods that set internal oslo_db state, but it does not claim to use the database. This will conflict with the setup of tests that do use the database and cause failures later.10:08
openstackgerritMerged openstack/nova-specs master: Update hacking for Python3  https://review.opendev.org/71565010:08
*** ociuhandu has quit IRC10:09
*** yaawang has joined #openstack-nova10:09
*** ociuhandu has joined #openstack-nova10:10
*** rcernin has quit IRC10:14
*** ociuhandu has quit IRC10:14
*** ociuhandu has joined #openstack-nova10:14
openstackgerritAndreas Jaeger proposed openstack/python-novaclient master: Update to hacking 3.0  https://review.opendev.org/71622810:20
openstackgerritjayaditya gupta proposed openstack/nova master: Support for nova-manage placement heal_allocations --cell  https://review.opendev.org/71445910:22
*** haleyb has quit IRC10:25
*** amoralej|off has quit IRC10:36
*** rnoriega_ has quit IRC10:36
*** zzzeek has quit IRC10:44
*** zzzeek has joined #openstack-nova10:45
*** rnoriega_ has joined #openstack-nova10:51
*** rpittau is now known as rpittau|bbl11:05
openstackgerritjayaditya gupta proposed openstack/nova master: Support for nova-manage placement heal_allocations --cell  https://review.opendev.org/71445911:06
openstackgerritMerged openstack/nova master: Add new default roles in os-agents policies  https://review.opendev.org/70164811:11
bauzasgibi: stephenfin: when you're around, i have a question about a reshape11:27
*** sapd1_y has joined #openstack-nova11:28
bauzasgibi: stephenfin: context is -1 for a reshape https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackcdn.com/715489/1/check/nova-tox-functional-py36/481510f/testr_results.html11:30
*** sapd1 has quit IRC11:30
bauzasbut I removed the support11:30
*** jangutter has quit IRC11:34
*** psachin has quit IRC11:35
gibibauzas: ack. I'm on a meeting. Will ping you after11:35
bauzascool thanks11:35
*** psachin has joined #openstack-nova11:36
bauzasgibi: stephenfin tl;dr: it's about deleting some upgrade support for Rocky>Stein in https://review.opendev.org/#/c/715489/1/nova/virt/libvirt/driver.py@7008a11:37
bauzasbut the reshape functional test won't support it then11:37
*** sapd1 has joined #openstack-nova11:45
gibibrinzhang_, dansmith: the notification sample test failure shows a relevant problem in the new implementation https://review.opendev.org/#/c/69382811:45
*** sapd1_y has quit IRC11:48
*** rnoriega_ has quit IRC11:50
brinzhang_gibi: the serverId is in the request path https://review.opendev.org/#/c/693828/22/nova/api/openstack/compute/schemas/volumes.py@10011:52
brinzhang_but what is 'id'?11:53
gibiI think id is the attachment id11:53
*** psachin has quit IRC11:53
brinzhang_ PUT /servers/{server_id}/os-volume_attachments/{volume_id}11:54
brinzhang_gibi: I am not sure the id and serverId does need to add the request body, looks like we dont need that while we update an attachment11:55
*** psachin has joined #openstack-nova11:55
kevinzgibi: can you take a look at this https://review.opendev.org/#/c/714311/ and https://review.opendev.org/712607, those two already get one +211:55
kevinzThanks11:55
gibibrinzhang_: it is about how we define RESTFull11:58
gibibrinzhang_: if we want that the GET response can be sent back as PUT request then we need that the GET rsp matches with the PUT req11:59
*** ralonsoh has quit IRC11:59
*** ralonsoh has joined #openstack-nova12:00
gibikevinz: ack, I will try12:00
kevinzgibi: Thanks ~12:00
gibibauzas: so you think there is a fault in the functional test test_create_servers_with_vgpu ?12:02
bauzasgibi: not really12:02
bauzasgibi: tbc we supported a reshape for Stein12:02
bauzasfor Rocky>Stein12:02
bauzasnow, we're in Ussuri12:02
brinzhang_gibi: yeah, as you think it's should keep the same, but we add the tag, device, because swap volume need these parameters, so we should add them in the reqeust body, if we are just update the delete flag for the attachemt, these are invalid, do we need to add these check, such as attachment_id and serverId cannot be changed12:02
bauzasgibi: so I can remove the upgrade support that we created12:03
bauzasgibi: but then, of course the reshape method won't longer work12:03
bauzasgibi: so I should probably remove it too, right? (and the tests)12:03
bauzasbut then I think about FFU12:03
brinzhang_gibi: so form this side, I think they are redundant to add the PUT request body, maybe dansmith have some idea of this.12:04
gibibrinzhang_: let's ask dansmith how serious he want the two json body to match12:04
*** ociuhandu has quit IRC12:04
gibibauzas: yeah FFU support is a question12:04
*** ociuhandu has joined #openstack-nova12:04
*** zzzeek has quit IRC12:05
*** zzzeek has joined #openstack-nova12:06
gibibauzas: if we can say that we dont support FFU between Rocky - Ussuri then we can remove the reshape code12:06
bauzasgibi: ... or I would just leave the upgrade support until we agree on that12:07
bauzasgibi: but do we have already some consensus about those kind of questions ?12:07
gibibauzas: yeah, I think we had the agreement in the past that we keep reshape support for a while12:07
bauzasam I the first folk asking about it ?12:07
gibibauzas: I think we don't have12:07
openstackgerritHuaqiang Wang proposed openstack/nova master: tox: Integrate mypy  https://review.opendev.org/67620812:07
gibior at least I dont rememer12:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Update and correct typing information  https://review.opendev.org/71469412:07
openstackgerritHuaqiang Wang proposed openstack/nova master: libvirt: Add typing information  https://review.opendev.org/71469512:07
bauzashum12:07
openstackgerritHuaqiang Wang proposed openstack/nova master: tests: Split instance NUMA object tests  https://review.opendev.org/71469612:07
openstackgerritHuaqiang Wang proposed openstack/nova master: objects: Replace 'cpu_pinning_requested' helper  https://review.opendev.org/71469712:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Don't consider overhead CPUs for unpinned instances  https://review.opendev.org/71469812:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Remove handling of pre-Train compute nodes  https://review.opendev.org/71469912:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Add validation for 'cpu_realtime_mask'  https://review.opendev.org/46820312:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Tweak the 'cpu_realtime_mask' handling slightly  https://review.opendev.org/46145612:07
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Rework 'get_realtime_constraint'  https://review.opendev.org/71470012:08
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Invert order of NUMA topology generation  https://review.opendev.org/71470112:08
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Remove '_numa_fit_instance_cell_with_pinning'  https://review.opendev.org/71470312:08
openstackgerritHuaqiang Wang proposed openstack/nova master: Introduce 'pcpuset' field for InstanceNUMACell  https://review.opendev.org/71465812:08
openstackgerritHuaqiang Wang proposed openstack/nova master: hardware: Add support for 'hw:cpu_dedicated_mask' extra spec  https://review.opendev.org/71470612:08
openstackgerritHuaqiang Wang proposed openstack/nova master: libvirt: set host CPUs for the mixed instance  https://review.opendev.org/71465512:08
openstackgerritHuaqiang Wang proposed openstack/nova master: Setup 'mixed' instance through 'PCPU' and 'VCPU' resource  https://review.opendev.org/71335512:08
openstackgerritHuaqiang Wang proposed openstack/nova master: metadata: export the vCPU IDs that are pinning on the host CPUs  https://review.opendev.org/68893612:08
openstackgerritHuaqiang Wang proposed openstack/nova master: Introduce the 'CPUAllocationPolicy.MIXED' enum  https://review.opendev.org/71626712:08
*** rnoriega_ has joined #openstack-nova12:08
gibibauzas: I think it is worth to ask the others how they think about it12:08
bauzasgibi: I think we would need to have some policy about it12:08
gibiyeah12:08
bauzasgibi: because before FFU, it was simple12:08
gibiI can imagine that the default policy is not to remove reshape, eer12:08
gibiever12:09
bauzasgibi: we were just removing upgrade support after one release12:09
bauzasgibi: but now, I no longer know when we should do it12:09
*** jangutter has joined #openstack-nova12:09
bauzasgibi: and like you say, some operators could tell us to just support reshapes for a whole12:09
bauzasif so, uhu12:10
*** ociuhandu has quit IRC12:10
brinzhang_gibi: http://paste.openstack.org/show/791394/ https://review.opendev.org/#/c/693828/22/nova/tests/functional/api_sample_tests/test_volumes.py@30512:13
brinzhang_I debuged in  http://paste.openstack.org/show/791394/12:13
*** slaweq has quit IRC12:14
*** jangutter has quit IRC12:14
*** slaweq_ has joined #openstack-nova12:14
*** rpittau|bbl is now known as rpittau12:15
gibibrinzhang_: what do you mean?12:16
gibiI simply removed the sub and the test still passed.12:17
gibiso the sub is unused12:17
brinzhang_gibi: yes, it unused12:17
*** artom has joined #openstack-nova12:17
*** artom has quit IRC12:18
brinzhang_gibi: gibi: when the data volume attached to the server, the delete_on_termination will be set to False by default https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py:_attach_volume()12:18
*** artom has joined #openstack-nova12:18
*** mkrai has quit IRC12:18
brinzhang_gibi: I think that's why the sub['delete_on_termination'] is unused reason12:19
brinzhang_https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py#L450512:20
gibibrinzhang_: I think the sub is not used as it is not referred in the template update-volume-attachment-delete-flag-req12:22
gibinova/tests/functional/api_sample_tests/api_samples/os-volumes/v2.85/update-volume-attachment-delete-flag-req.json.tpl12:23
brinzhang_gibi: you mean we can change ""delete_on_termination": true" to ""delete_on_termination": %(delete_on_termination)s" to resolve this issue?12:25
gibiif you replace the "delete_on_termination": true with "delete_on_termination": "%(delete_on_termination)s"12:25
gibithen the subs will be applied12:25
brinzhang_yeah, I will try12:26
brinzhang_gibi: it's true, thanks for you explain ^^12:27
openstackgerritMaciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network  https://review.opendev.org/71627512:29
openstackgerritMaciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network  https://review.opendev.org/71627512:30
gibibauzas: I only found two mentions in the nova doc about FFU12:30
bauzasgibi: I'm writing a ML thread FWIW12:31
gibi$ egrep -e "fast forward|FFU" -R doc/12:31
gibidoc/source/user/cells.rst:   be a gap for other deployment tools. Consider also the FFU case12:31
gibidoc/source/reference/upgrade-checks.rst:   fast forward upgrading from Ocata to Rocky, something could have been12:32
gibibauzas: yeah thanks.12:32
gibibauzas: one way to remove reshape is to add an upgrade check12:33
bauzasgibi: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013709.html12:35
johnthetubaguyare we not meant to be able to FFU between *any* release, like gibi said, we are probably just missing an upgrade check12:37
bauzasgibi: mmm, that'd make sense12:37
openstackgerritMaciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network  https://review.opendev.org/71627512:38
johnthetubaguybauzas: can your code be activated without any nova services running?12:38
*** udesale_ has joined #openstack-nova12:38
bauzasgibi: but since reshapes are made automatically when you restart nova-compute in Stein or later, that doesn't need an operator modification12:38
bauzasjohnthetubaguy: nope, you need to restart nova-compute, that's the main concern12:39
johnthetubaguybauzas: in which case we can't remove that code until we have one12:39
johnthetubaguywhen we then enforce to be run via an upgrade check12:39
gibibauzas: we need to make sure that all the compute was started up one during FFU _before_ Ussuri12:39
johnthetubaguythen following release we can drop the code12:39
bauzasand I think we started discussing on this kind of problem, but we haven't had an agreement *yet*12:39
gibiyeah, I don't find any agreement12:40
gibibut the above upgrade check based solution could be a good proposal12:40
bauzasjohnthetubaguy: the problem I have with this direction is that usually we write an upgrade check for asking operators to do *something* before upgrading12:40
bauzasjohnthetubaguy: in this specific case, what would it be ? restart n-cpu?12:40
johnthetubaguybauzas: we need to give the operators a way to do something though, we *cannot* requite nova-compute to be started12:40
johnthetubaguys/requite/require/12:41
*** udesale has quit IRC12:41
johnthetubaguyat least that was my understanding of the situation12:41
bauzasjohnthetubaguy: well, I think we drafted this discussion somewhere sometimes in a PTG and we said it should be a separate module that would be run off nova services12:41
bauzasit, being the reshape codes (with a trailing s, please note)12:42
bauzasbut we honestly never designed it12:42
sean-k-mooneyjohnthetubaguy: requireing n-cpu to be started breaks ffu12:42
johnthetubaguyI was fairly sure it had to be nova-manage, possibly running on each compute node... but yeah I guess we didn't12:42
johnthetubaguysean-k-mooney: exactly what I am saying, +112:42
sean-k-mooneybut only if we remove the code before x releases12:42
bauzasand i don't disagree with it12:42
sean-k-mooneye.g. we have to keep the reshape and code for ~3 release if we require you to start the agent12:43
bauzasbut given we never thought more about that, we never agreed on *when* and *how* to remove such reshape codes12:43
johnthetubaguyI guess we can't remove the code till we design a way to get rid of it12:43
bauzasagreed12:43
johnthetubaguycool12:44
sean-k-mooneyi think osa and ooo are the only tools that do ffu12:44
*** jangutter has joined #openstack-nova12:44
sean-k-mooneyand i think both only support 3 releases max so at most we should need to keep it for 3 releases12:44
johnthetubaguyI kinda got the impression the packages folks were going to adopt it at some point12:44
*** zzzeek has quit IRC12:44
sean-k-mooneyffu12:44
bauzassean-k-mooney: the problem is that we need to leave this code for 5 releases then12:44
johnthetubaguyyeah12:45
sean-k-mooneyhonestly i thnk ffu was a mistake to begin with and we should have followed kolla anisbles lead and gone with rolling upgrades12:45
*** ociuhandu has joined #openstack-nova12:45
bauzasie. we can assume that people could FFU from Train to Victoria or W12:45
*** zzzeek has joined #openstack-nova12:45
bauzasactually, it's a bad example, nevermind12:45
sean-k-mooneyfor me ffu was a fairly major design mistake12:45
bauzasthe worst case scenario is in my case : upgrade from Rocky to Ussuri12:46
johnthetubaguyI think for FFU we basically have to say *any* to *any*, else its pointless12:46
johnthetubaguywell, that or we only care about osa/ooo12:46
bauzasso, at least in my case, Ussuri *has to* support FFU12:46
johnthetubaguybauzas: are you saying punt the conversation to the PTG?12:47
bauzasI mean, only if we agree on a 3-release time window as a maximum12:47
bauzasjohnthetubaguy: I'm saying I'm shooting myself in the foot, yes12:47
* gibi needs on a meeting again12:47
johnthetubaguyheh, I was just checking ;)12:47
* gibi needs to be on a meeting again12:47
sean-k-mooneyjohnthetubaguy: redhat is moving ore ffu cycle to 2 release by the way12:47
bauzasjohnthetubaguy: I have concerns about how the virtual PTG would be productive, but let's be it12:48
*** jangutter has quit IRC12:48
johnthetubaguyit depends how much work folks do ahead of time, it *can* work well, seen that in kolla12:48
* bauzas always has to manage his productivity with 2 kids at home and schools closed12:48
sean-k-mooneyso every second release will be an LTS and the plan is to ffu between those, although that plan could change. the first case of this will be train to victorica12:48
ebbexI'm having issues with live-migration on stable/stein, at first neutron was complaining about port_id existing on the target (even though status was inactive), so I removed the port_id in neutron.ml2_port_binding{s,_levels}. Now when trying to migrate I got this stack-trace; http://paste.openstack.org/show/791395/ and a vm_state error. Which databases and tables should I look at to fix this?12:49
bauzassean-k-mooney: the whole point of FFU is that we don't have *LTS* releases12:49
bauzasevery release can be seen as a LTS one12:49
sean-k-mooneybauzas: FFU encurages them12:49
bauzasno12:49
sean-k-mooneyyes12:49
sean-k-mooneythat is why we have so many people on osp 10 and 1312:49
bauzasevery single user of FFU can just promote any release as an LTS12:50
sean-k-mooneyit makes upgrading harder at least with ooo12:50
bauzassure, for redhat, but what about other FFU users  ?12:50
sean-k-mooneyits mainly just redhat12:50
sean-k-mooneyosa support it12:50
bauzaswe provided the tools for this, we can't just say 'heh, it's just redhat'12:50
bauzashah, jinxed12:50
sean-k-mooneybut they can do better upgrades without it12:51
johnthetubaguyI like to think windows 10 adopted the same approach as kolla-ansible (although clearly factually incorrect)12:51
bauzasI just think we entered a rabbit hole12:51
bauzashonestly, we have to be pragmatic and solve the problem that johnthetubaguy stated : n-cpu restart shouldn't be a prereq12:52
bauzasthat's it12:52
sean-k-mooneyif we dont cap the limit on ffu we can never remove reshape code which i dont think is a resonable constratint12:52
bauzasthen we can argue on the tooling we would make12:52
johnthetubaguythe question to ooo and osa, is runing a nova-manage command on every compute node a big deal or not12:52
bauzassean-k-mooney: if reshape code isn't tied to a specific nova module, I'm fine with it12:52
johnthetubaguybauzas: does reshape need details from the compute node?12:53
johnthetubaguyI was assuming it does12:53
gibibauzas: is it expensive to keep the reshape code?12:53
sean-k-mooneyjohnthetubaguy: in general yes12:53
bauzasjohnthetubaguy: you know what ? when we started to draft it, I was even on a stance about a specific other library12:53
sean-k-mooneysomethimes that info will be stored in the db but not always12:53
johnthetubaguycould we make operators supply enough enough to not need that info?12:53
bauzasjohnthetubaguy: again, the problem is that we haven't designed the expected API between the compute  service and the reshape code12:53
sean-k-mooneyin the numa case im expecting most of the inf would be in the resouce track numa toplogy blob so it might not need to have acess to the compute node but that depends on if we remove the info form the db or not12:54
johnthetubaguy+1 gibi's question12:54
bauzasI personnally wrote my own reshape code by writing some hard dependencies12:54
bauzas(IIRC, it's even requiring libvirtd to run)12:54
johnthetubaguysounds like we could write something that we backport to train that fixes this on the api node12:55
sean-k-mooneyjohnthetubaguy: for the vgpus no12:55
johnthetubaguywell, then we need that info from the operator12:55
sean-k-mooneyjohnthetubaguy: we dont track those in the db12:55
bauzasI  need to look at the reshape spaghetti code for the vgpus12:55
bauzasand see what assumptions I made12:55
johnthetubaguyand we would need something from placement, as its API will not be up?12:56
bauzasjohnthetubaguy: we *at least* need placement-api to be up and running12:56
johnthetubaguynot allowed12:56
bauzasyeah I know12:56
johnthetubaguywould need placement-manage to take something12:56
bauzasbut that's what we merged12:56
johnthetubaguyyep yep12:57
johnthetubaguywe merged something that violates the rules for FFU12:57
bauzascorrect12:57
bauzaswell, technically, you need to start n-cpu and placement in Stein12:57
bauzaswhen you FFU from Rocky to Train12:57
bauzasthat's the prereq12:57
*** ociuhandu has quit IRC12:58
*** jangutter has joined #openstack-nova12:58
*** jangutter has quit IRC12:58
bauzas(but honestly, since Ussuri works, you can FFU to Ussuri and do the reshape then)12:58
*** dklyle has joined #openstack-nova12:58
johnthetubaguysounds like we keep it till at least Z12:58
*** ociuhandu has joined #openstack-nova12:58
bauzasoh yeagh12:58
*** jangutter has joined #openstack-nova12:58
bauzasor we write something to fix that in V12:59
sean-k-mooneyi know that ffu in k8s land or rather openshift has stopper versions12:59
bauzasor W12:59
johnthetubaguysounds like we have better things to do12:59
sean-k-mooneye.g. you can fast forwared but they publish a list of verions you must stop at and start the kublet before continuing12:59
johnthetubaguysean-k-mooney: they also break their public API most releases12:59
sean-k-mooneythat is basically what we  have12:59
bauzasthe problem is that this little assumption that we could be in non-nested world makes my life on feature development much harder12:59
bauzaswhich is something I can expose to my management13:00
sean-k-mooneyjohnthetubaguy: well its technically versioned so you can use the older version but yes13:00
bauzasand say that we need to work on a solution in V or W13:00
johnthetubaguysean-k-mooney: till they remove it, yep13:00
johnthetubaguynot saying its bad, just different13:00
johnthetubaguythey have a different context13:00
johnthetubaguysounds like if we wait a few more releases, it will sort its-self out one way or the other13:01
sean-k-mooneyyes and no, they have a different approch. we have similar but not idential scopes. they do applciation lifecyle management better and openstack is better sutied to infrastuture13:01
johnthetubaguylike gibi said, maybe the cost isn't that high13:01
johnthetubaguysean-k-mooney: agreed13:02
*** nweinber has joined #openstack-nova13:02
johnthetubaguypersonally, running something on every compute node sounds a lot like starting up n-cpu13:02
johnthetubaguyso really we just shouldn't do that kind of thing13:02
sean-k-mooneywell if your calling if FFU13:03
sean-k-mooneyi like how kolla-ansible does there upgrades13:03
johnthetubaguyso we need some comprimise where the easy thing (just reshape after upgrade) works for most folks, and the last few folks have some workaround (supply info about the shape of their hosts to some nova-manage)13:03
johnthetubaguybut that's just my take13:03
*** ociuhandu has quit IRC13:04
bauzasgibi: I know you're on a meeting, but do we already have an etherpad for the virtual Victoria PTG ?13:04
gibibauzas: yes, https://etherpad.openstack.org/p/nova-victoria-ptg13:04
*** ociuhandu has joined #openstack-nova13:04
bauzasthanks13:04
sean-k-mooneygibi: one thing i think we need to plan for are some cross project sessions too13:04
gibisean-k-mooney: true. Do you have topic for cross-project discussion?13:05
sean-k-mooneynot specifcally but i was concerned that that topic had not come up13:05
gibisean-k-mooney: I think you can simply add that to the current etherpad (just start a new section that indicate that this is a cross project topic that needs anohter team)13:05
gibiyou mean people are not thinking about cross project topics because there is no place to put them?13:06
sean-k-mooneyther are things like the unified limits work johnthetubaguy et al are working on that i think needs to continue but i did not really have anything i wanted to drive13:06
sean-k-mooneygibi: i think when we talk about a virtual ptg many teams are just thinking about there team, not the collabative cross team stuff we also do at the ptg13:07
gibisean-k-mooney: OK, I hope the affected people will propose topics13:07
bauzasthat reminds me I have to provide my toughts on two ML threads from gibi13:07
gibisean-k-mooney: added a Cross project topics section13:10
sean-k-mooneygibi: one topic that comes to mind actully is the schduling supprot for routed networks13:11
sean-k-mooneyor network aware schduling in general13:11
*** slaweq_ is now known as slaweq13:11
sean-k-mooneythat said im not sure i plan to work on that in the near term so im not going to add it13:11
sean-k-mooneybut i know the neuton team are interested in that topic13:12
gibisean-k-mooney: ack,  that is actually one thing I can add as I started looking at that from nova perspective13:13
gibisean-k-mooney: added one item for routed nets13:15
*** ociuhandu has quit IRC13:15
*** ratailor has quit IRC13:15
*** ociuhandu has joined #openstack-nova13:16
sean-k-mooneygibi: cool, i kind of wrote up how i think it should work in the comment on matts poc13:16
sean-k-mooneybut that was more involed then the minium viable change13:16
gibisean-k-mooney: if you have input then do not hesitate to write it up, I kept that patch on the minimum viable change level but we can agree to do a bigger change in V13:17
gibisean-k-mooney: my idea was that the current minimum viable patch does not need neutron change13:18
sean-k-mooneyunless you are doing sriov nova just assumes that the destination host will be able to support the networking that is requested. this has always been the case and has worked because for the most part ops make there vxlan and vlans span the datacenter but it has never really been a correct assumtion to make.13:18
johnthetubaguyrouted networks make the opposite assumption, you usually don't get to pick the IP until you know where has compute resources (unless you are re-using a port, when there are other issues in play).13:19
sean-k-mooneyjohnthetubaguy: correct and nova currently is not aware of those constraints13:20
sean-k-mooneywhich is why live migration basially does not work unless you spcify a host in the same segment13:20
johnthetubaguyyeah, only does a safety check13:20
*** ociuhandu has quit IRC13:21
sean-k-mooneymy toughts on the topic are partly summerised in https://review.opendev.org/#/c/656885/ in my top comment on 25 of feb13:21
johnthetubaguylive-migration scheduling is an interesting one... I don't really see a use case for it, but I hey.13:21
sean-k-mooneyjohnthetubaguy: you dont see a usecase for allowing live migration to move the vm to another host in the same network segment where it can keep its ip13:22
*** rnoriega_ has quit IRC13:22
johnthetubaguyoperationally, for our customers, its super rare you want it "to go somewhere the scheduler picks", sure we can make up cases where its needed13:23
sean-k-mooneywell that is the oppisite feedback we are geting from the neutron folks13:23
johnthetubaguyI think there is a bigger issue there, you want to define live-migratable pools, etc, etc.13:24
johnthetubaguywell I look forward to better understanding those folks use cases13:24
sean-k-mooneyjohnthetubaguy: yes i tired to adress the more generic case to include vlan awarenes and ip pools modeled in placment in my comment13:25
sean-k-mooneybasically using placment aggreates to model pool affinity with sharing resouce providers modelign ip capsity,vlan/vxlan ids(as segmenation_ids) ectra and traits modeling the type of network13:26
johnthetubaguyI still think folks most likely want host aggregate style live-migratable "zones", etc13:27
*** brinzhang has joined #openstack-nova13:28
sean-k-mooneywell peole used to use AZs for that to take advandgte of the fact we dont migrate across AZs by defualt13:29
gibijohnthetubaguy, sean-k-mooney: It would be good to get feedback on the use cases I collected as functional tests https://review.opendev.org/#/c/656885/7/nova/tests/functional/test_servers.py and https://review.opendev.org/#/c/711071/1/nova/tests/functional/test_servers.py13:30
sean-k-mooneyjohnthetubaguy: but that is essically what you would get, the vm would migrate withing the placmenet aggreate with the current poc13:30
*** brinzhang_ has quit IRC13:31
sean-k-mooneye.g. the placment aggreate created by neutron that mapes to the ip segment13:31
johnthetubaguysean-k-mooney: targeting a placement aggregate rather than a host, with some way of defaulting to the "current" live-migration tagged placement aggregate, would be crazy useful, but its not just network concerns13:32
*** rnoriega_ has joined #openstack-nova13:32
*** ociuhandu has joined #openstack-nova13:32
johnthetubaguyI have a bunch of use cases around that area, but often its independent of xvlan reach, etc.13:33
*** macz_ has joined #openstack-nova13:38
*** zzzeek has quit IRC13:38
*** pooja_pf9 has joined #openstack-nova13:38
pooja_pf9Hello.. has anyone run into this os-brick issue with multipath failure reported in https://bugs.launchpad.net/nova/+bug/1414527?13:39
openstackLaunchpad bug 1414527 in OpenStack Compute (nova) "The multipath device descriptors remove failed when the volume has partition" [Undecided,Confirmed]13:39
*** zzzeek has joined #openstack-nova13:39
pooja_pf9Is there any known workaround for this issue or plan to fix it in nova?13:40
*** macz_ has quit IRC13:42
*** Luzi has quit IRC13:54
huaqiangstephenfin: my new patches are based on your patches, I haven't changed most of them, but my operations changed the commit hash for most of your pathes,13:54
huaqianghope it will not trouble you13:55
*** bnemec has quit IRC14:00
*** lpetrut has quit IRC14:01
*** lpetrut has joined #openstack-nova14:08
sean-k-mooneyjohnthetubaguy: yes it also matters for storage/cinder az and well jsut general falut domains although you can model that via host aggregates14:12
* johnthetubaguy nods14:12
dansmithbrinzhang: are you addressing feedback on that patch?14:12
*** mkrai has joined #openstack-nova14:13
sean-k-mooneyjohnthetubaguy: what i wanted to do was build on the resouce requests in the neutron port and have neutron pass traits and aggreates as constratins via the same mechanisum14:13
*** haleyb has joined #openstack-nova14:14
*** bnemec has joined #openstack-nova14:16
johnthetubaguysean-k-mooney: sure, it just seems boring compared to the wider use cases14:17
artomAnyone seens https://zuul.opendev.org/t/openstack/build/e0e47deeb33b476db792fd8b83680fbb before?14:18
artomWarning: Permanently added '198.72.124.121' (ECDSA) to the list of known hosts.14:18
artomrsync: link_stat "/var/lib/zuul/builds/e0e47deeb33b476db792fd8b83680fbb/work/ca-bundle.pem" failed: No such file or directory (2)14:18
artomrsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]14:18
artomAsking here because... not really sure where Zuul job questions belong14:18
artomI guess I'm doing something wrong in my .zuul.yml14:19
*** mriedem has joined #openstack-nova14:20
*** bnemec has quit IRC14:22
sean-k-mooneyno i dont think that is related to your job14:22
sean-k-mooneyi think its an issue win one of the other playbooks14:22
*** dave-mccowan has quit IRC14:23
*** ociuhandu has quit IRC14:24
*** ociuhandu has joined #openstack-nova14:26
*** zzzeek has quit IRC14:28
*** ociuhandu has quit IRC14:31
*** dave-mccowan has joined #openstack-nova14:31
*** zzzeek has joined #openstack-nova14:32
*** ociuhandu has joined #openstack-nova14:35
*** tetsuro has joined #openstack-nova14:36
artomsean-k-mooney, inorite?14:39
artomExcept it's consistently reproducible14:39
*** tetsuro has quit IRC14:40
*** sapd1_y has joined #openstack-nova14:43
*** tkajinam has quit IRC14:45
*** sapd1 has quit IRC14:45
*** spatel has joined #openstack-nova14:49
spatelsean-k-mooney: is it possible that SR-IOV support security group? (i did google and didn't find any vendor who provide that card/nic)14:51
openstackgerritMerged openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls.  https://review.opendev.org/70422714:54
openstackgerritCorey Bryant proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages  https://review.opendev.org/71632814:54
sean-k-mooneythe nics dont in generally but you can sometimes use a heriachical port binding driver to implement security groups at the top of rack switch14:54
sean-k-mooneyif your using hardware offloade ovs which use ovs as the contol plane and sriov as the dataplane then it can technically do security groups14:55
sean-k-mooneybut normally if you use sriov then no14:55
spatelsean-k-mooney: thanks for the explanation :)14:58
*** lbragstad_ has joined #openstack-nova15:02
*** lbragstad has quit IRC15:03
*** macz_ has joined #openstack-nova15:03
*** dave-mccowan has quit IRC15:04
*** pooja_pf9 has quit IRC15:06
openstackgerritMerged openstack/python-novaclient master: Update to hacking 3.0  https://review.opendev.org/71622815:12
gibisean-k-mooney: do you happen to know if we support booting with UEFI + PXE over IPv6?15:14
sean-k-mooneyin ironic?15:14
*** spatel has quit IRC15:14
gibiin nova + libvirt + qemu kvm15:15
sean-k-mooneygibi: i dont think we support pxe boot in nova15:15
sean-k-mooneygibi: i know we can enable the boot menu but i dont think we support pxe booting officaly15:15
gibithanks15:16
*** vishalmanchanda has quit IRC15:18
*** spatel has joined #openstack-nova15:22
*** maciejjozefczyk has quit IRC15:36
*** tesseract has quit IRC15:37
openstackgerritStephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs  https://review.opendev.org/71622215:38
openstackgerritStephen Finucane proposed openstack/nova master: api: Add microversion 2.85, extra spec validation  https://review.opendev.org/70843615:38
openstackgerritStephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs  https://review.opendev.org/71003715:38
*** vishalmanchanda has joined #openstack-nova15:41
*** avolkov has quit IRC15:49
*** nweinber has quit IRC15:51
*** nweinber has joined #openstack-nova15:54
*** udesale_ has quit IRC16:01
*** rpittau is now known as rpittau|afk16:07
*** jangutter has quit IRC16:08
*** dtantsur is now known as dtantsur|afk16:08
dansmithgibi: around?16:10
gibidansmith: yes16:11
dansmithgibi: "doh" and "duh" on the rpc cast, thanks for that16:11
*** bnemec has joined #openstack-nova16:11
dansmithgibi: what do you want to do about it? we can move the non-swap parameter updates before the swap16:12
dansmithwhich means we'll update those values and then if the swap fails, we will have made part of the changes but not all, but given how swap works, there isn't much choice16:12
gibihm hm16:14
gibiif changing the order does not mean that we update the d-o-t on the old volume attachment the swap that with a new attachement with default d-o-t then I'm OK with it16:15
dansmithor go back to what I had, which was swap or d-o-t, but not both, although I definitely get the argument that you'd expect to be able to update all at once16:15
dansmithgibi: I think because it looks up the BDM and updates it with the new volume that it should be fine16:15
*** eharney has quit IRC16:15
gibiOK, then I suggest to do the reordeing. If swap fails then we need to accept a partial PUT16:16
gibias swap is async16:16
dansmithack16:16
dansmithgibi: by the way, on your comment about the notification test,16:16
dansmithwhen enabling debug, I did not see the compute manager code logging the messages that should have come out16:17
dansmithso I'm not sure the compute manager code is really running, even though that *seems* to be where the finish notification comes from16:17
gibiwith 2.85 you don't as the whole test failed before the compute had a chance to progress with the message16:17
dansmithbut I ran out of time trying to trace that down and the logs weren't coming..16:18
dansmithahh, that makes sense16:18
gibiyeah, it was not a trivial thing. I spent at least an hour figuring it out why it behaves differently16:18
dansmiththe notification stuff is too confusing in general so I didn't trust myself16:18
dansmithand with no logs from compute manager... I tried putting castascall on there, butI got many more errors16:19
*** eharney has joined #openstack-nova16:19
dansmithgibi: can you check my reply here? https://review.opendev.org/#/c/693828/22/nova/api/openstack/compute/schemas/volumes.py16:19
gibilooking16:19
*** mlavalle has joined #openstack-nova16:20
gibidansmith: you copy the POST req schema, but that is different from the schema of the GET response16:21
gibiif we want that the client GET the current attachment, change a field in it, then PUT it back, then PUT needs to accept the format of the GET response16:21
gibior did I missunderstood the intention here?16:22
dansmithlet me go look for an example of a get16:22
*** tobias-urdin has joined #openstack-nova16:22
dansmithare you saying because volumeAttachments[] vs volumeAttachment ?16:23
dansmith2.79 GET of a single attachment looks the same to me, no?16:23
gibiit has id in it16:24
dansmithhttps://docs.openstack.org/api-ref/compute/?expanded=update-server-detail,list-volume-attachments-for-an-instance-detail,show-a-detail-of-a-volume-attachment-detail#show-a-detail-of-a-volume-attachment16:24
*** lpetrut has quit IRC16:24
tobias-urdindoing upgrade testing after upgrade nova-compute throws a RuntimeError: maximum recursion depth exceeded while calling a Python object http://paste.openstack.org/show/791412/16:25
gibicrate only allows volumeId and device16:25
gibicreate16:25
dansmithah, okay gotcha16:25
tobias-urdinbased on traceback i've tried upgrading oslo.db 5.0.2 and oslo.concurrency 3.30.0 (and all other oslo for that matter) but it won't start16:25
gibiyou added tag and d-o-t16:25
dansmithI thought you were saying it was structurally quite different or something16:25
gibiI meant we have different amout of fields16:25
gibistructure seems to be the same16:26
dansmithokay I guess I missed serverId although I thought I had it in there16:26
gibijust GET returns extra fields which PUT does not allow16:26
dansmithyep, I see now16:26
*** mkrai has quit IRC16:26
gibiserverId and id (which is the attachment id based on the doc)16:27
gmanndansmith: gibi : should we allow tag update also in this - https://review.opendev.org/#/c/693828/21/nova/api/openstack/compute/volumes.py@47516:31
dansmithgmann: sorry I should have said something, but I looked into it and it requires an rpc call to update that, so I think we should punt16:32
gmanndansmith: ohk. it's not our DB only things. got it.16:33
dansmithyeah16:33
tobias-urdinanybody has an idea what could be causing the traceback? :) http://paste.openstack.org/show/791412/16:35
*** evrardjp has quit IRC16:36
* gibi leaves for today16:36
*** evrardjp has joined #openstack-nova16:36
*** psachin has quit IRC16:50
*** dustinc has joined #openstack-nova17:00
*** ryneq has quit IRC17:00
*** derekh has quit IRC17:02
openstackgerritStephen Finucane proposed openstack/nova master: Remove future imports  https://review.opendev.org/71467517:07
openstackgerritStephen Finucane proposed openstack/nova master: Use unittest.mock instead of third party mock  https://review.opendev.org/71467617:07
openstackgerritMerged openstack/os-vif master: Update hacking for Python3  https://review.opendev.org/71565117:26
*** links has quit IRC17:32
*** ociuhandu has quit IRC17:33
*** ociuhandu has joined #openstack-nova17:34
*** ociuhandu has quit IRC17:39
openstackgerritGhanshyam Mann proposed openstack/nova master: Introduce scope_types in lock server policy  https://review.opendev.org/71611417:44
sean-k-mooneystephenfin: didnt efried already sumbit a patch for https://review.opendev.org/#/c/714676/17:47
sean-k-mooneydid he abandon it?17:47
sean-k-mooneystephenfin: https://review.opendev.org/#/c/708262/17:49
sean-k-mooneystephenfin: it looks like you have fixed import ordering and some other minor thinks so i guess your patch is more complete but you should probably cherry-pick the hacking change ontop of your patch17:54
openstackgerritDan Smith proposed openstack/nova master: Allow PUT volume attachments API to modify delete_on_termination  https://review.opendev.org/69382818:00
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles in lock server policies  https://review.opendev.org/71612218:01
*** mgariepy has quit IRC18:15
*** brinzhang_ has joined #openstack-nova18:17
*** brinzhang has quit IRC18:20
*** mgariepy has joined #openstack-nova18:21
*** nightmare_unreal has quit IRC18:33
efriedstephenfin, sean-k-mooney: feel free to take over or abandon mine as needed.18:33
efriedbut yeah, the hacking change should be included in the series.18:33
*** mgariepy has quit IRC18:35
*** martinkennelly has quit IRC18:35
*** ralonsoh has quit IRC18:40
*** mgariepy has joined #openstack-nova18:48
*** d34dh0r53 has quit IRC18:56
openstackgerritCorey Bryant proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages  https://review.opendev.org/71632819:01
openstackgerritMarcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64  https://review.opendev.org/71442519:06
stephenfinsean-k-mooney: Ah, I'd forgotten about that. Will combine19:10
*** dustinc has quit IRC19:23
*** iurygregory has quit IRC19:27
*** vishalmanchanda has quit IRC19:28
*** luyao has quit IRC19:32
openstackgerritMerged openstack/nova master: [Community goal] Update contributor documentation  https://review.opendev.org/71242019:33
openstackgerritMerged openstack/nova master: Fix os-ips policy to be admin_or_owner  https://review.opendev.org/71549619:33
openstackgerritMerged openstack/nova master: Add test coverage of existing ips policies  https://review.opendev.org/71547719:34
openstackgerritMerged openstack/nova master: Introduce scope_types in os-ips  https://review.opendev.org/71552919:34
openstackgerritMerged openstack/nova master: Add new default roles in os-ips policies  https://review.opendev.org/71554519:34
openstackgerritMerged openstack/nova master: Pass the actual target in os-agents policy  https://review.opendev.org/70164920:03
*** ociuhandu has joined #openstack-nova20:12
*** ociuhandu has quit IRC20:18
*** mgariepy has quit IRC20:21
*** xek has quit IRC20:26
*** mgariepy has joined #openstack-nova20:34
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in unlock override policy  https://review.opendev.org/71642820:46
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576120:55
dansmithgmann: you around?20:55
dansmithowalsh has a question for you :)20:55
gmanndansmith: hi20:55
dansmithgmann: http://paste.openstack.org/show/kckeKCDgq679ixa2g5IK/20:55
dansmithgmann: when running nova-manage with an empty policies file20:56
owalshnova-manage cell_v2 discover_hosts --by-service if it matters20:56
dansmithowalsh: I gotta step away for a bit to get ready for something, but from poking around I feel like gmann is probably your mann :)20:58
owalshdansmith: ack, thanks20:58
gmann:)20:58
openstackgerritsean mooney proposed openstack/nova master: [WIP] cyborg evacuate support  https://review.opendev.org/71532620:58
owalshgmann: already covered by one of the bp/policy-default-refresh patches?20:59
gmannowalsh: those are new defaults and it add the deprecation even you have not override it. but old token keep working as they are maintained as deprecated rule till now.20:59
gmannyeah20:59
owalshgmann: cool, so should go away once they all merge21:00
gmannowalsh: we are changing all the policy to adopt the system scope and new defaults like read-only etc21:00
*** rcernin has joined #openstack-nova21:02
gmannowalsh: warnings will stay till we remove the deprecated old rules in 1 or 2 cycle from now21:03
owalshgmann: ack, thanks, expect I'll get asked about the warning quite often until then :-)21:05
gmannowalsh: basically signal to adopt the scope check, those are configurable for now and disabled as default. our goal is to 1. remove the old deprecated roles 2. enable scope check together.  but you can always move to new policy by configuring the enforce_scope=Ture21:09
gmanni am still working on those and should provide a doc on 'how to migrate to new policy' once done.21:09
gmannowalsh: i hope those warnings are not much disturbing (as they are for every rule).21:10
melwittgmann: ++ I was just gonna say I wonder if we can improve that warning message and link to a doc explaining the details and process for migrating. a main point in it is the user being able to tell whether they need to migrate at all, based on their existing policy21:11
melwittat a minimum once you have written a doc, we should update the warning message to include the link to the documentation21:11
gmannmelwitt: that is good idea. it will be easy to link doc to warning21:12
*** nweinber has quit IRC21:16
*** slaweq has quit IRC21:19
*** iurygregory has joined #openstack-nova21:21
owalshgmann: so for default (empty) policy file we will still get warning for 1-2 cycles?21:21
owalshor just if deprecated roles are used in the policy?21:21
dansmithit definitely sucks to warn about deprecated policy when the deprecated things are defaults21:22
dansmithif we can't tell what is deprecated (defaults vs. overrides) I would argue we should squelch that warning21:22
gmannowalsh: all becasue defaults are deprecated21:25
gmannit is for all rule as we use those defaults rules as check_str for every rule and oslo policy just add warning for those21:27
gmannnot sure how to combine those.21:27
gmannone way is disable oslo warning completely and add a single combined warning form nova policy code with link to migration doc.21:30
bnemecThe deprecations are warning you that something might break next cycle and you should test with the future defaults now.21:34
gmannbnemec: we test with both old and new but with disable wanring.21:35
dansmithbnemec: sounds like he has deprecated our existing defaults21:36
dansmithwhich is why I think we should *not* show this to the user21:36
dansmiththere's nothing they can do about it, other than ignore21:36
dansmithit teaches our users to ignore deprecation warnings which is majorly uncool21:36
bnemecAh, this is a different type of deprecation than what I was thinking of.21:38
gmannand each warning teach what is new defaults to that operator can overidde if anything breaking for them21:38
gmannthough that info is present in policy doc also21:38
dansmithgmann: I'm not sure what you're saying21:39
bnemecI think the intent when a policy rule name is changing is that if the new policy name is in the policy file then we don't log the warning.21:39
*** artom has quit IRC21:39
dansmithif the user has made no policy choices and we're logging things telling them that their policy is deprecated, that's a problem21:39
dansmithalso, why are we logging this from nova-manage?21:40
dansmithwe're just making admin eyes bleed if we complain about something not even related to nova-manage on each command invocation21:40
gmanndansmith: i mean each warning say old default of xyz rule is replaced with one of new default. for example legacy admin to system_reader21:40
dansmithgmann: but we're complaining about our own defaults right?21:41
gmannyeah21:41
bnemecThat's fair, we've actually shut off the policy deprecations in some cli tools and unit tests.21:41
dansmith*that* is not okay21:41
dansmithif we have no way to distinguish then we need to squelch the warning until we've fixed all our defaults21:42
gmanni think waning should be added once during api service only21:42
dansmithand, we shouldn't be making those warnings on nova-manage invocations21:42
dansmithgmann: not for our own defaults21:42
dansmithif we're telling the user something is wrong and the thing that is wrong is our default, we're teaching them to ignore our deprecation warnings21:43
bnemecBut the user needs to take action. They _shouldn't_ ignore these messages.21:43
*** spatel has quit IRC21:44
gmannown default but still operator rely on those and new default can change the behaviour if they have new roles like read only etc21:44
dansmithgmann: that's what release notes are for21:44
gmannscope is disabled by default so no issue there21:44
dansmithlogging that once per startup is totally unreasonable, IMHO21:44
owalshcould nova status upgrade check validate any policy overrides if they exist?21:45
dansmithalso that21:45
bnemecIf a policy is overridden then you don't get the message.21:45
dansmithnova-status is supposed to be a dynamic release note checker21:45
gmannfor this case, i agree on that because it is for every rule and lot of warnings21:46
bnemeccmurphy did have a patch up to further consolidate the deprecation messages, but I feel like there were other concerns with it.21:46
gmannyeah, if rule is override there is no warning for default change. it warn only if rule name change21:48
dansmithwe tell people not to override every rule, and almost nobody would override everything,21:48
melwittgmann: what is happening here is that the defaults are being deprecated and new defaults will be activated in one or two cycles right? maybe a Upgrade release note saying "the default policies are going to change in the W release, please review them" is good enough?21:48
dansmithwhich means everyone will receive that warning21:48
dansmithmelwitt: ++21:49
dansmiththis is precisely what nova-status and renos are for21:49
gmannyeah new defaults are not enforced by default.21:50
bnemecThe new defaults are active already. They're just OR'd with the old defaults (if an explicit override is not set) to make sure that the rules are at least as permissive as the old rule so nobody is broken without notice.21:50
dansmithI have to run to a thing,21:50
dansmithbut tldr of my opinion is.. there *has* to be a way to make this message go away.. I'd prefer reno/status. If not, then there has to be some way to say "OKAY I GOT IT"21:50
melwittgmann: and include instructions on how to set enforce_scope = True to see and try the new defaults? also instructions on how to dump the new defaults to review21:50
gmanndansmith: melwitt reno is planned at the end.21:50
bnemecThere is. You explicitly set the new rule in your policy file and the deprecation warning goes away.21:51
dansmithbnemec: but we've spent years telling people NOT to do that21:51
gmannbnemec: but that is not expected21:51
gmannyeah what dansmith mentioned21:51
melwittyeah ... that seems backwards. shouldn't default mean an empty policy file?21:51
dansmithyes21:51
bnemecIt's essentially the operator saying, yes, we've looked at this change and it's fine.21:51
melwittthat's what we made a big deal about policy in code back when that was added21:52
gmanntrue21:52
dansmithcopying defaults into the policy file to shut it the eff up moves us backwards many years21:52
melwittnot sure I'd want to confuse users by saying "ok now go set every single rule in your policy file" that seems counterintuitive21:52
melwittI would imagine their takeaway from that is we've removed policy-in-code and we're back to the old way21:53
dansmithright, because they won't go to the trouble of understanding why,21:53
dansmiththey will just hear that is the solution to make it stop warning21:54
bnemecI will say I don't think the policy deprecation mechanism was designed for deprecating the entire policy file at once, like we're doing now.21:54
melwittyes, I agree this is not the usual thing21:54
gmannyeah, in this case where all defaults are changing warning is too much.21:54
bnemecAlso, the redundant rule tool was designed to let them clean up their policy files once the deprecation process is over.21:55
gmannfor one or two policy change and name etc then it is fine21:55
bnemecIt will tell them that they have rules in their policy file that don't need to be there anymore.21:55
gmannyup that wanring make sense.21:55
* dansmith runs away21:55
bnemecI wonder if we should make that a runtime check instead of a separate tool.21:56
gmannif rule name changing21:56
* bnemec pages lbragstad_ too21:57
bnemecHe knows way more about why things work the way they do than I do.21:57
melwitttaking some steps back, I feel like we have changed the defaults for a reason right, that we think they are better defaults. when I say new defaults become "active" I mean when they become the only default, when we're no longer OR'ing them. I feel like maybe we don't need to sound an alarm about it, but rather let the notice in the release notes explain the upcoming change and how to dump the new defaults to review. that is our normal22:04
melwitt way to communicate upcoming changes to our operators22:04
*** mriedem has quit IRC22:16
openstackgerritmelanie witt proposed openstack/nova master: Add info about affinity requests to the troubleshooting doc  https://review.opendev.org/71509222:22
sean-k-mooneydansmith: if you are about can you read the question i left in https://review.opendev.org/#/c/715326/4. basicaily im wondering if i should be binding the arqs in teh conductor during evacuate or on the destinaiton node. and if the conducrot are we ok with the rpc change that will required like we did in build_and_run_instance22:30
sean-k-mooneydansmith: im done for the day so no rush but ill try and rework that tomorrow22:31
*** sapd1 has joined #openstack-nova22:44
*** sapd1_y has quit IRC22:46
*** tkajinam has joined #openstack-nova22:49
*** tosky has quit IRC22:54
*** macz_ has quit IRC23:06
gmannmelwitt: dansmith lgtm. I will propose the disable warnings when I cut the releasenotes and doc for new defautls.23:18
gmanni think gibi planning this in ussuri highlights also which also good enough signals23:18
openstackgerritGhanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy  https://review.opendev.org/71576123:26
*** artom has joined #openstack-nova23:37
*** gibi has quit IRC23:57
*** gibi has joined #openstack-nova23:57
*** seba has quit IRC23:58

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!