Monday, 2019-02-25

*** erlon has quit IRC00:00
*** tbachman has joined #openstack-nova00:04
*** ttsiouts has quit IRC00:04
*** ttsiouts has joined #openstack-nova00:05
*** markvoelker has quit IRC00:06
*** ttsiouts has quit IRC00:09
*** erlon has joined #openstack-nova00:27
*** tbachman has quit IRC00:29
*** sdake has joined #openstack-nova00:46
*** ileixe has joined #openstack-nova00:50
*** ircuser-1 has joined #openstack-nova00:58
*** _fragatina_ has quit IRC01:02
*** _fragatina has joined #openstack-nova01:02
*** sdake has quit IRC01:03
*** wolverineav has joined #openstack-nova01:06
*** sdake has joined #openstack-nova01:07
*** threestrands has joined #openstack-nova01:10
openstackgerritZhenyu Zheng proposed openstack/nova master: Add method to allow reset fields for root bdm in BDM obj  https://review.openstack.org/61467201:16
openstackgerritZhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported  https://review.openstack.org/61475001:17
*** sdake has quit IRC01:19
*** dave-mccowan has joined #openstack-nova01:29
*** dave-mccowan has quit IRC01:35
*** tbachman has joined #openstack-nova01:35
*** threestrands has quit IRC01:35
*** wolverineav has quit IRC01:36
*** tiendc has joined #openstack-nova01:38
openstackgerritYongli He proposed openstack/nova master: Add server subresouce topology API  https://review.openstack.org/62147601:58
yonglihemriedem: runway seems already got 3 items, i did not put https://review.openstack.org/#/c/621474/21  in the run way for now.02:00
yonglihedo i still allow to add more?02:02
openstackgerritZhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported  https://review.openstack.org/61475002:03
openstackgerritZhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported  https://review.openstack.org/61475002:07
*** markvoelker has joined #openstack-nova02:07
*** igordc has quit IRC02:16
*** Dinesh_Bhor has joined #openstack-nova02:20
*** jbernard has quit IRC02:23
*** dave-mccowan has joined #openstack-nova02:23
*** jbernard has joined #openstack-nova02:25
*** yaawang has quit IRC02:33
*** markvoelker has quit IRC02:37
*** yaawang has joined #openstack-nova02:41
*** hongbin has joined #openstack-nova02:52
*** wolverineav has joined #openstack-nova02:53
*** dave-mccowan has quit IRC02:53
*** sdake has joined #openstack-nova03:02
*** wolverineav has quit IRC03:02
*** whoami-rajat has joined #openstack-nova03:12
*** hongbin has quit IRC03:30
*** markvoelker has joined #openstack-nova03:35
*** janki has joined #openstack-nova03:35
*** sdake has quit IRC03:36
*** sdake has joined #openstack-nova03:41
*** brault has joined #openstack-nova03:45
*** brault has quit IRC03:49
*** udesale has joined #openstack-nova03:51
*** sdake has quit IRC03:56
*** tbachman has quit IRC03:57
*** markvoelker has quit IRC04:03
*** wolverineav has joined #openstack-nova04:12
*** wolverineav has quit IRC04:17
*** udesale has quit IRC04:21
*** sdake has joined #openstack-nova04:21
*** macza has joined #openstack-nova04:22
*** udesale has joined #openstack-nova04:22
*** spsurya has joined #openstack-nova04:24
*** sdake has quit IRC04:25
*** sdake has joined #openstack-nova04:26
*** sdake has quit IRC04:30
*** sdake has joined #openstack-nova04:33
*** macza has quit IRC04:34
*** sdake has quit IRC04:35
*** sdake has joined #openstack-nova04:37
*** sdake has quit IRC04:40
*** sdake has joined #openstack-nova04:44
*** sdake has quit IRC04:45
*** ShilpaSD has joined #openstack-nova04:51
*** sdake has joined #openstack-nova04:51
*** sdake has quit IRC04:55
*** sdake has joined #openstack-nova04:58
*** tbachman has joined #openstack-nova04:58
*** sdake has quit IRC05:00
*** markvoelker has joined #openstack-nova05:00
*** sdake has joined #openstack-nova05:01
*** janki has quit IRC05:02
*** sdake_ has joined #openstack-nova05:10
*** sdake has quit IRC05:10
*** sdake_ has quit IRC05:15
*** sdake has joined #openstack-nova05:18
zhubx007Can anyone help to take a look at this https://review.openstack.org/#/c/638080/? Thanks.05:18
*** sdake has quit IRC05:21
*** sdake has joined #openstack-nova05:22
openstackgerritmelanie witt proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules  https://review.openstack.org/63857405:24
openstackgerritmelanie witt proposed openstack/nova master: WIP Add online data migration for populating user_id  https://review.openstack.org/63335105:24
openstackgerritmelanie witt proposed openstack/nova master: WIP Add get_counts() to InstanceMappingList  https://review.openstack.org/63807205:24
openstackgerritmelanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement  https://review.openstack.org/63807305:24
openstackgerritmelanie witt proposed openstack/nova master: Use instance mappings to count server group members  https://review.openstack.org/63832405:24
*** sdake has quit IRC05:26
*** ratailor has joined #openstack-nova05:28
*** sdake has joined #openstack-nova05:28
*** bhagyashris has joined #openstack-nova05:29
*** sdake has quit IRC05:30
*** sdake_ has joined #openstack-nova05:32
*** markvoelker has quit IRC05:33
*** sdake_ has quit IRC05:35
*** sdake has joined #openstack-nova05:36
openstackgerritBrin Zhang proposed openstack/nova master: Creating a flavor only supports the integer type  https://review.openstack.org/63901205:38
*** macza has joined #openstack-nova05:39
*** macza has quit IRC05:43
*** yaawang has quit IRC05:45
*** sdake has quit IRC05:45
*** yaawang has joined #openstack-nova05:45
*** wolverineav has joined #openstack-nova05:47
*** Zhang has joined #openstack-nova05:48
*** wolverineav has quit IRC05:48
*** wolverineav has joined #openstack-nova05:48
*** sdake has joined #openstack-nova05:48
*** sdake has quit IRC05:51
*** sdake has joined #openstack-nova05:51
*** Zhang is now known as Kunpeng05:52
*** sdake has quit IRC05:55
*** tetsuro has joined #openstack-nova05:56
*** sdake has joined #openstack-nova05:57
*** sdake has quit IRC06:00
*** dpawlik has joined #openstack-nova06:01
*** sdake has joined #openstack-nova06:02
*** sdake has quit IRC06:06
*** sdake_ has joined #openstack-nova06:07
openstackgerritYongli He proposed openstack/nova master: Add server subresouce topology API  https://review.openstack.org/62147606:09
*** yaawang has quit IRC06:09
*** sdake_ has quit IRC06:10
*** sdake has joined #openstack-nova06:10
*** sdake has quit IRC06:10
yonglihealex_xu: Updated the topology subresource per your comments, please check it. and should i put 2 of them on the stein-runway?  There is already 3 items.06:17
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147606:21
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP: Testing nova legacy jobs on bionic  https://review.openstack.org/63901706:27
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP: Testing nova legacy jobs on bionic  https://review.openstack.org/63901706:36
*** tiendc has quit IRC06:36
*** sridharg has joined #openstack-nova06:46
*** Luzi has joined #openstack-nova06:51
*** ileixe has quit IRC07:04
*** slaweq has joined #openstack-nova07:11
*** udesale has quit IRC07:27
*** udesale has joined #openstack-nova07:27
*** ttsiouts has joined #openstack-nova07:29
*** markvoelker has joined #openstack-nova07:30
*** jangutter has joined #openstack-nova07:39
*** belmoreira has joined #openstack-nova07:40
*** ttsiouts has quit IRC07:52
*** ttsiouts has joined #openstack-nova07:52
*** ttsiouts has quit IRC07:57
*** wolverineav has quit IRC07:57
*** awalende has joined #openstack-nova07:59
*** awalende has quit IRC08:01
*** takashin has left #openstack-nova08:01
*** markvoelker has quit IRC08:03
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147408:05
*** lyaaaaarwood is now known as lyarwood08:06
kashyapsean-k-mooney: Hi, when you're about, what is the URL again to see if there's a pattern/trend of this bug: https://bugs.launchpad.net/nova/+bug/181732408:06
openstackLaunchpad bug 1817324 in OpenStack Compute (nova) "Intermittent "Failed to start libvirt guest: libvirt.libvirtError: monitor socket did not show up: No such file or directory" failures in the gate" [Undecided,Confirmed]08:06
kashyap"Ara" reports I guess08:06
*** liuyulong has joined #openstack-nova08:11
kashyapHmm, I see indexing is behind by 76 hours: http://status.openstack.org/elastic-recheck/08:14
*** Sundar has joined #openstack-nova08:14
*** tkajinam has quit IRC08:14
*** Sundar has quit IRC08:15
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398108:16
*** tesseract has joined #openstack-nova08:18
*** takamatsu_ has quit IRC08:19
*** dtantsur|afk is now known as dtantsur08:21
*** takamatsu_ has joined #openstack-nova08:21
*** takamatsu_ has quit IRC08:32
*** helenafm has joined #openstack-nova08:35
*** yaawang has joined #openstack-nova08:37
*** takamatsu_ has joined #openstack-nova08:38
*** awalende has joined #openstack-nova08:42
*** ccamacho has joined #openstack-nova08:45
*** tssurya has joined #openstack-nova08:48
*** stakeda has joined #openstack-nova08:52
*** tosky has joined #openstack-nova08:55
*** giblet is now known as gibi08:55
openstackgerritTetsuro Nakamura proposed openstack/nova-specs master: Update alloc-candidates-in-tree  https://review.openstack.org/63903308:56
*** rcernin has quit IRC09:00
*** ttsiouts has joined #openstack-nova09:00
*** markvoelker has joined #openstack-nova09:01
*** tetsuro has quit IRC09:07
*** snevi has joined #openstack-nova09:18
*** owalsh_ is now known as owalsh09:23
*** ralonsoh has joined #openstack-nova09:24
*** derekh has joined #openstack-nova09:30
*** markvoelker has quit IRC09:34
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147609:35
*** wolverineav has joined #openstack-nova09:36
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147609:37
*** ccamacho has quit IRC09:38
*** wolverineav has quit IRC09:41
*** cdent has joined #openstack-nova09:47
*** yaawang has quit IRC09:53
*** cdent has quit IRC09:56
*** bhagyashris has quit IRC10:02
*** erlon has quit IRC10:03
openstackgerritSurya Seetharaman proposed openstack/nova master: [Doc] Best practices for effectively tolerating down cells  https://review.openstack.org/63817310:03
*** ccamacho has joined #openstack-nova10:13
*** jmlowe has quit IRC10:16
*** jmlowe has joined #openstack-nova10:17
*** sambetts_ has quit IRC10:28
*** sambetts_ has joined #openstack-nova10:30
*** markvoelker has joined #openstack-nova10:31
*** nehaalhat has joined #openstack-nova10:35
*** jaosorior has joined #openstack-nova10:37
*** ccamacho has quit IRC10:43
*** cdent has joined #openstack-nova10:43
*** ccamacho has joined #openstack-nova10:43
*** ccamacho has quit IRC10:45
*** trident has quit IRC10:47
openstackgerritAdam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver  https://review.openstack.org/63868010:49
*** trident has joined #openstack-nova10:50
*** stakeda has quit IRC10:50
*** yankcrime has quit IRC10:59
openstackgerritAdam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver  https://review.openstack.org/63868011:00
openstackgerritya.wang proposed openstack/nova master: Select cpu model from a list of cpu models  https://review.openstack.org/63783411:02
*** tbachman has quit IRC11:03
*** markvoelker has quit IRC11:04
sean-k-mooneykashyap: you can go directly into logstack's kiban instance http://logstash.openstack.org/#/dashboard/file/logstash.json11:06
*** yankcrime has joined #openstack-nova11:07
*** Dinesh_Bhor has quit IRC11:07
kashyapsean-k-mooney: Yep, noted11:08
*** ccamacho has joined #openstack-nova11:12
lyarwoodmdbooth: https://review.openstack.org/#/c/637527/ - If you have time today would you mind going over this again given our discussion on Friday?11:13
*** ccamacho has quit IRC11:13
*** ccamacho has joined #openstack-nova11:14
*** liuyulong has quit IRC11:15
mdboothlyarwood: Yep, sure. Will do it now.11:18
lyarwoodmdbooth: thanks11:18
*** udesale has quit IRC11:18
mdboothlyarwood: Although... Hmm. I wonder if my comments are still relevant, despite my previous misunderstanding.11:19
mdboothlyarwood: Backend_names != hosts, right?11:20
lyarwoodmdbooth: they should form part of the hostname itself11:21
lyarwoodmdbooth: host@backend#type11:21
mdboothOk, so if there's 1 c-vol and 2 backend_names then there are 2 'hosts' as reported by list_hosts()?11:22
lyarwoodcorrect11:22
lyarwoodc-api is all over the place tbh11:23
*** ttsiouts has quit IRC11:23
mdboothhttps://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=list-all-hosts-for-a-project-detail#hosts-extension-os-hosts11:25
mdboothThe 'cinder-volume' in that case has host@backend11:26
*** ccamacho has quit IRC11:28
lyarwoodmdbooth: right sorry, src_host is coming from os-vol-host-attr:host on the volume and that's host@backend#type11:29
lyarwoodmdbooth: or at least that can be host@backend#type11:29
lyarwoodmdbooth: thus the host_name not in src_host check when trying to find a destination host11:29
mdboothlyarwood: Does host *always* have #type appended?11:33
mdboothBecause you're doing a straight string comparison11:34
*** ttsiouts has joined #openstack-nova11:36
lyarwoodmdbooth: volume['os-vol-host-attr:host'] appears to, again I was wrong about host['host_name'], it doesn't contain #type11:39
*** finucannot is now known as stephenfin11:40
mdboothlyarwood: Ok, does that mean you need to parse #type out of the former?11:44
mdboothIt would be nice if this was consistent11:45
*** sdake has joined #openstack-nova11:46
lyarwoodmdbooth: I don't think so, we only care about the host@backend part here for migrations11:46
lyarwoodmdbooth: we are just checking that the host@backend isn't hosting the volume at present11:46
lyarwoodmdbooth: the type isn't a factor here11:46
mdboothlyarwood: Right, but if I've understood what you've just told me, you're doing a string comparson between node@backend#type and node@backend, which is going to fail11:47
lyarwoodmdbooth: other way around, node@backend not in node@backend#type11:47
mdboothAh, you're doing a not in, not a string comparison...11:48
mdboothEww11:48
mdboothBut I see11:48
lyarwoodyeah I can spell that out more in a comment11:49
*** sdake has quit IRC11:50
*** sdake has joined #openstack-nova11:52
*** yaawang has joined #openstack-nova11:53
*** ratailor has quit IRC11:54
*** sdake has quit IRC11:55
mdboothlyarwood: Updated.11:56
lyarwoodmdbooth: thanks, would you mind hitting the actual nova bugfix while you're at it11:56
lyarwoodmdbooth: https://review.openstack.org/#/c/637224/11:56
mdboothlyarwood: I've asked for additional assertions, but I think you can cut/paste them out of my old patch.11:56
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398111:57
lyarwoodmdbooth: ack thanks11:58
*** sdake has joined #openstack-nova11:58
openstackgerritMerged openstack/nova stable/rocky: Avoid redundant initialize_connection on source post live migration  https://review.openstack.org/63689511:58
lyarwoodfinally11:58
mdboothlyarwood: Thinking about it, you might need to split up the tempest test into the familiar 'assert incorrect behaviour', 'fix incorrect behaviour' 2 part series.11:58
mdboothlyarwood: Nice :)11:59
*** ccamacho has joined #openstack-nova11:59
lyarwoodmdbooth: I don't think we do that with tempest test additions tbh11:59
mdboothBecause I think we want the nova fix to Depends-On the change which asserts the correct behaviour in retype so as to avoid a regression.12:00
mdboothBut once you've landed the assertions I asked for against migration, the tempest test will fail until the nova fix lands.12:00
*** sdake has quit IRC12:00
mdbooth(Which highlights why the assertions are required, btw)12:01
*** markvoelker has joined #openstack-nova12:01
lyarwoodmdbooth: The tempest changes will depend on the Nova fix12:02
*** panda|ruck is now known as panda|ruck|lunch12:02
lyarwoodmdbooth: we can land some updates to the existing retype assertions outside of that12:02
mdboothlyarwood: So you want to add the assertions to *retype* before landing the Nova change, because that asserts that you're not regressing retype12:02
lyarwoodmdbooth: yeah that's simple enough to land first12:03
lyarwoodmdbooth: so retype assertions update, nova fix and finally tempest migration test right?12:04
mdboothlyarwood: Yeah12:04
mdboothSo the Nova change will depends-on the retype tempest addition. The full tempest test will depends-on the nova change.12:05
lyarwoodcorrect12:05
lyarwoodzuul++12:05
*** cdent has quit IRC12:17
*** nehaalhat has quit IRC12:22
*** ttsiouts has quit IRC12:31
*** ttsiouts has joined #openstack-nova12:32
*** cdent has joined #openstack-nova12:34
*** markvoelker has quit IRC12:35
*** ttsiouts has quit IRC12:37
mdboothlyarwood: Done. -1 is for discussed tempest change. Unit test change could be a nit, but one I really think we should fix. I'd like to see +1 from a cinder dev before anybody +2s it.12:40
*** udesale has joined #openstack-nova12:42
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398112:48
*** ttsiouts has joined #openstack-nova12:48
openstackgerritMerged openstack/os-vif master: remove brctl from vif_plug_ovs  https://review.openstack.org/63682113:02
*** jistr is now known as jistr|mtg13:07
*** jistr|mtg is now known as jistr13:08
zhubx007Can anyone help to take a look at this https://review.openstack.org/#/c/638080/? A bug fix. Thanks.13:10
*** tbachman has joined #openstack-nova13:18
jaypipessean-k-mooney: trying to get through all os-vif patches you list in your email today.13:19
mdboothzhubx007: That isn't going to fly for a few reasons. One of which is that by using automatic format detection it opens a potential security hole in image import.13:19
mdboothzhubx007: In fact I'm almost certain that would open a major security hole.13:20
sean-k-mooneyjaypipes: thanks. im respinning "make functional tests run on python 3" based on the feedback13:20
mdboothzhubx007: Allowing any authenticated tenant to read all data from the compute host.13:21
jangutterjaypipes: I think that bridge+routing code is the classic monkeys+bananas thing.13:21
sean-k-mooneyjaypipes: does the timeline and porities make sense. once the final brctl patch merges we have reached the mvp for stien the rest are nice to have but dont block features13:24
*** panda|ruck|lunch is now known as panda|ruck13:26
gibijaypipes: hi! the next couple of patches in the bandwidth series (staring here https://review.openstack.org/#/c/616240) has mriedem's +2 on it. I'm working on a fup to fix his comments. So if you have time could you look at the series again?13:31
*** markvoelker has joined #openstack-nova13:32
jaypipessean-k-mooney: I'd like to get the native ovslib stuff in if possible.13:34
jaypipesgibi: yup13:34
gibijaypipes: thanks a lot13:34
alex_xusean-k-mooney: stephenfin something need your expert https://review.openstack.org/#/c/634828/24/nova/virt/libvirt/driver.py@6783 :)13:37
sean-k-mooneyjaypipes: yep that is why its in the prefer section :) its not required but im happy to wait a couple of extra hours to try and get it over the line13:37
*** udesale has quit IRC13:37
*** udesale has joined #openstack-nova13:38
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path  https://review.openstack.org/63909113:39
artomalex_xu, hah, was just about to ask :)13:40
sean-k-mooney alex_xu that is a good question. i dont really think there is a good usecase for different values13:40
alex_xuartom: hah13:40
artomalex_xu, thanks for taking a thorough look at that series, by the way :)13:40
alex_xunp :)13:40
sean-k-mooneyalex_xu: that said since it can be set per node it proably should be sent back13:40
alex_xusean-k-mooney: ok, thanks13:41
openstackgerritMerged openstack/os-vif master: remove use of brctl from vif_plug_linux_bridge  https://review.openstack.org/63682213:41
artomsean-k-mooney, noted, thanks13:41
sean-k-mooneyif there was a good usecase for different values we should be schduling on it and we cant today except via host aggregates13:42
sean-k-mooneywe could expose it via a custom trait at some point but i think this is too virtdirer specific to warrent it.13:44
*** jmlowe has quit IRC13:44
openstackgerritMerged openstack/os-resource-classes master: Add normalize_name utility  https://review.openstack.org/63425813:45
sean-k-mooneytechnically different prioties of realtime tasks is a thing but i dont think it should be a thing in cloud. im much more comfortable with a boolean form that point of view. e.g. it supprot realtime instance or it doesnt13:45
zhubx007mdbooth: Got your review. Is there any suggestion to fix the bug? If do not convert the qcow2 to raw here, the instance failed to boot. Thanks.13:47
mdboothzhubx007: I just added another comment on the review about that.13:47
mdboothI don't think you need to fix it, because if you leave force_raw_images with its default value of True then the image should be (safely) converted for you anyway.13:48
*** sapd1 has joined #openstack-nova13:48
alex_xusean-k-mooney: that priorities is also indicated the host whether support realtime? so you mean at least there is way to find out a host support realtime13:48
alex_xuah, I see now, we won't fix realtime and normal workload on the same host, right? sean-k-mooney13:49
alex_xus/fix/mix13:49
mdboothzhubx007: Are you setting force_raw_images to false?13:51
sean-k-mooneyalex_xu: well right now you have to use host aggrates to split them13:51
mdboothIf force_raw_images is True and you're hitting this, I think we should go back and open a bug about this to try to work out why before attempting a fix.13:51
sean-k-mooneyalex_xu: mainly because we dont know which host have a realtime kernel13:51
alex_xusean-k-mooney: I see now13:52
zhubx007mdbooth: :) wait for a minute. I check nova.conf file now.13:53
sean-k-mooneyif https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L759-L763 did not have a default we could use the presence or absence of that config value to know if we should add a realtime trait to the compute node13:53
sean-k-mooneybut since it default to 1 we cant13:54
sean-k-mooneywe might want to change that in the future but not in stien13:54
sean-k-mooneyalex_xu: ^ likely we would have to add another config to not break backwards compatiblity but the detail should praobly be discussed in a short spec.13:55
zhubx007mdbooth: yes, force_raw_images is False13:56
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222613:56
yonglihecall for review, thanks, it's small one: https://review.openstack.org/#/c/621474/2213:57
mdboothzhubx007: Cool, that's your problem.13:57
mdboothzhubx007: As I say it does feel wrong that the we're making it the operator's responsibility to get that right.13:58
alex_xusean-k-mooney: agree, and we can transulate hw:.... to a required trait in placement request13:58
mdboothzhubx007: But that would be a much lower priority issue :) Patches welcome.13:58
sean-k-mooneyyep we could. ill write something up for train and add you to the reviews list.13:59
alex_xucool13:59
cdentscheduler placement meeting in #openstack-meeting-alt now ish13:59
*** awaugama has joined #openstack-nova14:00
*** elbragstad has joined #openstack-nova14:01
openstackgerritGhanshyam Mann proposed openstack/nova master: DNM: Testing nova legacy jobs on bionic  https://review.openstack.org/63901714:01
zhubx007mdbooth: yeah, you are right. but when setting force_raw_images to False, I think it is still an issue.14:01
*** med_ has joined #openstack-nova14:01
*** mmethot has joined #openstack-nova14:03
*** fried_rice is now known as efried14:04
*** ttsiouts has quit IRC14:04
*** markvoelker has quit IRC14:05
*** ttsiouts has joined #openstack-nova14:05
*** ttsiouts has quit IRC14:06
*** dpawlik has quit IRC14:06
*** ttsiouts has joined #openstack-nova14:06
*** dave-mccowan has joined #openstack-nova14:07
*** owalsh_ has joined #openstack-nova14:08
*** owalsh has quit IRC14:09
openstackgerritJan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge)  https://review.openstack.org/63909914:09
mdboothzhubx007: Right. That setting is incompatible with rbd imagebackend. It would be nice to, for eg, give an error at startup pointing it out. Or perhaps just switching it off automatically and logging a warning.14:10
mdboothzhubx007: In fact it's only useful for flat and qcow2 imagebackends. LVM would also have a problem with it.14:11
stephenfinjangutter: Some small comments in that patch ^14:12
openstackgerritJan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge)  https://review.openstack.org/63909914:15
jangutterstephenfin: ask and ye shall receive.14:16
sean-k-mooneyjangutter: damb looks like i missed leaving the comment by a few seconds14:16
sean-k-mooneyjangutter: can ou add the comment too? thanks for doing this by the way14:16
janguttersean-k-mooney: hahaha, no worries. I don't have my Nagle algorithm turned on today.14:17
stephenfinjangutter: is that correct?14:17
stephenfinx, = (1, 2) gives a ValueError14:17
stephenfinYou'd need 'x, _'14:17
jangutterstephenfin: frack, you're right.14:18
jangutterstephenfin: just goes to show that code path is untested so badly.14:18
stephenfinOh, found an ancient change of mine. does this docs patch make sense to you, jaypipes? https://review.openstack.org/#/c/445436/14:18
sean-k-mooneyoh thats to nova i was like i dont remember that14:19
*** owalsh has joined #openstack-nova14:19
*** owalsh_ has quit IRC14:20
openstackgerritJan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge)  https://review.openstack.org/63909914:23
jangutterstephenfin, sean-k-mooney: 3rd time lucky Monday?14:23
*** tbachman has quit IRC14:24
*** mvkr has quit IRC14:24
jangutterI think that code is dead since before I touched OpenStack, but I'm worried that breaking it will cause CERN to accidentally create a black hole or something.14:27
*** jmlowe has joined #openstack-nova14:30
openstackgerritGhanshyam Mann proposed openstack/nova stable/rocky: DNM: Testing nova legacy jobs on rocky still use xenial  https://review.openstack.org/63910714:30
sean-k-mooneyjangutter: the linux bridge pluging is partcalarly archane as we spend much less time maintaining it. im hoping that by sharing code with the ovs plugin in train we can impove the quality of both14:31
*** tbachman has joined #openstack-nova14:32
sean-k-mooneyjangutter: i would also like to add an sriov plugin intree in train so we can finally remove the last of the vif.py legacy code from nova14:32
janguttersean-k-mooney: ++ on both of those.14:32
sean-k-mooneywe have avoided sharing code so people can copy a sub directly and use that as a base for a new plugin but instead i would like to create a cookiecutter template for that and document it14:33
sean-k-mooney*sub directory14:34
*** mvkr has joined #openstack-nova14:35
*** snevi has quit IRC14:35
*** sridharg has quit IRC14:36
*** snevi has joined #openstack-nova14:37
zhubx007mdbooth: as you say, it is ok when I set force_raw_images to True. Whether it is great to add checking the image format when call import_image under rbd imagebackend because only raw is good for this backend.14:38
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147614:39
openstackgerritsean mooney proposed openstack/os-vif master: make functional tests run on python 3  https://review.openstack.org/63805314:40
openstackgerritsean mooney proposed openstack/os-vif master: modify functional base.py to allow using vscode  https://review.openstack.org/63805814:40
*** eharney has joined #openstack-nova14:40
*** mriedem has joined #openstack-nova14:47
*** cdent has quit IRC14:53
*** tbachman has quit IRC14:55
*** mlavalle has joined #openstack-nova14:58
*** sapd1 has quit IRC14:59
*** udesale has quit IRC15:02
mriedemjaypipes: efried: i'm +2 on the current bottom 4 bw provider series changes https://review.openstack.org/#/c/616240/ - nits to be sure but can be addressed in another follow up i think15:04
mriedemi think the api change is the goal for stein https://review.openstack.org/#/c/636360/ so i'm trying to do a review push to get there this week15:04
*** tbachman has joined #openstack-nova15:10
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path  https://review.openstack.org/63909115:10
kashyapmriedem: Blast from the past ^15:10
efriedmriedem: ack. Trying to figure out if it's mathematically possible to have more fups than patches.15:11
mriedemefried: i made a similar joke on one of these15:11
mriedem1:1 fups15:11
efriedI hate being unoriginal. Now I will have to kill you.15:11
efriedNever mind, I'll need you to review my code. You live.15:12
*** Luzi has quit IRC15:13
gibiefried, mriedem: I working on a fup that will contain fixes up til https://review.openstack.org/#/c/57331715:16
kashyapWhat is a "fup"?15:16
gibikashyap: Follow up15:16
kashyapMy tool doesn't know it:15:16
kashyap$> wtf is fup15:16
kashyapwtf: I don't know what `fup' means!15:16
kashyapgibi: Ah, thanks.15:16
efriedor what you were thinking, depending.15:16
sean-k-mooneyfix up patch or follow up patch15:16
sean-k-mooneykashyap: ^15:17
kashyapPlease, "follow-up" as keyword.15:17
sean-k-mooneyno one uses that^15:17
kashyapAs I accidentally looked at the definition of "fup" on Urban Dictionary ... and "you won't believe what happens next!"15:17
kashyapsean-k-mooney: Yeah, yeah.  I know it's just IRC slang15:17
efriedBack in the day it was used by IBM support teams for APARs, in caps (FUP), simply shorthand for "follow up", as in "FUP with customer..."15:18
efriedand led to all kinds of raunchy (well, for IBM, anyway) jokes.15:18
sean-k-mooneyyep and recent slang at that. but i dont think we need to add follow-up: someithg to the commits15:18
kashyapI see15:19
efriedAgree with that; though I have to say I'm not a fan of commit titles like "Follow on for <change-id>" with nothing in the body of the message.15:19
efriedWhen I do these, I tend to do "FUP for <brief description>" and then enumerate links to specific comments I'm responding to in the body.15:20
efriedand of course, everybody should do it my way.15:20
*** jobewan has joined #openstack-nova15:20
sean-k-mooneyhaha well that at least makes sense15:20
efriedexample: https://review.openstack.org/#/c/600474/15:21
*** beekneemech is now known as bnemec15:21
sean-k-mooneyi think this is fine too https://review.openstack.org/#/c/639099/ but a midpoint betwen the too is praobly good too.15:22
kashyapefried: Yeah, I fully agree on "bad commit messages".  Reminds me of this excellent guide written by DanPB many moons ago: https://wiki.openstack.org/wiki/GitCommitMessages15:23
kashyapPeople should take that guide to the heart.15:23
sean-k-mooneythe disadvantage of both are you have to click the link/change id to see the context15:23
sean-k-mooneykashyap: there are some thing in the bad examples that i dont fully agree with in that guide but i do reference it frequently15:24
kashyap(And of course this excellent post from a certain Chris Beans: https://chris.beams.io/posts/git-commit/)15:24
kashyapsean-k-mooney: The fundamental rule I follow in commit messages is: provide all the context right there in the commit message.15:24
efriedkashyap: I frequently reference the GitCommitMessages wiki page. (That link showed up purple for me :)15:24
kashyapIf you have to link to something, summarize it15:24
kashyap(E.g. faciliate the poor suckers working without internet connection and are doing `git log` sleuthing)15:25
kashyapefried: Cool :-)15:25
kashyapsean-k-mooney: That point is actually point 2 in that Wiki page: "Do not assume the reviewer has access to external web services/site."15:25
sean-k-mooneykashyap: one thing that i always tought that wiki discuoraged was bullet point list in the commit which i think are actully good style15:25
sean-k-mooneyyep15:26
*** tbachman has quit IRC15:26
kashyapsean-k-mooney: Bullet points are fine -- as long as they are complete, and _coherent_ sentences15:26
kashyapAnd not no-assed "thoughts"15:26
sean-k-mooneyso i think https://review.openstack.org/#/c/638058/2//COMMIT_MSG is a good commit message but that general styple would be discuraged15:26
kashyapsean-k-mooney: Was actually reading that change15:27
efriedMy understanding is that what's discouraged is changing more than one thing in a commit. A bullet list sometimes (but definitely not always) indicates that that's happening. But a bullet list isn't inherently bad.15:28
efriedbe like saying, "never use the word 'also' in a commit message"15:28
sean-k-mooneyefried: ya that is true the distinciton is not made clear in the example in the wiki15:29
kashyapsean-k-mooney: I have a small 'issue' with that vscode commit message15:29
*** awalende has quit IRC15:29
kashyapIt doesn't follow the general "scheme" most of the human brains are used to:  describe the problem, then tell the solution.15:30
sean-k-mooneykashyap: there are 2 thing i need to fix15:30
*** awalende has joined #openstack-nova15:30
sean-k-mooneykashyap: so leave a comment and ill adress them shortly15:30
kashyapLastly, this is my Git commit message 'scheme':15:30
kashyap[One line summary -- in imperative mood]15:30
kashyapDescribe the problem.15:30
kashyapDescribe your solution.  And more importantly, tell *why*.15:30
kashyap(You do that, though.  But all of them in bullets :-))  Anyway, don't want to belabor on this.15:31
stephenfinbauzas: Fancy doing me the honour? https://review.openstack.org/#/c/445436/15:32
bauzasstephenfin: with pleasure15:32
bauzasstephenfin: oh wait, sec. the option is *already* deprecated ?15:33
bauzasstephenfin: if so, it should have a reno note15:33
bauzasif not, we need it15:33
stephenfinthat's a good point15:34
stephenfinlemme fix that15:34
*** awalende has quit IRC15:34
bauzasstephenfin: will update the commit msg to stop the zuul check then15:35
*** elbragstad is now known as lbragstad15:35
stephenfinIf you remove the -W, it'll take it out of the gate15:35
openstackgerritSylvain Bauza proposed openstack/nova master: conf: Improve documentation for defer_iptables_apply  https://review.openstack.org/44543615:35
bauzasstephenfin: nope, unless zuul changed15:37
bauzasfor pushing the change out of the gate pipeline, we need to have a new revision15:37
bauzasanyway, it's done15:38
*** agopi has quit IRC15:40
*** macza has joined #openstack-nova15:44
openstackgerritLajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.70  https://review.openstack.org/63723415:46
*** macza has quit IRC15:48
openstackgerritStephen Finucane proposed openstack/nova master: conf: Deprecated 'defer_iptables_apply'  https://review.openstack.org/44543615:54
stephenfinbauzas, jaypipes: That should be better ^15:54
stephenfinsean-k-mooney tells me what I'm doing is likely correct and I'm going to b̶l̶a̶m̶e̶ ̶h̶i̶m̶ ̶i̶f̶ ̶I̶'̶m̶ ̶w̶r̶o̶n̶g̶ trust him :)15:55
jaypipesheh15:56
* sean-k-mooney til you can do stike though text in irc15:58
openstackgerritMatt Riedemann proposed openstack/nova master: Add unit tests for missing VirtualInterface in 2.70 os-interface  https://review.openstack.org/63914115:59
mriedemcan i get another core on the 'expose virtual device tags' api change? https://review.openstack.org/#/c/631948/ alex +2ed it and it's pretty straight-forward. last day in the runway queue for this one.16:00
stephenfinsean-k-mooney: My docs are "nice to have". I feel cheated, Good Sir ;)16:00
stephenfinmriedem: I can take a gawk16:00
mriedemthanks16:00
yonglihethis one in same situation: https://review.openstack.org/#/c/621474/2216:01
sean-k-mooneystephenfin: docs chagnes are non fuctional and can can be merged after the client lib freeze. since we generally just use the latest version of the docs people should still see them but they also can be backported to stable branches more easily so nice to have16:01
sean-k-mooneystephenfin: hehe but i also think they will be straigt forward to merge so im going to go review them shortly anyway16:02
mriedemyonglihe: i'll try to get to that one16:02
*** _alastor_ has joined #openstack-nova16:02
yonglihethanks.16:03
yonglihei suppose all stuff piled up at end of dev cycle, sorry for that.16:04
*** markvoelker has joined #openstack-nova16:05
*** mkarpiarz has joined #openstack-nova16:08
*** mkarpiarz has quit IRC16:10
*** ttsiouts has quit IRC16:11
*** tbachman has joined #openstack-nova16:11
*** ttsiouts has joined #openstack-nova16:12
mriedemnp, it always happens16:12
*** macza has joined #openstack-nova16:14
*** ttsiouts has quit IRC16:16
*** cdent has joined #openstack-nova16:18
bauzasstephenfin: +Waboom16:20
*** mrch_ has quit IRC16:20
*** ivve has joined #openstack-nova16:21
*** _hemna has joined #openstack-nova16:23
*** imacdonn has joined #openstack-nova16:23
openstackgerritMerged openstack/nova master: Refactor "networks" processing in ServersController.create  https://review.openstack.org/63359416:25
stephenfinbauzas: Tank u16:27
*** agopi has joined #openstack-nova16:28
stephenfin    .--._____,16:28
stephenfin .-='=='==-, "16:28
stephenfin(O_o_o_o_o_O)16:28
* cdent blinks16:28
*** _hemna has quit IRC16:30
yonglihe-:)16:33
*** markvoelker has quit IRC16:34
*** gyee has joined #openstack-nova16:37
*** takamatsu_ has quit IRC16:39
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation' spec  https://review.openstack.org/63873416:40
*** dklyle_ has quit IRC16:40
*** takamatsu_ has joined #openstack-nova16:41
openstackgerritMatt Riedemann proposed openstack/nova master: [Doc] Best practices for effectively tolerating down cells  https://review.openstack.org/63817316:42
tssuryathanks mriedem ^16:43
mriedemnp16:43
*** helenafm has quit IRC16:44
*** takamatsu_ has quit IRC16:45
*** takamatsu_ has joined #openstack-nova16:51
*** ttsiouts has joined #openstack-nova16:51
*** dklyle has joined #openstack-nova16:55
openstackgerritBalazs Gibizer proposed openstack/nova master: Fup for the bandwidth series  https://review.openstack.org/63915916:57
gibimriedem: your comments for the bandwidth series are fixed in ^^16:58
gibijaypipes, efried: thanks for the comments in the bandwidth series, I will update https://review.openstack.org/639159 with your comments as well, possibly tomorrow16:58
*** ttsiouts has quit IRC16:59
*** ttsiouts has joined #openstack-nova16:59
artomObject equality in tests in a PITA17:00
artom*is17:00
artomExpect call: Flavor(<some stuff>), Actual call: Flavor(<exact same stuff>)17:01
artom*facepalm*17:03
artomNo, that's not i :(17:03
artom*it17:03
*** ttsiouts has quit IRC17:04
sean-k-mooneystephenfin: left some comments on you os-vif docs changes most are minor17:04
*** takamatsu_ has quit IRC17:06
*** takamatsu_ has joined #openstack-nova17:07
sean-k-mooneyartom: object equality check pending change so you need to reset changes on both object before comparing them17:07
sean-k-mooneyotherwise you get X != X issues17:08
*** _fragatina_ has joined #openstack-nova17:08
*** _fragatina has quit IRC17:10
jaypipesartom: what sean-k-mooney said is almost always the problem with that.17:10
*** spotz has joined #openstack-nova17:10
sean-k-mooneyjaypipes: artom we proably should just create a function in the base tescae for comparing objects17:10
jaypipessean-k-mooney: there was one somewhere I think... maybe dansmith can remember :)17:11
sean-k-mooneye.g. self.assertObjEquals17:11
sean-k-mooneyjaypipes: would it break the world if we changed __eq__ in base ovo to ignore the changed state of fields?17:12
*** snevi is now known as IvensZambrano17:12
sean-k-mooneyi assume yes since we have not done so before17:12
artomsean-k-mooney, jaypipes, yeah, so it this case it was dumber than that - my main problem was I had an - and an _ in my fake values17:12
sean-k-mooneyoh :)17:13
artomBut once that hurdle was over, there was still an object I had to replace with a fake string.17:13
artomBut yeah, a more intelligent way of comparing objects would be super17:13
jaypipeshah :)17:13
artomIt wouldn't even be that hard - implement __eq__ in the base fields, and then recursively compare fields17:14
sean-k-mooneyartom: yes but we dont know if anyting depens on the fact that object comparisons current check the changed fields state of the objects17:15
sean-k-mooneyos its not that its hard to do but would it break anything17:15
*** bjolo has quit IRC17:16
*** snevi has joined #openstack-nova17:16
*** IvensZambrano has quit IRC17:16
sean-k-mooneyartom: https://github.com/openstack/nova/blob/eb5bdd33052166e4375f924456438f11be03310a/nova/test.py#L704 we have this by the way17:17
*** snevi has quit IRC17:17
artomsean-k-mooney, that's not useful when you're asseting call param tho17:17
artomAnyways, it's a pain, but all things considered a minor one17:17
*** eharney has quit IRC17:17
*** IvensZambrano has joined #openstack-nova17:18
*** efoley has joined #openstack-nova17:18
*** mrch_ has joined #openstack-nova17:18
*** takamatsu_ has quit IRC17:21
*** takamatsu_ has joined #openstack-nova17:22
*** dtantsur is now known as dtantsur|afk17:23
*** erlon has joined #openstack-nova17:23
*** takamatsu_ has quit IRC17:25
*** sdake has joined #openstack-nova17:26
*** takamatsu_ has joined #openstack-nova17:31
*** markvoelker has joined #openstack-nova17:32
mriedemartom: i've got some object equality test utils in my cross-cell resize series, sec17:33
mriedemartom: https://review.openstack.org/#/c/627892/15/nova/tests/unit/conductor/tasks/test_cross_cell_migrate.py@19317:36
*** dpawlik has joined #openstack-nova17:43
mriedemdansmith: random question, when detaching the root volume of a server and attaching a new root volume, would you expect the device name on that bdm to change? or remain vda or whatever?17:44
mriedemi would expect it to *not* change17:44
mriedemsince the boot_index is still 017:44
mriedemand the disk_bus and device_type can't change17:44
*** takamatsu_ has quit IRC17:46
*** takamatsu_ has joined #openstack-nova17:48
sean-k-mooneymriedem: i think the only time we would expect that it could change would be a rebuild with a different image or perhaps a volume retype operation. so if your question was related to the cross cell resize i think that is a safe assumtion to make17:49
mriedemit's not17:50
mriedemit's for Kevin_Zheng's root bdm attach/detach series17:50
sean-k-mooneyoh ok17:50
sean-k-mooneyam well if you detach attach anoth volume and then attach the root again i guess it could change17:51
*** _fragatina_ has quit IRC17:51
sean-k-mooneyi dont know that code that well however17:51
*** dpawlik has quit IRC17:52
mriedemhttps://review.openstack.org/#/c/614750/34/nova/compute/manager.py17:52
mriedemif i boot from volume and get vda, then attach a data volume which is vdb, then detach the root volume and attach another root volume, would i expect to have that as vda or vdc?17:52
mriedemi would expect vda because the root volume being higher than the data volume seems wrong17:53
dansmithmriedem: yeah, expect the name to remain stable17:54
sean-k-mooneymriedem: that might depend on the os and the udev rules. but i would expect it to stay the same. i dont know if it actully would17:54
* sean-k-mooney reads matts initall comment17:55
mriedemwell, we also don't guarantee the device name the user requests is honored by the hypervisor anyway17:56
artommriedem, interesting, but I feel like that's specific to what you're doing with them (which is fine!)18:01
*** derekh has quit IRC18:01
*** ralonsoh has quit IRC18:02
sean-k-mooneymriedem: for the detach attach root volume spec18:02
sean-k-mooneymriedem: is it the same volume or can it be any volume that is reattached18:02
artomAnd as far as I can tell _assertEqualObjects doens't handle nested objects18:02
artomAnyways, as I said, it's an annoyance, but a minor one, though it might be worth it to put in the time to do it properly in a single place so that we stop fixing this each in our little corners18:03
sean-k-mooneymriedem: im wondering if we supprot reading the hw_disk_bus key form image metadata on a volume18:04
sean-k-mooneyi think the answer is no but im checking18:04
*** takamatsu_ has quit IRC18:05
*** sdake_ has joined #openstack-nova18:05
*** markvoelker has quit IRC18:05
*** sdake has quit IRC18:07
*** sdake_ has quit IRC18:10
*** takamatsu_ has joined #openstack-nova18:10
openstackgerritMerged openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge)  https://review.openstack.org/63909918:10
*** sdake has joined #openstack-nova18:11
sean-k-mooneymriedem: it looks like we can get the image meta form the volume https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/utils.py#L92818:11
sean-k-mooneymriedem: so if we are allowing attaching an arbiatry volume as the new root volume the diskbus could change18:12
sean-k-mooneyif it has to be the same volume it wont18:12
sean-k-mooneythat is called form https://github.com/openstack/nova/blob/5a09c81af3b438ecbcf27fa653095ff55abb3ed4/nova/compute/api.py#L105718:14
*** takamatsu_ has quit IRC18:14
*** sdake_ has joined #openstack-nova18:15
*** Swami has joined #openstack-nova18:15
*** sdake has quit IRC18:16
*** mvkr has quit IRC18:16
*** tesseract has quit IRC18:18
*** takamatsu_ has joined #openstack-nova18:20
*** sdake_ has quit IRC18:20
*** sdake has joined #openstack-nova18:22
sean-k-mooney mriedem: ah never mind the propsed change stats the detach will be garded by the instance being shelve offloaded18:24
sean-k-mooneyill update my comment on the patch18:24
sean-k-mooneyoh thats the mitaka spec...18:25
*** sdake has quit IRC18:26
*** sdake_ has joined #openstack-nova18:26
sean-k-mooneythe stein spech allow detach when the instance is powered off which may not work if the iamge changes18:27
*** wolverineav has joined #openstack-nova18:27
openstackgerritMerged openstack/python-novaclient master: Handle unicode multi-byte characters  https://review.openstack.org/63294218:32
*** mvkr has joined #openstack-nova18:33
*** wolverineav has quit IRC18:35
melwitto/18:35
sean-k-mooneymelwitt: o/18:35
*** sdake_ has quit IRC18:35
*** sdake has joined #openstack-nova18:36
openstackgerritMerged openstack/nova master: Pass resource provider mapping to neutronv2 api  https://review.openstack.org/61624018:36
openstackgerritMerged openstack/nova master: Recalculate request group - RP mapping during re-schedule  https://review.openstack.org/61952918:36
openstackgerritMerged openstack/nova master: Add microversion to expose virtual device tags  https://review.openstack.org/63194818:36
openstackgerritMerged openstack/nova master: api-ref: mark os-cells as deprecated  https://review.openstack.org/63670818:36
openstackgerritMerged openstack/nova master: Replace ansible --sudo with --become in live_migration/hooks scripts  https://review.openstack.org/63530818:36
*** wolverineav has joined #openstack-nova18:37
*** macza has quit IRC18:39
*** bnemec has quit IRC18:40
*** sdake has quit IRC18:41
*** sdake_ has joined #openstack-nova18:41
*** macza has joined #openstack-nova18:41
*** IvensZambrano has quit IRC18:42
*** bnemec has joined #openstack-nova18:45
*** sdake_ has quit IRC18:45
*** sdake has joined #openstack-nova18:47
*** tssurya has quit IRC18:47
*** belmorei_ has joined #openstack-nova18:48
openstackgerritAndrey Volkov proposed openstack/nova master: Check hosts have no instances for AZ rename  https://review.openstack.org/50920618:48
*** jmlowe has quit IRC18:49
mriedemsean-k-mooney: yeah it can be a different volume18:49
*** takamatsu_ has quit IRC18:50
*** sdake has quit IRC18:50
sean-k-mooneymriedem: do you think my concern regarding powered off instance is vlaid18:50
sean-k-mooneymriedem: i updated the comment on the patch18:51
mriedemhow would powered off be different from when we unshelve the instance with a new root volume?18:51
sean-k-mooneya powered off instace is associated with a host18:52
sean-k-mooneywe read the image metadata form volumes18:52
sean-k-mooneyso if you can change the voluems you can change the requirement for the host18:52
*** sdake has joined #openstack-nova18:52
sean-k-mooneyin unshevle we will hit the schuler18:52
sean-k-mooneybut for powered off instnace we dont18:52
sean-k-mooneywhen we we start it again that is18:53
*** jmlowe has joined #openstack-nova18:53
*** efoley has quit IRC18:54
mriedemyes i see the issue, but i don't think he's reading the new root volume image_meta on unshelve either,18:55
*** sdake has quit IRC18:55
sean-k-mooneya concreate example would be if the instance was pinned and the original volume was create from an image with hw:numa_nodes=1 and the new volume was created form an iamge with hw:numa_node=2 it will invalidate the pinnings18:55
mriedemso as far as i know when we unshelve we're not using the new image meta anyway18:55
sean-k-mooneyoh well it could be broken in both cases18:56
*** takamatsu_ has joined #openstack-nova18:56
sean-k-mooneyi didnt actully check the code18:56
*** sdake has joined #openstack-nova18:56
sean-k-mooneywe do get the metadata from the volume when initally spawning the instace18:56
mriedemyeah i know, and on rebuild18:57
sean-k-mooneyi assume we would do it again on unselve but maybe not18:57
mriedemno,18:58
mriedembecause on unshelve you either boot from the shelve snapshot (if not volume-backed), otherwise you boot from the root volume,18:58
mriedemwhich before this couldn't change18:58
sean-k-mooneyright but on unselve we would have hit the schuler right. i guess it uses the embeded image metadata so it does not have to go back to cinder18:59
*** belmorei_ has left #openstack-nova18:59
mriedemyes unshelve hits the scheduler18:59
mriedemand it would use whatever is in the request spec from the original server create19:00
mriedemwhich uses the volume image meta here https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/compute/api.py#L88619:00
*** sdake has quit IRC19:01
sean-k-mooneyya. so we could enable this to work for unselve by updating the request spec or just regtiving the metadata form the volume but i dont know how to "fix" start of a powered off instance19:01
sean-k-mooney i would expect the image to go into an error state on start if its requirements chagne19:01
sean-k-mooneybut that is not very friendly19:01
sean-k-mooneyor start with the old requirement i guess19:02
*** sdake has joined #openstack-nova19:02
mriedeminititally the spec never said anything about supporting detach/attach of the root volume for powered off instances19:02
mriedemonly shelved offloaded19:02
mriedemwhich is how hpe wrote it up long ago19:02
sean-k-mooneyyep in mitaka19:02
mriedemi do remember that the RequestSpec.image.id is *not* set for volume-backed servers, so some of our scheduler filters don't work on volume-backed servers19:03
mriedemlike IsolatedHostsFilter19:03
mriedemduring server create, we do calculate the numa topology requirements from the flavor and image meta, and for volume-backed we get that image meta from the root volume, like you said19:04
mriedemso technically on unshelve we could screw up and not honor the image meta in the new root volume19:04
mriedemb/c we don't update the request spec19:04
*** sdake has quit IRC19:05
sean-k-mooneyright.  i think that is just an oversight however. e.g. readign the spec i would have assume we woudl cater for that edgecase in the implemnation and they jsut chose not to document it in the spec19:05
*** sdake has joined #openstack-nova19:06
mriedemi wouldn't be so sure19:06
sean-k-mooneyanyway it looks like newton was still only allowing this for shelved instance so its only allowed for powered off instance in the stein spec19:06
mriedemi'm pretty sure i didn't think about the root image meta changing when s10 pushed for supporting attach/detach of the root volume on stopped instances19:07
sean-k-mooneymriedem: im giving people the benifit of the doubt but perhaps it was not taught of19:07
*** igordc has joined #openstack-nova19:07
sean-k-mooneyso with 2 weeks to feature freeze i dont really want to reopen the design of this given how long people have been waiting for it.19:09
sean-k-mooneyi could propose a revision to the spec to reduce it to only shelved insntace  or to document the behavior that will happen for poered off instace19:10
*** sdake has quit IRC19:11
sean-k-mooney*powered off19:11
sean-k-mooneyim going to grab dinner but ill be back in an hour or so19:11
sean-k-mooneyactully i have to push a small revision to a patch then dinner19:12
*** sdake has joined #openstack-nova19:13
mriedemsean-k-mooney: i commented on https://review.openstack.org/#/c/614750/ as well to recap our irc discussion. i'll talk with Kevin_Zheng about it tonight since we have a meeting anyway19:13
mriedemi don't think we can support the stopped case - that would essentially get us back to volume-backed rebuild with a new image that we don't really honor19:14
*** sdake has quit IRC19:15
*** sdake_ has joined #openstack-nova19:15
sean-k-mooneymriedem: ya that was my feeling too but i could see use allowing it and refusing to boot the instacne if the requirement could not be supported19:16
*** eharney has joined #openstack-nova19:16
sean-k-mooneythat felt overly complicated however19:16
sean-k-mooneymriedem: can we shelve a powered off instance?19:16
mriedemyes19:17
mriedemwhich i think i said in the spec review when this came up,19:17
mriedemjust stop the instance, shelve it, swap the root volume, and unshelve,19:17
sean-k-mooneyok so you jsut need to shelve it and then unshelve after changing volumes and you can more or less achive the same use case19:17
mriedembut people thought that was too complicated19:17
sean-k-mooneyperhaps but ill take complicated over broken any day19:18
*** sdake_ has quit IRC19:20
mriedemsean-k-mooney: i guess i did think about this https://review.openstack.org/#/c/600628/7/specs/stein/approved/detach-boot-volume.rst@12719:22
*** _fragatina has joined #openstack-nova19:22
sean-k-mooney mriedem ya looks like you did but it never  made it into the spec in the end.19:25
sean-k-mooneymriedem: atleast a concreate proposal for what to do in this case was not added to the spec. your comment are obviously there19:26
openstackgerritsean mooney proposed openstack/os-vif master: modify functional base.py to allow using vscode  https://review.openstack.org/63805819:28
mriedemyeah i just don't want to get into a case where someone swaps the root volume on a stopped instance, then they rebuild it with what they thought was the original volume and rebuild blows up saying you can't rebuild a volume-backed instance with a new image, or they pass the image_id of the new root volume and the scheduler kicks it out saying it's not valid for the current host19:30
mriedems/original volume/original image/19:30
*** IvensZambrano has joined #openstack-nova19:40
*** markvoelker has joined #openstack-nova20:02
openstackgerritMerged openstack/nova master: quota: remove QuotaEngine.register_resources()  https://review.openstack.org/61561320:04
*** IvensZambrano has quit IRC20:15
*** jmlowe has quit IRC20:21
*** dosaboy has quit IRC20:34
*** dosaboy has joined #openstack-nova20:36
*** markvoelker has quit IRC20:36
*** dosaboy has quit IRC20:37
*** wolverineav has quit IRC20:37
*** wolverineav has joined #openstack-nova20:37
*** ccamacho has quit IRC20:39
*** wolverineav has quit IRC20:39
*** _hemna has joined #openstack-nova20:41
*** dosaboy has joined #openstack-nova20:46
*** ivve has quit IRC20:50
*** _hemna has quit IRC20:50
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.openstack.org/63566920:51
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source  https://review.openstack.org/63482720:51
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source  https://review.openstack.org/63482820:51
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source  https://review.openstack.org/63522920:51
openstackgerritArtom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration  https://review.openstack.org/63460520:51
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP needs more tests] Full NUMA live migration support  https://review.openstack.org/63460620:51
artomSo that was "sync" push - let's run this in my test env to see what I've broken20:51
dansmithdang20:57
dansmithI was just working my way through them20:57
dansmithnow I have to start all over aain20:57
dansmithguess I'll wait for next monay20:57
dansmithalso, wtf is up with my keys20:57
*** agopi has quit IRC20:58
sean-k-mooneydansmith: are you on vacation until monday? or just monday is the next time you will be able to review it20:58
sean-k-mooneydansmith: just wondering if you will be around later in the week is all20:59
*** agopi has joined #openstack-nova20:59
artomdansmith, I'm sorry, are you asking for "monay"? I thought RH payed you well ;)20:59
*** jobewan has quit IRC21:00
*** wolverineav has joined #openstack-nova21:00
dansmithartom: monay monay21:01
artomIt's a Smith-man world!21:01
dansmithsean-k-mooney: I'm giving artom a hard time implying that I only review large, late patch series on monday mornings21:01
sean-k-mooneyhehe in that case feel free to add my/adrianc's sriov patch set to that list :P21:02
sean-k-mooneybut on a serios note artom i deployed v21 on friday21:02
sean-k-mooney*serious21:02
artomv21?21:03
sean-k-mooneyam ill redeploy tomorow ish do you think it will change much21:03
sean-k-mooneythis was the top patch in the series on friday https://review.openstack.org/#/c/635229/2121:05
artomsean-k-mooney, dunno, lemme run my tests against what I have now, see what breaks21:05
sean-k-mooneyit looks like https://review.openstack.org/#/c/634606/30 is not the top patchset in the series21:05
artomsean-k-mooney, that's changed. Claim creating and cleanup needs to happen in the same patch, along with a version bump because we need to check that source and/or dest support claims21:06
*** agopi_ has joined #openstack-nova21:07
*** jmlowe has joined #openstack-nova21:07
sean-k-mooneyright but https://review.openstack.org/#/c/634606/30 is now the final patch in the series right21:07
*** gokhani has quit IRC21:07
artomSo there's 2 service bumps to keep the patches reasonnably sized21:07
artom1 for the RPC stuff21:07
artomAnd 1 for the final "we support NUMA LM" switchover21:07
artomsean-k-mooney, correct21:08
artomThe overall mechanics haven't really changed, but they way they're presented/ordered and some details have21:08
sean-k-mooneyi can put off deploying the it for another few days and just to a code review tomorow and focus on other tasks if that helps. it will take me the better part of a day to run all the test i want too on it so i was going to wait till it sables a bit more21:09
*** agopi has quit IRC21:10
*** kashyap has quit IRC21:10
artomsean-k-mooney, your call, really. Ideally any tests that are missing from https://review.rdoproject.org/r/#/c/18832/ would get added there, so that we don't have to manually redo everything everytime there's a new patchset21:10
sean-k-mooneyartom: ok what i want to be able to do is send an email to the list and say i test all these senarios with this reviesion and heres what work and didnt21:10
sean-k-mooneythere are quite a lot of tests that arent covered21:10
artomFor instance, I realized I wasn't saving the new instance numa topology (fixed now), so I should add that to the tests21:11
*** jobewan has joined #openstack-nova21:11
artomsean-k-mooney, oh I'm sure there are :) So... if you like it, just add them directly, or just write them out in English and I'll code them up21:12
sean-k-mooneyi might spend some time writing automated test but i also want to manually run them and verify it.21:12
mriedemefried: jaypipes: i've gone through the next bw provider change in the series https://review.openstack.org/#/c/622421/ - i might be overly harsh on this one21:12
openstackgerritMerged openstack/nova master: conf: Deprecated 'defer_iptables_apply'  https://review.openstack.org/44543621:13
*** agopi__ has joined #openstack-nova21:13
*** agopi_ has quit IRC21:16
*** agopi__ is now known as agopi21:16
jaypipesmriedem: I'm still trudging through them... sorry for the slowness. :(21:20
mriedemthat's fine21:21
mriedemi'm about reviewed out for the day21:21
*** cfriesen has joined #openstack-nova21:21
sean-k-mooneyjaypipes: hi am do you want to pushout the os-vif release to tomrow morning. i can send an update to the list with where things are or should i propose a relase with the current master.21:22
sean-k-mooneyjaypipes: i would like to get the new release into the gate by tomorrow at the latest but we should be ok to wait anouter few hours e.g. till US moring to tag21:23
jrolldansmith: on https://review.openstack.org/#/c/635006 , this code path is in a periodic. so if we explode, the nova-compute won't crash, just won't expose any resources. that okay with you?21:27
*** sdake has joined #openstack-nova21:28
dansmithjroll: I mean, if it's a case that makes sense to not do anything then sure21:28
jrolldansmith: reworded, do you think operators will see that problem if nova-compute keeps running?21:29
jaypipessean-k-mooney: yes, that would be good if we can delay one more day.21:29
dansmithjroll: I mean, it's the same deal as if they mis-configured with nothing in that list right?21:29
dansmithjroll: obviously it should be error-logged21:30
jrolldansmith: right, I mean if it's unset21:30
sean-k-mooneyjaypipes: sure. i just want to have 1-2 days of gate time before the non-client lib freeze.21:30
jaypipesack21:31
sean-k-mooneyjaypipes: ill propose a patch and -w flow it with the current master and ill updated it tommorow once that feature lands. ill update teh list with all this soon21:31
jaypipes++21:31
*** markvoelker has joined #openstack-nova21:33
dansmithjroll: if we have no other option than to log errors in each periodic, then, I think that's about all we can do21:33
dansmiththat said,21:33
dansmithwe have a place for the virt driver to run during host init, and you could sanity check config there and explode to stop nova-compute I think21:34
dansmithjroll: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L120221:34
jrolldansmith: ah, good point, I'll do that instead. thanks.21:35
*** wolverineav has quit IRC21:42
cfriesenmriedem: sean-k-mooney: For the vTPM stuff,  do we need to be fully feature-complete to merge anything?  Or could we review the currently proposed code and then do a followup commit to make cold migrations work?21:42
*** wolverineav has joined #openstack-nova21:42
sean-k-mooneywell we can review the code but how is the feature enabled. e.g. will the ablilty to request a vTPM only be enable with the colde migrate code or will it be enabled in an early patch21:43
sean-k-mooneycfriesen: also how likely is it that the coldmigrate code will be ready in the next 2 weeks?21:44
sean-k-mooneycfriesen: is this the full series https://review.openstack.org/#/q/topic:bp/add-emulated-virtual-tpm+(status:open+OR+status:merged)21:46
*** rcernin has joined #openstack-nova21:46
*** whoami-rajat has quit IRC21:47
*** sdake has quit IRC21:48
sean-k-mooneycfriesen: i think we still plan to merge the bwandwith based schduleing patch without migration support but in the case of vTPM livemigration will work right since the vTPM data is copied by qemu it will jsut be colde migrate that is missing?21:49
cfriesensean-k-mooney: paul-emile got moved internally, so I get to do it now.  I'm ramping up, but I think there's a small piece missing to enable the functionality via image property and a piece missing for cold migration.21:49
cfriesensean-k-mooney: with our earlier implementation live migration just worked, I'm hoping that'll still be true.21:50
cfriesensean-k-mooney: crap, you're right.  there's a bit missing to actually enable it.21:52
cfriesenminor detail. :)21:52
melwittit's true we're planning to merge bw based scheduling without migration support but we're able to reject it via 403 error (I think is the plan that was landed on?) to be enabled later21:52
sean-k-mooneyright so i havent looked at this properly since looking at the spec.21:52
sean-k-mooneycfriesen: so your in luck i have a dev env that i was usign to test artoms numa livemigration stuff that a knew enought version of qemu and libvirt21:53
sean-k-mooneycfriesen: i can try and test this tommorw21:54
melwittwould the vTPM stuff be able to do similar? we'd have to get some consensus about what to do, if so21:54
cfriesensean-k-mooney: okay, I'll try and get you something usable.21:54
sean-k-mooneymelwitt: we might be able to21:55
cfriesenmelwitt: currently the code automatically advertises vTPM support if qemu/libvirrt is new enough, but we could add a config option to disable that.21:56
sean-k-mooneymelwitt: we can certenly put a check in the conductor to reject the migration if we dont have the support21:56
*** takashin has joined #openstack-nova21:56
cfriesenyeah, we could do the conductor change too21:56
* mriedem throws up in mouth over all of the conditional support we have now21:56
sean-k-mooneycfriesen: the cold migration support should be fairly stright forward right21:57
sean-k-mooneycfriesen: you just need to coppy the backing file for the vtpm?21:57
melwittyeah... config option for the support isn't something appealing21:57
cfriesensean-k-mooney: pretty much, yeah.21:57
melwittit wouldn't be able to reject before conductor? not in the API?21:57
sean-k-mooneymelwitt: we dont really want to do a virt dirver specific check in the api21:57
mriedemsurprise surprise everyone, resize/cold migrate is an RPC call from api to conductor21:58
mriedemso in that case, conductor is the api21:58
melwittyeah, like isn't conductor also not a good place to do a virt driver specific check?21:58
sean-k-mooneyyes21:58
sean-k-mooneyi was about to say that21:59
melwittok21:59
sean-k-mooneythe condoctor call can live migrate dest/source on the dirver21:59
sean-k-mooneythat is where the actual check woudl have to go21:59
melwittah, ok21:59
mriedemcurrently the numa checks happen in conductor21:59
mriedemvgpus also landed in queens with a bunch of caveats https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#caveats21:59
mriedemfor resize21:59
sean-k-mooneymriedem: ya we could put the with the numa stuff21:59
mriedemdo those not also apply to vtpm, i.e. you can resize but it doesn't transfer your stuff, so you have to rebuild after that - which sucks22:00
sean-k-mooneybut numa worksi in hyperver and nova. actull vtpm technically is support in hyperv too22:00
openstackgerritJim Rollenhagen proposed openstack/nova master: ironic: partition compute services by conductor group  https://review.openstack.org/63500622:00
*** agopi has quit IRC22:00
mriedemwith 2 weeks left i don't really want to have to think about hacking in a half-baked feature22:01
mriedemi'd rather just defer to train22:01
mriedemwhen you can do something with the actual server that has vtpm22:01
sean-k-mooneycfriesen: ill need to check the spec but what did we say we woudl do for shelve ecrta22:01
cfriesenokay.  I'll try hard to get it all working then.22:01
mriedemsean-k-mooney: i believe the spec punted on shelve22:02
cfriesenpretty sure we said shelve *could* be supported by saving the TPM data as a glance image.22:02
cfriesenbut that we weren't planning on doing that22:02
cfriesensince shelve is already broken for UEFI NVRAM22:02
sean-k-mooneymriedem: right so we always  defered part of it to after stien22:03
sean-k-mooneycfriesen: right but i assume you would like to fix those edgecase in trian?22:03
*** sdake has joined #openstack-nova22:03
cfriesensean-k-mooney: I personally would love to.  I don't think shelve is a big deal for our customers though.22:03
sean-k-mooneycfriesen: or rather you would like them to be fix but dont nessisarily want to have to be the one to fix them :)22:03
mriedemwindriver doesn't shelve so it doesn't matter to them22:03
*** markvoelker has quit IRC22:04
sean-k-mooneyso to summerise i get that the preference would be to punt unless both cold/live migrate and resize work by the end of the week?22:05
*** sdake has quit IRC22:05
mriedemi only have personal preferences22:06
mriedemand right now i feel the crushing weight of a deluge of last minute blueprints that need review right before FF22:07
*** sdake has joined #openstack-nova22:07
dansmithseriously, why are we even considering adding something we know we haven't fully implemented and thus can't move?22:07
dansmithwe already have an embarrassing number of "yeah this works, BUT YOU CAN NEVER MOVE IT" things, IMHO22:08
sean-k-mooneydansmith: well live migration should work22:08
sean-k-mooneyits just cold/rezise but fair point22:08
*** mrjk_ has joined #openstack-nova22:08
sean-k-mooneyfor livemigrat qemu copies the vtpm data iteslf but for cold we have to do it if i remember correctly22:08
melwittmriedem: I guess this convo is as good segue as any to something I was thinking about, FFE process. do we want to do the ML post, etherpad request, sponsor gathering process we have done in the past?22:10
*** mrjk has quit IRC22:10
dansmithsean-k-mooney: so just the thing that *most* users will be able to trigger?22:10
*** sdake has quit IRC22:10
*** imacdonn_ has joined #openstack-nova22:10
*** artom has quit IRC22:10
sean-k-mooneydansmith: yes. i am actully feeling that we should punt unless it works too but it also seams quite small22:11
*** imacdonn has quit IRC22:11
*** s10 has joined #openstack-nova22:11
sean-k-mooneyworks -> is feature complete includign move operations22:11
*** wolverineav has quit IRC22:12
*** _alastor_ has quit IRC22:13
sean-k-mooneycfriesen: in anycase if you have someting that works im happy to test it with the other live migration feature im planning to test.22:13
*** wolverineav has joined #openstack-nova22:13
cfriesensean-k-mooney: appreciated.22:13
sean-k-mooneycfriesen: i get the feeling all of them will be punted to train m1 however22:13
*** sdake has joined #openstack-nova22:13
*** sdake has quit IRC22:13
cfriesen:)22:13
sean-k-mooneyif we can get numa/sriov/cross-cell migration landed in m1 with vtpm and bandwith mover opertion that would be a.) alot of work and b.) alot of valuable features landed early/late depending on your view point22:16
*** erlon has quit IRC22:17
*** hongbin has joined #openstack-nova22:17
dansmithmelwitt: what are the things that are realistically candidates for FFE?22:17
*** agopi has joined #openstack-nova22:19
*** _alastor_ has joined #openstack-nova22:20
mriedemjaypipes: good question on "wtf happens if the port is detached (or deleted) out of band while it has allocations"22:20
*** _alastor_ has quit IRC22:20
mriedemjaypipes: i replied, but tl;dr - we don't handle it,22:20
mriedemand it really kind of sucks that we (nova) are the ones managing that22:21
sean-k-mooneyif you delete it in neutron the send an event to nova which causes it to be detach form the vm22:21
mriedembzzt!22:22
mriedemthe nova code relies on getting the allocation information from the port's binding:profile22:22
mriedemso if the port is deleted, we can't very well look it up22:22
sean-k-mooneywell it should be in the network info cache but yes that might be an issue22:22
mriedemso either neutron needs to cleanup the allocation, or we have to store information about the allocation in the info cache22:23
mriedemnone of this is in the info cache22:23
mriedemnone of the requested resources / allocations stuff22:23
mriedemi've asked gibi about that a few times, i.e. "you know if we just stored x in the info cache we could use it here rather than calling neutron"22:23
sean-k-mooneyi had tought the vif:port_profile was in the vif object in the info cache but maybe not. i havent looked at it in a while22:24
melwittdansmith: well, I'm not sure who would request one, but I thought maybe the detach root volume bp or volume-backed rebuild, or other smaller things like adding numa topo or server group to 'nova show'22:24
mriedemsean-k-mooney: oh i guess it is, the binding:profile that is22:24
mriedemi'm not sure it would be up to date...22:24
mriedemmelwitt: the volume backed rebuild isn't happening i don't tink22:25
mriedem*think22:25
sean-k-mooneywe sore https://github.com/openstack/nova/blob/master/nova/network/model.py#L378-L40022:25
dansmithmelwitt: okay both of those seemed to be too far and too large to be FFE material to me,22:25
sean-k-mooneywhich has the profile in it22:25
dansmithbut granted I've been a bit disconnected22:25
mriedemand i'll be talking about root volume detach with Kevin_Zheng tonight but there are going to be issues with that as well22:25
dansmithto me, FFE is for the final push for something that is almost done and I guess nothing pops out in my head at the moment as obviously fitting that description22:25
mriedemsean-k-mooney: yeah i know yo'ure right, so we might be able to handle the port getting deleted there22:25
mriedemsean-k-mooney: if the cache is up to date22:26
melwittlooks like the FFE process is supposed to kick in the week after freeze anyway, so I guess I'm thinking about it too early https://docs.openstack.org/nova/latest/contributor/process.html#non-priority-feature-freeze22:26
mriedemwell how many weeks are there between FF and RC1?22:26
mriedemif it's 2, there isn't really time for FFE unless like dansmith it's a low risk change that is already there22:26
melwitt222:27
melwittok. last cycle I didn't raise the FFE process because I assumed there wasn't enough time and this time I wanted to make sure I brought it up22:28
sean-k-mooneyso the event we get i think will be a network-vif-unplugged event which is handeled by the periodic task the updated the network info cache. we might be able to hook that event in the periodic job to do the clean up22:28
sean-k-mooneyi can try and take a look at that code tomrrow. im a bitt too tired to look this evening22:29
mriedemis it network-vif-unplugged or network-changed?22:29
mriedembecause we do different things in that ase22:29
mriedem*case22:29
*** avolkov has quit IRC22:30
mriedemanyway, i left comments on https://review.openstack.org/#/c/622421/ so gibi can sort it out and at least leave TODOs to handle those22:30
sean-k-mooneyi think you will get both. you will get an network-vif-unpluged for the ovs agent when it tears down the port and a newtork-changed event form the deletion22:30
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147422:31
mriedemoh i was talking about the case that someone (the admin?) sets the device_id on the port to None/''22:31
mriedemso the port isn't deleted, it's just detached from the server22:31
mriedemgranted one should probably never do that, and cinder doesn't allow you to detach like that (unless you force it)22:32
sean-k-mooneyoh am a.) the whould not do that  :) and b.) ... i can test that tomorrow and let you know what happens. neutron will allow note allow you to set it to the python None but it will allow you to set it to the string "None"22:33
sean-k-mooney* a.) they should not...22:34
mriedemmelwitt: the api change for this is merged https://review.openstack.org/#/c/636779/ so if you get a minute can you review the novaclient change, it should be pretty simple22:41
mriedemi'm taking that one out of runways though22:41
mriedemtakashin: ^22:41
melwittmriedem: ok, can do. thanks22:41
takashinmriedem: Okay. I will review it.22:42
mriedemthanks22:42
openstackgerritMerged openstack/nova master: Send RP uuid in the port binding  https://review.openstack.org/56945922:43
openstackgerritMerged openstack/nova master: Test boot with more ports with bandwidth request  https://review.openstack.org/57331722:44
openstackgerritMerged openstack/nova master: Use placement.inventory.inuse in report client  https://review.openstack.org/56863922:47
melwittpy27: commands succeeded22:50
melwittcongratulations :)22:50
melwitt*eyes shimmering*22:51
sean-k-mooneymelwitt: :) what patch are you working on ?22:53
melwittcounting quota usage from placement22:53
melwittwhen I see those green messages it's just like.... yess22:53
sean-k-mooneyand that is always nice to see but it kill me when pythone 3 fails after python 2 passes22:53
melwittoh yeah. that's bitten me before22:54
*** tkajinam has joined #openstack-nova22:57
*** markvoelker has joined #openstack-nova23:01
openstackgerritChris Friesen proposed openstack/nova master: Flavor extra spec and image properties validation  https://review.openstack.org/62070623:02
*** _alastor_ has joined #openstack-nova23:03
yonglihemriedem: just  rebase  to new microversion. zuul running.23:04
mriedemyonglihe: yup i saw23:04
cfriesenFYI, in the context of this ^ commit, I'm taking over from jackding.23:04
sean-k-mooneycfriesen: ok. are you the only windriver person working on nova currently again?23:05
sean-k-mooneycfriesen: als that is targetign train right? stephen has reproposed the spec for train23:06
cfriesensean-k-mooney: there are a couple other guys that will hopefully pop their heads up. :)23:06
cfriesensean-k-mooney: that's targetting stein and is currently on a runway23:07
cfriesensean-k-mooney: stephen proposed a whole separate thing for train23:07
sean-k-mooneyoh ok23:07
sean-k-mooneyill also try and review that tomorrow so.23:07
sean-k-mooneyanyway ill call it a day there o/23:08
cfriesensean-k-mooney: I just took a quick look at it, need to review it fully.  looks like he's proposing defining a proper generic schema for the various properties/extra-specs23:08
cfriesensean-k-mooney: later23:08
sean-k-mooneystephenfin: spec23:08
sean-k-mooneyya so there is a glance api we could already use23:09
sean-k-mooneybut we migth want to seperate it out into a reusable lib or something23:09
sean-k-mooneyhe would like to have a single source to both use for validation and documentaiton generation acorss favor extraspec/image metatdata/volume metadata23:10
*** awaugama has quit IRC23:10
sean-k-mooneythe glance metadef api does that allready but he is also considering other options23:10
*** _alastor_ has quit IRC23:13
*** _alastor_ has joined #openstack-nova23:14
*** _alastor_ has quit IRC23:16
*** mlavalle has quit IRC23:16
*** cfriesen has quit IRC23:16
*** _alastor_ has joined #openstack-nova23:17
*** cfriesen has joined #openstack-nova23:17
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147623:17
*** _alastor_ has quit IRC23:17
aspierswho's our resident KVM / machinetype expert?23:18
aspiersI've just discovered a snag with SEV detection23:18
aspierslibvirt's virConnectGetDomainCapabilities() API requires specifying a particular arch and machine type23:19
mriedemaspiers: hook up with kash23:19
mriedemkashyap23:19
aspiersmriedem: thanks23:19
*** mlavalle has joined #openstack-nova23:20
aspiersso the results presumably could vary per architecture and machine type, although in practice it seems that if the SEV feature is supported, it is supported across all (arch, machine type) pairs the host provides23:20
aspiersbut in order to detect the SEV capability (and provide a trait), this API call needs to be done during initHost() where arch/machtype is not known, rather than just before booting an instance when it is known23:21
aspierssince currently this getDomainCapabilities API call is only used for SEV detection and nothing else, I could hardcode it to x86_64 and a single machine type23:22
*** _alastor_ has joined #openstack-nova23:22
aspiersbut that seems a bit ugly23:22
aspiersor I could call it once for each (arch, machine type) the host provides, and then if SEV is supported for any one of those tuples, mark the SEV capability as supported for the host23:23
aspiersbut kashyap isn't currently here it seems ...23:24
*** awalende has joined #openstack-nova23:31
melwittkashyap is EU time zone23:32
aspiersmelwitt: OK thanks23:33
*** markvoelker has quit IRC23:34
*** s10 has quit IRC23:34
*** awalende has quit IRC23:35
cfriesenaspiers: don't we specify arch in the nova config?23:36
aspierscfriesen: I don't think so23:37
aspiersbut actually it's only one of two possibilities in the libvirt driver23:38
aspierscfriesen: https://github.com/openstack/nova/blob/c7f0d160e4df95cc82706bcd8c4a9890a4dfeb51/nova/virt/libvirt/driver.py#L43823:39
aspiersso I can iterate over those two, but that still leaves the question of machine type23:39
aspiersof which there are a zillion23:39
cfriesenaspiers: ah...I was actually thinking of the "hw_machine_type" config option23:39
aspiersah yeah, that's different23:40
aspiersand that's only a default23:40
cfriesenright23:40
aspiersbut it seems wrong to call the virConnectGetDomainCapabilities API twice for each known machine-type23:40
aspierswell not wrong, but inelegant at least23:40
aspiersand expensive23:41
aspiersnot that initHost() happens often, but still ...23:41
cfriesenthat is kind of icky.  what if you stopped as soon as you got SEV supported for one machine type?23:41
aspierswell sure, could do that, but if I'm going to hardcode an assumption that this API call is only used for SEV capability detection then I could make it even simpler23:41
cfriesenI think you could just make a "can host support SEV" call which just checks one known-to-be-valid config23:42
aspiersexactly23:43
aspiersbut then what if something else in the future needs other data from this API?23:43
aspiersor am I prematurely optimizing :)23:43
cfriesenwhich API exactly are you talking about?23:43
aspiersthe one above23:44
aspiersvirConnectGetDomainCapabilities23:44
aspiersactually I think I've just discovered a bug in libvirt23:44
aspiersvirsh domcapabilities --virttype kvm --emulatorbin /usr/bin/qemu-kvm --arch x86_64 --machine pc-i440fx-1.4 | xq /domainCapabilities/features/sev/@supported actually returns 'yes'23:45
aspiersbut SEV is not supported unless you use a q35 machine type23:45
* aspiers reports it ...23:46
cfriesenI think you could just add a little helper function in virt/libvirt/guest.py that calls virConnectGetDomainCapabilities, then add another "is sev supported" helper function that calls the guest.py routine and is in turn called from LibvirtDriver.init_host()23:48
openstackgerritChris Friesen proposed openstack/nova master: Improve libvirt image and snapshot handling  https://review.openstack.org/61669223:48
*** _alastor_ has quit IRC23:57
*** _alastor_ has joined #openstack-nova23:58

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