Monday, 2019-01-21

*** slaweq has joined #openstack-nova00:13
*** erlon_ has joined #openstack-nova00:15
*** markvoelker has joined #openstack-nova00:16
*** hongbin has joined #openstack-nova00:18
*** slaweq has quit IRC00:25
*** erlon_ has quit IRC00:48
*** markvoelker has quit IRC00:49
*** takashin has joined #openstack-nova00:55
*** ileixe has joined #openstack-nova00:56
*** slaweq has joined #openstack-nova01:11
*** tbachman_ has joined #openstack-nova01:14
*** tbachman has quit IRC01:17
*** tbachman_ is now known as tbachman01:17
*** slaweq has quit IRC01:25
*** hongbin has quit IRC01:39
*** hongbin has joined #openstack-nova01:41
*** hongbin_ has joined #openstack-nova01:45
*** hongbin has quit IRC01:45
*** markvoelker has joined #openstack-nova01:46
openstackgerritZhenyu Zheng proposed openstack/nova master: Don't call begin_detaching when detaching volume from sheveld vm  https://review.openstack.org/62495902:01
openstackgerritZhenyu Zheng proposed openstack/nova master: Add support matrix for Delete (Abort) on-going live migration  https://review.openstack.org/62578102:01
*** Dinesh_Bhor has joined #openstack-nova02:06
*** Dinesh_Bhor has quit IRC02:06
*** sapd1_x has joined #openstack-nova02:11
*** slaweq has joined #openstack-nova02:16
*** markvoelker has quit IRC02:19
*** Dinesh_Bhor has joined #openstack-nova02:22
*** slaweq has quit IRC02:24
*** mschuppert has quit IRC02:27
*** tiendc has joined #openstack-nova02:36
*** fanzhang has quit IRC03:04
*** psachin has joined #openstack-nova03:04
*** slaweq has joined #openstack-nova03:13
*** markvoelker has joined #openstack-nova03:16
*** slaweq has quit IRC03:24
*** tbachman_ has joined #openstack-nova03:27
*** tbachman has quit IRC03:29
*** tbachman_ is now known as tbachman03:29
*** ircuser-1 has joined #openstack-nova03:31
*** sapd1_x has quit IRC03:38
*** Dinesh_Bhor has quit IRC03:39
*** Dinesh_Bhor has joined #openstack-nova03:43
*** wolverineav has joined #openstack-nova03:47
*** markvoelker has quit IRC03:48
openstackgerritYikun Jiang proposed openstack/nova master: Per aggregate scheduling weight  https://review.openstack.org/62816303:51
*** wolverineav has quit IRC03:51
*** sapd1_x has joined #openstack-nova03:56
*** udesale has joined #openstack-nova04:00
*** udesale has quit IRC04:00
*** udesale has joined #openstack-nova04:01
*** slaweq has joined #openstack-nova04:16
*** slaweq has quit IRC04:24
*** ileixe has quit IRC04:32
*** lpetrut has joined #openstack-nova04:42
*** Dinesh_Bhor has quit IRC04:46
*** tbachman has quit IRC04:52
*** Dinesh_Bhor has joined #openstack-nova04:53
*** ileixe has joined #openstack-nova05:02
*** lpetrut has quit IRC05:05
*** slaweq has joined #openstack-nova05:15
*** Luzi has joined #openstack-nova05:19
*** ratailor has joined #openstack-nova05:23
*** slaweq has quit IRC05:24
*** ratailor_ has joined #openstack-nova05:34
*** ratailor has quit IRC05:37
*** ratailor__ has joined #openstack-nova05:37
*** ratailor_ has quit IRC05:40
*** spsurya has joined #openstack-nova05:40
*** tetsuro has joined #openstack-nova05:45
*** sridharg has joined #openstack-nova06:02
*** tbachman has joined #openstack-nova06:08
*** lpetrut has joined #openstack-nova06:10
*** bhagyashris has joined #openstack-nova06:15
*** Dinesh_Bhor has quit IRC06:16
*** markvoelker has joined #openstack-nova06:16
*** Dinesh_Bhor has joined #openstack-nova06:17
*** hongbin has joined #openstack-nova06:25
*** hongbin has quit IRC06:25
*** hongbin_ has quit IRC06:27
*** egonzalez has quit IRC06:42
*** zioproto has quit IRC06:42
*** mrhillsman has quit IRC06:42
*** johnsom has quit IRC06:42
*** seyeongkim has quit IRC06:42
*** rabel has quit IRC06:42
*** icey has quit IRC06:42
*** ebbex has quit IRC06:42
*** rabel has joined #openstack-nova06:42
*** seyeongkim has joined #openstack-nova06:42
*** zioproto has joined #openstack-nova06:42
*** johnsom has joined #openstack-nova06:42
*** mrhillsman has joined #openstack-nova06:42
*** icey has joined #openstack-nova06:43
*** egonzalez has joined #openstack-nova06:43
*** ebbex has joined #openstack-nova06:47
*** markvoelker has quit IRC06:48
*** rcernin has quit IRC07:00
openstackgerritSagar Waghmare proposed openstack/nova master: Added new repo  https://review.openstack.org/63203107:03
*** pooja_jadhav has joined #openstack-nova07:04
*** wolverineav has joined #openstack-nova07:11
*** wolverineav has quit IRC07:12
*** dpawlik has joined #openstack-nova07:13
*** wolverineav has joined #openstack-nova07:14
*** ccamacho has joined #openstack-nova07:28
*** avolkov has joined #openstack-nova07:41
*** tetsuro has quit IRC07:43
*** slaweq has joined #openstack-nova07:43
*** tetsuro has joined #openstack-nova07:43
*** markvoelker has joined #openstack-nova07:46
*** tetsuro has quit IRC07:47
*** sapd1_x has quit IRC07:47
*** sapd__x has joined #openstack-nova07:47
*** YaWang has joined #openstack-nova07:50
*** jangutter has joined #openstack-nova07:51
*** rpittau has joined #openstack-nova07:54
*** tetsuro has joined #openstack-nova07:55
*** lpetrut has quit IRC07:58
*** tetsuro has quit IRC07:58
*** tetsuro has joined #openstack-nova07:58
*** takashin has left #openstack-nova08:00
*** ratailor_ has joined #openstack-nova08:08
*** ratailor__ has quit IRC08:11
*** tkajinam has quit IRC08:16
*** wolverineav has quit IRC08:18
*** markvoelker has quit IRC08:19
*** yan0s has joined #openstack-nova08:23
*** helenafm has joined #openstack-nova08:24
*** wolverineav has joined #openstack-nova08:26
*** ralonsoh has joined #openstack-nova08:26
*** wolverineav has quit IRC08:28
*** wolverineav has joined #openstack-nova08:29
*** sapd__x has quit IRC08:30
*** sapd__x has joined #openstack-nova08:30
*** wolverineav has quit IRC08:33
*** xek_ has joined #openstack-nova08:42
openstackgerritBhagyashri Shewale proposed openstack/os-resource-classes master: Add PCPU standard resource class  https://review.openstack.org/63171108:46
openstackgerritMerged openstack/gantt master: Retire gantt  https://review.openstack.org/63013808:53
openstackgerritMerged openstack/python-ganttclient master: Retire python-ganttclient  https://review.openstack.org/63015408:53
*** wolverineav has joined #openstack-nova09:05
*** tetsuro has quit IRC09:05
*** tetsuro has joined #openstack-nova09:08
*** tetsuro has quit IRC09:11
*** tetsuro has joined #openstack-nova09:11
*** tetsuro has quit IRC09:14
*** markvoelker has joined #openstack-nova09:16
*** sapd__x has quit IRC09:18
*** Dinesh_Bhor has quit IRC09:21
*** Dinesh_Bhor has joined #openstack-nova09:24
*** wolverineav has quit IRC09:28
*** panda|off is now known as panda09:29
*** sapd__x has joined #openstack-nova09:30
*** derekh has joined #openstack-nova09:38
*** yan0s has quit IRC09:48
*** markvoelker has quit IRC09:49
*** ratailor_ has quit IRC09:52
*** jaosorior has joined #openstack-nova09:53
*** dtantsur|afk is now known as dtantsur09:57
*** bhagyashris has quit IRC09:58
*** cdent has joined #openstack-nova09:59
*** yan0s has joined #openstack-nova10:01
*** ralonsoh has quit IRC10:10
*** ralonsoh has joined #openstack-nova10:11
*** ratailor has joined #openstack-nova10:12
*** openstackgerrit has quit IRC10:21
*** ratailor has quit IRC10:38
*** Dinesh_Bhor has quit IRC10:39
*** wolverineav has joined #openstack-nova10:41
*** cdent has quit IRC10:45
*** markvoelker has joined #openstack-nova10:46
*** ratailor has joined #openstack-nova10:48
*** tetsuro has joined #openstack-nova10:50
*** ratailor_ has joined #openstack-nova10:55
*** ratailor has quit IRC10:57
*** tssurya has joined #openstack-nova10:59
*** ratailor_ has quit IRC11:00
*** ratailor has joined #openstack-nova11:00
*** ratailor has quit IRC11:06
*** pooja_jadhav has quit IRC11:09
*** poojajadhav has joined #openstack-nova11:09
*** cdent has joined #openstack-nova11:10
*** moshele has joined #openstack-nova11:10
*** ratailor has joined #openstack-nova11:13
*** tiendc has quit IRC11:19
*** markvoelker has quit IRC11:19
*** erlon has joined #openstack-nova11:19
*** udesale has quit IRC11:20
*** shilpasd has joined #openstack-nova11:26
*** poojajadhav has quit IRC11:33
*** poojajadhav has joined #openstack-nova11:34
*** ratailor has quit IRC11:36
*** ratailor has joined #openstack-nova11:36
*** lpetrut has joined #openstack-nova11:47
*** poojajadhav has quit IRC11:49
*** sapd__x has quit IRC11:53
*** yan0s has quit IRC11:54
*** openstackgerrit has joined #openstack-nova12:01
openstackgerritsean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf  https://review.openstack.org/62484212:01
openstackgerritsean mooney proposed openstack/nova master: Add free for claimed, allocated devices  https://review.openstack.org/61612012:01
openstackgerritsean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile  https://review.openstack.org/60736512:01
openstackgerritsean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif  https://review.openstack.org/61992912:01
openstackgerritsean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support  https://review.openstack.org/62011512:01
openstackgerritsean mooney proposed openstack/nova master: [WIP] libvirt: auto detach/attach sriov ports on migration  https://review.openstack.org/62958912:01
*** moshele has quit IRC12:04
openstackgerritsean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf  https://review.openstack.org/62484212:05
openstackgerritsean mooney proposed openstack/nova master: Add free for claimed, allocated devices  https://review.openstack.org/61612012:05
openstackgerritsean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile  https://review.openstack.org/60736512:05
openstackgerritsean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif  https://review.openstack.org/61992912:05
openstackgerritsean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support  https://review.openstack.org/62011512:05
openstackgerritsean mooney proposed openstack/nova master: [WIP] libvirt: auto detach/attach sriov ports on migration  https://review.openstack.org/62958912:05
*** yan0s has joined #openstack-nova12:07
*** cdent has quit IRC12:08
*** moshele has joined #openstack-nova12:14
*** panda is now known as panda|lunch12:14
*** zul has joined #openstack-nova12:16
*** markvoelker has joined #openstack-nova12:16
*** tetsuro has quit IRC12:19
*** udesale has joined #openstack-nova12:26
*** ratailor has quit IRC12:38
*** jistr is now known as jistr|afk12:38
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add test to check os_vif.internal.command.ip.exists  https://review.openstack.org/63207712:38
*** ratailor has joined #openstack-nova12:47
*** markvoelker has quit IRC12:49
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Cleanup device at the end of 'test_iproute_object_closes_correctly' test  https://review.openstack.org/62911212:52
*** shilpasd has quit IRC12:56
ralonsohjaypipes, hi. I added the cleanup to avoid leaving any device created in the system if the test goes wrong12:57
jaypipesralonsoh: morning! :)13:02
jaypipesralonsoh: was I correct though, that line 183/4 is doing that delete?13:03
ralonsohjaypipes, yes, the device is being deleted in this line, but this cleanup is just for precaution13:03
jaypipesralonsoh: the delete of the link itself should be done with an addCleanup() call, but AFAICT, the self._del_device() is ensuring that the other device(s) are deleted appropriately, right?13:04
*** eharney has joined #openstack-nova13:04
jaypipesralonsoh: sure, since the _delete_device() method is idempotent, it won't hurt.13:04
ralonsohjaypipes, yes, that's the point13:05
jaypipesralonsoh: ack, ok, I'll push it through.13:09
jaypipesralonsoh: done13:10
ralonsohjaypipes, thanks!13:10
*** jistr|afk is now known as jistr13:10
*** ShilpaSD has joined #openstack-nova13:11
sean-k-mooneyso looking at https://review.openstack.org/#/c/629112/4..5/os_vif/tests/functional/internal/command/ip/test_impl_pyroute2.py we are just being extra safe by registering both cleanup function13:15
sean-k-mooneyralonsoh: jaypipes ^13:15
openstackgerritNatal Ngétal proposed openstack/nova master: [Configuration] Clean up .gitignore references to personal tools  https://review.openstack.org/63208613:16
ralonsohsean-k-mooney, yes, to ensure, in case of any problem, we delete both devices13:16
sean-k-mooneyralonsoh: jaypipes  that said wont hte device created on line 193 actully be called test_dev_9.100 as it is a vlan100 subport13:16
sean-k-mooneyactully i guess that is just a convention13:17
sean-k-mooneyit will actully be called test_dev_913:17
sean-k-mooneyok13:17
ralonsohsean-k-mooney, well yes, and the same in test_add_vlan13:17
sean-k-mooneyya if we were using ifconfig the dev.vlan name would be required i think but since we are using ip link to create them we are free to call them whatever we like13:18
*** ratailor has quit IRC13:19
sean-k-mooneyill need to resping the change to the release repo so ill pick up the 4 patch in that chain when i do for the 1.14.0 release13:21
sean-k-mooneystephenfin: are you to quckly review some os-vif changes. im +2 on all of them but could you take a look at them https://review.openstack.org/#/c/631829/313:24
sean-k-mooney*are you free13:24
*** cdent has joined #openstack-nova13:33
*** panda|lunch is now known as panda13:38
openstackgerritMerged openstack/os-resource-classes master: Add PCPU standard resource class  https://review.openstack.org/63171113:40
*** priteau has joined #openstack-nova13:41
*** yan0s has quit IRC13:46
*** yan0s has joined #openstack-nova13:48
*** yan0s has quit IRC13:50
*** yan0s has joined #openstack-nova13:51
edleafeI know we skipped one conference; can't remember which13:52
edleafewrong window13:52
*** takashin has joined #openstack-nova13:54
*** nehaalhat has joined #openstack-nova13:55
efriedn-sch meeting in 5 minutes in #openstack-meeting-alt. Expect it to be a short one.13:55
*** sum12 has quit IRC13:56
*** ileixe has quit IRC13:56
*** sum12 has joined #openstack-nova13:56
*** tetsuro has joined #openstack-nova13:59
*** mriedem has joined #openstack-nova14:02
openstackgerritNatal Ngétal proposed openstack/nova master: [Configuration] Clean up .gitignore references to personal tools  https://review.openstack.org/63208614:03
*** udesale has quit IRC14:05
*** udesale has joined #openstack-nova14:06
*** lbragstad has joined #openstack-nova14:11
*** nehaalhat has quit IRC14:12
*** eharney has quit IRC14:19
*** sapd__x has joined #openstack-nova14:21
*** xek_ has quit IRC14:25
*** xek_ has joined #openstack-nova14:26
*** takashin has left #openstack-nova14:26
*** Luzi has quit IRC14:26
*** tetsuro has quit IRC14:26
*** cdent has quit IRC14:30
*** mvkr has quit IRC14:33
sean-k-mooneyjaypipes: thanks for the +w i forgot stephenfin is on PTO today14:37
jaypipessean-k-mooney: no problemo.14:38
*** efried has quit IRC14:41
*** efried has joined #openstack-nova14:42
*** kmalloc has joined #openstack-nova14:44
*** YaWang has quit IRC14:44
*** mchlumsky has joined #openstack-nova14:46
gibimriedem: hi, I see that jaypipes already +2 the ensure consumer status check but I have a question in https://review.openstack.org/#/c/631671/7/placement/cmd/status.py@5114:46
mriedemgibi: so a consumer record for allocations but no generation?14:49
mriedemi don't think that's possible...14:49
mriedemthe consumer generation would start at 0 if it's new14:49
gibimriedem: based on your docstring I felt that you wanted to detect this case as well with the query but I don't think that the current query detects that14:50
mriedemthe consumers table defaults generation to 0 so as long as there is a consumers table record, i think it has a generation14:50
gibimriedem: OK, then I just overreacted. thanks for the explanation14:50
mriedemnp14:51
mriedemgibi: while you're here, and you've been on the per-aggregate weights patch, i had a usage/behavior question about one of the weighers which you might have an opinion https://review.openstack.org/#/c/628163/12/nova/tests/unit/scheduler/weights/test_weights_compute.py@9514:52
*** wolverineav has quit IRC14:53
mriedemi'd ask dan but he's out this week14:54
*** efried is now known as efried_mlk14:55
*** dave-mccowan has joined #openstack-nova14:55
mriedemstephenfin: easy cleanup patch on which you have context https://review.openstack.org/#/c/628205/14:57
sean-k-mooneymriedem: stephenfin is on PTO today he will be back tomorrow14:57
mriedemah yes MLK day in ireland...14:58
sean-k-mooneyno he just took today off14:58
sean-k-mooneyi think he was at a gig over the weekend or something14:58
gibimriedem: looking...15:00
sean-k-mooneyactully he may been skying the cleanups make sense to me.15:01
*** maciejjozefczyk has quit IRC15:03
gibimriedem: I tend to agree to simply document that min in case of build_failure weigher means the min of the configured weights not the calculated (and negated) weights15:04
*** maciejjozefczyk has joined #openstack-nova15:05
*** mlavalle_ has joined #openstack-nova15:07
*** mlavalle_ has quit IRC15:08
*** cdent has joined #openstack-nova15:10
*** mlavalle has quit IRC15:11
*** mlavalle has joined #openstack-nova15:11
*** dave-mccowan has quit IRC15:12
mriedemgibi: ok so you wouldn't change anything about the docs here? https://review.openstack.org/#/c/628163/13/doc/source/user/filter-scheduler.rst@50815:13
*** szaher has quit IRC15:13
mriedemi had started commenting on that about whether or not we should mention something about that, or give an example, but when i read what i'd add it just makes it more confusing15:13
*** dpawlik has quit IRC15:14
mriedemi left a comment that i can't come up with a good comment, +215:15
*** mlavalle has quit IRC15:16
*** mlavalle has joined #openstack-nova15:16
*** moshele has quit IRC15:17
*** szaher has joined #openstack-nova15:17
gibimriedem: I think that doc is correct from external perspective15:19
gibimriedem: and I agree configuring weighers are hard, and this patch now makes it even more complex15:19
mriedemheh15:20
mriedemtime for edleafe's scheduler dry run API15:20
gibiis it a test environment for scheduler config? :)15:21
edleafegibi: the idea was to pass in a request and some target hosts, and have the scheduler return the hosts that would have passed, but not actually build anything on those hosts15:23
edleafeIt would have been useful for the Watcher project to know if they try to move an instance to a host whether the new host was a valid target15:24
gibiedleafe: I see. It is interesting15:25
*** dpawlik has joined #openstack-nova15:26
edleafegibi: now what they do is try to move it and catch the failure. It's slow and expensive15:26
cdentI am slow and expensive15:28
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: A few miscellaneous items related to "native TLS"  https://review.openstack.org/63098015:30
openstackgerritKashyap Chamarthy proposed openstack/nova master: docs: Update references to "QEMU-native TLS" document  https://review.openstack.org/63128315:30
*** dpawlik has quit IRC15:30
*** mriedem has quit IRC15:32
gibiedleafe: in return, such a dryrun might return True for a host but then the actual scheduling will fail a due to races15:35
gibiedleafe: but I see that this is a tradeoff15:35
edleafegibi: sure, that's always been understood, and things like total available resources are already able to be known. What it *would* do is help with things like affinity/anti-affinity, aggs, etc., that are pure nova-isms15:37
gibiedleafe: yeah, make sense15:38
*** TxGirlGeek has joined #openstack-nova15:43
*** temka has quit IRC15:50
*** munimeha1 has joined #openstack-nova15:52
*** whoami-rajat has quit IRC15:55
*** mriedem has joined #openstack-nova15:57
*** macza has joined #openstack-nova15:59
*** udesale has quit IRC16:01
*** psachin has quit IRC16:12
gibimriedem: btw, as dansmith is on vacation, I16:12
gibimriedem: btw, as dansmith is on vacation, I'd like to ask your oppinion on my answer in the bandwidth ML thread16:12
gibimriedem: of course if your oppinion is to wait for dansmith then I will wiat16:12
gibiwait16:13
sean-k-mooneygibi: by the way i was not arguing that all features reqire move support just that numa is not a good example :)16:14
gibisean-k-mooney: yeah. I could use other example like virt driver support for certain operations16:15
sean-k-mooneyyep ironic does not really have much of a choice16:15
*** cfriesen has joined #openstack-nova16:16
sean-k-mooneygibi: speaking of ironic i assume there is noting in pricipal stopping bw based schduling from being extended to ironic if the appropriate ml2 drivers were extended16:17
gibisean-k-mooney: yes and no. From nova perspective nothing prevents ironic to handle bandwidth16:17
*** hemnaaway is now known as hemna16:17
sean-k-mooneyyou would just need to update the ml2 drivers for the tor switch16:17
gibisean-k-mooney: from neutron perspective I'm not sure bandwidht allocation can be enforced16:17
gibisean-k-mooney: if you use the tor for it then it is not the same bandwidth as in case of libvirt and sriov16:18
*** hongbin has joined #openstack-nova16:18
sean-k-mooneygibi: yes and no16:18
gibisean-k-mooney: in theory we can extend the current bandwidth support for the tor switch in in case of libvirt + sriov16:19
sean-k-mooneygibi: well for the libvirt case to include the tor means hierarcical port binding16:19
*** TxGirlGeek has quit IRC16:19
sean-k-mooneybut for ironic the tor is the l1 port binding16:19
sean-k-mooneyanyway that is for the future16:20
gibisean-k-mooney: yes :)16:20
gibisean-k-mooney: my problem with dansmith mail is that I thought that microversion can be used to signal a new, supported use case, if the change affect an API behavior. But from the mail it seems that is only true for complete feature16:22
cfriesensean-k-mooney: PCI/SRIOV question for you.  with the upstream code, how do you ensure that an instance that requests a PCI NIC ends up on a compute node that has physical NICs on the desired physical network?  Is that just host aggregates?   As I recall, the network-aware scheduling stuff never landed.16:22
sean-k-mooneythe pci filter performs that check16:22
sean-k-mooneyin the whitelist we declare the physnet that the pf is connected too16:23
mriedemgibi: for supporting numa live migration, i don't think a microversion was going to be added - today it just fails (might be a 400, i'd have to look),16:23
mriedemi see both sides and i think the argument for not adding a microversion for move support is to avoid the ux mess of being able to create a server with one microversion but then you have to use another to do something with it16:24
sean-k-mooneycfriesen: the network aware schdulling stuff was for offloads. idealy we would do this with placement rather then the pcipassthough filter16:24
mriedemi guess that argument could be made for something like volume-backed rebuild as well16:25
mriedemyou can create a volume-backed server with 2.1 but can't rebuild and re-image the root volume without a new microversion16:25
sean-k-mooneycfriesen: whenever we get around to modeling PFs/VFs in placemetn we could use either placement aggrates or traits to model physnets16:25
*** sapd__x has quit IRC16:25
mriedemgibi: anyway, if we don't have move support in stein anyway, then the microversion for move is a train discussion and we can defer until then can't we?16:25
gibimriedem: so in this case discoverability is less important here than ux microversion usage16:25
mriedemunless the argument is being made that we shouldn't ship the create support in stein unless move support is also ready...which i don't think we should do (and that argument could be made about a lot of features we add, like vgpus and trusted certs)16:26
mriedemi.e. resize with vgpus doesn't work completely, you have to rebuild the server after the resize to get the vgpus16:27
mriedembtw, now that i say that, i wonder if that would work for bw resources as a workaround for cold migration ^16:27
gibimriedem: OK then I will propose the first microversion top of the create / delete support and deferr the move support microversion question for Train16:28
mriedemgibi: or at least defer for a week until dan is back :)16:28
gibimriedem: yeah :)16:28
gibimriedem: does rebuild re-allocate today?16:28
sean-k-mooneygibi: mriedem i was under the impression rebuild would not work either in stien16:29
mriedemgibi: no, since resources shouldn't really change on rebuild since the flavor doesn't change16:30
mriedemso i guess that won't work16:30
gibimriedem: so it would be an extra check during rebuild, to see if healing is needed16:30
sean-k-mooneyits not strictly a move operation but i has understood that effectivly start,stop,pause/unpause,suspend and resume were the only actions that would work16:30
mriedemrebuild is specifically not a move16:30
mriedemthere is no resource claim on rebiuld16:31
mriedem*rebuild16:31
sean-k-mooneywell unless the image is chaged16:31
mriedemeven though we have an outstanding bug about the pci resource usage changing b/c of changing the image16:31
sean-k-mooneyin which case we have to go back to the scheuler16:31
*** dpawlik has joined #openstack-nova16:31
mriedemsean-k-mooney: yes but that's for filtering the image, not for claiming resources16:31
mriedem"does the new image work on this existing compute host"16:31
sean-k-mooneywell if the image changes the resouces that are need they would have to be claimed/updated16:32
mriedemhttps://bugs.launchpad.net/nova/+bug/178044116:32
openstackLaunchpad bug 1780441 in OpenStack Compute (nova) "Rebuild does not respect number of PCIe devices" [Undecided,New]16:32
mriedemsean-k-mooney: normal resources don't change based on the image16:32
mriedemexcept pci16:32
mriedemhence that bug16:32
gibimriedem: in theory I can trigger a resource healing check during rebuild, but I guess I should not fail the rebuild if bandwidth resource is not available, should I?16:32
sean-k-mooneywell you can enable hugepags and cpu pinning and pinning policies and numa too16:32
sean-k-mooneyall of which may change the resoces required16:33
sean-k-mooneybut in general yes16:33
mriedemfor anything nfv related, the answer is don't ever try to do anythign with the server once you created it16:33
sean-k-mooneygibi: mriedem for rebuild with BW aware schduling you would also need to validate if the port request changed16:33
cfriesenmriedem: wouldn't that fall under https://bugs.launchpad.net/nova/+bug/1763766 ?16:33
openstackLaunchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow resource consumption changes on image rebuild" [Medium,Triaged]16:33
mriedembecause nova doesn't support operations on those servers16:33
mriedemcfriesen: oh i thought that was your bug16:34
sean-k-mooneymriedem: well we have never enforced that16:34
cfriesenyeah, it is.  I haven't done anything about it yet.16:34
cfriesenI'm just thinking that PCI would fall under it too16:34
sean-k-mooneymriedem: its good advice but its not explcitly stated as far as i know16:34
mriedemsean-k-mooney: yes i know16:35
sean-k-mooneycfriesen: yes likely.16:35
gibisean-k-mooney: in general we said that changing the resource request of a port is not supported (yet). I don't see how this is special for rebiuld. The port can be changed any time16:35
spotzAnyone able to ask a quick keypair metadata questioon?16:35
spotzerr answer... not enough coffee16:35
*** dpawlik has quit IRC16:35
sean-k-mooneygibi: for rebuild we are recreating the vm from scratch and should validate its resocues16:35
gibisean-k-mooney: but current nova code assumes that the resource allocation of such VM is unchanged hence no reallocation happen16:36
mriedemcorrect16:36
gibisean-k-mooney: so it is not special for banwidth16:36
mriedembecause all of the nfv stuff added in juno didn't take rebuild into account16:36
*** eharney has joined #openstack-nova16:36
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/176376616:36
openstackLaunchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow resource consumption changes on image rebuild" [Medium,Triaged]16:36
mriedems/rebuild/any other operation besides delete/16:37
sean-k-mooneytrue but the bug cfriesen pointed to would cover it^16:37
cfriesenmriedem: and resize16:37
mriedem"any other operation besides delete"16:37
gibisean-k-mooney: OK, so you suggest to fail rebuild if the port's resource request changed16:37
sean-k-mooneygibi: yes16:37
gibisean-k-mooney: that would need nova to store such request16:37
gibisean-k-mooney: to have something to compare with16:38
mriedemummm16:38
sean-k-mooneygibi: it could compare it to the existing placement allocation16:38
gibisean-k-mooney: I'm more like the idea that neutron rejects the change of a qos rule if the port is bound16:38
mriedemthat seems pretty shitty for nova have to do that enforcement,16:38
gibisean-k-mooney: with multiple port, that comparision is really ahrd16:38
gibihard16:38
sean-k-mooneygibi: that was brought up before16:38
mriedemneutron should be responsible for not allowing bw policy changes on attached ports16:38
sean-k-mooneygibi: it would be a change in the neutron behaivor but not one that they said the were against16:39
mriedemgibi: yes i agree with what you said,16:39
sean-k-mooneymriedem: well this is special for min mandwith16:39
mriedem"I'm more like the idea that neutron rejects the change of a qos rule if the port is bound"16:39
sean-k-mooneythere is no reason max bandwith of dscp cant change16:39
gibisean-k-mooney: I reacall that this was stated in the spec16:39
openstackgerritMerged openstack/nova master: Reduce calls to placement from _ensure  https://review.openstack.org/61567716:39
*** yan0s has quit IRC16:39
sean-k-mooneygibi:  i raised this before yes but i dont think we made a decision to actully modify neutron to do it16:40
gibisean-k-mooney: I will ping rubasov tomorrow about it, he is leading the neutron work16:40
sean-k-mooneygibi: anyway this is why assumed rebuild would be out of scope until the migration stuff was done as i assuem someone nova or neutron would have to do this type of validaion16:41
gibisean-k-mooney: https://review.openstack.org/#/c/595243/2/specs/stein/approved/bandwidth-resource-provider.rst@110 here I state in the spec that changing rule is out of scope https://review.openstack.org/#/c/595243/2/specs/stein/approved/bandwidth-resource-provider.rst@11016:41
*** whoami-rajat has joined #openstack-nova16:41
gibisean-k-mooney: but rebuild is not the good time to check, the port might changed without anybody calling rebuild on the server the port is bound to16:42
sean-k-mooneygibi: yes i am aware its out of scope but its required for rebuild and move i think16:42
sean-k-mooneygibi: anyway i dont think it should be a blocker for this in stien16:43
sean-k-mooneyits just another edgecase to be address in train16:43
gibisean-k-mooney: move will use the actual state of the port not because it wants to use the updated value but because neutron is considered the source of truth in case of port resource request so nova does not store such request16:43
gibiwhen somebody try to change a QoS rule on a boun port, neutron should check if there are enough resource before it accepts the rule change16:44
sean-k-mooneygibi: sure is it not logical that rebuild should also use the actual state of the port for the same reason16:44
mriedemi assume this is already a problem in the neutron api which is much more loosey goosey about making changes to bound ports, unlike cinder's strong enforcement of not making changes to attached volumes16:44
sean-k-mooneygibi: yep we discussed that in dublin16:44
mriedeme..g in neutron am i able to change port binding details about a bound port?16:45
sean-k-mooneymriedem: the other qos type dont consome resouces16:45
sean-k-mooneye.g. max bandwith and dscp marking can be changed on the fly16:46
gibisean-k-mooney: in generan nova will not be able to prevent the user to change a port in a way that leads to inconsistencies so neutron should do the check16:46
sean-k-mooneygibi: yep im not arguing it should try16:46
*** smcginnis has joined #openstack-nova16:47
cfriesensean-k-mooney: is this still correct as far as the formatting of the PCI whitelist or is there a newer doc somewhere? https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/pci-passthrough-sriov.html16:48
gibisean-k-mooney: but re-allocation during rebuild only needed if neutron allowed the bound port to change.16:48
sean-k-mooneythere is a new dock but let me check16:48
gibisean-k-mooney: so if neutron rejects that then reubild does not need to be changed due to bandwidth16:49
sean-k-mooney gibi which it does hand has always supported16:49
*** sridharg has quit IRC16:49
gibisean-k-mooney: it should not be supported to min bandwidth any more without making sure that the placement allocation is updated16:49
gibisean-k-mooney: otherwise we end up in resource inconsistencies16:50
mriedemcfriesen: there are examples in https://docs.openstack.org/nova/latest/admin/pci-passthrough.html16:50
sean-k-mooneygibi: sure but doing so was not covered in the spec because it was declared out of scope16:50
gibisean-k-mooney: exactly16:50
mriedemcfriesen: and https://docs.openstack.org/nova/latest/configuration/config.html#pci.passthrough_whitelist16:50
sean-k-mooneygibi: so in stien it wont be done16:50
gibisean-k-mooney: so I will ping rubasov tomorrow to make it clear if they will do the reject or not16:50
sean-k-mooneyadn we can get out of sync with neutron16:50
sean-k-mooneygibi: that is a neutron api change and would need a neutron spec right16:51
gibisean-k-mooney: let me check what the neutron spec states about this16:51
mriedemgoing back to what i said earlier, "here is a thing you can do to create a server, but don't ever touch it after that" :)16:52
gibisean-k-mooney: neutron spec states it is out of scope too https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html#out-of-scope16:52
sean-k-mooneymriedem: you mean treat your instances like cattel and not pets16:52
gibisean-k-mooney: I will clarify with rubasov what does it mean16:52
openstackgerritMatt Riedemann proposed openstack/nova master: Share snapshot image membership with instance owner  https://review.openstack.org/63076916:53
sean-k-mooneygibi: i had assumed that it would be addressed at some point in the future16:53
mriedemi don't see why disallowing making min bw allocation changes on a bound port is tied up in os-vif migration16:53
sean-k-mooneybut yes good to check16:53
mriedemseems like an unnecessary dependency16:54
sean-k-mooneyits not16:54
gibisean-k-mooney: yeah supporting the update is future, but rejecting it to prevent incosystencies might be in the current scope16:54
sean-k-mooney does the spec say that?16:54
mriedemi would think, "don't give users a loaded gun to f up resource tracking in their system" as not a feature16:54
mriedemsean-k-mooney: yes16:54
mriedem"This is out of scope in this spec and should be done during the work related to os-vif migration tasks [5]."16:54
gibiyeah I don't see the reason there too ^^16:54
mriedemin fact it would a bug in neutron16:55
sean-k-mooneymriedem: it was proably related the use of os-vif for port negociation or something its likely out of date16:55
*** moshele has joined #openstack-nova16:55
sean-k-mooneymriedem: again changing qos policy is ment to be allowed in neutron16:55
sean-k-mooneymriedem: and sice min bandwith was best effort before there was noting to validate16:56
sean-k-mooneyso the only thing that would have added such a check are these specs16:56
mriedemsure i get it16:57
mriedemin the before times it was the wild west and you get lucky16:57
sean-k-mooneythey declared the check/supprot out of scope so i would assume we keep the status quo by default.16:57
gibisean-k-mooney: I think keeping the resouce view consistent is important enough that this can be reported as a bug agains neutron as soon as nova create/delete support in nova merges16:57
mriedemlike mlavalle said on the call on friday, why even go to the trouble of adding placement to this to guarantee minimum bandwidth if we're not going to enforce it and make sure we calculate it properly16:57
mriedemgibi: agree16:58
sean-k-mooneygibi: sure16:58
mriedemif we're going to punt on keeping the system in check, then we shouldn't even add the feature16:58
*** priteau has quit IRC16:58
*** moshele has quit IRC16:58
sean-k-mooneynot agruing we should punt16:58
mriedemi have to move on from this16:59
*** rpittau has quit IRC16:59
sean-k-mooneyjsut taht we had said we would not do it in the spec. if we and to bring it into scope then greate but its another depency for adding support to nova16:59
sean-k-mooneyok16:59
*** priteau has joined #openstack-nova17:00
*** helenafm has quit IRC17:01
gibimriedem, sean-k-mooney: thanks for the discussion. talk to you tomorrow17:02
*** dpawlik has joined #openstack-nova17:02
cfriesensean-k-mooney: am I understanding this right that the "physical_network" name in the pci whitelist will be correlated against the neutron provider network for the passed-in neutron port?17:05
sean-k-mooneycfriesen: it correaltes to the the neutron physenet17:05
sean-k-mooneycfriesen: so yes it corralate to the provider:physical_network in the neutron network object17:07
*** dpawlik has quit IRC17:07
cfriesencool, thanks17:07
*** dtantsur is now known as dtantsur|afk17:16
openstackgerritsean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration  https://review.openstack.org/62958917:25
*** tssurya has quit IRC17:28
*** mlavalle has quit IRC17:38
*** mlavalle has joined #openstack-nova17:39
*** mlavalle has quit IRC17:41
*** mlavalle has joined #openstack-nova17:41
*** mlavalle has quit IRC17:42
*** mlavalle has joined #openstack-nova17:42
*** mlavalle has quit IRC17:43
*** fragatina has joined #openstack-nova17:43
*** mlavalle has joined #openstack-nova17:43
*** fragatina has quit IRC17:44
*** fragatina has joined #openstack-nova17:44
*** mlavalle has quit IRC17:47
*** mlavalle has joined #openstack-nova17:48
*** mriedem has quit IRC17:50
*** mlavalle has left #openstack-nova17:50
*** fragatina has quit IRC17:52
*** logan- has quit IRC17:52
*** fragatina has joined #openstack-nova17:52
*** mlavalle has joined #openstack-nova17:53
*** logan_ has joined #openstack-nova17:53
*** logan_ is now known as logan-17:53
*** fragatina has quit IRC17:55
*** fragatina has joined #openstack-nova17:56
*** fragatina has quit IRC17:58
*** fragatina has joined #openstack-nova17:58
*** moshele has joined #openstack-nova18:00
*** priteau has quit IRC18:01
*** derekh has quit IRC18:01
*** fragatina has quit IRC18:03
*** fragatina has joined #openstack-nova18:03
*** fragatina has quit IRC18:05
*** artom has joined #openstack-nova18:05
*** fragatina has joined #openstack-nova18:05
*** lpetrut has quit IRC18:06
*** openstackgerrit has quit IRC18:07
*** fragatina has quit IRC18:07
*** fragatina has joined #openstack-nova18:08
*** fragatina has quit IRC18:08
*** fragatina has joined #openstack-nova18:09
*** fragatina has quit IRC18:09
*** fragatina has joined #openstack-nova18:10
*** fragatina has quit IRC18:11
*** fragatina has joined #openstack-nova18:12
*** fragatina has quit IRC18:13
sean-k-mooneyhi so quick question. _rollback_live_migration in the compute manager does not currently appear to ever call the virt driver on the source node18:13
*** fragatina has joined #openstack-nova18:14
sean-k-mooneyi assume it would be ok to add a _rollback_live_migration_at_source to the base driver interface that was a noop and implement it for the libvirt driver?18:14
sean-k-mooneywe have have rollback_live_migration_at_destination but that dose not help me.18:15
*** fragatina has quit IRC18:15
*** fragatina has joined #openstack-nova18:16
*** _fragatina_ has joined #openstack-nova18:17
*** fragatina has quit IRC18:22
*** ralonsoh has quit IRC18:26
*** tbachman has quit IRC18:27
*** lbragstad is now known as lbragstad_afk18:27
*** lbragstad_afk is now known as lbragstad_50318:27
*** ccamacho has quit IRC18:33
cdentjaypipes: I believe this is for you: http://existentialcomics.com/comic/27318:35
*** _fragatina_ has quit IRC18:40
*** fragatina has joined #openstack-nova18:41
sean-k-mooneycdent: if only that was the calibar of converstations at a typical bar discussing such matters hehe18:43
cdenti might actually go to bars if that were the case18:44
edleafesean-k-mooney: I prefer this: http://theincidentaleconomist.com/wordpress/wp-content/uploads/2014/11/sportsball.jpg18:45
*** fragatina has quit IRC18:47
sean-k-mooney it is good but i can feel the heat of the browns burn in cdents link from here and i dont even follow american football18:47
*** fragatina has joined #openstack-nova18:47
*** fragatina has quit IRC18:47
*** fragatina has joined #openstack-nova18:48
*** ccamacho has joined #openstack-nova18:50
*** erlon has quit IRC18:54
*** fragatina has quit IRC18:56
*** fragatina has joined #openstack-nova18:56
*** mvkr has joined #openstack-nova18:56
*** fragatina has quit IRC18:57
*** fragatina has joined #openstack-nova18:58
*** openstackgerrit has joined #openstack-nova19:00
openstackgerritsean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration  https://review.openstack.org/62958919:00
*** fragatina has quit IRC19:03
*** dpawlik has joined #openstack-nova19:03
*** fragatina has joined #openstack-nova19:04
*** moshele has quit IRC19:04
*** fragatina has quit IRC19:07
*** fragatina has joined #openstack-nova19:07
*** dpawlik has quit IRC19:07
-openstackstatus- NOTICE: The error causing post failures on jobs has been corrected. It is safe to recheck these jobs.19:17
*** dpawlik has joined #openstack-nova19:19
*** dpawlik has quit IRC19:23
*** fragatina has quit IRC19:28
*** fragatina has joined #openstack-nova19:29
*** mriedem has joined #openstack-nova19:35
jaypipescdent: that is friggin brilliant.19:38
*** fragatina has quit IRC19:39
*** fragatina has joined #openstack-nova19:39
*** fragatina has quit IRC19:42
*** fragatina has joined #openstack-nova19:43
cdentjaypipes: isn't it delightful?19:44
*** markvoelker has joined #openstack-nova19:46
jaypipescdent: it is indeed.19:49
cdentjaypipes: you may be the Übermensch19:49
*** Vek has joined #openstack-nova19:51
jaypipescdent: heh19:58
*** dpawlik has joined #openstack-nova19:58
*** dpawlik has quit IRC20:02
sean-k-mooneyhttps://review.openstack.org/#/c/631829/ well this is new. all post_failures and all i have check apparently  passed...20:03
*** xek_ has quit IRC20:09
*** whoami-rajat has quit IRC20:15
*** eharney has quit IRC20:16
*** markvoelker has quit IRC20:20
*** fragatina has quit IRC20:20
*** fragatina has joined #openstack-nova20:21
*** ianw is now known as ianw_pto20:26
*** tbachman has joined #openstack-nova20:42
*** macza has quit IRC20:43
*** macza has joined #openstack-nova20:45
*** priteau has joined #openstack-nova20:51
*** ade_lee has quit IRC20:58
*** avolkov has quit IRC21:03
*** priteau has quit IRC21:04
*** markvoelker has joined #openstack-nova21:17
*** ccamacho has quit IRC21:28
*** ade_lee has joined #openstack-nova21:38
*** cdent has quit IRC21:48
*** markvoelker has quit IRC21:49
*** takashin has joined #openstack-nova21:50
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Add TargetDBSetupTask  https://review.openstack.org/62789221:52
openstackgerritMatt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask  https://review.openstack.org/63158121:52
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtDestTask  https://review.openstack.org/62789021:52
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtSourceTask  https://review.openstack.org/62789121:52
*** rcernin has joined #openstack-nova21:54
*** sean-k-mooney has quit IRC21:56
*** sean-k-mooney has joined #openstack-nova21:58
*** dpawlik has joined #openstack-nova21:59
*** dpawlik has quit IRC22:03
*** fragatina has quit IRC22:04
*** fragatina has joined #openstack-nova22:04
zzzeekmriedem: am I allowed to +2 + workflow my own sqlalhcemy-migrate patch ?22:05
mriedemzzzeek: which one? the mysqlclient one?22:06
zzzeekthe "quote=force" one22:06
mriedemi just approved it22:06
mriedemi would like to avoid self approvals, but on that project i think a single +2/+W is probably OK given it's basically just you and me22:06
zzzeekmriedem: that's what i was asking :)22:07
zzzeeker where is verified coming from on that ?  is there another zuul job ?22:07
*** markvoelker has joined #openstack-nova22:08
mriedemzuul will run the gate queue jobs on it22:08
mriedemjobs for that project are defined here https://github.com/openstack-infra/project-config/blob/fcc974bf4c0dc324f93a2aec0520e6e4889c106d/zuul.d/projects.yaml#L810622:09
*** spsurya has quit IRC22:09
*** fragatina has quit IRC22:11
*** fragatina has joined #openstack-nova22:12
*** dpawlik has joined #openstack-nova22:15
*** fragatina has quit IRC22:18
*** fragatina has joined #openstack-nova22:19
*** dpawlik has quit IRC22:20
mriedemzzzeek: fyi i'm proposing a release for sqla-migrate https://review.openstack.org/63218022:21
zzzeekmriedem: OK so if this does include the quote=force change, note that I bumped the minimum sqlalchemy vresion to 0.922:22
mriedemyup that's why i did a minor version bump22:22
zzzeekmriedem: OK if that's what we need then that's great22:23
zzzeeksqla 0.9 is like 5 years ago22:23
openstackgerritTakashi NATSUME proposed openstack/nova master: Add description about sort order in API ref guideline  https://review.openstack.org/62728222:29
jaypipesmriedem: so I think I remember what that rebuild bug/issue I was asking you about last week was...22:35
jaypipesmriedem: if we rebuild to same host but change the image from the original image, we do a full select_destinations-code-path again, right?22:35
*** priteau has joined #openstack-nova22:36
jaypipesmriedem: but we include a single destination host when doing the select_destinations(), yeah? In order to basically determine if the original destination host is still a match for the new image?22:37
jaypipesmriedem: if this is the case, we're seeing a problem where we're getting NoValidHost back from the scheduler because the amount of resources "used" for the original host doesn't account for the original instance. In other words, we erroneously double-up the amount of requested resources when attempting to ask the scheduler if the original host is still a fit.22:38
jaypipesmriedem: or rather, that we're not correctly subtracting the amount of used original instance resources from the amount we request in the "recreate" scheduler request.22:39
*** fragatina has quit IRC22:39
jaypipesgawd, this stuff is hard to talk about in any sort of reasonably clear language, sorry :(22:39
*** fragatina has joined #openstack-nova22:40
*** fragatina has quit IRC22:40
*** fragatina has joined #openstack-nova22:40
*** fragatina has quit IRC22:41
*** fragatina has joined #openstack-nova22:42
*** fragatina has quit IRC22:44
*** fragatina has joined #openstack-nova22:45
melwittjaypipes: correct that we go through the scheduler for rebuilds, as of queens. fwiw, it looks like it will say NoValidHost when filters fail https://bugs.launchpad.net/nova/+bug/1744325 but I don't recall issues with doubling up allocations for rebuilds before22:47
openstackLaunchpad bug 1744325 in OpenStack Compute (nova) pike "If a rebuild is refused by the scheduler, the instance's imageref is not rolled back" [High,Fix committed] - Assigned to melanie witt (melwitt)22:47
melwitt(that bug shows brief explanation of rebuild going through scheduler and what happens when there's a failure to schedule)22:48
*** imacdonn_ has quit IRC22:48
*** imacdonn_ has joined #openstack-nova22:48
mriedemjaypipes: pretty sure that's been fixed by cfriesen and/or hongbin22:50
mriedemmaybe you don't have the backport22:50
jaypipesmelwitt: thx Melanie :) as you know, we're on Ocata currently for VMs and I'm seeing that the "solution" internally is "don't change the image when rebuilding"...22:50
* mriedem runs to a wake22:50
*** mriedem has quit IRC22:51
jaypipesHave I mentioned I hate the fact that rebuild is basically a crutch because people can't stand to lose their IP addresses because they hard-code them everywhere? :(22:51
*** fragatina has quit IRC22:51
*** fragatina has joined #openstack-nova22:52
melwittheh, yeah, good ol rebuild22:52
melwittso, if this is ocata, you wouldn't be going through scheduler for rebuild right?22:53
jaypipesmelwitt: yeah, it's been backported.22:54
melwittah ok. I'm looking for a bug fix like mriedem mentioned22:54
jaypipesmelwitt: well, at least according to https://bugs.launchpad.net/nova/+bug/1744325 (and we have that code merged in our local ocata branch)22:54
openstackLaunchpad bug 1744325 in OpenStack Compute (nova) pike "If a rebuild is refused by the scheduler, the instance's imageref is not rolled back" [High,Fix committed] - Assigned to melanie witt (melwitt)22:54
melwittjaypipes: here we go https://review.openstack.org/56101522:55
melwittgood memory mriedem22:55
jaypipesmelwitt: that's it! thank you!22:57
melwitt\o/22:57
*** tkajinam has joined #openstack-nova23:03
*** fragatina has quit IRC23:07
*** fragatina has joined #openstack-nova23:08
*** tbachman has quit IRC23:08
*** tbachman has joined #openstack-nova23:09
*** mlavalle has quit IRC23:15
*** slaweq has quit IRC23:35
*** hongbin has quit IRC23:42
*** munimeha1 has quit IRC23:53
*** macza has quit IRC23:59

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