Wednesday, 2018-03-21

*** amodi has joined #openstack-nova00:02
*** oomichi has quit IRC00:03
*** wolverineav has quit IRC00:03
*** wolverineav has joined #openstack-nova00:04
*** yassine has joined #openstack-nova00:05
*** vladikr has quit IRC00:06
*** vladikr has joined #openstack-nova00:07
*** xinliang has quit IRC00:07
*** sean-k-mooney has quit IRC00:07
*** odyssey4me has quit IRC00:10
*** odyssey4me has joined #openstack-nova00:10
*** sean-k-mooney has joined #openstack-nova00:10
*** germs has joined #openstack-nova00:11
*** germs has quit IRC00:11
*** germs has joined #openstack-nova00:11
*** itlinux has joined #openstack-nova00:12
*** _ix has joined #openstack-nova00:13
*** germs has quit IRC00:15
*** _ix_ has joined #openstack-nova00:18
*** AlexeyAbashkin has joined #openstack-nova00:18
*** wolverineav has quit IRC00:18
*** _ix has quit IRC00:19
*** xinliang has joined #openstack-nova00:19
*** wolverineav has joined #openstack-nova00:21
*** AlexeyAbashkin has quit IRC00:22
mriedemalex_xu_: gmann_: there is a question in here about API validation outside of the json schema, would be nice to get your input https://review.openstack.org/#/c/546925/00:23
*** wolverineav has quit IRC00:29
*** wolverineav has joined #openstack-nova00:30
*** r-daneel has quit IRC00:31
*** wolverineav has quit IRC00:40
*** yamamoto has joined #openstack-nova00:43
*** yamamoto has quit IRC00:48
gmann_mriedem: sure, ll check00:49
*** claudiub has quit IRC00:50
*** hongbin has joined #openstack-nova00:51
*** felipemonteiro_ has joined #openstack-nova00:52
*** wolverineav has joined #openstack-nova00:53
*** felipemonteiro__ has joined #openstack-nova00:54
*** wolverin_ has joined #openstack-nova00:55
*** felipemonteiro_ has quit IRC00:58
*** sdague has quit IRC00:58
*** wolverineav has quit IRC00:59
*** zhaochao has joined #openstack-nova01:00
*** yassine has quit IRC01:02
*** yassine has joined #openstack-nova01:03
*** _ix_ has quit IRC01:05
*** gjayavelu has quit IRC01:07
*** chyka has joined #openstack-nova01:07
*** harlowja has quit IRC01:07
*** phuongnh has joined #openstack-nova01:08
*** vladikr has quit IRC01:08
Kevin_Zhengmriedem got it01:08
*** vladikr has joined #openstack-nova01:08
*** gcb has joined #openstack-nova01:08
*** chyka has quit IRC01:12
*** wolverin_ has quit IRC01:13
*** wolverineav has joined #openstack-nova01:13
*** vladikr has quit IRC01:14
*** vladikr has joined #openstack-nova01:14
*** tiendc has joined #openstack-nova01:15
*** wolverineav has quit IRC01:17
*** AlexeyAbashkin has joined #openstack-nova01:18
*** AlexeyAbashkin has quit IRC01:22
*** yingjun has joined #openstack-nova01:31
*** felipemonteiro_ has joined #openstack-nova01:32
*** felipemonteiro__ has quit IRC01:32
*** suresh12 has quit IRC01:33
*** suresh12 has joined #openstack-nova01:38
mriedemjohnthetubaguy: thanks for the review on https://review.openstack.org/#/c/520248/ - i didn't see the -1 until now; as for the script thing where someone starts using an IP before the server is ready, we don't show the server address while it's building01:38
mriedembecause of this fun guy https://github.com/openstack/nova/blob/3fd863d8bf2fa1fc09acd08d976689462cffd2e3/nova/conf/api.py#L26401:38
*** moshele has joined #openstack-nova01:39
mriedemgmann_: btw, i think you can remove that option now, it's been over 3 months01:39
mriedem^01:39
*** fragatina has quit IRC01:39
*** suresh12_ has joined #openstack-nova01:40
*** fragatina has joined #openstack-nova01:41
*** vladikr has quit IRC01:42
*** vladikr has joined #openstack-nova01:43
*** suresh12 has quit IRC01:43
*** suresh12_ has quit IRC01:45
*** yamamoto has joined #openstack-nova01:45
*** fragatina has quit IRC01:46
openstackgerritZhenyu Zheng proposed openstack/nova master: Add [placement]/region_name to compute manager placement config check  https://review.openstack.org/55475901:47
*** yamamoto has quit IRC01:51
*** amodi has quit IRC01:53
*** licanwei has joined #openstack-nova01:54
yikunmriedem, sorry, I misunderstand your means to have to use the schema to validate per-policy rule. : )01:56
yikunso, you mean it's just a code validation after schema validation, right?01:56
mriedemyikun: yes, since we can't define a mapping in the json schema document01:57
mriedemnot that i know of anyway, without some custom schema code01:57
yikunok, got it. :)01:59
mriedembut alex_xu_ might have other ideas02:06
mriedemanyway, time for me to stop working, ttyl02:06
*** mriedem has quit IRC02:06
*** AlexeyAbashkin has joined #openstack-nova02:18
*** AlexeyAbashkin has quit IRC02:23
*** yamamoto has joined #openstack-nova02:37
*** yassine has quit IRC02:38
*** psachin has joined #openstack-nova02:38
openstackgerritJulia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call  https://review.openstack.org/55476202:39
*** zhurong has joined #openstack-nova02:40
*** Zames has joined #openstack-nova02:45
*** suresh12 has joined #openstack-nova02:46
*** salv-orl_ has joined #openstack-nova02:48
vivsoni_if we have two compute node, compute1 & compute202:48
*** andreas_s has joined #openstack-nova02:49
vivsoni_and if we create nova instance1 from compute102:49
vivsoni_then is that instance1 visible from compute2 as well02:49
vivsoni_?02:49
vivsoni_i mean when i execute 'nova list' command from compute2, will that instance1 will be listed ?02:50
*** suresh12 has quit IRC02:51
*** salv-orlando has quit IRC02:51
*** Zames has quit IRC02:51
*** yassine has joined #openstack-nova02:53
*** andreas_s has quit IRC02:53
*** yamamoto has quit IRC02:55
*** felipemonteiro_ has quit IRC02:55
*** wolverineav has joined #openstack-nova02:56
*** fragatina has joined #openstack-nova03:00
*** tianhui has quit IRC03:06
*** tianhui has joined #openstack-nova03:07
*** tianhui has quit IRC03:11
openstackgerritYikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies  https://review.openstack.org/54692503:12
*** tianhui has joined #openstack-nova03:13
yikunmriedem, :), thanks, have a good rest.03:14
*** sree has joined #openstack-nova03:16
*** wolverineav has quit IRC03:16
*** sree has quit IRC03:16
*** dave-mccowan has quit IRC03:16
yikunand alex_xu_ any other idea about it, : ) Cloud you give me some advice about how to validate? https://review.openstack.org/#/c/546925/03:17
*** wolverineav has joined #openstack-nova03:17
*** tianhui_ has joined #openstack-nova03:17
*** sree has joined #openstack-nova03:17
*** tianhui has quit IRC03:18
*** sree_ has joined #openstack-nova03:18
*** sree_ is now known as Guest2197703:19
*** hongbin has quit IRC03:19
*** Guest21977 has quit IRC03:20
*** wolverineav has quit IRC03:21
*** sree has quit IRC03:21
*** sree has joined #openstack-nova03:22
*** zhurong has quit IRC03:44
*** yamamoto has joined #openstack-nova03:45
*** diga has joined #openstack-nova03:58
*** links has joined #openstack-nova04:00
*** links has quit IRC04:00
*** Zames has joined #openstack-nova04:04
*** jaypipes has quit IRC04:05
*** jaypipes has joined #openstack-nova04:06
*** Zames has quit IRC04:06
*** yamamoto has quit IRC04:07
*** yamamoto has joined #openstack-nova04:08
*** udesale has joined #openstack-nova04:09
*** abhishekk has joined #openstack-nova04:15
digajaypipes: Hi04:16
digajaypipes: I have assigned https://bugs.launchpad.net/nova/+bug/1751692 bug to me from the shared list04:17
openstackLaunchpad bug 1751692 in OpenStack Compute (nova) "os_region_name an unnecessary required option for placement " [Low,Triaged] - Assigned to Digambar (digambarpatil15)04:17
*** Zames has joined #openstack-nova04:18
*** Zames has quit IRC04:23
*** yamamoto has quit IRC04:33
*** diga has quit IRC04:33
*** chyka has joined #openstack-nova04:34
*** suresh12 has joined #openstack-nova04:35
openstackgerritMichael Still proposed openstack/nova master: Remove duplicative implementation of temporary directories.  https://review.openstack.org/55479104:36
openstackgerritMichael Still proposed openstack/nova master: Use a pythonic delete.  https://review.openstack.org/55479204:36
openstackgerritMichael Still proposed openstack/nova master: Use a pythonic delete, with a retry.  https://review.openstack.org/55479304:36
*** Spazmotic has quit IRC04:37
*** harlowja has joined #openstack-nova04:39
*** chyka has quit IRC04:39
*** sree has quit IRC04:54
*** sree has joined #openstack-nova04:55
*** harlowja has quit IRC04:56
*** sree has quit IRC04:59
*** ratailor has joined #openstack-nova05:02
*** suresh12 has quit IRC05:03
*** ratailor_ has joined #openstack-nova05:04
*** sree has joined #openstack-nova05:05
*** lpetrut has joined #openstack-nova05:06
*** ratailor has quit IRC05:07
*** sree has quit IRC05:09
*** imacdonn has quit IRC05:14
*** imacdonn has joined #openstack-nova05:14
*** sree has joined #openstack-nova05:27
*** vladikr has quit IRC05:28
*** vladikr has joined #openstack-nova05:28
*** rybridges has quit IRC05:30
*** sridharg has joined #openstack-nova05:30
*** sree has quit IRC05:31
*** mdnadeem has joined #openstack-nova05:32
*** vladikr has quit IRC05:34
*** vladikr has joined #openstack-nova05:35
*** fragatina has quit IRC05:35
*** fragatina has joined #openstack-nova05:35
*** moshele has quit IRC05:39
*** rybridges has joined #openstack-nova05:43
*** claudiub has joined #openstack-nova05:43
gmann_yikun: i think we can do using json schema with power of oneOf/anyOf. i wrote my comments on patch05:43
gmann_yikun: oneOf might be good here as at a time only 1 policy can exist05:44
*** kholkina has joined #openstack-nova05:44
*** gjayavelu has joined #openstack-nova05:45
*** kholkina has quit IRC05:49
*** rybridges has quit IRC05:51
*** sidx64 has joined #openstack-nova06:01
*** rybridges has joined #openstack-nova06:04
*** masuberu has quit IRC06:04
*** sidx64 has quit IRC06:05
*** zhurong has joined #openstack-nova06:05
*** sidx64 has joined #openstack-nova06:07
*** sree_ has joined #openstack-nova06:07
*** sree_ is now known as Guest8329406:08
*** sidx64 has quit IRC06:08
*** rybridges has quit IRC06:09
*** sidx64 has joined #openstack-nova06:09
*** Guest83294 has quit IRC06:12
*** sree_ has joined #openstack-nova06:12
*** sree_ is now known as Guest5607606:13
*** germs has joined #openstack-nova06:13
*** germs has quit IRC06:13
*** germs has joined #openstack-nova06:13
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/54877206:15
*** germs has quit IRC06:18
*** lpetrut has quit IRC06:19
*** udesale has quit IRC06:21
*** udesale has joined #openstack-nova06:21
*** ratailor_ has quit IRC06:22
*** rybridges has joined #openstack-nova06:23
*** ratailor has joined #openstack-nova06:24
*** lajoskatona has joined #openstack-nova06:25
*** Guest56076 has quit IRC06:27
*** yamamoto has joined #openstack-nova06:28
openstackgerritjichenjc proposed openstack/nova master: mv generate_glance_url to get_image_endpoint_url  https://review.openstack.org/51140006:30
*** moshele has joined #openstack-nova06:31
*** masber has joined #openstack-nova06:31
*** jichen has joined #openstack-nova06:31
*** suresh12 has joined #openstack-nova06:31
openstackgerritjichenjc proposed openstack/nova master: Avoid raise InstanceNotRunning exception  https://review.openstack.org/54115206:32
yikungmann_, Thanks, cool, ``oneOf`` is like a powerful enum, and we can use it in here.06:32
*** ratailor_ has joined #openstack-nova06:32
yikungmann_, and for the things about policy name, I just think it's ok to me to change ``policy`` to ``name``, and do some convert in api to transfer this ``name`` to the ``policy`` in db.06:32
openstackgerritjichenjc proposed openstack/nova master: Move placement test cases from db to placement  https://review.openstack.org/55314906:34
*** gus has quit IRC06:34
*** lpetrut has joined #openstack-nova06:35
*** ratailor has quit IRC06:35
*** StevenK has quit IRC06:35
*** sdake has quit IRC06:35
*** gus has joined #openstack-nova06:36
*** StevenK has joined #openstack-nova06:36
*** ratailor_ has quit IRC06:37
*** suresh12 has quit IRC06:37
*** sdake has joined #openstack-nova06:37
*** sdake has quit IRC06:37
*** sdake has joined #openstack-nova06:37
yikungmann_, actually, the 'name/type' also as a alternative name for policy, as I mentioned, in PS2:06:38
yikunhttps://review.openstack.org/#/c/546925/2/specs/rocky/approved/allow-specifying-limit-for-affrinity-group.rst@4906:38
yikunBut I thought it seems we need keep consist between api and db, so, in current PS, I use the 2 times policy which look like a bit redundant.06:39
*** diga has joined #openstack-nova06:39
*** ratailor has joined #openstack-nova06:41
*** elmaciej has joined #openstack-nova06:46
*** elmaciej has quit IRC06:54
*** gongysh has joined #openstack-nova06:55
*** lpetrut has quit IRC06:55
openstackgerritzhufl proposed openstack/nova master: Fix api-ref: nova image-meta is deprecated from 2.39  https://review.openstack.org/55481306:55
*** vladikr has quit IRC06:56
*** Spazmotic has joined #openstack-nova06:58
*** logan- has quit IRC06:58
*** logan- has joined #openstack-nova06:58
openstackgerritjichenjc proposed openstack/nova master: Remove quota reserve/commit/rollback  https://review.openstack.org/52147006:59
*** Eran_Kuris has joined #openstack-nova07:02
*** rmart04 has joined #openstack-nova07:02
*** jaosorior has quit IRC07:05
*** masber has quit IRC07:05
*** masber has joined #openstack-nova07:06
*** rmart04 has quit IRC07:07
openstackgerritjichenjc proposed openstack/nova master: deprecate fping_path config option  https://review.openstack.org/52660207:07
*** sidx64_ has joined #openstack-nova07:12
*** salv-orl_ has quit IRC07:12
*** sree_ has joined #openstack-nova07:13
*** sree_ is now known as Guest7002707:14
*** sidx64 has quit IRC07:14
*** alexchadin has joined #openstack-nova07:14
*** salv-orlando has joined #openstack-nova07:16
*** sidx64_ has quit IRC07:16
*** gjayavelu has quit IRC07:17
*** sidx64 has joined #openstack-nova07:17
*** Guest70027 has quit IRC07:18
*** sar has joined #openstack-nova07:19
*** rcernin has quit IRC07:21
*** voelzmo has joined #openstack-nova07:21
*** andreas_s has joined #openstack-nova07:26
*** yamamoto has quit IRC07:32
*** moshele has quit IRC07:36
*** jaosorior has joined #openstack-nova07:44
*** maciejjozefczyk has joined #openstack-nova07:44
*** ralonsoh has joined #openstack-nova07:46
*** moshele has joined #openstack-nova07:46
*** moshele has quit IRC07:50
*** moshele has joined #openstack-nova07:51
*** priteau has joined #openstack-nova07:52
openstackgerritjichenjc proposed openstack/nova master: Add more functional test for placement.usage  https://review.openstack.org/51326407:53
*** AlexeyAbashkin has joined #openstack-nova07:55
*** yamahata has joined #openstack-nova07:55
*** jmlowe has quit IRC07:57
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi: Use XAPI pool instead of aggregate pool for shared SR migration  https://review.openstack.org/55415407:59
*** yamamoto has joined #openstack-nova08:00
*** yamamoto has quit IRC08:03
gmann_yikun: i see, just respond. changing to name looks ok to me.08:05
gmann_yikun: i will give try to test the schema in parallel but tomorrow as it is holiday in japan so not allowed to work much due to wife order :)08:06
*** priteau has quit IRC08:07
openstackgerritjichenjc proposed openstack/nova master: Remove translate and a TODO  https://review.openstack.org/55482708:07
yikunha, really thanks, and I also try it now, but it seems doesn't work, I'm trying to find the reason.08:08
yikungmann_,08:08
yikun^08:08
gmann_ohk, sure08:08
*** danpawlik has joined #openstack-nova08:10
*** damien_r has joined #openstack-nova08:11
*** ragiman has joined #openstack-nova08:12
*** yamamoto has joined #openstack-nova08:13
*** yamamoto has quit IRC08:16
*** yamamoto has joined #openstack-nova08:16
*** Zames has joined #openstack-nova08:21
*** kholkina has joined #openstack-nova08:23
yikungmann_, good msg, it works.08:24
yikunit didn't work well before, the reason is a typo in "s/aditionalProperties/additionalProperties",08:24
yikunsorry, I just copy from your comment and didn't find this tiny typo.08:24
yikunand my result paste here:08:24
yikunhttp://paste.openstack.org/show/707232/08:24
*** chyka has joined #openstack-nova08:24
*** Zames has quit IRC08:26
gmann_yikun: ahhh, thanks that's my bad finger when editing on vim :) good to hear that worked08:26
yikungmann_, lol, I will update specs later, and have a good holiday. : )08:29
*** sahid has joined #openstack-nova08:29
*** chyka has quit IRC08:29
gmann_yikun: thanks, ll review that once you push new version.08:29
*** sidx64 has quit IRC08:30
*** tesseract has joined #openstack-nova08:31
*** sidx64 has joined #openstack-nova08:31
*** sidx64 has quit IRC08:32
openstackgerritMerged openstack/nova stable/ocata: Fix joins in instance_get_all_by_host  https://review.openstack.org/51168208:33
*** sidx64 has joined #openstack-nova08:33
*** brad[] has quit IRC08:34
*** sidx64 has quit IRC08:34
*** ratailor has quit IRC08:35
*** ratailor has joined #openstack-nova08:35
*** amoralej|off is now known as amoralej08:36
*** ccamacho has joined #openstack-nova08:38
*** masber has quit IRC08:40
*** jpena|off is now known as jpena08:43
*** lpetrut has joined #openstack-nova08:45
*** lpetrut has quit IRC08:48
*** lpetrut_ has joined #openstack-nova08:48
*** claudiub has quit IRC08:50
*** tesseract has quit IRC08:51
*** tesseract has joined #openstack-nova08:52
*** tesseract has quit IRC08:54
*** tesseract has joined #openstack-nova08:57
*** lucas-afk is now known as lucasagomes08:59
*** sidx64 has joined #openstack-nova09:00
*** sidx64 has quit IRC09:02
*** mgoddard has joined #openstack-nova09:03
*** zhurong has quit IRC09:04
*** sidx64 has joined #openstack-nova09:09
openstackgerritYikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies  https://review.openstack.org/54692509:12
*** zhurong has joined #openstack-nova09:14
*** licanwei has quit IRC09:15
*** mdbooth has joined #openstack-nova09:17
*** masber has joined #openstack-nova09:20
*** zhaochao has quit IRC09:29
*** gongysh has quit IRC09:30
*** zhaochao has joined #openstack-nova09:31
*** derekh has joined #openstack-nova09:34
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver  https://review.openstack.org/52338709:37
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver  https://review.openstack.org/52765809:37
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add snapshot function  https://review.openstack.org/53424009:37
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add power actions  https://review.openstack.org/54334009:37
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add get console output  https://review.openstack.org/54334409:37
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver  https://review.openstack.org/52765809:41
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add snapshot function  https://review.openstack.org/53424009:41
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add power actions  https://review.openstack.org/54334009:41
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add get console output  https://review.openstack.org/54334409:41
*** Zames has joined #openstack-nova09:41
*** yamamoto has quit IRC09:42
openstackgerritzhufl proposed openstack/nova master: Fix api-ref: nova image-meta is deprecated from 2.39  https://review.openstack.org/55481309:42
*** Zames has quit IRC09:43
*** yingjun has quit IRC09:43
*** yamamoto has joined #openstack-nova09:43
*** sdague has joined #openstack-nova09:43
*** Zames has joined #openstack-nova09:46
openstackgerritsahid proposed openstack/nova master: libvirt: move get_numa_memnode in designer module  https://review.openstack.org/55485009:47
openstackgerritsahid proposed openstack/nova master: libvirt: move vpu_realtime_scheduler in designer  https://review.openstack.org/55485109:47
*** yamamoto has quit IRC09:48
*** yamamoto has joined #openstack-nova09:48
*** yamamoto has quit IRC09:48
*** Zames has quit IRC09:48
*** yingjun has joined #openstack-nova09:49
*** Zames has joined #openstack-nova09:49
*** Zames has quit IRC09:52
*** Zames has joined #openstack-nova09:53
*** yingjun has quit IRC09:54
*** voelzmo has quit IRC09:54
*** voelzmo has joined #openstack-nova09:55
*** voelzmo has quit IRC09:55
*** claudiub has joined #openstack-nova09:55
*** voelzmo has joined #openstack-nova09:56
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi: Use XAPI pool instead of aggregate pool for shared SR migration  https://review.openstack.org/55415409:58
*** phuongnh has quit IRC09:59
*** Zames has quit IRC10:00
*** phuongnh has joined #openstack-nova10:00
*** voelzmo has quit IRC10:00
*** sridharg has quit IRC10:03
*** sidx64 has quit IRC10:04
*** sidx64 has joined #openstack-nova10:05
*** priteau has joined #openstack-nova10:11
*** jichen has quit IRC10:17
*** alexchadin has quit IRC10:27
*** alexchadin has joined #openstack-nova10:28
*** phuongnh has quit IRC10:28
*** elmaciej has joined #openstack-nova10:29
*** alexchadin has quit IRC10:30
*** alexchadin has joined #openstack-nova10:35
*** sidx64 has quit IRC10:36
*** tssurya has joined #openstack-nova10:37
*** sapd_ has quit IRC10:38
*** sapd has joined #openstack-nova10:39
*** sidx64 has joined #openstack-nova10:40
*** diga has quit IRC10:44
*** alexchadin has quit IRC10:46
*** yamamoto has joined #openstack-nova10:48
*** dtantsur|afk is now known as dtantsur10:49
*** yamahata has quit IRC10:52
*** yamamoto has quit IRC10:54
*** zhurong has quit IRC10:55
*** yamamoto has joined #openstack-nova10:56
lyarwoodquick sanity check if anyone has a second, rebuild is the only way to propagate changes to the metadata of an image into an instance previously created from that image right?10:59
lyarwoodsay I wanted to enable the QEMU guest agent in an instance, I'd need to add hw_qemu_guest_agent=yes to the image and then rebuild?11:00
*** yamamoto has quit IRC11:01
*** chyka has joined #openstack-nova11:02
*** yamamoto has joined #openstack-nova11:02
openstackgerritsahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes  https://review.openstack.org/53960511:03
*** voelzmo has joined #openstack-nova11:04
*** udesale_ has joined #openstack-nova11:04
*** suresh12 has joined #openstack-nova11:04
lyarwoodstephenfin, mdbooth, sahid ^ quick sanity-check question above if you have time11:06
*** yamamoto has quit IRC11:06
*** udesale has quit IRC11:07
*** chyka has quit IRC11:07
* mdbooth looks11:07
stephenfinlyarwood: That sounds correct, yes. If you rebuild with an image specifying differing CPU policies, the newer policy will get applied11:08
stephenfinI assume it's the same for other options11:08
mdboothlyarwood: Sounds correct to me, but I'd need to check to be sure. Do you need me to check code?11:08
*** suresh12 has quit IRC11:09
*** gyankum has joined #openstack-nova11:10
*** udesale_ has quit IRC11:13
*** yamamoto has joined #openstack-nova11:16
*** yamamoto has quit IRC11:16
*** alexchadin has joined #openstack-nova11:16
*** cdent has joined #openstack-nova11:18
*** abhishekk has quit IRC11:21
lyarwoodstephenfin / mdbooth ; thanks, I've quickly scanned the compute code around this so no need to dive any deeper, just wanted to make sure I hadn't missed something obvious.11:21
*** sidx64 has quit IRC11:29
*** stvnoyes1 has joined #openstack-nova11:31
*** voelzmo has quit IRC11:32
*** sidx64 has joined #openstack-nova11:33
*** sidx64 has quit IRC11:34
*** claudiub has quit IRC11:35
*** claudiub has joined #openstack-nova11:36
*** jpena is now known as jpena|off11:39
*** jpena|off is now known as jpena11:40
*** sar has quit IRC11:41
*** tiendc has quit IRC11:42
gibimelwitt, mriedem: reported a followup bug for the yestardays notification issue https://bugs.launchpad.net/nova/+bug/175740711:44
openstackLaunchpad bug 1757407 in OpenStack Compute (nova) "Notification sending sometimes hits the keystone API to get glance endpoints" [Undecided,New]11:44
*** Zames has joined #openstack-nova11:45
*** yamamoto has joined #openstack-nova11:48
*** Zames has quit IRC11:48
*** takedakn has joined #openstack-nova11:50
*** yamamoto has quit IRC11:52
*** takedakn has quit IRC11:52
*** sidx64 has joined #openstack-nova11:54
*** RaoulHC has joined #openstack-nova11:54
*** sidx64 has quit IRC11:55
*** sidx64 has joined #openstack-nova11:56
*** sidx64 has quit IRC11:58
*** sar has joined #openstack-nova12:03
openstackgerritMerged openstack/nova stable/queens: Update the nova-manage db archive_deleted_rows description  https://review.openstack.org/55373312:03
*** yamamoto has joined #openstack-nova12:03
*** odyssey4me has quit IRC12:03
*** odyssey4me has joined #openstack-nova12:03
*** sidx64 has joined #openstack-nova12:04
*** sidx64 has quit IRC12:06
jaypipesmorning supernovas12:06
* jaypipes hopes to have a ore productive day today12:06
*** ragiman has quit IRC12:06
*** pchavva has joined #openstack-nova12:07
*** jmlowe has joined #openstack-nova12:08
*** yamamoto has quit IRC12:08
cdentjaypipes: you making steel?12:08
jaypipesheh :)12:08
cdentBecause I would totally go for a "Sword by Jay" sword12:09
*** sidx64 has joined #openstack-nova12:09
jaypipescdent: '"s"words', said in the voice of Sean Connery from Celebrity Jeopardy.12:09
cdentbum cover!12:10
jaypipesI'll play your game, you rogue.12:10
cdentI rarely get the fits of laughing from thing on tv, but that skit kills me12:10
jaypipesindeed.12:11
*** sidx64 has quit IRC12:11
jaypipescdent: although I must say Keenan Thompson doing Steve Harvey on Family Feud over the last 5 years or so is also pretty hysterical.12:11
cdentI'll have to check that out, as a foreigner these days I'm out of touch12:12
jaypipes:)12:12
*** lucasagomes is now known as lucas-hungry12:16
*** yamamoto has joined #openstack-nova12:18
*** jpena is now known as jpena|lunch12:20
*** READ10 has joined #openstack-nova12:22
*** yamamoto has quit IRC12:22
*** efried has quit IRC12:23
*** sambetts|afk is now known as sambetts12:24
*** efried has joined #openstack-nova12:24
*** sidx64 has joined #openstack-nova12:28
*** artom has joined #openstack-nova12:29
sahidjaypipes: anychance you have a look at https://review.openstack.org/#/c/511188/ ?12:30
*** artom has quit IRC12:31
*** lajoskatona has quit IRC12:31
*** yamamoto has joined #openstack-nova12:33
*** artom has joined #openstack-nova12:34
jaypipessahid: yes, will do this morning. sorry for delay. yesterday was a lost day for me.12:35
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438412:37
sahidjaypipes: no worries :) thanks for looking at it12:37
*** sridharg has joined #openstack-nova12:38
*** yamamoto has quit IRC12:38
*** edmondsw has joined #openstack-nova12:40
tssuryacfriesen: around ?12:41
*** gcb has quit IRC12:42
*** yamamoto has joined #openstack-nova12:48
*** lyan has joined #openstack-nova12:52
*** lyan is now known as Guest1710112:52
*** yamamoto has quit IRC12:53
sean-k-mooneyQQ is there any gate issues currently, the nova-tox-functional-py35 timed out on one of my patches so just wondering if i should recheck or is the gate under heavy load?12:57
jaypipessean-k-mooney: I've noticed the same...13:00
*** felipemonteiro_ has joined #openstack-nova13:01
jaypipessean-k-mooney: not sure if it's temporary, though. I've seen a few patches get through, which indicates it probably is (plus all the failures I see have been POST_FAILURE)13:01
*** eharney has joined #openstack-nova13:01
sean-k-mooneyjaypipes perhaps the timeout needs t obe raised over 90 mins that said the py27 fucntional tests only last 18 mins. ill look at the log13:02
*** felipemonteiro__ has joined #openstack-nova13:02
*** yamamoto has joined #openstack-nova13:03
jaypipessean-k-mooney: yeah, the func tests should *not* take more than around 20 minutes max.13:04
efriedbauzas: You around?13:04
*** germs has joined #openstack-nova13:04
*** germs has quit IRC13:04
*** germs has joined #openstack-nova13:04
gibijaypipes, sean-k-mooney: I think we had to increase the functional timeout recently due to slowness of the instances running the tests in CI13:05
sean-k-mooneyjaypipes: its stange i can see the func tests  running fine until here http://logs.openstack.org/72/553072/3/check/nova-tox-functional-py35/6ccdce3/job-output.txt.gz#_2018-03-20_20_02_28_641084 and then it just stops outputing until it hits the time out13:05
gibijaypipes, sean-k-mooney: https://review.openstack.org/#/c/537933/13:05
sean-k-mooneygibi: perhaps but it looks like the func tests are haning after like 5 mins13:06
gibisean-k-mooney: OK then that is a different issue13:06
*** felipemonteiro_ has quit IRC13:06
gibisean-k-mooney: anyhow the current func test timeout is 60 minutes13:06
sean-k-mooneygibi: ya that should be more then enough13:06
*** yamamoto has quit IRC13:08
jaypipesindeed.13:08
*** udesale has joined #openstack-nova13:12
*** vladikr has joined #openstack-nova13:12
openstackgerritJon Schlueter proposed openstack/os-vif stable/queens: Fix VF-rep lookup routine to use parent PF number  https://review.openstack.org/55491713:12
*** yamamoto has joined #openstack-nova13:18
*** lajoskatona has joined #openstack-nova13:19
*** mriedem has joined #openstack-nova13:20
openstackgerritSurya Seetharaman proposed openstack/nova master: [WIP] Cleanup RP and HM records while deleting a compute service.  https://review.openstack.org/55492013:21
*** _pewp_ has quit IRC13:22
*** yamamoto has quit IRC13:22
kashyapsahid: Hey, thanks for the review here: https://review.openstack.org/#/c/534384/13:23
kashyapLooking now...13:24
*** ratailor has quit IRC13:24
*** alexchad_ has joined #openstack-nova13:24
*** jpena|lunch is now known as jpena13:25
*** alexchadin has quit IRC13:25
*** awaugama has joined #openstack-nova13:26
*** tssurya has quit IRC13:26
*** amoralej is now known as amoralej|lunch13:27
*** edleafe- has joined #openstack-nova13:28
*** lucas-hungry is now known as lucasagomes13:29
*** edleafe has quit IRC13:29
*** edleafe- is now known as edleafe13:29
*** eharney has quit IRC13:30
*** mvk has quit IRC13:31
*** yamamoto has joined #openstack-nova13:33
*** elmaciej has quit IRC13:36
openstackgerritMerged openstack/nova stable/pike: Add regression test for BFV+IsolatedHostsFilter failure  https://review.openstack.org/54360213:37
*** tbachman has quit IRC13:37
*** brad[] has joined #openstack-nova13:38
*** yamamoto has quit IRC13:38
*** tssurya has joined #openstack-nova13:40
efriedbauzas: I wanted to get some feedback on vGPU inventorying/reporting through the Nova API, when you've got a minute.13:40
*** dklyle has joined #openstack-nova13:44
*** david-lyle has quit IRC13:44
*** mvk has joined #openstack-nova13:47
bauzasefried: sure ?13:47
*** yamamoto has joined #openstack-nova13:48
efriedbauzas: What I'm wondering is: 1) Does the host's inventory of (v)GPUs show up in some nova API?; 2) Once you've created an instance with a vGPU, does that vGPU show up anywhere on the instance when you query it through the nova API?13:48
*** psachin has quit IRC13:48
efried...and then assuming 'yes' to either/both, more details...13:48
bauzasefried: 1) no13:49
bauzasefried: 2) it's just a new PCI device13:49
efriedbauzas: Okay, cool.13:50
efriededmondsw: ^13:51
edmondswbauzas any plans to address that gap?13:52
*** yamamoto has quit IRC13:53
efriedjaypipes, edleafe, cdent: Is there a Nova API (as opposed to a placement API) where I can see an instance's allocations?  In particular, for an arbitrary resource class I sent through via flavor extra_specs.13:54
*** alexchad_ is now known as alexchadin13:54
bauzasedmondsw: you mean, how to know the vGPU inventory by the API ?13:54
*** idlemind has joined #openstack-nova13:54
bauzaswell, good question13:54
bauzasI haven't planned it yet13:54
bauzasusing the Placement API, that said, you can ask for it13:55
cdentefried: I don't know, but you might dig around in the instance object to see which objects it links to and what method it and the have13:55
*** jackie-truong has joined #openstack-nova13:56
jaypipesefried: os-simple-tenant-usage13:56
jaypipesefried: is about the closest.13:56
jaypipesefried: doesn't look at placement though.13:56
jaypipesefried: and doesn't look at flavor extra specs :(13:56
bauzasyeah, for the moment, Placement API rather13:57
efriedso resources other than proc, mem, disk, and PCI won't appear13:57
*** tidwellr has joined #openstack-nova13:57
cdentefried: did you mean HTTP API?13:57
bauzasefried: for vGPUs yeah13:57
*** tbachman has joined #openstack-nova13:57
efriedcdent: Um, I think so?13:57
efriedAs opposed to, like, driver methods or whatever.13:57
efriedNot sure whether it's HTTP or RPC - but yeah, remote officially-supported API.13:58
efriedI guess it's HTTP.13:58
mriedemvgpu is stored as a vgpu resource / allocation in placement isn't it?13:58
*** jackie-truong has quit IRC14:00
*** crushil has joined #openstack-nova14:00
*** tidwellr has quit IRC14:02
*** yamamoto has joined #openstack-nova14:03
bauzasmriedem: that's correct, a specific RC14:03
*** jackie-truong has joined #openstack-nova14:03
bauzasso, specific inventories and allocations14:04
bauzasI have a devstack running somewhere14:05
bauzasI can show it14:05
bauzasmriedem: replied on https://bugs.launchpad.net/nova/+bug/175246314:05
openstackLaunchpad bug 1752463 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova" [Medium,Incomplete]14:05
bauzasmriedem: thoughts on providing docs related to a specific device ?14:05
*** swamireddy has quit IRC14:05
mriedemyeah so vgpu will show up in placement, and you can use osc-placement to get the CLI14:06
mriedemsimple tenant usage is going to be woefully out of date wrt the new fangled placement resources14:06
bauzasmriedem: IMHO, those kinds of driver-specific docs should be done downstream (like with RH OSP)14:06
edmondswuse case 1... need to query inventory data (type, whether / to what VM they are allocated, etc.) of GPUs and vGPUs on a given host14:06
bauzasmriedem: but if you'd like to get some nvidia specific details in https://docs.openstack.org/nova/queens/admin/virtual-gpu.html , lemme know14:07
mriedembauzas: a small 'driver notes' section or something for known issues seems ok in the openstack docs14:07
bauzasmriedem: okay,n14:07
bauzasmriedem: I can add a note then14:07
edmondswuse case 2...  need to query inventory data of GPUs and vGPUs allocated to a given VM14:07
mriedemdoesn't answer my question if https://review.openstack.org/#/c/459753/ handles this14:07
mriedemfor nvidia14:07
edmondswI think we can get some of that from placement, but not all?14:07
bauzasmriedem: no, it's not helping14:07
mriedemedmondsw: i think you can get all of that from placement14:07
bauzasmriedem: hiding is just for PCI passthrough14:07
*** yamamoto has quit IRC14:07
*** sar has quit IRC14:07
mriedemedmondsw: and with what's already available in the CLI https://docs.openstack.org/osc-placement/latest/index.html14:08
bauzasmriedem: the problem with OVH is that they use some product lines that are not accepted by the nvidia driver :p14:08
bauzasmriedem: so they hide the fact they're virtualizging14:08
*** hongbin has joined #openstack-nova14:08
bauzasmriedem: but in order to make virtual GPUs, you need a specific product line anyway14:08
*** swamireddy has joined #openstack-nova14:10
edmondswmriedem can you query the placement API by server instance?14:10
bauzasshit, pilgrimstack isn't here14:10
edmondswif not, then placement doesn't give you use case 214:11
bauzascan't remember the product that OVH used for their production boxes, but it's not a Tesla line14:11
bauzashence the need for hiding the virt driver14:11
*** sar has joined #openstack-nova14:12
bauzasedmondsw: https://developer.openstack.org/api-ref/placement/#list-allocations14:13
bauzasedmondsw: the consumer_uuid is the instance UUID14:13
mriedemedmondsw: yes14:14
edmondswbauzas ah tx14:14
bauzasedmondsw: it'll show up the existing allocations for each RP14:14
*** Zames has joined #openstack-nova14:14
mriedemedmondsw: in the CLI, the instance == the consumer14:14
*** mgoddard has quit IRC14:14
mriedemedmondsw: https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-allocation-show14:14
mriedemthat's the one you want i think14:14
mriedemshows allocations for a given consumer (instance)14:14
mriedemhttps://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-show shows inventory for a given provider (compute node)14:15
edmondswthanks14:15
mriedemif you love that stuff, https://review.openstack.org/#/q/status:open+project:openstack/osc-placement+branch:master+topic:bp/placement-osc-plugin-rocky14:15
mriedemreviews welcome14:15
*** itlinux has quit IRC14:16
*** Zames has quit IRC14:16
*** itlinux has joined #openstack-nova14:17
*** mlavalle has joined #openstack-nova14:18
*** yamamoto has joined #openstack-nova14:18
*** esberglu has joined #openstack-nova14:19
bauzasjaypipes: cfriesen: stephenfin: efried: thanks for your reviews on https://review.openstack.org/#/c/552924/314:20
bauzasI need to look at all of them14:20
*** tssurya has quit IRC14:20
*** itlinux has quit IRC14:22
Kevin_ZhengHi, could anyone kindly provide some suggestions on funcional tests in https://review.openstack.org/#/c/553288/14:22
*** yamamoto has quit IRC14:23
*** tidwellr has joined #openstack-nova14:24
bauzasjaypipes: efried: stephenfin: could we maybe do a hangout based on https://review.openstack.org/#/c/552924/3/specs/rocky/approved/numa-topology-with-rps.rst ?14:24
*** derekh has quit IRC14:25
jaypipesbauzas: maybe tomorrow morning?14:25
*** r-daneel has joined #openstack-nova14:25
jaypipesbauzas: currently working on a number of things that might affect that14:25
Kevin_ZhengI'm adding 'request_id' field to the nofitications, while testing, I have to compare the 'request_id' field in the payload with the reference, as req_id is  in the response header, so it seems I have to modify the return value in common methods in nova.tests.functional.api.client, don't know if this is a suitable approach or not14:25
bauzasjaypipes: I'm not in a rush14:25
efriedbauzas: I'm game.  Just let me know.14:25
bauzasjaypipes: I just felt that sharding our resources between NUMA nodes is at risk14:26
bauzasjaypipes: hence the use of specific RCs14:26
openstackgerritDan Smith proposed openstack/nova stable/queens: Add --by-service to discover_hosts  https://review.openstack.org/55460014:26
*** derekh has joined #openstack-nova14:27
*** tidwellr has quit IRC14:28
*** jackie-truong has quit IRC14:29
stephenfinbauzas, jaypipes: Tomorrow afternoon (GMT) would be OK with me, yes14:30
bauzask14:31
bauzaswe could need cfriesen too14:31
bauzasbut he's in another TZ14:31
*** sar has quit IRC14:31
*** elmaciej has joined #openstack-nova14:32
*** gouthamr has joined #openstack-nova14:32
*** yamamoto has joined #openstack-nova14:33
*** tssurya has joined #openstack-nova14:34
*** suresh12 has joined #openstack-nova14:34
mriedemKevin_Zheng: it looks like that patch is already testing what you want14:36
mriedemthe sample in https://review.openstack.org/#/c/553288/4/doc/notification_samples/common_payloads/InstanceActionPayload.json is just for docs,14:36
mriedemthe request id generated in the functional test run is going to be unique,14:36
mriedemwhich is why you are doing the replacement stuff in https://review.openstack.org/#/c/553288/4/nova/tests/functional/notification_sample_tests/test_instance.py14:37
*** yamamoto has quit IRC14:38
mriedemKevin_Zheng: left a comment / suggestion about possibly cleaning up the copy/paste in ^14:38
*** abhishekk has joined #openstack-nova14:38
*** suresh12 has quit IRC14:39
mriedemseems you have a bug in the functional tests http://logs.openstack.org/88/553288/4/check/nova-tox-functional/6049993/testr_results.html.gz14:39
*** amoralej|lunch is now known as amoralej14:40
Kevin_Zhengactually I only changed test_create_server_error thistest14:40
Kevin_Zhengfor testing14:40
Kevin_Zhengyou can check the result for this one14:40
Kevin_Zhengthe req_id didn't match14:41
Kevin_Zhengwhich I did replaced14:41
*** jbernard has quit IRC14:42
*** jbernard has joined #openstack-nova14:42
mriedemis an admin context getting generated somewhere?14:43
mriedemcontext.get_admin_context() will return a unique request id14:43
Kevin_ZhengI will check14:44
*** yamamoto has joined #openstack-nova14:46
*** yamamoto has quit IRC14:46
*** dave-mccowan has joined #openstack-nova14:47
openstackgerritMerged openstack/nova master: trivialfix: cleanup _pack_instance_onto_cores()  https://review.openstack.org/53869814:47
*** felipemonteiro__ has quit IRC14:47
*** felipemonteiro__ has joined #openstack-nova14:47
openstackgerritMerged openstack/nova master: Handle EndpointNotFound when building image_ref_url in notifications  https://review.openstack.org/55470314:47
openstackgerritMerged openstack/nova stable/queens: Only attempt a rebuild claim for an evacuation to a new host  https://review.openstack.org/55054514:47
openstackgerritMerged openstack/nova stable/queens: Unmap compute nodes when deleting host mappings in delete cell operation  https://review.openstack.org/55349614:48
jaypipesbauzas: cfriesen is in EST timezone I think?14:48
openstackgerritMerged openstack/nova stable/pike: Detach volumes when VM creation fails  https://review.openstack.org/54414314:48
bauzasjaypipes: living in Alberta IIRC14:49
jaypipesah.. I thought it was Ottawa14:49
*** sidx64 has quit IRC14:49
*** alexchadin has quit IRC14:50
*** germs has quit IRC14:51
*** gyankum has quit IRC14:51
*** felipemonteiro_ has joined #openstack-nova14:52
*** germs has joined #openstack-nova14:52
mriedemdansmith: thoughts on a better name for this thing in tssurya's disabled cells series? https://review.openstack.org/#/c/550188/12/nova/objects/cell_mapping.py@16514:53
Kevin_Zhengmriedem thanks for the comment and advise, I will have to check the details tomorrow, it is late here :)14:54
mriedemKevin_Zheng: np, ttyl14:54
mriedemtssurya: also, i wonder if it would be better if the 'disabled' param doesn't have a default14:54
mriedemsince 'enabled_or_disabled' is further confused by the fact it has a default behavior14:54
tssuryayea I was waiting for inputs regarding the name for that function14:55
*** felipemonteiro__ has quit IRC14:55
openstackgerritSilvan Kaiser proposed openstack/nova master: Exec systemd-run with privileges in Quobyte driver  https://review.openstack.org/55419514:55
dansmithmriedem: commented14:55
*** Eran_Kuris has quit IRC14:56
mriedemi'm cool with get_by_disabled, but don't default the 'disabled' param?14:56
mriedemso caller has to know what they are asking for14:56
dansmithyep14:56
mriedemok wfm14:57
tssuryawiat, so get_by_disabled() will give enabled by default right ?14:57
mriedemno14:57
mriedemno default14:57
mriedemno kwarg14:57
stephenfinIs there another stable core that could take a look at this, please? https://review.openstack.org/#/c/550079/14:57
tssuryaah so the user has to pass a value14:57
mriedemstephenfin: i can14:57
mriedemtssurya: yeah14:57
tssuryait becomes mandatory, got it14:57
tssuryaworks for me as well14:57
tssuryathanks14:57
stephenfinmriedem: Thank you14:59
*** yamahata has joined #openstack-nova14:59
*** amodi has joined #openstack-nova15:00
mriedemstephenfin: do you want to propose a release for os-vif on master?15:00
mriedemif this is high severity15:00
openstackgerritDan Smith proposed openstack/nova master: Add aggregates list to Destination object  https://review.openstack.org/54472915:00
openstackgerritDan Smith proposed openstack/nova master: Add request filter functionality to scheduler  https://review.openstack.org/54473015:00
openstackgerritDan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions  https://review.openstack.org/54799015:00
openstackgerritDan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter  https://review.openstack.org/54500215:00
openstackgerritDan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement  https://review.openstack.org/54628215:00
*** crushil has quit IRC15:04
mriedemstephenfin: what is the minimum version that --may-exist exists in ovs-vsctl?15:04
*** mdnadeem has quit IRC15:06
*** felipemonteiro__ has joined #openstack-nova15:07
*** sidx64 has joined #openstack-nova15:07
*** moshele has quit IRC15:09
mriedemlooks like forever ago https://github.com/openvswitch/ovs/commit/bb1c67c813c9bd80c2bd9acf2bf5158b48841c6115:10
*** Drankis has joined #openstack-nova15:10
*** felipemonteiro_ has quit IRC15:11
*** gjayavelu has joined #openstack-nova15:11
cfriesenbauzas: you wanted to set up a meeting?   I'm in CST timezone...it's 9:12.15:12
*** _ix has joined #openstack-nova15:12
bauzascfriesen: just discussing about NUMA topology15:12
bauzascfriesen: but jaypipes asked for tomorrow morning EST15:12
cfriesenshould be doable15:13
cfriesenjaypipes: my team is in Ottawa, I'm in Saskatchewan15:13
*** sidx64 has quit IRC15:14
mriedemsean-k-mooney: are you ok with this on stable/queens? https://review.openstack.org/#/c/554917/15:16
gibiKevin_Zheng: sorry I haven't had time yet to think about your request_id functional test problem but I did not forget it15:16
gibimriedem: fyi here is a followup bug for the notifications-calling-keystone problem https://bugs.launchpad.net/nova/+bug/175740715:18
openstackLaunchpad bug 1757407 in OpenStack Compute (nova) "Notification sending sometimes hits the keystone API to get glance endpoints" [Undecided,New]15:18
gibimriedem: there is a case where we hit keystone even if only versioned notifications are configured to be emitted15:18
Kevin_Zhenggibi: np I was also busy these days so I didn’t dig deeper, I will try to find out what’s going on tomorrow:)15:18
stephenfinmriedem: Yup, it's there since forever. There was an issue with it but that was resolved in...OVS 2.5, iirc15:19
stephenfinand it wasn't a significant issue. Could only be reproduced under very specific circumstances15:19
*** elmaciej_ has joined #openstack-nova15:19
mriedemgibi: yeah so we could optimize to not even do that lookup if only using versioned notifications,15:21
mriedemalso, efried said the glance endpoint / service catalog information should be cached in ksa, so we shouldn't be hitting the keystone API every time, only the first time,15:21
stephenfinmriedem: Also, I can propose a fix, yup15:21
mriedembut it's curious that we could create a server (which would fetch the image on the compute) and then the periodic (without a token) would have problems stopping it15:22
*** sridharg has quit IRC15:22
mriedemunless you did something like had (1) cached images on the compute or (2) restarted nova-compute in between to invalidate the ksa cache15:22
*** elmaciej has quit IRC15:22
openstackgerritMerged openstack/os-vif stable/queens: ovs: do not delete port if already exists  https://review.openstack.org/55007915:22
mriedemunless the cache has a timer on it? or is somehow otherwise request-specific15:22
gibimriedem: I can try to create a functional test for this15:23
sahidjaypipes, mriedem, anychance to have you ack this ? https://review.openstack.org/#/c/485522/15:23
mriedemsahid: i'll look at it again today15:23
mriedems/today/now15:24
sahidcool thanks15:24
efriedmriedem, gibi: The caching would be specific to the context.  So you would be hitting the endpoint (to do version discovery) once per unique context (as opposed to just the first time overall).15:24
*** jamesdenton has quit IRC15:24
efried...I think.15:25
mriedemah ok15:25
mriedemwell that makes sense then15:25
*** sridharg has joined #openstack-nova15:25
*** sridharg has quit IRC15:25
gibiefried, mriedem: a periodic task runs with the same context every time, i guess15:25
*** sridharg has joined #openstack-nova15:25
mriedemgibi: nope15:26
mriedemgibi: periodic tasks actually run with the last context stored in the local thread,15:26
mriedemsomething like that, but that's why we see request IDs for user contexts get mixed up with periodic tasks in the logs15:26
mriedemand it's totally confusing15:26
gibimriedem: I thought about this https://review.openstack.org/#/c/52430615:26
mriedemyes we were talking about that the otherday15:27
*** abhishekk has quit IRC15:27
gibimriedem: so that patch will make sure that the periodic task runs with the same context every time15:27
mriedemfor the lifetime of that service process yes i think so15:28
gibimriedem: which will limit the performance impact of the notifications calling keystone15:28
mriedemwell, the notifications can't call keystone anyway15:28
gibimriedem: due to the cache in ksa15:28
mriedemthey don't have a token15:28
gibimriedem: OK, I'm confused. :)15:29
mriedemwe realized that "ctxt = context.get_admin_context()" has this overwrite=False flag: https://github.com/openstack/nova/blob/master/nova/context.py#L29015:29
mriedemwhich is used in the parent class in oslo.context15:29
mriedemhttps://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L22515:29
gibimriedem: so if the first call to keystone from the periodic task fails then there is nothing to cache so the next call will also go to keystone and fail again15:31
mriedemfrom what i can tell, that's why periodic tasks re-use the request id from the local thread store15:31
mriedemgibi: i think so15:31
dansmithmriedem: stvnoyes1: this patch is changing code you wrote for the new attachment workflow, but makes it much simpler.. what am I missing? https://review.openstack.org/#/c/55130215:31
gibimriedem: then definitely need remove the keystone call from the notification codepath15:32
gibimriedem: what do you think can we do someting with the legacy notifications top of what you already did by catching the exception?15:32
gibimriedem: to avoid the keystone call15:32
mriedemdansmith: i haven't dug into that one in detail yet15:33
*** yamamoto has joined #openstack-nova15:33
mriedembecause it's going to require loading a bunch of context into my head, including stuff like mixed version compute issues15:33
dansmithmriedem: I don't think it does actually,15:34
gibimriedem: maybe not even trying to generate the glance url (and call keystone) if the glance/api_server config is not set15:34
dansmithmriedem: it doesn't change what we do over the wire15:34
mriedemgibi: can't really do much there for the legacy ones15:34
*** zhaochao has quit IRC15:34
mriedemi'm mid-review in sahid's spec review so will have to look in a bit15:35
dansmithack, thanks15:35
stvnoyes1dansmith, thanks, I'll take a look at it. I'll have to remember what I did and why.15:35
*** liverpooler has joined #openstack-nova15:35
*** kholkina has quit IRC15:35
mriedemeverything stvnoyes1 added would have just been conditional logic on the flow for the new attachment ID stuff15:36
mriedemwhich was fairly mechanical, i.e. 'we used to call initialize_connection to get a new connection_info, now we call attachment_update'15:37
dansmithmriedem: yeah, but the intersection is that this seems to preclude adding old_attachment_id to the migratedata stuff for the v3 attach,15:37
dansmithbut also fixes the same issue that old_attachment_id fixes for v3, but for v215:38
dansmithI mean, that's the assertion15:38
*** tidwellr has joined #openstack-nova15:38
dansmithmdbooth: the bug is basically just the commit message on the patch.. can you add some more detail (logs, traces, etc) to help make it more convincingly problematic?15:39
*** RaoulHC has quit IRC15:39
dansmithmdbooth: because since the old side of all this code has been around for a while, it's legit to question that it's been broken this long, even if it's just for one driver15:39
*** elmaciej has joined #openstack-nova15:40
*** elmaciej_ has quit IRC15:42
*** tidwellr has quit IRC15:43
openstackgerritMerged openstack/nova master: ironic: stop lying to the RT when ironic is down  https://review.openstack.org/54547915:46
openstackgerritDan Smith proposed openstack/nova master: Add aggregates list to Destination object  https://review.openstack.org/54472915:48
openstackgerritDan Smith proposed openstack/nova master: Add request filter functionality to scheduler  https://review.openstack.org/54473015:48
openstackgerritDan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions  https://review.openstack.org/54799015:48
openstackgerritDan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter  https://review.openstack.org/54500215:48
openstackgerritDan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement  https://review.openstack.org/54628215:48
*** eharney has joined #openstack-nova15:48
mriedemsahid: question in https://review.openstack.org/#/c/485522/ about how the guest knows if the VFs are trusted15:50
*** chyka has joined #openstack-nova15:50
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Handle EndpointNotFound when building image_ref_url in notifications  https://review.openstack.org/55496315:52
*** Drankis has quit IRC15:52
*** mgoddard has joined #openstack-nova15:56
mriedemalright now for this live migration funbag15:57
dansmithmriedem: I just threw some more info into the bug from our downstream details15:58
dansmithmight be worth reading first, it's short15:58
*** munimeha1 has joined #openstack-nova15:58
*** gjayavelu has quit IRC15:59
mriedemalright. i do remember talking about this a bit with mdbooth pre-patch16:00
*** yamahata has quit IRC16:00
*** lajoskatona has quit IRC16:00
*** efried is now known as efried_rollin16:01
mriedemoh btw, here i can trade a volume issue during cold migration https://review.openstack.org/#/c/554667/16:04
mriedemmuch easier16:04
dansmithsure, I'll take that trade16:05
sahidmriedem: good i did not provided any information about that point, do you know that there is a ask for that?16:06
sahids/good/good question16:06
*** itlinux has joined #openstack-nova16:07
mriedemsahid: i think the user impact section of the spec says that with this, the user can change the mac address,16:07
mriedembut that happens in the guest (not noted clearly really in that section),16:07
sahidmriedem: yes in the guest16:07
openstackgerritSurya Seetharaman proposed openstack/nova master: Add CellMappingList.get_by_disabled() query method  https://review.openstack.org/55018816:07
openstackgerritSurya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler)  https://review.openstack.org/55052716:07
mriedemand i was thinking, how is the guest going to know if it can do this unless there are device tags on that sriov port in the config drive / metadata16:07
mriedemor is there another way?16:08
mriedemwe don't model VFs in the metadata that goes into the guest do we?16:08
mriedemi thought it was just block devices and ports16:09
sahidfrom the guest, instead of trying to change the MAC address, we can't really know if the VF is using trusted or mode16:10
sahidabout metadata16:10
sahidi think there were some work around that16:10
sahidi will check16:10
sahidperhaps we could add a new attribute16:10
mriedemi'm looking at nova.network.netutils.get_network_metadata16:10
*** danpawlik has quit IRC16:11
mriedemseems like the _get_eth_link method would be the place to take information off the vif's port binding profile that has the 'trusted' flag and put that into the entry16:12
artommriedem, we have a generic 'devices' section in the metadata, we can add stuff to it16:12
artomhyperv already do stuff in there that's not related to device tagging16:12
mriedemthis is specific to network data though16:13
mriedemidk what's the best solution here, i'm not an expert on the metadata service or how a guest would consume trusted SRIOV ports in the guest,16:13
mriedembut it's obviously something we should think about how that gets modeled so the guest application can actually leverage the thing16:14
artommriedem, wait, we're talking about trusted VFs?16:14
mriedemyes16:15
artomWhat's wrong with just having an interface: {mac: blah, trusted:true} blob in there.16:15
artom?16:15
*** itlinux has quit IRC16:15
artomThe exact format is obviously to be worked out :)16:15
mriedemhold dear caller16:15
mriedemartom: https://review.openstack.org/#/c/485522/16:16
mriedemquestions/comments are in there16:16
*** diga has joined #openstack-nova16:16
*** andreas_s has quit IRC16:16
digajaypipes: Hi16:16
*** Guest17101 has quit IRC16:16
*** jackie-truong has joined #openstack-nova16:17
digajaypipes: assigned this bug - https://bugs.launchpad.net/nova/+bug/1751692 to me16:17
openstackLaunchpad bug 1751692 in OpenStack Compute (nova) "os_region_name an unnecessary required option for placement " [Low,Triaged] - Assigned to Digambar (digambarpatil15)16:17
artommriedem, aha, thanks - I keep being dragged off for downstream stuff, but I've already added myself in there, will try to take a look16:17
* sahid on call16:17
*** derekh has quit IRC16:21
*** derekh has joined #openstack-nova16:22
*** wolverineav has joined #openstack-nova16:22
mriedemdansmith: mdbooth: ok for this bug, first thing, the bug report says, "During live migration we update bdm.connection_info for attached volumes  in pre_live_migration to reflect the new connection on the destination  node." - in the libvirt driver pre_live_migration i see where we connect the volumes on the dest host: https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/virt/libvirt/driver.py#L16:23
mriedemand we stash the bdm info for the migration data object https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/virt/libvirt/driver.py#L762116:23
mriedembut don't see where the bdm.connection_info gets updated and saved off from the dest host into the db16:23
dansmithhang on16:24
dansmithoh, where it gets saved16:24
mdboothmriedem: I think I put that in a review comment somewhere because it's super obtuse16:24
dansmithwe look it up from the db again, but..16:24
dansmithis this the weird commit() decorator thing?16:24
mriedemupdate_db()?16:24
mdboothHmm, perhaps I'm imagining the review comment. Or perhaps it was a different review.16:25
dansmithyeah I don't see a comment16:25
mriedemi don't see pre_live_migration() go through nova.virt.block_device to attach anything though16:25
dansmithbut BDMs get magically saved I think no?16:26
mriedemthe virt driver gets the bdms and connects them on the host directly16:26
*** andreas_s has joined #openstack-nova16:26
mriedemso, pre_live_migration on the dest host calls this16:26
mriedem        block_device_info = self._get_instance_block_device_info(16:26
mriedem                            context, instance, refresh_conn_info=True,16:26
mriedem                            bdms=bdms)16:26
mriedemand that will initialize the connection on the dest host and update the connection_info and save it16:26
mriedemso that's likely it16:26
mdboothIt's in _get_instance_block_device_info() I think16:26
mriedemyeah ^16:27
mdboothYeah, that's it16:27
mdboothrefresh_conn_info16:27
mriedemthe thing dansmith just approved my multiattach patch16:27
*** masber has quit IRC16:27
mriedemright so during pre_live_migration on the dest host the compute manager gets here https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/virt/block_device.py#L63316:27
mriedemuses the host connector from the dest host16:27
mriedemgets a new connection_info and updates the bdm16:27
openstackgerritSaju M proposed openstack/python-novaclient master: pypy is not checked at gate  https://review.openstack.org/55498316:27
mriedembecause @update_db16:27
mriedemand then uses that to connect the volumes in the virt driver16:28
mriedemand that gets put into the LibvirtLiveMigrateBDMInfo objects16:28
mriedemwith the new flow, the connection_info for the source and dest attachments are stored in cinder with those attachments, so not a problem for the new flow16:28
*** diga has quit IRC16:29
mriedemproblem in nova is we have 1 bdm for all attachments so the connection_info gets overwritten16:29
dansmithjump down, turn around, pick a bail of cotton16:29
*** afaranha has quit IRC16:29
*** AlexeyAbashkin has quit IRC16:29
dansmithteag16:29
dansmither, yeah16:29
mriedemnow i'm thining about line dancing to brooks and dunn in 6th grade gym class,16:29
mriedemthanks for that16:29
dansmithmriedem: so did you see my comment about not changing the new path?16:30
dansmithsince I think it's immune16:30
mriedemi'm just loading context from the first sentence in the bug report at this point :)16:30
mriedemand also https://www.youtube.com/watch?v=d05tQrhNMkA16:30
dansmithheh, okay16:30
*** andreas_s has quit IRC16:30
dansmithain't nothin' wrong with that16:31
mriedemthere is plenty wrong with that16:31
mriedemok so back to this16:31
*** tidwellr has joined #openstack-nova16:32
mriedemok so in _post_live_migration in the compute, we get the BDMs again but don't refresh their connection_info b/c that would screw up the bdms which are now on the dest host,16:32
mriedemwe call into the virt driver's post_live_migration method to disconnect the volumes and have to call initialize_connection from the source host to get the proper connection_info for the source host16:33
mriedemfor the old flow16:33
mriedemand at this point, the cinder driver is returning different connection_info from what was used to originally connect the volume on the source host, and we blow up16:34
dansmithmriedem: youtube tells me there's an upcoming Brooks & Dunn concert in MN in July.. better get on that16:35
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438416:35
mriedemnow, the goal here is to stash off the original source host connection_info so we can use that to disconnect later?16:35
mriedempost-live migrate16:35
dansmithyeah16:35
mriedemwhat if we should be using the latest connection_info from cinder for the source host to disconnect?16:35
mriedemlike, what if the rbd driver changed the auth information for the ceph backend?16:35
mriedemand the original stuff in the source host connection_info is stale16:36
*** elmaciej_ has joined #openstack-nova16:36
*** elmaciej has quit IRC16:36
dansmithmriedem: did you check out the cinder bug and patch?16:36
dansmithgorka says we shouldn't sending the latest16:36
mriedemlooking16:36
dansmithI dunno if that means we shouldn't be sending the thing we grabbed before the migration if it changed right after,16:37
dansmithbut that'd be fairly obscure and hard to do I think16:37
*** danpawlik has joined #openstack-nova16:37
dansmithwe'd have to catch it before it gets set and overwritten16:37
dansmithwell, I guess gorka's comments are in our downstream bug actually16:38
mriedemyeah was going to say16:38
mriedemi feel like i'll get different answers based on which cinder cores i ask16:38
*** gyee has joined #openstack-nova16:38
mriedemjgriffith: smcginnis16:38
mriedemhemna16:38
mriedemhaving said that, for the new flow, the original connection_info from the source host is stored in cinder with the attachment record for the source host,16:39
dansmithmriedem: can you see this? https://bugzilla.redhat.com/show_bug.cgi?id=155223216:39
openstackdansmith: Error: Error getting bugzilla.redhat.com bug #1552232: NotPermitted16:39
mriedemso when we disconnect post live migration, we'll be using that original value, not something new16:39
*** sar has joined #openstack-nova16:39
dansmithguess not16:39
mriedemdansmith: nope16:39
dansmithmriedem: yeah, using the original attachment id is definitely better than having to have these connectors line up and potentially be changed if you're saying that could happen mid-migration16:40
*** damien_r has quit IRC16:41
mriedemi guess my point is just, i wouldn't be surprised if at some later date, someone reports a bug saying something in the storage backend or source host changed and they actually need to get the latest information to disconnect16:41
mriedemsort of like the discussion in denver about always refreshing connection_info whenever we do stuff16:42
mriedemto get things like latest ceph mon address and creds16:42
dansmithmriedem: so actually, re-reading gorka's comments,16:42
*** danpawlik has quit IRC16:42
dansmithmriedem: what he's saying we shouldn't be doing is calling initialize_connection again to get the connector from the volume16:43
dansmithwhich we're then using to detach16:43
dansmithso old line 7724 here: https://review.openstack.org/#/c/551302/6/nova/virt/libvirt/driver.py16:43
mriedemyeah i understand, but as noted, we have to do that because right now with the old flow, the bdm.connection_info is from the dest host, and the only way to get the connection_info with the old flow for the source host is to call initialize_connection with the source host connector16:44
*** jackie-truong has quit IRC16:44
dansmithyeah I know16:44
mriedemso i guess the point is calling initialize_connection when the volume is already connected on another host can cause problems if you call it again, for some cinder backends16:45
mriedembut we've been doing this forever16:45
dansmithmriedem: "So Nova should not be making a second initialize connection for a volume that is already attached to the node and use the information it already has in the DB to do the disconnect"16:45
mriedemexcept we didn't have that information in the db16:46
dansmith^ gorka's comments from the downstream bug16:46
mriedemhence the workaround16:46
dansmithmriedem: well, it's just one backend remember, and that one is fixed now16:46
mriedemif initialize_connection is supposed to be idempotent, which i always thought it was, i don't see the issue16:46
jgriffithmriedem: you have a link to the bug?16:46
mriedemjgriffith: nova bug https://bugs.launchpad.net/nova/+bug/175471616:46
openstackLaunchpad bug 1754716 in OpenStack Compute (nova) "Disconnect volume on live migration source fails if initialize_connection doesn't return identical output" [Undecided,In progress] - Assigned to Matthew Booth (mbooth-9)16:46
mriedemjgriffith: cinder bug https://bugs.launchpad.net/cinder/+bug/175691416:46
openstackLaunchpad bug 1756914 in Cinder "Dell EMC SC: Initialize_connection returns all connections" [Undecided,Fix released] - Assigned to Tom Swanson (tom-swanson)16:46
mriedemplus a red hat bz that we don't have access to16:47
dansmithyeah, sorry :(16:47
*** lyan has joined #openstack-nova16:47
dansmithjgriffith: gorka has context on this but I don't see him around here16:47
*** lyan is now known as Guest9089316:47
mriedemhe's in -cinder16:47
jgriffithYeah, not in this channel, I'll ping him16:47
dansmithI looked, maybe I don't know his nick?16:47
dansmithI thought it was geguilar or something16:48
mriedemhe's been pung16:48
*** geguileo has joined #openstack-nova16:48
dansmithhuh, sorry, I looked and just missed it16:48
geguileomriedem: jgriffith hi16:48
*** Swanson has joined #openstack-nova16:49
mriedemwho wants to update him?16:49
mriedemi can start16:49
mriedemgeguileo: so you're familiar with https://bugs.launchpad.net/nova/+bug/1754716 right?16:49
openstackLaunchpad bug 1754716 in OpenStack Compute (nova) "Disconnect volume on live migration source fails if initialize_connection doesn't return identical output" [Undecided,In progress] - Assigned to Matthew Booth (mbooth-9)16:49
dansmithgeguileo: it's about this: https://bugs.launchpad.net/nova/+bug/175471616:49
dansmithgeguileo: which was a cinder backend fix for the dell driver, plus making nova not call initialize_connection() a second time16:49
mriedemgeguileo: i'm trying to understand if initialize_connection is supposed to be idempotent or not16:49
smcginnisSwanson: You may be interested too. ^^16:49
Swansonsmcginnis, already there16:49
dansmithgeguileo: you asserted in our downstream bug that calling initialize_connection really late during disconnect after a live migration was wrong and we should avoid doing it16:50
geguileomriedem: the problem is that Cinder never asked drivers to be idempotent16:50
Swansonhere16:50
jgriffithmriedem: you're just begging for 3 different answers :)16:50
smcginnismriedem: It is, but that was a surprise to most around the Liberty timeframe.16:50
* dansmith shuts up16:50
smcginnisOr rather, it wasn't, until we found out around liberty that nova was initializing repeatedly.16:50
geguileodansmith: it's wrong because Cinder never specified that initialize_connection should be idempotent  :-(16:50
*** itlinux has joined #openstack-nova16:50
jgriffithummm.....16:50
mriedemsmcginnis: yeah we do it all the time during migrations because we only have one copy of the connection_info at any time with the old flow16:50
mriedemso the only copy of the connection_info is in the nova bdm table, and it's host-specific16:51
mriedemon which was the last host to update it16:51
*** diga has joined #openstack-nova16:51
mriedemwith the new flow, that's all stored in cinder per-host attachment16:51
mriedemso nova doesn't have to care16:51
jgriffithinitialize_connection has never been designed as an idempotent thing, in fact it was intentionally abused for that very reason16:51
geguileomriedem: but if Nova is the source of truth it shouldn't overwrite their data16:51
geguileofor old API I mean16:52
mriedemgeguileo: cinder is the source of truth when it comes to volume informatoin imo16:52
mriedembut,16:52
geguileomriedem: not for attach information on the old API16:52
mriedemif 'source of truth' means, when you disconnect a volume, regardless of host, you need to use the exact same connection_info as you used when you connected it,16:52
mriedemthen yes nova needs to track that for the old flow16:52
geguileoyup, that's what I meant by 'source of truth'16:53
mriedemit's just a surprise to me that after all these years it's a new problem16:53
dansmithmriedem: with one (known) driver, remember16:53
smcginnismriedem: Why is this a new problem?16:53
jgriffithmriedem: so the trick is that early drivers (and a large percentage) don't care here16:53
mriedemand, as i said to dan earlier here, "i wouldn't be surprised if at some later date, someone reports a bug saying something in the storage backend or source host changed and they actually need to get the latest information to disconnect"16:53
*** gjayavelu has joined #openstack-nova16:53
smcginnisI thought we mostly had fixed all instances we identified when we realized the call was being used this way.16:54
jgriffithmriedem: they don't have any interaction with the initiator or it's settings, that's just been extra *data*16:54
dansmithsmcginnis: all but one, which was recently fixed:16:54
dansmithhttps://review.openstack.org/#/c/552933/16:54
jgriffithbut now with new fangled iSCSI stuff and LIO drivers that's not the case any more16:54
geguileomriedem: the big problem here is not as much the data you pass to disconnect to Cinder, it's what you pass to os-brick16:54
mriedemgeguileo: yeah i realize16:54
mriedemdetach api in cinder is just flipping the volume status in the db16:55
mriedemso another question in that regard,16:55
mriedemwe use a host connector with the original initialize_connection call,16:55
mriedemand we pass a host connector to terminate_connection,16:55
mriedemdo those host connectors have to be the same?16:55
jgriffithmriedem: but terminate con has implications for some devices, that's the part that matters (which is what I think you're saying right now)16:55
mriedemnova just gets the host connector from os-brick on the fly16:56
mriedemexcept in some weird edge cases like when the source compute is down (evacuate)16:56
geguileomriedem: For the RBD driver (which is the one I primarily touch) it doesn't matter, but I don't know about other drivers16:56
geguileoin theory it should not matter16:57
jgriffithmriedem: for some drivers it matters, they modify and access entry for the initiator iqn16:57
mriedemok. i'm alright with us being told that we shouldn't assume initialize_connection is idempotent and we should use the same connection_info to disconnect the volume as was used to connect the volume16:57
jgriffithmriedem: and they get that from the connector16:57
geguileoas long as you haven't changed the initiator name or something crazy like that (I've seen bugs around this)16:57
mriedemi just don't want to find out later that someone relied on us always getting the latest info16:58
jgriffithmriedem: +1 for NOT assuming idempotency, AND +2 for suggesting upgrades and using the new API's instead :)16:58
mriedemwith the new flow, we don't get the latest info anyway, it's all stored in cinder and we just re-use it16:58
dansmithmriedem: "much later" we expect to always be using the new API that doesn't suffer from this right?16:58
mriedemdansmith: yeah16:58
jgriffithof course, assumign we're not broken in there as well somewhere16:58
mriedemany existing attached volumes would have the old flow stuff until they get migrated16:59
jgriffithbecause I think we may be now in our efforts to emulate the old behavior16:59
mriedemwhich now this makes me paranoid about https://review.openstack.org/#/c/549130/16:59
melwittgibi: are you able to run the nova meeting tomorrow?16:59
mriedemjgriffith: this is the problematic code https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/virt/libvirt/driver.py#L774317:00
mriedemthat runs on the source host post-live migration17:00
gibimelwitt: yes I can run it17:00
mriedemfor the new flow, we just get the connection_info out of the attachment record17:00
melwittgibi: cool, ty for confirming17:00
jgriffithahh, yeah17:00
mriedemso the old flow thing there to call init_connectoin was a workaroudn17:01
gibimelwitt: will you update the agenda or shall I do it?17:01
mriedemb/c at this point in the flow, in the nova db, the bdm.connection_info is actually for the dest host17:01
melwittgibi: I'll update the agenda17:01
gibimelwitt: OK, thanks17:02
jgriffithmriedem: yeah, I get ya17:02
mriedemok so to summarize, i think i'm hearing the majority of the cinder peeps in here saying doing https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/virt/libvirt/driver.py#L7749 is a bad workaround and only works for some drivers b/c we're getting lucky17:02
melwittgibi: no, thank YOU :)17:03
mriedemeven though we've always done it....but anyway17:03
*** bradjones has quit IRC17:03
dansmithmriedem: well, we've always done it which ended up in them changing a bunch of drivers to tolerate it17:03
*** udesale has quit IRC17:03
mriedemsure, good point17:03
mriedemit's a fun incestual relationship17:03
geguileorofl17:03
dansmithreally? I don't enjoy any of it :)17:04
dansmithbut you're into some weird shit, granted17:04
mriedemjgriffith: btw, we should remember to talk about this in vancouver about why the new flow is much better....17:04
jgriffithmriedem: +117:04
mriedemalright i'll move onto reviewing the nova patch then, thanks geguileo jgriffith smcginnis17:04
geguileono problem, and thanks for fixing that  :-)17:05
*** geguileo has left #openstack-nova17:05
jgriffithmriedem: just for the record one more time and to hope it sticks in peoples heads... "Never update/modify and attachment, just delete it and create a new one"17:05
jgriffithThat way you still have the ability to access the old data if you need it and nothing gets funky behind your back17:06
jgriffithhmmm... well, anyway17:06
jgriffith"funky behind your back" isn't the best phrase I guess17:06
mriedembecause that would be like calling initialize_connection again17:06
jgriffithmriedem: exact-u-mundo17:06
*** danpawlik has joined #openstack-nova17:06
*** felipemonteiro__ has quit IRC17:11
*** danpawlik has quit IRC17:11
*** felipemonteiro__ has joined #openstack-nova17:11
dansmithmdbooth: did you follow all that ^ ?17:11
*** gjayavelu has quit IRC17:12
mriedemi put the link into the bug for the irc log and a summary17:13
dansmithcool17:13
*** sahid has quit IRC17:13
mriedemwhile we're on the topic https://review.openstack.org/#/c/549130/2/nova/compute/manager.py@61617:14
mriedemin case any cinder people are still here and can direct me17:14
*** elmaciej_ has quit IRC17:16
dansmithmriedem: btw, I changed this to fixes and left a snarky remark: https://review.openstack.org/#/c/554600/17:16
dansmithif you say that's good I'll fix the pike backport17:16
dansmithmriedem: melwitt: tssurya: do we need to have a cells meeting today? I know there are a bunch of tssurya's patches to review, but other than that, I don't know of anything else burning that justifies it17:18
tssuryadansmith: not needed17:19
dansmithtssurya: especially if it means I spend the time reviewing your stuff yeah? :)17:19
tssuryayeaaaaa :D17:19
*** danpawlik has joined #openstack-nova17:20
melwitt+1 to skipping today17:20
cdentthe whole day17:20
dansmithwoot, even if mriedem really wants a meeting, he's outnumbered17:20
ildikovjgriffith: you need to repeat those that thousands of times so they stick in people's heads :)17:21
cfriesen tssurya: you pinged earlier?17:22
*** danpawlik has quit IRC17:25
mriedemildikov: or push a patch to nova to add something to the docstring for the attachment_update method so we don't forget17:25
mriedemi'd +2 that17:25
ildikovmriedem: I can when I'm off booth duty and got to the next hotel today17:26
mriedemdansmith: we've changed 'features' to 'fixes' in release notes in backports for other nova-manage changes for optional things, in order to fix bugs, so i think that's fine17:26
tssuryacfriesen: yea just to ask about the third point in the bug description, since you explicitly stated delete service/compute node, I wanted to just confirm we are still doing a soft delete17:27
tssuryacfriesen: saw you review btw, will change it to cascade, working on some tests and then will update the patch17:27
ildikovmriedem: It won't replace the need of repeating the phrase a thousand times everywhere else17:27
cfriesentssurya: I think the service/node portion can remain as it is currently.  what you have looks reasonable to me with the cascade change17:28
tssuryacfriesen: ack, however I think maybe we need to provide a new command at some point to allow compute node deletions ? like we have osc placement allowing resource provider deletions ?17:29
cfriesentssurya: dansmith is the go-to guy in this area. :)17:29
cfriesentssurya: you mean compute node deletions without service deletion?17:30
dansmithmriedem: fine, fine17:30
tssuryacfriesen: yes he is, he just promised he will review ^^ ;)17:30
tssuryacfriesen: yes17:30
sean-k-mooneymriedem: just looked at https://review.openstack.org/#/c/554917 and yes i think that is fine for stable/queens17:31
tssuryaI mean deletion of cn, along with its dependencies17:31
*** lucasagomes is now known as lucas-afk17:31
tssuryathe record as such does not get removed right ?17:32
tssuryaor I don't know when its moved to shadow tables17:32
*** lpetrut_ has quit IRC17:32
dansmithin the nova database,17:34
dansmithdeleting a thing marks it as deleted (deleted=row['id'])17:34
mdboothdansmith: Thanks for the ping, caught up.17:34
dansmith"nova-manage db archive-deleted rows" moves it to shadow tables17:34
dansmith"nova-manage db purge" removes it from shadow tables17:34
dansmithtssurya: ^17:34
dansmithmdbooth: ack, I assume we're to expect a review from mriedem forthwith17:34
*** moshele has joined #openstack-nova17:34
* dansmith checks his use of forthwith on google17:34
tssuryaah yes was just checking this, I don't know why for some reason I though only the instance* tables were archived17:34
mdboothdansmith: Fortunately the above is consistent with my understanding having spoken to Gorka the other week.17:35
dansmith\o/17:35
* mdbooth wipes his brow17:35
dansmithmdbooth: ack, that's good :)17:35
mdboothdansmith: Heh, I do that, except I tend to google first :)17:35
dansmithmdbooth: this is 'merica.. fire from the hip and ask questions later17:35
cfriesentssurya: under what scenario would we want to delete only a compute node and not a service?17:35
dansmithcfriesen: ironic nodes outnumber the service(s) they're owned by17:36
dansmithcfriesen: and, ironic nodes balance between services, and could potentially be orphaned17:36
tssuryacfriesen: nope, I was talking about the delete records in the compute node table17:36
dansmithcfriesen: I would guess maybe the same could happen if you change the hostname on a virt host17:36
tssuryabut that is done by archive_deleted_rows17:36
tssuryaalready so taken care of :)17:36
tssuryasorry for the confusion17:37
mdboothmriedem: Incidentally lyarwood pointed out that we're not running volume tests in the live migration job by default, so on his suggestion I hacked a run based on another patch he pointed me at. Link is in a review comment.17:37
*** jmlowe has quit IRC17:37
*** NobodyCam has quit IRC17:37
*** r-daneel has quit IRC17:37
*** r-daneel has joined #openstack-nova17:37
*** toan has quit IRC17:37
*** icey has quit IRC17:37
*** Hazelesque has quit IRC17:38
*** gus has quit IRC17:38
*** Hazelesque has joined #openstack-nova17:38
*** gmann_ has quit IRC17:38
openstackgerritStephen Finucane proposed openstack/nova-specs master: Update spec to reflect reality  https://review.openstack.org/55500017:38
*** andreaf has quit IRC17:39
*** NobodyCam has joined #openstack-nova17:39
*** gus has joined #openstack-nova17:39
*** andreaf_ has joined #openstack-nova17:39
stephenfinjaypipes, gibi: Could you stick this on your review queue. Just ensure the spec for a Queens feature matches the actual implementation https://review.openstack.org/55500017:39
stephenfin*?17:39
*** felipemonteiro_ has joined #openstack-nova17:40
*** gmann_ has joined #openstack-nova17:40
*** icey has joined #openstack-nova17:40
*** danpawlik has joined #openstack-nova17:40
sean-k-mooneystephenfin: is that the pci numa policy stuff?17:40
*** toan has joined #openstack-nova17:41
sean-k-mooneystephenfin: i taught we did not want to put the policy in the alias?17:41
*** sridharg has quit IRC17:41
*** moshele has quit IRC17:41
*** andreaf_ is now known as andreaf17:41
*** felipemonteiro__ has quit IRC17:41
sean-k-mooneystephenfin: hum well its in the code here https://github.com/openstack/nova/blob/master/nova/pci/request.py#L90-L92 so i guess we did17:43
cfriesensean-k-mooney: ah, but we did...that way you can be flexible for one device and strict for another17:43
openstackgerritDan Smith proposed openstack/nova stable/pike: Add --by-service to discover_hosts  https://review.openstack.org/55460317:43
sean-k-mooneycfriesen: yes i see that i guess it works but eventually i would hope we can get this kind of stuff out of configs and into openstack server create --device vendor-id=xyz ...17:45
*** cdent has quit IRC17:45
*** suresh12 has joined #openstack-nova17:45
*** danpawlik has quit IRC17:45
sean-k-mooneycfriesen: with cyborg becoming a thing that seams like the correct route long term17:45
cfriesensean-k-mooney: I'd be fine with that, but it might affect the instance packing (which dansmith has smacked me with before)17:46
sean-k-mooneyinstance packing?17:46
sean-k-mooneyin placement17:46
cfriesendefining flavors to pack instances neatly onto a compute node with minimal waste17:46
*** oomichi has joined #openstack-nova17:46
*** mdbooth has quit IRC17:46
*** Drankis has joined #openstack-nova17:47
dansmithcfriesen: I don't believe I smacked you, I just made a big farting noise and gave it a thumbs down17:47
dansmithyou know, to be respectfyul17:47
sean-k-mooneycfriesen: ah ok. well currently passh through devices are not first class resouces. if they are it changes the usage model and billing model17:47
*** gjayavelu has joined #openstack-nova17:47
sean-k-mooneybut ya in any case having the numa policy in the alias kind of works but its not discoverable by the tenant so it wont work for everyone. espcilally the people that dont like setting things in the nova conf17:49
openstackgerritmelanie witt proposed openstack/nova master: Add periodic task to clean expired console tokens  https://review.openstack.org/32538117:50
openstackgerritmelanie witt proposed openstack/nova master: Use ConsoleAuthToken object to generate authorizations  https://review.openstack.org/32541417:50
openstackgerritmelanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation  https://review.openstack.org/33399017:50
cfriesensean-k-mooney: are you proposing that we add an HTTP API for PCI aliases?17:51
sean-k-mooneycfriesen: well no i dont think we should keep adding features to the aliases but maybe in the flavour details show some of the alais fields17:53
sean-k-mooneycfriesen: long term however i would much prefer this handeled with resouce requests and traits in the flavor then using aliases17:53
sean-k-mooneycfriesen: the mater of how that resource request gets there(set by admin directly or via boot option e.g. --device) is a seperate disction17:55
sean-k-mooney/disction/topic/17:55
sean-k-mooneycfriesen: these  https://github.com/openstack/nova/blob/master/nova/pci/request.py#L74-L89 can all be modeled as traits on the RP in placement and the numa_policy can be modeled as a flavor extra spec key that is consumed by the numa_topology/pci passhtrough filters.17:58
*** derekh has quit IRC18:00
*** sambetts is now known as sambetts|afk18:00
*** diga has quit IRC18:02
*** felipemonteiro__ has joined #openstack-nova18:02
*** AlexeyAbashkin has joined #openstack-nova18:03
openstackgerritMark Goddard proposed openstack/nova master: Request only instance_uuid in ironic node list  https://review.openstack.org/53950918:04
*** felipemonteiro_ has quit IRC18:06
*** danpawlik has joined #openstack-nova18:12
*** jpena is now known as jpena|off18:14
*** jmlowe has joined #openstack-nova18:15
*** dtantsur is now known as dtantsur|afk18:15
*** danpawlik has quit IRC18:17
cfriesenonce nova-compute spawns a privsep daemon, does it stay running after that?18:18
*** tidwellr has quit IRC18:19
*** tidwellr has joined #openstack-nova18:19
*** ircuser-1 has quit IRC18:20
*** lpetrut has joined #openstack-nova18:20
sean-k-mooneycfriesen: yes and a seperate priv sep deamon is spawned for each context18:21
*** AlexeyAbashkin has quit IRC18:21
*** EmilienM is now known as mimi18:21
*** mimi is now known as EmilienM18:21
sean-k-mooneycfriesen: so if you have two contexts with 2 different permission sets you will have 2 privsep deamons running for nova-compute18:22
sean-k-mooneywhen nova compute exits the deamons also exits when the unix socket gets closed18:22
*** harlowja has joined #openstack-nova18:24
melwittdansmith: patch for removing the useless non-periodic task line has acks from efried_rollin and gibi https://review.openstack.org/#/c/55438118:26
dansmithmelwitt: ah yeah thanks for the reminder18:27
dansmithmelwitt: so confirmed what I was saying about that test yeah?18:27
melwittyes, I tried it out and indeed it was only covering that one line :18:27
dansmithmelwitt: and I also wonder if that was the only source of the overwriting-context problem initially18:27
melwitt:\18:27
dansmithack18:27
*** amodi has quit IRC18:27
melwittyeah, I think it was -_-18:27
*** jmlowe has quit IRC18:36
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot  https://review.openstack.org/54302318:38
edmondswhttps://review.openstack.org/#/c/547169/ should be a quick review if someone has a few minutes18:40
edmondswprereq to starting to flip some of those capabilities to True as we introduce functions in later commits18:40
cfriesensean-k-mooney: cool, thanks18:42
*** tssurya has quit IRC18:42
*** yamamoto has quit IRC18:43
*** andreas_s has joined #openstack-nova18:45
mriedemdansmith: commented on mdbooth's change https://review.openstack.org/#/c/551302/18:46
mriedemdansmith: overall it's ok, but i think we also have a problem in rollback18:46
*** jmlowe has joined #openstack-nova18:46
dansmithmriedem: cool thanks18:48
*** Swami has joined #openstack-nova18:48
*** ralonsoh has quit IRC18:49
*** andreas_s has quit IRC18:50
*** lpetrut has quit IRC18:51
*** danpawlik has joined #openstack-nova18:52
*** fragatina has quit IRC18:53
mriedemi looked at his live migration test patch that enabled the volume-backed live migration tests,18:53
mriedemthe grenade live migration job passed, which uses mixed computes18:54
mriedemand goes back and forth (rocky->queens->rocky)18:54
mriedemand vice-versa18:54
mriedemthe other non-grenade live migration job failed, looks like all rpc messaging timeouts18:54
*** danpawlik has quit IRC18:56
mriedemhuh, same thing in melwitt's patch to enable the volume-backed live migratoin tests http://logs.openstack.org/04/528104/6/check/legacy-tempest-dsvm-multinode-live-migration/ff90ecb/logs/subnode-2/screen-n-cpu.txt.gz?level=TRACE18:57
mriedemi wonder if there is just something about doing a volume-backed live migration that takes that much longer such that pre_live_migration rpc call times out18:57
*** jmlowe has quit IRC18:57
melwittyeah, I had been rechecking the patch periodically but it never passed reliably upon multiple rechecks18:58
mriedemi'm seeing the same rpc timeouts in your patch and https://review.openstack.org/#/c/553377/18:58
mriedemwhich depends on your patch18:58
melwittyeah18:58
melwittI just mean I had been checking on it to see if we were going to be able to re-enable those tests but it wasn't panning out. will try depending on your queens uca patch18:59
mriedemyou could try setting the rpc timeout to 120 in nova-cpu.conf in the job config and see if that makes a difference18:59
mriedemi don't think libvirt is the problem here18:59
melwittokay, will do that instead18:59
*** mgoddard has quit IRC19:00
*** lpetrut has joined #openstack-nova19:00
mriedemthis is how you do something like that https://review.openstack.org/#/c/549789/9/playbooks/legacy/nova-cells-v1/run.yaml@3819:00
mriedemexcept you'll use $NOVA_CPU_CONF19:00
mriedemoh, but,19:01
mriedemfirst you need to move the live migratoin job defs in tree19:01
mriedemsomething i've been thinking about doing anyway19:01
melwitthm, okay. (on a call atm)19:02
dansmithor I could finish my live heartbeating thing in oslo.messaging19:04
*** sidx64 has joined #openstack-nova19:05
*** brault has joined #openstack-nova19:05
*** jmlowe has joined #openstack-nova19:06
*** brault_ has quit IRC19:07
mriedemor you could take this over https://review.openstack.org/#/c/452546/19:09
*** mvk has quit IRC19:09
mriedemlike you PROMISED at the PTG19:10
dansmithum, wut?19:10
dansmithI thought you said you were going to do that?19:11
mriedemoh on19:11
mriedem*no19:11
mriedemi said i had tried at one point and was shot down19:11
mriedemand was welcome to others getting shot19:11
mriedembtw i think the cellsv1 + neutron job is ready to go https://review.openstack.org/#/c/549789/19:12
mriedemi can't drop the old cells v1 job from master until that flushes through19:12
*** READ10 has quit IRC19:13
*** felipemonteiro__ has quit IRC19:13
*** felipemonteiro__ has joined #openstack-nova19:13
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class  https://review.openstack.org/54905319:14
openstackgerritEric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk  https://review.openstack.org/54930019:14
dansmithmriedem: that's a long ways from "promised" :)19:14
mriedemi know, i was hoping the caps would convey the joke19:15
mriedemlike, "omfg there was pug shit EVERYWHERE!"19:15
dansmithmriedem: so this patch's cells job came from the in-tree version https://review.openstack.org/#/c/549780/2 ?19:16
dansmithah, I guess there are two on there19:16
*** sidx64 has quit IRC19:17
*** AlexeyAbashkin has joined #openstack-nova19:17
*** suresh12 has quit IRC19:18
dansmithmriedem: your job's cells-child log has a little extra red in it from the base job: http://logs.openstack.org/80/549780/2/check/nova-cells-v1/66d336e/logs/screen-n-cell-child.txt.gz?level=TRACE19:18
dansmithalthough that looks vaguely familiar, so maybe not a problem19:18
*** suresh12 has joined #openstack-nova19:18
mriedemi've seen those before19:18
mriedemrace in the metadata updates19:19
dansmithokay19:19
mriedemso yeah what i did was move the existing job in-tree19:19
*** tidwellr has quit IRC19:19
mriedemand renamed it19:19
mriedemb/c that's what we do when we move them in tree,19:19
*** tidwellr has joined #openstack-nova19:19
mriedemand then tweaked it to be the new thing with neutron19:19
dansmithso after we merge that first one, we can remove the base job from infra, right?19:20
mriedemin https://review.openstack.org/#/c/549789/ we are getting both jobs b/c at this point the legacy job is still in openstack-zuul-jobs19:20
mriedemyeah i have all of thoes patches lined up19:20
mriedemhttps://review.openstack.org/#/q/topic:bp/remove-nova-network+(status:open+OR+status:merged)19:20
*** amodi has joined #openstack-nova19:21
*** AlexeyAbashkin has quit IRC19:21
*** suresh12 has quit IRC19:22
*** jaosorior has quit IRC19:23
dansmithmriedem: cool, +2 on the bottom two19:24
dansmithmelwitt: ^19:24
*** eharney has quit IRC19:26
*** sree has joined #openstack-nova19:26
*** mgoddard has joined #openstack-nova19:27
*** eharney has joined #openstack-nova19:28
*** danpawlik has joined #openstack-nova19:28
*** suresh12 has joined #openstack-nova19:29
*** sree has quit IRC19:31
*** danpawlik has quit IRC19:33
*** salv-orlando has quit IRC19:34
*** liverpooler has quit IRC19:34
*** salv-orlando has joined #openstack-nova19:35
*** sidx64 has joined #openstack-nova19:37
*** efried_rollin is now known as efried19:37
*** tesseract has quit IRC19:38
*** salv-orlando has quit IRC19:38
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Preserve multiattach flag when refreshing connection_info  https://review.openstack.org/55502919:44
*** jaosorior has joined #openstack-nova19:44
openstackgerritMatt Riedemann proposed openstack/os-vif stable/pike: ovs: do not delete port if already exists  https://review.openstack.org/55008019:44
*** yamamoto has joined #openstack-nova19:44
*** salv-orlando has joined #openstack-nova19:44
*** kuzko_ has quit IRC19:46
*** yamamoto has quit IRC19:49
*** sidx64_ has joined #openstack-nova19:53
mriedemdansmith: i skimmed the review comments on https://review.openstack.org/#/c/452546/ again and there were some todos that came out of that as prereqs, one of which was tagged attach which we've had since pike. there was another about returning bdm tags out of the volume attachments API. i had a separate spec for that which got held up in committee because of local disk tags and also exposing vifs tags in GET requests but which19:53
mriedem to do that from.19:53
mriedemone thing that could move it forward was just remove device_name from the volume attach API (not bfv), because that doesn't have the sneaky ec2 thing that ftersin was -1ing this for19:54
*** sidx64 has quit IRC19:55
dansmithmriedem: ah, that seems like incremental improvement and probably the 90% case where people attach a volume and expect it to go in a certain place19:55
*** moshele has joined #openstack-nova19:55
mriedemthe device name is also presumably for correlating on the guest right?19:57
mriedemi know this volume has something in it that my app needs, so i'll attach it at vdc and my guest will expect it to be at vdc19:57
dansmithyeah19:57
dansmithit's the only use for it19:57
*** eharney has quit IRC19:57
mriedemso i think what i'd propose, if i were to redo this, is (1) drop device_name from attach volume API, (2) return tags in GET calls to the os-volume_attachments and os-interface APIs19:59
*** sidx64 has joined #openstack-nova19:59
mriedemand then cross my fingers that john, booth, feodor and artom don't show up to review the spec19:59
*** ekhugen has quit IRC19:59
*** egarbade has quit IRC19:59
dansmithand take tags in volume/interface attach?19:59
dansmithor do we already have that?20:00
mriedemwe've had that since pike20:00
mriedemthat was one of the pre-reqs for this other removal spec20:00
dansmithon both interface and volume? but not sriov or something?20:00
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: Network interface attach/detach  https://review.openstack.org/54681320:00
mriedemsame20:00
mriedemsriov ports are attached the same way20:00
mriedemthey have to be pre-created in neutron is all with the special binding profile i think20:00
*** sidx64_ has quit IRC20:00
dansmithI thought there was some way to attach something where we were still missing tag function20:01
mriedemor are you referring to the bug that artom was trying to fix20:01
mriedemhttps://review.openstack.org/#/c/533805/ ?20:01
dansmithanyway, yes, I think making those three changes together makes sense. I need to refresh on the bfv/ec2 issue I guess,20:01
*** danpawlik has joined #openstack-nova20:01
dansmithbecause that doesn't sound like a great reason to remove it from bfv either but..20:01
dansmithto nop20:02
dansmithnot20:02
mriedemyeah, i said the same to ftersin basically, it is completely undocumented and untested behavior20:02
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver  https://review.openstack.org/52609420:03
*** egarbade has joined #openstack-nova20:03
*** ekhugen has joined #openstack-nova20:03
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot  https://review.openstack.org/54302320:04
artommriedem, I thought we matches volume tags based on device name?20:04
artom*matched20:04
dansmithmriedem: if we remove it, it prevents them from using the boot call past that microversion forever I guess?20:05
*** tssurya has joined #openstack-nova20:05
dansmithmriedem: I guess I don't see why a tag on bfv won't work the same for them,20:05
mriedemdansmith: if we removed device_name from the bdm object in server create, yeah.20:05
dansmithbut I also don't really understand the exchange between you two either20:05
dansmithI think there's ML context probably20:05
mriedemftersin pointed out some stuff about image-defined BDMs don't have tags20:05
mriedemit's in the spec review20:06
mriedemartom: not sure20:06
*** moshele has quit IRC20:06
mriedemyou wrote that code :)20:06
artommriedem, I have the memory of a goldfish20:06
dansmithoh, image-defined I see.. either way, those device names don't get honored any more than the volume-attach ones, so I don't see what that matters20:06
*** danpawlik has quit IRC20:06
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class  https://review.openstack.org/54905320:06
artommriedem, yeah, we do: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L857020:07
*** suresh12 has quit IRC20:07
artomBut... where does that device name come from?20:07
mriedemoh i guess there was some ML stuff http://lists.openstack.org/pipermail/openstack-dev/2017-April/114858.html20:07
mriedemartom: i think nova.virt.libvirt.blockinfo.py20:07
artommriedem, is that the one the user gives in the boot request?20:08
artomOr attach request, whatever20:08
mriedemhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L870320:08
mriedemno,20:08
mriedemthe libvirt driver completely ignores what the user requested20:08
mriedemsince liberty20:08
mriedemsee ^20:09
mriedemwhen you attach a volume, the api rpc calls the compute to create the bdm and get the device name from the driver20:09
mriedemassuming the stupid instance isn't shelved offload20:09
dansmithmriedem: yeah, from that thread I'm not sure why tags won't work20:09
dansmithoh, because the image properties20:10
mriedemyeah it's a different use case,20:10
mriedemi think the image has bdms in it,20:10
mriedemthe user can override those,20:10
mriedembut the override relies on the device name as the primary key20:11
dansmithbut .. if they're providing bdms, they're doing full override, or is it that they're doing override of individual bdms referenced by name?20:11
mriedemso you say, the image has vda/vdb/vdc and i don't like the image-defined vdc bdm, so i'm going to overwrite it20:11
mriedemthe latter i think20:11
dansmithyeah, okay20:11
dansmiththat seems like a really odd thing that we ever allowed20:11
mriedemheh, that's what i said20:11
mriedem"people do this?!"20:12
openstackgerritEric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk  https://review.openstack.org/54930020:12
dansmithlike, it seems weird that you would expect to provide bdms, but get a union of the bdms on the image and the ones you provided, with some replacement20:12
dansmithmriedem: so since this is so obscure,20:12
*** eharney has joined #openstack-nova20:13
dansmithwhat if we just defined a pattern like volume-bdm-$devname and auto-tag BDMs from the image, and then you can use the tag on the bdm command line to override those?20:13
dansmithI mean, I know it's kinda secret sauce, but so is what we have today20:13
openstackgerritEric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk  https://review.openstack.org/54930020:13
*** suresh12 has joined #openstack-nova20:13
dansmithwe could actually document it though going forward20:13
mriedemthis is the merge-a-roo https://github.com/openstack/nova/blob/master/nova/compute/api.py#L67020:13
dansmithand avoid the surprise later when we all forget gain20:13
dansmiththat that suck-a-roo-s20:14
openstackgerritEric Berglund proposed openstack/nova master: WIP: Resize  https://review.openstack.org/55358320:14
dansmiththe ML thread made it sound like he was amenable to something else if you provided it20:15
openstackgerritEric Berglund proposed openstack/nova master: WIP: Resize  https://review.openstack.org/55358320:15
*** priteau has quit IRC20:15
dansmithpresumably the client (ec2api in this case) could also just get the properties from the image, and generate a fresh new set of BDMs that are the union of the two, if we convert over to not merging in some microversion20:15
mriedemyeah they'd have to do the full override client side20:17
dansmithyeah, and what's wrong with that?20:17
dansmithit'd suck for someone using novaclient, but not so much for ec2api using REST20:17
*** suresh12 has quit IRC20:18
*** suresh12 has joined #openstack-nova20:18
dansmithwhat does horizon do if you have an image with BDMs in it? does it properly show what your instance is going to look like pre-boot?20:18
*** AlexeyAbashkin has joined #openstack-nova20:18
mriedemnot sure, don't have a devstack handy20:19
mriedemoh, but, i have a vexxhost handy :)20:20
mriedemalso, if we stopped doing the merging in a new microversion that drops device name, the client has two options: use an older microversion for the server create request and hope they didn't need a newer microversion, or merge client side20:20
mriedemnvm i don't know if vexxhost has any images with BDMs in them20:21
dansmithmriedem: did you look or find any documentation that advertises this as a thing?20:21
mriedemhttps://docs.openstack.org/nova/pike/user/block-device-mapping.html#intermezzo-problem-with-device-names20:22
mriedem"Currently (mid Liberty) users are discouraged from specifying device names for all calls requiring or allowing block device mapping, except when trying to override the image block device mapping on instance boot, and it will likely remain like that in the future. "20:22
*** AlexeyAbashkin has quit IRC20:22
*** suresh12 has quit IRC20:23
dansmithhrm20:24
*** mgoddard has quit IRC20:24
mriedemthat's about all i can find20:24
mriedemfrom that ML thread: http://lists.openstack.org/pipermail/openstack-dev/2017-April/114866.html20:24
mriedemthis is also timely: "Well, i cannot estimate the importance in absolute measurement, but in comparison with OpenStack this use case is more important in AWS. Volume backed images (EBS images) are used in AWS much more widely than in OpenStack. There are some difficulties in Nova and Cinder because that users try to avoid using volume backed images in favor of disk based (instance-store) ones. This  explain why this use case20:24
mriedemess important for pure OpenStack users."20:24
mriedemi.e. bfv in openstack sucks ux-wise20:25
*** gouthamr has quit IRC20:26
dansmithyeah20:26
mriedemfrom what i can tell, we don't even have any direct tests for _merge_bdms_lists20:26
dansmithmriedem: well, I commented and summarized my feelings20:26
dansmithmriedem: heh, nice20:27
dansmithand no tempest test,20:27
dansmithwhich means it's not part of the are-you-openstack test right?20:27
mriedeminterop, no20:31
mriedemmost things aren't in interop though fwiw20:31
dansmithI know, I'm just poking20:31
*** salv-orlando has quit IRC20:32
mriedemalright i'll give myself a todo to re-spec-ify this20:32
*** jaosorior_ has joined #openstack-nova20:33
*** danpawlik has joined #openstack-nova20:33
*** jaosorior has quit IRC20:37
*** suresh12 has joined #openstack-nova20:37
*** danpawlik has quit IRC20:38
*** amoralej is now known as amoralej|off20:43
*** yamamoto has joined #openstack-nova20:45
openstackgerritJulia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call  https://review.openstack.org/55476220:47
melwittran into something unexpected today, apparently when you specify a non-existent field when creating a nova object, it doesn't complain about it upon create(), it just silently never applies it https://github.com/openstack/nova/blob/master/nova/tests/functional/compute/test_instance_list.py#L6920:49
*** arvindn05 has left #openstack-nova20:50
*** yamamoto has quit IRC20:51
*** jmlowe has quit IRC20:56
*** suresh12 has quit IRC20:57
cfriesenwhen we evacuate a boot-from-volume instance and it's starting up on the new compute node, would we expect the HTTP API calls to cinder to have the same "req-*" number as the evacuate in nova?20:58
*** suresh12 has joined #openstack-nova20:59
*** esberglu has quit IRC21:01
*** tidwellr has quit IRC21:01
dansmithmelwitt: yeah, it's always been that non-field properties are free-form21:04
dansmiththat's how we manage local caching of stuff, and some of the other things instance does, for example21:05
dansmithI found it surprising the first time someone else brought it up and was surprised by it :)21:05
melwittyeah, I guess I haven't used the non-field properties too much. or I keep forgetting about them21:05
sean-k-mooney[m]melwitt: ya that has come up a few times21:06
* melwitt is late to the party ... again21:06
*** fragatina has joined #openstack-nova21:06
*** danpawlik has joined #openstack-nova21:07
sean-k-mooney[m]Eveyone finds it surprising as they expect ovo/nova objects to prevent python being python and allowing you to add attributes to objects when ever you feel like it21:07
melwittI think it was the use of it in the init that threw me off. InstanceMapping(user_id=<id>) looked so official21:09
*** moshele has joined #openstack-nova21:09
sean-k-mooney[m]Hum it could still be a bug. Non fields are not serialised, the user id sounds like it should be persistent21:10
*** eharney has quit IRC21:10
*** pchavva has quit IRC21:11
melwittyeah, I'm guessing the use wasn't intentional (it's just in a test)21:11
melwittI'm trying to recreate a bug and been poking around these functional tests21:11
*** bnemec is now known as sin-master21:12
*** sin-master is now known as bnemec21:12
*** danpawlik has quit IRC21:12
sean-k-mooney[m]Thats always an interesting experience, your never sure what you will find21:13
openstackgerritmelanie witt proposed openstack/nova stable/pike: DNM: reproducing bug 1746509  https://review.openstack.org/55505821:13
openstackbug 1722404 in OpenStack Compute (nova) ocata "duplicate for #1746509 Database transactions can fail with "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" because of scatter_gather_cells" [Undecided,In progress] https://launchpad.net/bugs/1722404 - Assigned to Matt Riedemann (mriedem)21:13
*** esberglu has joined #openstack-nova21:14
*** AlexeyAbashkin has joined #openstack-nova21:17
dansmithmelwitt: ah, I'd be fine restricting init to only things in fields, that makes plenty of sense to me21:18
dansmithmelwitt: just not instance.does_not_exist = True21:19
mriedem^ is definitely something that tripped me up with something in the nova-network API code that relies on setting things on an object which aren't in fields, and reads that attribute in the REST API21:19
mriedemcan't remember which one specifically, but it was probably me that surprised dan about being surprised21:19
dansmithheh21:20
mriedemunrelated, but coincidental to the service / compute node delete and host discovery stuff lately https://bugs.launchpad.net/nova/+bug/175720721:20
openstackLaunchpad bug 1757207 in OpenStack Compute (nova) "compute resource providers not equal to compute nodes in deployment" [Undecided,Incomplete]21:20
sean-k-mooney[m]dansmith: personally i think the best solution would be to add a mixin to ovo to all strict dield checks and then use it where it is correct to.21:21
*** AlexeyAbashkin has quit IRC21:21
*** jmlowe has joined #openstack-nova21:21
sean-k-mooney[m]*allow strict field checks21:22
dansmithsean-k-mooney[m]: it's just not a thing I care much about, but if it's a mixin, then that's better than changing the behavior of the base object21:22
dansmiththey behave like any other python object right now, which seems more like I would expect21:22
dansmithit just only version-tracks the things in fields21:23
dansmithI agree we should only set things in init if they're in fields, and explode otherwise21:23
*** awaugama has quit IRC21:24
sean-k-mooney[m]Ya the current behavior has helped us break some circular depency too so the current behavior makes sense as the default.21:24
tssuryamriedem: the new bug is again the same thing right ? because a) RPs are not deleted and b)probably the compute service was not shut down before deleting ? so the compute_node record keeps getting recreated ?21:25
mriedemmikal: nice topic https://review.openstack.org/#/q/topic:bp/execs-ive-had-a-few+(status:open+OR+status:merged)21:25
melwittdansmith: so it would be a mixin in ovo and then use the mixin only in the nova base object? just making sure I understand the best way to go about it21:25
mriedemtssurya: yes21:25
tssuryamriedem: just saw you updated the bug, cool21:26
dansmithmelwitt: well you couldn't do it in the nova base object because we utilize the fact that we can set non-field properties on some of our objects21:26
dansmithmelwitt: but you could mix it into certain objects if you want21:26
dansmithmelwitt: the init fix though could go to the base object in o.vo I think21:27
melwittI mean to restrict only when calling __init__21:27
melwittoh, I see21:27
*** priteau has joined #openstack-nova21:27
dansmithoh no, that can co straight to the core as far as I'm concerned21:27
dansmithalthough we might break some things by doing that, but they're broken now silently21:27
melwittthe setting of non-field properties hasn't confused me before, it's only the passing them in __init__ that has21:27
melwitt(for whatever that's worth :P)21:27
dansmithI guess some library types might want a warning instead of a failure in a minor/rev release or something21:27
dansmithmelwitt: ah okay21:28
mikalmriedem: you're welcome21:28
sean-k-mooney[m]Melwitt probably 2 mixins. One for init check that could be in base nova object and one for all assignments that would not be in base nova object21:28
dansmithlike, mark it as deprecated, warn and then fail later21:28
dansmithsean-k-mooney[m]: I dunno, we don't actually set the values from init if they're not in fields, do we?21:28
dansmithah I guess we do21:29
dansmithwell, I dunno,21:29
dansmitha warning initially would be totally fine on the base object IMHO21:29
dansmithand the make it required in a year on a version bump21:29
sean-k-mooney[m]Dansmith apparently in the tests mel found21:29
dansmithsean-k-mooney[m]: yeah, I just didn't think it was actually _setting_ it, but I see it is21:29
*** sidx64 has quit IRC21:30
sean-k-mooney[m]Yeah more warning in test output :)21:30
dansmithwell, then we fix it :)21:30
dansmithwe could do it in our nova object to pre-fix everything21:30
melwittyeah, I'm not clear on if everyone would want to warn/fail if they call init with non-existent fields. maybe someone likes a shortcut like that21:31
dansmith*shrug* I guess21:31
sean-k-mooney[m]Ya im sure you could phase it in gradually21:31
dansmithit was my intent to allow free-form properties, not to allow anything in init(), that's my bias I guess :)21:32
*** felipemonteiro_ has joined #openstack-nova21:32
melwittyeah, I had the same thinking too as a user of objects21:32
*** salv-orlando has joined #openstack-nova21:32
sean-k-mooney[m]Melwitt well if they ever call make compatible or serialise the object those non fields are lost so you still have to be careful with thwm or you will get weird bugs21:33
melwittyeah. I agree it makes sense to make it more intentional when setting free-form properties, i.e. you have to do that outside of init21:34
melwittbeing that those will be lost as you said in those situations21:34
sean-k-mooney[m]Yep. We don't really use the free form attributes that often but they can be useful sometimes21:35
*** felipemonteiro__ has quit IRC21:35
*** salv-orlando has quit IRC21:38
*** jackie-truong has joined #openstack-nova21:42
openstackgerritMerged openstack/nova stable/pike: Handle volume-backed instances in IsolatedHostsFilter  https://review.openstack.org/54360321:42
openstackgerritMerged openstack/nova stable/pike: Fix docs for IsolatedHostsFilter  https://review.openstack.org/54360421:42
mriedemso uh,21:42
mriedemhttps://bugs.launchpad.net/nova/+bug/175539221:42
openstackLaunchpad bug 1755392 in OpenStack Compute (nova) "resize the instance is fail" [Undecided,New]21:42
openstackgerritMerged openstack/nova master: Remove useless run_periodic_tasks call in ClientRouter  https://review.openstack.org/55438121:42
mriedemi thought there was a thing where you couldn't resize/migrate ephemeral/swap disks?21:43
mriedemam i making that up?21:43
*** danpawlik has joined #openstack-nova21:45
mriedemsimilar https://bugs.launchpad.net/nova/+bug/175526621:45
openstackLaunchpad bug 1755266 in OpenStack Compute (nova) "Instance resize with swap on cinder volume fails" [Undecided,New]21:45
*** yamamoto has joined #openstack-nova21:47
*** vladikr has quit IRC21:49
*** moshele has quit IRC21:50
*** danpawlik has quit IRC21:50
*** itlinux has quit IRC21:51
*** danpawlik has joined #openstack-nova21:52
*** yamamoto has quit IRC21:53
*** tbachman_ has joined #openstack-nova21:54
*** priteau has quit IRC21:54
*** tbachman has quit IRC21:55
*** tbachman_ is now known as tbachman21:55
*** pcaruana has quit IRC21:55
*** danpawlik has quit IRC21:57
*** salv-orlando has joined #openstack-nova21:59
openstackgerritJulia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call  https://review.openstack.org/55476222:02
*** vladikr has joined #openstack-nova22:02
sean-k-mooney[m]mriedem: i believe its undefined behavior if you change the number of ephemeral disk on resize. Migration of swap is fine. Resize is not22:02
sean-k-mooney[m]Actually swap resize should be fine since we basically reboot22:03
*** tbachman_ has joined #openstack-nova22:04
*** tbachman has quit IRC22:04
*** tbachman_ is now known as tbachman22:04
openstackgerritMichael Still proposed openstack/nova master: Remove duplicative implementation of temporary directories.  https://review.openstack.org/55479122:04
openstackgerritMichael Still proposed openstack/nova master: Use a pythonic delete.  https://review.openstack.org/55479222:04
openstackgerritMichael Still proposed openstack/nova master: Use a pythonic delete, with a retry.  https://review.openstack.org/55479322:04
melwittmriedem, dansmith: finally tracked down what's going on in the bug where after upgrading the pike, if there are service records with no uuid (from the N-1 version), they get the "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" error22:05
melwittexplained it here https://bugs.launchpad.net/nova/+bug/1746509/comments/922:05
openstackLaunchpad bug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,Confirmed]22:05
*** sc has joined #openstack-nova22:05
mriedemsean-k-mooney[m]: i seem to remember diana clarke trying to fix something wrt swap disks and resize, found https://github.com/dianaclarke/openstack-notes/wiki/resize-disks but not the thing she was trying to fix22:06
melwittthe good news is it's no longer a bug in queens or rocky, but it is a bug in pike22:06
*** burt has quit IRC22:08
melwittis it cool if I propose a fix only for pike? how does that usually work?22:08
dansmithmelwitt: ah yeah that sort of nesting is exactly what I was saying would have to happen, but was skeptical of it existing22:08
dansmithmelwitt: so.. glad you traced it all the way down :)22:08
cfriesenmriedem: what about this? https://bugs.launchpad.net/nova/+bug/155277722:09
openstackLaunchpad bug 1552777 in OpenStack Compute (nova) "resizing from flavor with swap to one without swap puts instance into Error status" [Medium,In progress] - Assigned to Kam Nasim (knasim-wrs)22:09
dansmithmelwitt: mriedem would know better than me, but we've had to do that before, IIRC22:09
mriedemreminds me of https://review.openstack.org/#/c/507854/22:09
*** sar has quit IRC22:09
cfriesenmriedem: though it looks like that one went away in pike22:10
sean-k-mooney[m]Cfriesen resize with swap is picky. I think it works more or less now22:10
melwittdansmith: yeah, initially I couldn't repro it (as expected) with only a service query. but yeah, got to the bottom of it :) I think it could be easily fixed by just splitting the _make_instance_list call out from under the _get_by_filters_impl, that is, move it to get_by_filters22:10
dansmithmelwitt: okay, I just read your comment but I didn't go look at the (old) code to see, but.. sounds good? :)22:11
melwittdansmith: yeah, just chattering aloud. I'm excited that this makes sense now22:11
dansmithmelwitt: I will put a dan dummy in my chair who will continue to listen to your chattering. he doesn't type though, so just assume he's saying "uh huh, yeah, oh. sounds good. uh huh, yeah..."22:12
melwitthaha22:12
dansmithmriedem: and no snide comments from you mister.22:13
openstackgerritJay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking  https://review.openstack.org/55508122:13
mikalpick me pick me!22:15
mriedemi'd have to see the proposed fix22:15
mikalBasically snide comments is all I do now.22:16
melwittSnide Comment Czar22:17
mriedemmelwitt: so you want to move this call to _make_instance_list from here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1235 to right after _get_by_filters_impl is called here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1243 ?22:17
mikalI would accept that job22:17
mikalOr anything entitled "Old man shakes fist at clouds"22:18
melwittmriedem: yeah, that's what I'm trying right now. already have the func test written. let's see if it works22:18
melwittyay22:19
*** mlavalle has quit IRC22:21
*** lpetrut has quit IRC22:22
mriedemso why couldn't we just also make this change on master and backport it?22:23
*** yamahata has joined #openstack-nova22:23
*** danpawlik has joined #openstack-nova22:23
mriedemeven if it's not a problem on master,22:24
mriedemwould changing the same code cause any problems?22:24
melwittoh yeah, that's a better idea actually22:24
melwittwhen I first asked, I wasn't thinking the code was going to be the same on master but it is22:25
*** munimeha1 has quit IRC22:25
*** rcernin has joined #openstack-nova22:25
mriedemdansmith: it would be best if your dan dummy looked like https://www.youtube.com/watch?v=_WQfZYacEAw22:26
melwittI'll have to rewrite this func test a bit to be a regression func test that will still fail on master. not a big deal22:26
*** liverpooler has joined #openstack-nova22:26
mriedemmelwitt: writing a test on master to fail for a thing that doesn't fail on master...breaks my brain22:26
dansmithmriedem: what else would it look like?22:26
mriedemunless you're not going to reproduce it through the API22:27
mriedembut just through the object methods directly22:27
melwittmriedem: sorry, it will fail on master in an artificial scenario that isn't currently being run. yeah, I don't think I can reproduce it through the API, from what I've seen so far22:27
openstackgerritMatt Riedemann proposed openstack/nova master: List instances performace optimization  https://review.openstack.org/50785422:27
melwittbut calling InstanceList.get_by_filters with expected_attrs=['services'] with a service record with no uuid should do it22:28
mriedemthat'd be fine then22:28
melwittk, doing22:28
mriedemi'd like to note that i can't remember the last time i've had so many "is this appropriate for stable" conversations in the same week22:28
*** danpawlik has quit IRC22:28
melwittStable Czar22:29
*** threestrands has joined #openstack-nova22:29
mriedemi would like to avoid the term "czar" for anything22:29
mriedemor tsar22:29
melwittyeah, good point22:29
mriedemor caesar22:29
*** felipemonteiro_ has quit IRC22:29
*** felipemonteiro_ has joined #openstack-nova22:29
*** threestrands has quit IRC22:30
mriedemisn't the point of czar kind of that there is only one anyway...22:30
*** threestrands has joined #openstack-nova22:30
*** threestrands has quit IRC22:30
*** threestrands has joined #openstack-nova22:30
melwittI dunno. years ago there was a czar for everything and I was thinking back to that22:30
mriedemi got the reference, i just never liked that22:30
mriedemhttps://wiki.openstack.org/wiki/Nova#People22:30
melwittyeah, same. I guess it stuck in my brain though22:31
dansmithmriedem is the sarcasm czar whether he likes it or not22:31
dansmithsorry mikal22:31
mriedemcfriesen: heh https://bugs.launchpad.net/nova/+bug/175478222:34
openstackLaunchpad bug 1754782 in OpenStack Compute (nova) "we skip critical scheduler filters when forcing the host on instance boot" [Undecided,Opinion]22:34
mriedem"nova put the instance on the host where i told it to"22:34
mriedemcfriesen: if you haven't realized it yet, the RUN_ON_BUILD = True thing is not something we enjoy having in the scheduler22:35
mriedem*RUN_ON_REBUILD22:35
mriedemalso, remember the -5 to forcing a host during cold migration22:35
*** ccamacho has quit IRC22:35
cfriesenmriedem: so why don't we just run all the filters and only evaluate the specified hostname?22:35
cfriesenother than "because that's how we've always done it"22:36
*** ccamacho has joined #openstack-nova22:36
mriedemask bauzas22:36
mriedemhe talks at least semi-annually about changing the forst host/node stuff in server create to be a 'requested' destination22:37
mriedemevaluated by the scheduler22:37
cfriesendo it22:37
cfriesen;)22:37
mriedemthat would be a microversion of course22:37
mriedemwhich i'd be ok with, it would be like passing a host to evacuate or live migrate22:37
mriedemand cold migrate now i guess22:37
cfriesendid we do a microversion when we started prefiltering via placement when forcing the destination?22:38
cfriesenI guess it's the claim in placement that I mean, not the prefiltering22:39
mriedemno, but i don't buy that argument22:41
mriedemi believe you could still fail the claim in the compute even if you force22:41
mriedembut i might be wrong, as i think the filters add the limits to the dict that gets passed down from scheduler to compute22:42
mriedemanyway, we have to claim in placement (Create the allocations) otherwise our tracking gets all screwed up, so i don't feel bad about breaking the 'force host' contract there22:43
cfriesenI think the limits happen after the filters...but in any case I get that we don't want to change behaviour without a microversion even if we never really defined the behaviour.22:43
mriedemthe limits dict is passed from the scheduler down through conductor to the compute22:44
mriedemand used for the claim22:44
mriedemthe limits dict in the scheduler is i believe populated via the filters22:44
mriedemwhich is why we can't remove the old school claim stuff in compute until we at least drop something like the caching scheduler, which doesn't use placement and relies on the late ass claim22:45
cfriesenI think you're right...I see the filters updating host_state.limits22:46
mriedemguh, i've triaged at least 2 bugs like this today https://bugs.launchpad.net/nova/+bug/175454322:46
openstackLaunchpad bug 1754543 in OpenStack Compute (nova) "not update request_spec.request_networks after attach or detach interface" [Undecided,Invalid] - Assigned to Deepak Mourya (mourya007)22:46
*** andreas_s has joined #openstack-nova22:47
mriedem"request spec isn't what i expect it to be"22:47
mriedemhow is that a bug, except for wanting to hack in your own private stuff22:47
*** tssurya has quit IRC22:48
*** yamamoto has joined #openstack-nova22:49
*** elmaciej has joined #openstack-nova22:49
*** hongbin has quit IRC22:50
*** sapcc-bot3 has joined #openstack-nova22:50
*** sapcc-bot has quit IRC22:50
*** andreas_s has quit IRC22:51
*** esberglu has quit IRC22:51
cfriesenheh...so they want request spec to reflect the instance as it is now, rather than as it was at boot time?22:51
sean-k-mooney[m]mriedem:  i havent read it yet but i would expect the request spec in the instance to be updated when i attach or detach an interface so livemigration would work right22:51
mriedemcfriesen: i guess22:52
mriedemsean-k-mooney[m]: we already have a thing that tracks that,22:52
mriedemit's called,22:52
mriedemthe instance22:52
mriedemthe request spec is not in the instance22:53
mriedemit's a copy of the initial server create request22:53
cfriesenmriedem: don't we feed the request spec to the scheduler when searching for a dest?22:53
mriedemminus ports and bdms22:53
mriedemcfriesen: sure do22:53
mriedemsometimes slightly modified22:53
mriedemso my guess would be, people have out of tree filters,22:53
mriedemand those filters need to know information about volumes and ports on the instance,22:54
mriedemand they want to get it from the request spec,22:54
*** _ix has quit IRC22:54
cfriesenI was going to ask about ports/bdms, but then you pointed out that they were subtracted anyways.22:54
mriedembecause they are too lazy to hit the DB, or cinder or neutron APIs22:54
mriedemthey aren't subtracted, they just aren't persisted in the request spec22:54
sean-k-mooney[m]mriedem: well if we send the request spec to the schduler when livemigrating then would you not want it to have the list of networks you vm currently has instead of the inital set22:54
*** yamamoto has quit IRC22:54
mriedemsean-k-mooney[m]: we don't have any filters that look at that22:55
mriedem"nova doesn't provide the thing my private out of tree filter needs" isn't a bug22:55
sean-k-mooney[m]the pci passthrough fileter looks at this22:56
sean-k-mooney[m]that said i guess we dont supprot hot attach for sriov interfaces currently22:56
sean-k-mooney[m]you can detach actully but just not attach22:56
sean-k-mooney[m]actully the pci passthroguh filter looks at the pci requests specs which i guess is a little different22:57
mriedemright22:57
mriedemnow i'm sure it's possible to attach a port to an instance where the network that port is on is available to the current compute host, and then live migrate the instance to another host where that network is't available,22:58
mriedembut that's also a problem we have with server create today22:58
sean-k-mooney[m]i always forget how the routed networks stuff works but do they just track the subnets in placement or is there also a sechuler filter22:59
mriedemthere isn't a filter22:59
mriedemthey use aggregates somehow22:59
mriedemi still don't know how it actually works22:59
sean-k-mooney[m]mriedem: on boot that is "fine" because we can retry. on livemigrate not so much23:00
mriedemwithout doing the port stuff in conductor23:00
*** gjayavelu has quit IRC23:02
sean-k-mooney[m]well if the request spec is intended to store teh inital request then ya thats not a bug23:03
*** masber has joined #openstack-nova23:04
*** danpawlik has joined #openstack-nova23:04
*** gjayavelu has joined #openstack-nova23:04
sean-k-mooney[m]mriedem: by the way was i chatting to you at the ptg about the pci white list parser bug i found. i think i tracked it to here https://github.com/openstack/nova/blob/master/nova/pci/whitelist.py#L58 do you know if there is a reason we use jsonutils directly here and not oslo.config23:07
*** edmondsw has quit IRC23:07
*** danpawlik has quit IRC23:08
*** suresh12 has quit IRC23:08
mriedemsean-k-mooney[m]: wasn't me23:10
sean-k-mooney[m]not looking to blame :)23:12
*** suresh12 has joined #openstack-nova23:13
sean-k-mooney[m]the call to jsonutils.loads(jsonspec) can raise error other then value error so if you have unicode in your  whitelist the nova compute agent can die because the exception is not caught23:13
mriedemlyarwood was looking at something similar before the ptg23:14
sean-k-mooney[m]mriedem:  i hard locked 15 server with this bug + a docker/centos kernel bug the week before the ptg23:15
sean-k-mooney[m]our lab time was interested in why our rack was suddenly draw 5% of the total phase23:15
mriedemefried: this is a fun one up your ksa alley https://bugs.launchpad.net/nova/+bug/175215223:15
openstackLaunchpad bug 1752152 in OpenStack Compute (nova) queens "Attach Volume Fails with secure call to cinder" [Undecided,Triaged]23:15
sean-k-mooney[m]any way i was talking to dug helmen about if i should "fix" it in oslo or nova ill proably submit a patch to both and see which one merges first23:17
*** elmaciej has quit IRC23:17
efriedmriedem: Looks like it has an owner?23:18
*** itlinux has joined #openstack-nova23:20
mriedemefried: dikonoor doesn't seem to actually be working on it23:20
mriedemmaybe run that through the internal powervc sametime channel :)23:21
mriedemer verse23:21
mriedemer slack23:21
efriedmriedem: Do we need to use https to get the version document??23:21
mriedemi assume https is what's in the service catalog?23:22
mriedemapparently you don't need a token to get the version document, which is ok with http23:23
mriedemso uh,23:23
mriedemhow terrible would it be if we s/https/http/ in this cinderclient code?23:23
efriedMITM?23:24
mriedemaaS23:24
efriedmordred: Care to render an opinion?  (TL;DR: is it okay to demote https to http if we're just getting the version document?)23:25
*** salv-orlando has quit IRC23:26
cfriesenany way to do a MiTM attack with the version document?23:26
cfriesenwhoops, efried already said that23:26
efriedOther than, like, corrupting it.23:26
*** salv-orlando has joined #openstack-nova23:26
efriedOr maybe spoofing a microversion with a known security flaw?23:26
cfriesenyeah, that's what I was thinking23:26
mriedemotherwise i can probably hack something like where we actually create a cinderclient client object, and then use it's internal client to make the request23:28
efriedmriedem: The alternative, though, is for this method (still in cinderclient) to use proper ksa loading instead of direct requests.get23:28
mriedemor, just use ksa23:28
efriedyeah, any of that.23:28
*** r-daneel has quit IRC23:30
*** salv-orlando has quit IRC23:30
efriedmriedem: If we want to keep that method in cinderclient, we could add a kwarg that lets you pass in a ksa session.  Then from nova use the _SESSION global which we've already loaded by that point.23:31
openstackgerritJay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking  https://review.openstack.org/55508123:31
efriedmriedem: Howzat sound?23:31
mriedemefried: i'd then have to plumb that through into cinderclient i think23:31
efriedyes, that's what I mean.23:31
mriedemsee https://bugs.launchpad.net/nova/+bug/1752152/comments/223:31
openstackLaunchpad bug 1752152 in OpenStack Compute (nova) queens "Attach Volume Fails with secure call to cinder" [Undecided,Triaged]23:31
mriedemi would like to just cut out cinderclient altogether23:31
efriedThe alternative is duplicating the cinderclient code in nova.23:31
efriedyeah, that.23:32
openstackgerritmelanie witt proposed openstack/nova master: Add functional regression test for bug 1746509  https://review.openstack.org/55509223:32
openstackbug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,Confirmed] https://launchpad.net/bugs/174650923:32
openstackgerritmelanie witt proposed openstack/nova master: Move _make_instance_list call outside of DB transaction context  https://review.openstack.org/55509323:32
mriedemalso, we can't change cinderclient API code and require a new minimum version on stable23:32
mriedemso that's kind of a non-starter23:32
mriedemalright, i can make that my tomorrow if i can get a recreate with devstack configuring cinder for ssl23:34
mriedemactually this is strange because devstack already sets up the endpoint using https if tls-proxy is enabled, which it is in our CI runs23:37
*** danpawlik has joined #openstack-nova23:39
*** chyka has quit IRC23:39
melwittmriedem: not always right? we had to enable it explicitly for nova-next, right?23:40
mriedemhttp://logs.openstack.org/45/508345/13/check/tempest-full/893771e/controller/logs/devstacklog.txt.gz#_2018-03-15_19_48_10_16723:40
openstackgerritmelanie witt proposed openstack/nova master: Add functional regression test for bug 1746509  https://review.openstack.org/55509223:40
openstackbug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,In progress] https://launchpad.net/bugs/1746509 - Assigned to melanie witt (melwitt)23:40
openstackgerritmelanie witt proposed openstack/nova master: Move _make_instance_list call outside of DB transaction context  https://review.openstack.org/55509323:40
mriedemENABLED_SERVICES=g-reg,rabbit,n-api,c-api,g-api,mysql,tempest,etcd3,s-proxy,q-dhcp,n-api-meta,tls-proxy,q-l3,c-sch,n-novnc,s-object,peakmem_tracker,n-cauth,q-metering,key,n-cond,s-container,q-meta,q-svc,placement-api,n-cpu,s-account,c-vol,n-obj,c-bak,q-agt,cinder,n-sch,dstat23:40
*** felipemonteiro_ has quit IRC23:41
melwitthm, okay23:42
mriedemmaybe it's a legacy job vs zuulv3 job thing, not sure23:42
mriedemtempest-full is zuulv3 native23:42
melwittyep, enabled there. not sure why we had to enable it in nova-next23:42
*** danpawlik has quit IRC23:44
*** gyee has quit IRC23:45
mriedemyeah right here http://logs.openstack.org/45/508345/13/check/nova-next/aa61d86/logs/screen-c-api.txt.gz#_Mar_15_20_00_06_20139523:45
mriedemMar 15 20:00:06.201395 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: INFO cinder.api.openstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] GET https://198.72.124.205/volume/23:45
mriedemMar 15 20:00:06.201628 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: DEBUG cinder.api.openstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] Empty body provided in request {{(pid=32243) get_body /opt/stack/new/cinder/cinder/api/openstack/wsgi.py:718}} Mar 15 20:00:06.202003 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: DEBUG cind23:46
mriedempi.openstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] Calling method '<bound method VersionsController.all of <cinder.api.versions.VersionsController object at 0x7f81c53a0550>>' {{(pid=32243) _process_stack /opt/stack/new/cinder/cinder/api/openstack/wsgi.py:872}} Mar 15 20:00:06.202926 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: INFO cinder.api23:46
mriedemnstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] https://198.72.124.205/volume/ returned with HTTP 30023:46
mriedemyikes23:46
mriedemMar 15 20:00:06.202003 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: DEBUG cinder.api.openstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] Calling method '<bound method VersionsController.all of <cinder.api.versions.VersionsController object at 0x7f81c53a0550>>' {{(pid=32243) _process_stack /opt/stack/new/cinder/cinder/api/openstack/wsgi.py:872}}23:46
mriedemthat's hitting the versions controller23:46
mriedemMar 15 20:00:06.202926 ubuntu-xenial-inap-mtl01-0002993032 devstack@c-api.service[32240]: INFO cinder.api.openstack.wsgi [req-2e3a55fd-3ed7-4b7f-b902-c4671afa83c4 req-d6e11ad6-95b0-42ed-bcb2-af3996a69096 admin admin] https://198.72.124.205/volume/ returned with HTTP 30023:46
mriedemidk, maybe that's via the client doing it's own version negotiation23:47
mriedemalso, if this has been regressed since pike, i'm pretty sure we would have heard more about this by now right?23:48
mriedemi assume most clouds are using ssl23:48
openstackgerritArtom Lifshitz proposed openstack/nova-specs master: NUMA-aware live migration  https://review.openstack.org/55272223:50
*** claudiub has quit IRC23:51
*** yamamoto has joined #openstack-nova23:51
*** jackie-truong has quit IRC23:54
*** yamamoto has quit IRC23:55
openstackgerritMerged openstack/nova master: Rename '_numa_get_constraints_XXX' functions  https://review.openstack.org/38507223:58

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