Thursday, 2019-03-21

*** lbragstad has quit IRC00:14
*** cdent has quit IRC00:36
*** gyee has quit IRC00:48
*** ileixe has joined #openstack-nova00:56
*** igordc has quit IRC01:16
*** Kevin_Zheng has joined #openstack-nova01:17
*** imacdonn has quit IRC01:19
*** mriedem has quit IRC01:26
*** lbragstad has joined #openstack-nova01:35
*** tbachman has joined #openstack-nova01:40
*** BjoernT has joined #openstack-nova02:01
*** BjoernT has quit IRC02:03
*** markvoelker has joined #openstack-nova02:43
*** janki has quit IRC02:44
*** cfriesen has quit IRC02:54
*** wolverineav has joined #openstack-nova02:55
*** tzumainn has quit IRC03:00
*** zhubx has quit IRC03:04
*** zhubx has joined #openstack-nova03:06
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates  https://review.openstack.org/54785003:29
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates  https://review.openstack.org/54785003:29
*** zhubx has quit IRC03:38
*** zhubx007 has joined #openstack-nova03:38
*** zhubx007 has quit IRC03:41
*** zhubx has joined #openstack-nova03:41
*** nicolasbock has quit IRC03:53
*** janki has joined #openstack-nova04:00
*** cfriesen has joined #openstack-nova04:04
*** whoami-rajat has joined #openstack-nova04:10
*** betherly has joined #openstack-nova04:19
*** ileixe has quit IRC04:21
*** betherly has quit IRC04:24
*** marst has joined #openstack-nova04:28
*** ileixe has joined #openstack-nova04:34
*** marst has quit IRC04:45
*** lpetrut has joined #openstack-nova04:54
openstackgerritYongli He proposed openstack/nova master: Clean up orphan instances  https://review.openstack.org/62776504:55
*** wolverineav has quit IRC05:02
*** wolverineav has joined #openstack-nova05:02
*** wolverineav has quit IRC05:08
*** phasespace has quit IRC05:14
openstackgerritMerged openstack/python-novaclient stable/stein: Update .gitreview for stable/stein  https://review.openstack.org/64418105:15
openstackgerritMerged openstack/python-novaclient stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein  https://review.openstack.org/64418205:15
*** lpetrut has quit IRC05:15
*** ivve has quit IRC05:18
*** janki has quit IRC05:20
*** wolverineav has joined #openstack-nova05:34
*** sridharg has joined #openstack-nova05:39
openstackgerritMerged openstack/os-vif stable/stein: Update .gitreview for stable/stein  https://review.openstack.org/64403405:42
*** janki has joined #openstack-nova05:51
*** lbragstad has quit IRC06:06
*** wolverineav has quit IRC06:07
*** pcaruana has joined #openstack-nova06:11
*** ivve has joined #openstack-nova06:22
*** brinzhang has joined #openstack-nova06:28
*** wolverineav has joined #openstack-nova06:41
*** Luzi has joined #openstack-nova06:44
*** slaweq has quit IRC06:45
*** sridharg has quit IRC06:50
*** sridharg has joined #openstack-nova06:53
*** ivve has quit IRC06:58
*** lpetrut has joined #openstack-nova07:02
*** ivve has joined #openstack-nova07:03
*** liuyulong_ has joined #openstack-nova07:17
*** cfriesen has quit IRC07:17
*** phasespace has joined #openstack-nova07:18
*** sridharg has quit IRC07:21
*** sridharg has joined #openstack-nova07:23
*** rcernin has quit IRC07:24
*** dpawlik_ is now known as dpawlik07:30
*** xek_ has joined #openstack-nova07:41
*** slaweq has joined #openstack-nova07:41
*** luksky has joined #openstack-nova07:46
kashyapsean-k-mooney: Hi, just saw the ping in the scrollback; there's a lot of text.  Hope klindgren's problem is resolved :-)07:51
*** wolverineav has quit IRC07:54
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable  https://review.openstack.org/64198108:00
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode  https://review.openstack.org/64337608:00
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode  https://review.openstack.org/64337708:00
*** tesseract has joined #openstack-nova08:02
kashyapefried: When you get a moment, lost yours / SylvainB's +2s & +W; appreciate if you can re-ACK|NACK it.08:04
*** liuyulong_ has quit IRC08:06
*** ttsiouts has joined #openstack-nova08:06
*** tssurya has quit IRC08:12
*** openstackgerrit has quit IRC08:17
*** dtantsur|afk is now known as dtantsur08:24
*** tssurya has joined #openstack-nova08:24
*** tosky has joined #openstack-nova08:27
*** helenafm has joined #openstack-nova08:31
*** slaweq_ has joined #openstack-nova08:36
*** slaweq has quit IRC08:38
kashyapbauzas: ^ When you get a moment :-)08:39
kashyap(It already had +W, just lost the ACK due to rebase)08:40
* bauzas looks08:41
*** slaweq_ has quit IRC08:47
*** mdbooth has joined #openstack-nova08:49
*** ralonsoh has joined #openstack-nova08:51
*** mdbooth_ has quit IRC08:51
*** whoami-rajat has quit IRC09:10
*** whoami-rajat has joined #openstack-nova09:18
*** sridharg has quit IRC09:19
*** IvensZambrano has joined #openstack-nova09:19
kashyapbauzas: Docs will be fixed in a separate change09:24
kashyapTo not let the core patch be blocked09:24
bauzascool with me then09:24
kashyapbauzas: Please see the review comments :-) MattR and MattB both agreed on the change09:24
kashyapThat to let this merge, and I fix the rest of the documenation09:24
bauzasjust comment and say you'll add a fup09:24
bauzassorry, fup == follow-up change09:24
kashyapYeah, it's actually added09:24
kashyapbauzas: Also at the end of the commit message I noted as such09:24
kashyap[quote]09:25
kashyapDo the minimum required update to the `disk_cachemodes` config help text. (In a future patch, rewrite the cache modes documentation to fix confusing fragments and outdated information.)09:25
kashyap[/quote09:25
*** SASAA has joined #openstack-nova09:27
bauzaskashyap: sure, but I still feel we need to document in the relnote why we now recommend writeback as default09:27
kashyapbauzas: Rel Note is also there09:27
bauzasbasically because modern OSes fsync09:27
kashyapbauzas: The default depends on what file system one is using09:27
*** sridharg has joined #openstack-nova09:27
bauzasbut if operators are scary about that, they should just keep writethrough and not use default09:27
bauzaskashyap: yup, but you're not telling it in the relnote09:28
kashyapbauzas: The documentation fix follow right after that.09:28
bauzasoperators litterally have to load a lot of context09:28
kashyapbauzas: No need for the operators to be "scary" here.  There are lots of myths about cache modes09:28
bauzasagain, I'm talking about relnotes09:28
kashyapLet me re-read it09:28
bauzastbc, my -1 is due to https://review.openstack.org/#/c/641981/13/releasenotes/notes/writeback-cache-mode-for-guests-a7e4d2806c956164.yaml@809:29
kashyapbauzas: Okay, saw your comment on the rel note -- again, not required to add your comment09:29
kashyapbauzas: Really, that's not required.  The guest OSes that don't fsync() are really really really horribly old and we don't support09:29
bauzaskashyap: I mean, we're making an opinionated choice, right? If so, let's just capture it in the relnote09:30
bauzasand not just in the commit msg, which is bad for operators09:30
bauzasand technically, I accepted it as a fix, but this isn't really a fix09:30
kashyapbauzas: Huh.  That's what the rel note says09:30
bauzasit's a performance improvement09:30
kashyapbauzas: I don't follow you.  What is not really a fix?09:30
kashyapWell, it's both.09:31
bauzaslet's take an example09:31
bauzasI have a car which is running09:31
kashyap(1) Fixing wrong assumption in Nova; (2) And (1) brings performance improvement09:31
bauzasfor sure, the engine is running09:31
bauzasbut I can make sure that I can improve the engine by changing some, say, injector09:32
bauzasthat will possibly make my engine having trouble when I stop, for example, but that's depending on my driving09:32
bauzasso, I like to know that I can improve my engine by changing my driving09:32
bauzaskashyap: again, the relnote doesn't mention a bit about guest OSes09:33
bauzasit's just litterally saying "heh, we're changing a default value"09:33
bauzasthere is no other contextual information09:33
bauzasif you say "ok, I'm going to amend the relnote in a fup", fine with me09:34
bauzasor I could just do it09:34
bauzasbut I just want to make sure operators know about the reasons we decided09:34
kashyapbauzas: Mentioning guest OSes really confuses at this point.09:34
kashyapIf an operator has longer attention span, they will carefully read the documentation09:35
sean-k-mooneykashyap: if it was just for perfromance we would not be changing the default however right09:35
sean-k-mooneythat is just a side benifit09:36
kashyapHuh, who said it was just for performance?09:36
bauzaskashyap: don't expect operators to load contect on every relnote09:36
bauzascontext*09:36
bauzasit's a massive amount of information they have to digest09:36
bauzasand we suffered some pain in the past by overexpecting their knowledge09:37
kashyapbauzas: I know very well about that.  I take great care in not assuming people will have context.09:37
gibistephenfin: do you have any suggestion about the table issue in https://review.openstack.org/#/c/644810/1/specs/stein/approved/bandwidth-resource-provider.rst@62409:37
bauzasanyway, I don't want to spend more time on it, will spin a new revision09:37
*** priteau has joined #openstack-nova09:38
bauzasgibi: stephenfin is mostly eaten by meetings all week09:38
gibibauzas: thanks I will try to fight sphinx alone then :)09:38
bauzaskashyap: let me just provide a new revision09:38
kashyapbauzas: Hang on09:38
sean-k-mooney kashyap could you update the release not with the explaning you gave to me about the 3 booleans that the cachemodes set to explain why its safe to ues writeback09:38
kashyapbauzas: Just post your new text as a comment09:39
sean-k-mooneykashyap: that is the context that ops will be missing. it was the context i was missing when i saw the commit first09:39
sean-k-mooneyops wont see the commit message so all they have is the release note09:39
bauzassean-k-mooney: yeah I agree09:40
* kashyap needs to be AFK; will address it later09:40
bauzassean-k-mooney: kashyap did a great work on documenting it in a docstring https://review.openstack.org/#/c/641981/13/nova/virt/libvirt/driver.py@41009:41
bauzasbut we don't take the opportunity to explain it to ops09:41
bauzaswhile it could be scary "heh, wtf, now I could loose data integrity?"09:41
sean-k-mooneyright well quickly looking at that it could be more or less copied into the release note09:42
sean-k-mooneyit might be a little verbose but that is not a bad thing09:42
*** derekh has joined #openstack-nova09:43
sean-k-mooneyi think all of the context is already in the patch just need to duplicate some of it into the release note09:43
*** pcaruana has quit IRC09:45
*** pcaruana has joined #openstack-nova09:46
*** wolverineav has joined #openstack-nova09:51
bauzasmdbooth: kashyap: sean-k-mooney: so, I provided an example of what I'd like to see in the relnote09:55
bauzasif operators don't want to expect modern OSes, it's their choices09:55
mdboothbauzas: I saw that. Honestly, though, this hasn't been an issue for at least a decade, maybe 2.09:55
bauzasmdbooth: not really, you can enable caching on some OSes that don't flush, right?09:56
mdboothI think it just increases cognitive load on the reader for no practical benefit.09:56
sean-k-mooneymdbooth: there are still people running centos 509:56
bauzasfrom my recall, W2K is one of those09:56
mdboothsean-k-mooney: Centos 5 definitely flushes!09:56
sean-k-mooneymdbooth: didnt it have issue with flushing09:56
sean-k-mooneyok09:56
sean-k-mooneythat was the distro that i always worried about for this kind of thing09:57
mdboothIf your OS doesn't flush data on request, you're going to find out about that real soon.09:57
sean-k-mooneyi know it does not partcally like virtio disks as i useulaly had to revert to useing other disk bus like ide to avoid kernel issues09:58
mdboothI remember having to be very careful shutting down my old 286-clone Tandy running DOS, though.09:58
bauzasoh, I remember some PITAs I got with Win2K guests in the past with OpenStack Essex09:58
bauzasI'm pretty sure they weren't flushing09:59
sean-k-mooneyim sure that at least 50% of all openstack workloads :P09:59
bauzasbut this could have been fixed in a SP or something else09:59
sean-k-mooneydos gaming in the cloud09:59
bauzasactually, that's a good question now we have containerizing OSes like Atomic10:00
bauzasdo we still flush on disk ?10:00
sean-k-mooneywith containers?10:00
sean-k-mooneythat shoudl not change10:00
mdboothbauzas: It's really an application issue: your application needs to flush.10:01
mdboothIf the application flushes, the OS should also flush.10:01
mdboothThe only thing writeback vs writethrough is going to fix is if your application flushes but the OS does not.10:01
mdboothIf the application doesn't flush, the OS can't flush it anyway, as it may not have the data.10:02
*** slaweq_ has joined #openstack-nova10:03
bauzashum, reading https://lifehacker.com/do-i-really-need-to-eject-usb-drives-before-removing-th-586381010:03
bauzasman, why is this so complicated ?10:04
bauzasanyway, I agree, it's maybe just a strawman10:04
bauzasbut I still feel we need to explain it10:04
mdboothbauzas: USB drives don't need O_SYNC either if your application flushes and you wait for your application to finish before unplugging.10:05
mdboothEject flushes the whole disk.10:05
*** cdent has joined #openstack-nova10:08
*** zbr has quit IRC10:08
bauzasyeah, just reading http://msdn.microsoft.com/en-us/library/windows/desktop/aa364218%28v=vs.85%29.aspx10:08
bauzasanyway, I'm balanced10:08
bauzassee, we're talking for 30 mins about something needing more than just a glance10:09
bauzasthe fact that mdbooth and kashyap know the situation makes reasonable the change10:09
bauzasbut I just feel we need to capture this knowledge10:09
bauzasand explain it thru the relnote10:10
*** zbr has joined #openstack-nova10:10
*** zbr has quit IRC10:16
*** slaweq_ is now known as slaweq10:18
*** zbr has joined #openstack-nova10:22
*** zbr has quit IRC10:22
*** wolverineav has quit IRC10:25
*** IvensZambrano has quit IRC10:28
stephenfingibi: Looks like you solved it :)10:34
gibistephenfin: yeah, I managed.10:35
sean-k-mooneybauzas: for the record we can talk for 30 mins about just about any topic :)10:51
*** IvensZambrano has joined #openstack-nova10:52
*** jaosorior has quit IRC10:53
*** nicolasbock has joined #openstack-nova10:58
*** eharney has quit IRC11:16
*** priteau has quit IRC11:19
*** ileixe has quit IRC11:20
*** wolverineav has joined #openstack-nova11:23
*** whoami-rajat has quit IRC11:30
*** whoami-rajat has joined #openstack-nova11:34
*** ttsiouts has quit IRC11:37
*** ttsiouts has joined #openstack-nova11:37
*** zbr has joined #openstack-nova11:38
*** wolverineav has quit IRC11:40
kashyapbauzas: Just back; ah, I mistook your formatting comment11:41
*** luksky has quit IRC11:41
*** ttsiouts has quit IRC11:42
*** eharney has joined #openstack-nova11:43
*** dave-mccowan has joined #openstack-nova11:50
*** jaosorior has joined #openstack-nova11:51
*** openstackgerrit has joined #openstack-nova11:52
openstackgerritBalazs Gibizer proposed openstack/nova master: Fix links to neutron QoS minimum bandwidth doc  https://review.openstack.org/64508411:52
*** panda is now known as panda|lunch11:52
*** dave-mccowan has quit IRC11:53
*** IvensZambrano has quit IRC11:56
*** tbachman has quit IRC11:57
*** IvensZambrano has joined #openstack-nova11:57
kashyapsean-k-mooney: CentOS-5 is perfectly fine w.r.t. flushes.  Again, as noted only *horribly* old OSes that don't matter (like RHEL-4 or even older versions of Windoze)12:01
kashyap... that had problems.  And they're not relevant.12:01
sean-k-mooneykashyap: ya12:02
kashyapsean-k-mooney: /me reworks the rel note; and you're right - some of the info I could add there12:02
kashyapBut as Matt noted, I was being careful of not adding needless cognitive load to the reader.12:02
sean-k-mooneyi just have had data curption issue with centos 5 and centos 5 based vnf in the past and was not sure if that was due to flushing12:02
*** cdent has quit IRC12:04
sean-k-mooneythat said it could equally have been down to the use of ext2/3? i cant rememebr but all i recal was we had to be very care to ensure we shutdown cleanly or we woudl have to do a rebuild with a clean image and/or do a rescue to fix the file system12:05
* kashyap nods12:06
*** eharney has quit IRC12:09
*** ttsiouts has joined #openstack-nova12:13
kashyapsean-k-mooney: bauzas: Before I upload, does this read better? -- https://kashyapc.fedorapeople.org/PS14-writeback-cache-mode-for-guests-a7e4d2806c956164.yaml.txt12:15
kashyapmdbooth: ^12:15
kashyap(Hit refresh, if you already clicked it :D)12:17
sean-k-mooney haha i had12:17
kashyapSorry, removed a duplication.  (/me is obsessed with words)12:18
sean-k-mooneyyou also just fixed an issue i ws goint to raise12:19
sean-k-mooneywe are not ment to use phases like "we're"12:19
kashyapWhich one?12:19
kashyapYeah, I know.  Contractions, etc.12:19
kashyapI find it a bit irritating, though.  I'd assume people (even non-native speakers) are competent enough to parse "we're" as "we are"12:20
kashyapBut I see where "I'd" can can confusion, as it can read: "I had", or "I would" :D12:20
sean-k-mooneyactully its not the contractrions12:20
*** luksky has joined #openstack-nova12:20
kashyapOh?12:20
sean-k-mooneywe are ment to say nova in its the wrong perspective12:21
*** markvoelker has quit IRC12:22
kashyaptox -e releasenotes12:23
sean-k-mooneyhttps://docs.openstack.org/doc-contrib-guide/writing-style/general-writing-guidelines.html#write-in-second-person12:23
kashyapErr, wrong window12:23
sean-k-mooney"Use first person plural pronouns (we, our) judiciously." we are allowed to use "we" in some cases but its generally not teh perfered pharsing12:24
kashyapRight, I normally avoid using "we", beceause it is so loaded12:24
kashyapThanks for the pointer, though :-)12:24
sean-k-mooneykashyap: am so to your origninal question i would remove "And OSes do that."12:25
*** tbachman has joined #openstack-nova12:25
sean-k-mooneyi dont think its needed but otherswise that looks ok12:25
kashyapsean-k-mooney: Not quite sure, otherwise it leaves the reader in the dark.  They'll wonder: "will the OS do or not".  But all OSes "that matter" do that12:26
sean-k-mooneyperhaps12:26
kashyapI'll say "all modern OSes"12:27
sean-k-mooneyya that read better how about "All modern OSes flush data as requried."12:28
sean-k-mooney"And OSes do that." i a sentence fragment which is why i originly suggested removing it12:28
kashyapIt follows the previous sentence :-)  But point noted.12:28
kashyapI'll do that quick lunch12:28
sean-k-mooneyyes which is what makes it a sentence fragment :) it only makes sense when read in the context of the previous sentence. when read in isolate what does "that" refer to :)12:29
sean-k-mooneyanyway enjoy lunch12:30
kashyapOkido, will join them :-)  I'm all for clarity12:30
*** zhubx has quit IRC12:35
*** zhubx007 has joined #openstack-nova12:35
*** mriedem has joined #openstack-nova12:38
*** dtantsur is now known as dtantsur|brb12:52
*** lbragstad has joined #openstack-nova12:54
*** eharney has joined #openstack-nova12:56
mriedembauzas: want to help get this in for queens? https://review.openstack.org/#/c/611945/12:57
* bauzas clicks13:06
*** panda|lunch is now known as panda|sick13:07
*** irclogbot_1 has quit IRC13:07
bauzasmriedem: done13:08
*** irclogbot_1 has joined #openstack-nova13:09
mriedemthanks13:09
*** brinzhang has quit IRC13:11
*** yaawang has quit IRC13:11
*** yaawang has joined #openstack-nova13:12
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable  https://review.openstack.org/64198113:18
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode  https://review.openstack.org/64337613:18
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode  https://review.openstack.org/64337713:18
*** cdent has joined #openstack-nova13:20
*** BjoernT has joined #openstack-nova13:20
*** marst has joined #openstack-nova13:21
*** awaugama has joined #openstack-nova13:22
*** altlogbot_3 has quit IRC13:23
*** altlogbot_0 has joined #openstack-nova13:24
*** takashin has joined #openstack-nova13:27
*** janki has quit IRC13:28
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Re-propose cross-cell-resize spec for Train  https://review.openstack.org/64280713:31
mriedemdansmith: i tried to wordsmith the personality files limitation in the re-proposed cross-cell resize spec ^13:31
*** brinzhang has joined #openstack-nova13:32
dansmithokay I guess I'll have to diff it to see the changed part13:32
*** brinzhang has quit IRC13:33
sean-k-mooneymriedem: were we recreating the config dirve during a cross cell migration or something that would cause issue for personality files?13:35
mriedemwe are13:36
*** wolverineav has joined #openstack-nova13:37
mriedemwe spawn https://review.openstack.org/#/c/635080/13/nova/compute/manager.py@514513:37
sean-k-mooneyok then back to the conversation we had yesterday. if its oke to do it for cross cell resize it logically means we may be able to do the same in general. perhaps contoled by a config option to addes klindgren concers regarding ssh keys ans scp13:38
cdentscanning across the big window and seeing "mriedem: we spawn" is chilling and worrying. Somewhere in the basement the alien mriedem's are laying eggs13:38
*** gaoyan has joined #openstack-nova13:38
mriedemmuwahaha13:38
mriedemdon't worry, i only harvest their organs13:39
*** altlogbot_0 has quit IRC13:39
*** whoami-rajat has quit IRC13:40
mriedemsean-k-mooney: i'm not necessarily saying it's ok, but i don't have a good solution right now for dealing with those during a cross-cell resize13:40
mriedemwithout glance or nova-compute running it's own http server...13:41
*** altlogbot_1 has joined #openstack-nova13:41
efriedmriedem: Didn't you (or somebody? gibi?) propose the docs for bug 1821015 ?13:41
openstackbug 1821015 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova - libvirt reshaping" [Medium,Triaged] https://launchpad.net/bugs/182101513:41
mriedemefried: no, i mentioned it to bauzas yesterday13:41
efriedokay, thought I saw a patch come through.13:41
mriedemwhat i'd like to see in those docs is an example of the expected resource providers (2 of them) and inventory (VGPU on the child provider) in the osc command output, but since i don't have the hardware, i'd have to fake out anything about the child provider13:42
sean-k-mooneymriedem: ok, well if for no other reason then documentation and haveing a place to discuss if its ok i can write up a short strawman spec to propose recreating config drives on migration.13:42
*** marst has quit IRC13:42
efriedmriedem: ack, thanks.13:42
gibiefried: I don't have VGPU hardware either13:43
gibithe closest I can have is to extract examples from the functional test we have13:43
sean-k-mooneymriedem: but in any case yes for cross cell resize the option are limited13:43
*** irclogbot_1 has quit IRC13:45
bauzasmriedem: gibi: don't worry, I'm working on it13:46
openstackgerritDan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec  https://review.openstack.org/64462513:46
*** jaypipes has quit IRC13:46
gibibauzas: cool, thanks. Hit me with the review when it is ready13:46
*** irclogbot_3 has joined #openstack-nova13:46
dansmithsean-k-mooney: yeah, I don't think it's okay either13:47
dansmithsean-k-mooney: the user doesn't know they are getting a cross-cell resize13:47
sean-k-mooneydansmith: that is true but what i was thinking was proposing. if file injection is disable we always recreate the config drive13:48
sean-k-mooneydansmith: since that is the default the behavior sould be the same for cross cell and normal resizes13:49
dansmithsean-k-mooney: as I said yesterday, file injection being disabled at the compute has nothing to do with whether or not the files end up in config drive (at least as I understand it)13:49
sean-k-mooneyoh i was not aware of that13:49
openstackgerritTakashi NATSUME proposed openstack/nova master: Override the 'get' method in DriverBlockDevice class  https://review.openstack.org/63882113:49
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py  https://review.openstack.org/56615313:50
sean-k-mooneyok. that is partly why i was just going to creat a strawman spec as i honestly have not tought it true propely13:50
*** hemna has joined #openstack-nova13:50
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Remove deprecated options  https://review.openstack.org/64231213:50
dansmithI have not chased it down fully, but I believe this is where we pass the injected files to the configdrive creation process: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3632-L363513:50
sean-k-mooneyi was pretty sure other would find holes in it13:51
*** jistr is now known as jistr|call13:52
mriedemdansmith: fix the footnotes docs issue in your spec and i'm +213:54
mriedemdansmith: i also mentioned a rebuild thing which you can document or omit, so long as we remember it during implementation13:54
dansmithgah, okay13:54
dansmithmriedem: can I leave those footnotes as bullets?13:55
mriedemthey aren't really footnotes then13:55
dansmithi.e. "* .. [1] Glance..."13:55
*** marst has joined #openstack-nova13:56
mriedemi mean, yo'ure using the [1]_ format above, so use .. [1] below13:56
dansmithWell, I have that one caps-as-traits thing13:56
gibinova meeting starts in 5 minutes on openstack-meeting13:56
mriedemi think it's fine to mix them13:56
dansmithokay will push it up and check the render13:56
mriedemon stephenfin will lose sleep over that13:56
mriedemtox -e docs :)13:56
dansmithtoo hard, let jenkins do the work13:56
openstackgerritDan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec  https://review.openstack.org/64462513:56
mriedemactually i only noticed it because i threw it in http://rst.ninjs.org/#13:57
mriedemand it complained13:57
mriedemi always forget how to do footnotes in rst13:57
dansmithme too, I looked at one of your specs to cheat,13:57
dansmithbut then copied wrong :D13:57
sean-k-mooney dansmith looks like you are right. the only config value that i see that effect this is the injected_files quota and changing the behavior based on that seams wrong13:57
mriedemthe docs builder doesn't actually fail on busted footnotes i don't think13:57
dansmithmriedem: but I can look at the render and see if it looks right13:58
mriedemregarding personality files, i will say, they are best effort and broken in lots of ways13:58
mriedemas noted in my spec known issue, you lose them on unshelve, you lose them on evacuate, and you lose them if you're only relying on the metadata api and get migrated13:58
sean-k-mooneymriedem: ya which is part of the reaosn we deprecated them.13:58
*** phasespace has quit IRC13:58
dansmithI know, but it does kinda suck13:59
mriedemi'm not disagreeing13:59
mriedemit also seems like we kind of punted on fixing that long ago13:59
mriedemwhen we talked for years about deprecating personality files, and then finally did it13:59
dansmithand it sucks because we suck, not because throwing files in a disk image that we generate is icky for any other reason13:59
sean-k-mooneyon a pure policy basis do we/should we allow behavior changes that may break deprecated api features13:59
*** jistr|call is now known as jistr14:00
mriedemmeeting time14:00
dansmithdeprecated api features are no different than regular ones if they're still available,14:00
dansmithand especially if they're still the default for the base api version14:00
dansmith(IMHO)14:00
dansmithno nova meeting for me, I have a conflict14:00
mriedemagree ^14:00
sean-k-mooneyok14:00
mriedempeople can and do still use all this stuff on 2.114:00
mriedembecause that's what osc defaults to14:00
sean-k-mooneyya true. maybe we shoudl fix osc to not default to that first :)14:01
*** mlavalle has joined #openstack-nova14:05
*** lpetrut has quit IRC14:06
*** lpetrut has joined #openstack-nova14:07
*** wolverineav has quit IRC14:12
*** jaosorior has quit IRC14:15
bauzasmriedem: just to understand correctly, you want some examples using osc-placement ?14:19
bauzasso I need to use my hardware then14:19
* bauzas checks whether he still has it14:20
bauzasyay14:20
mriedembauzas: yeah14:20
mriedembecause the release note is just a lot of words,14:20
mriedembut you really need to see an example on the command line to drive this home i think14:20
bauzasokay, I'll try to get some commands14:20
bauzasI still have a devstack node14:20
*** whoami-rajat has joined #openstack-nova14:23
*** gaoyan has quit IRC14:25
*** hongbin has joined #openstack-nova14:29
*** gaoyan has joined #openstack-nova14:35
*** altlogbot_1 has quit IRC14:35
*** altlogbot_0 has joined #openstack-nova14:36
*** dtantsur|brb is now known as dtantsur14:37
*** ttsiouts has quit IRC14:37
*** irclogbot_3 has quit IRC14:38
*** ttsiouts has joined #openstack-nova14:38
*** BjoernT has quit IRC14:38
*** irclogbot_0 has joined #openstack-nova14:39
*** ttsiouts has quit IRC14:41
*** ttsiouts has joined #openstack-nova14:41
*** jackding has joined #openstack-nova14:42
jackdingmriedem: Hi Matt, could you or other cores have a look at this please? It's been sitting there for quite a while. https://review.openstack.org/#/c/621646/14:43
mriedemefried: you'll want to jump in #openstack-release at some point14:47
mriedemi added comments and re-word suggestions to the highlight patch https://review.openstack.org/#/c/644697/14:47
sean-k-mooneyjackding: am we are cutting RC1 today so still in code freeze mode14:48
jackdingsean-k-mooney: ok didn't know that14:49
efriedmriedem: ack; what's the timeline on this, do I need to hit it or can we wait for melwitt?14:49
sean-k-mooneyjackding: master will open for train tomorow14:49
mriedemefried: i think it's due today14:49
sean-k-mooneyjackding: not sure if this backportable but ill take a look again14:49
jackdingsean-k-mooney: will hassle cores later then :) thanks.14:49
mriedemhttp://lists.openstack.org/pipermail/openstack-discuss/2019-March/003952.html14:49
mriedemefried: ^14:49
mriedemjackding: i can try to look when i'm not doing with release issues14:50
mriedem*dealing with14:50
jackdingmriedem: great, thanks14:50
*** panda|sick is now known as panda|drappt14:50
*** gaoyan has quit IRC14:51
bauzashmmm, I thought we were tagging milestones automatically?14:51
bauzasI don't see a 19.0.0.0b1 tag14:52
bauzasmriedem: ^14:53
mriedemno14:54
bauzasor are we done with milestones ?14:54
mriedemnot anymore14:54
bauzasok I missed this crucial info14:54
mriedembauzas: https://releases.openstack.org/reference/release_models.html#cycle-with-rc14:54
bauzasI knew we weren't needing to provide a tag14:54
bauzasgotcha, thanks14:55
bauzasI was just wanting to checkout some m-1 tag for my devstack14:55
bauzasbut I'll rather checkout stable/rocky14:55
mriedemif you check out stable/rocky you won't get the nested/reshaper stuff but ok14:56
bauzaswell, I want to verify the reshape using osc-placement14:57
bauzasso I can provide some examples14:57
*** takashin has left #openstack-nova15:01
*** snevi has joined #openstack-nova15:02
*** cfriesen has joined #openstack-nova15:02
*** IvensZambrano has quit IRC15:03
*** wolverineav has joined #openstack-nova15:08
mriedemcdent: looks like the vmware 3rd party CI is skipping live migration tests... http://207.189.188.190/logs/52/626952/9/check-vote/ext-nova-zuul/744e2c6/tempest_results.html.gz15:11
mriedemkind of sucks to report in our prelude release notes that vmware supports live migration now but it's not tested15:12
mriedemhttp://207.189.188.190/logs/52/626952/9/check-vote/ext-nova-zuul/744e2c6/tempest.log.gz#_2019-03-19_10_59_00_15515:12
mriedemi shall post to the ML so it's not your issue :)15:12
*** dpawlik is now known as dpawlik_15:13
NobodyCamGood Morning nova folks, can someone point me in the right direction to troubleshoot A instance not starting? I see the instance get scheduled I see a entry in the selected hosts compute log like: "Instance <BLAH> has been scheduled to this compute host, the scheduler has made an allocation against this compute node but the instance has yet to start"15:16
sean-k-mooneyNobodyCam: if you have got that far your next step is to check the nova compute agent log and see if it ever recived a boot request15:16
sean-k-mooneyif it did not then you shoudl check the nova-conductor log to ensure the down call from the conductor to the compute node was made.15:17
*** liuyulong|away is now known as liuyulong15:17
dansmithsean-k-mooney: that message is from the compute log15:18
sean-k-mooneyif it was then the issue is related to rabbitmq and you shoudl check the memsage queue15:18
sean-k-mooneydansmith: oh ok15:18
NobodyCamsean-k-mooney: Thank you :)15:18
sean-k-mooneyNobodyCam: from dansmith reply given the message you quated is form the nova compute agent are there any errors?15:20
*** sapd1_x has joined #openstack-nova15:21
NobodyCamno errors15:21
NobodyCamRabbit appears up and running15:21
NobodyCamI see services connecting15:21
*** eharney has quit IRC15:22
openstackgerritMerged openstack/nova stable/queens: Don't persist RequestSpec.requested_destination  https://review.openstack.org/61194515:22
sean-k-mooneyNobodyCam: if you grep for the instace uuid in the logs of the nova compute agent are there any results? if so coudl you share the last couple so we know howfar it got15:23
NobodyCamjust that message repeating itself several times15:24
dansmithNobodyCam: that message is not an error15:24
*** Luzi has quit IRC15:25
NobodyCamyea I not seeing nt errors15:25
dansmithNobodyCam: it means that the scheduler picked that host but never got so far as to give it to the host to start, so the message is saying that it's ignoring that assuming the boot request will be coming in soon15:25
dansmiththat means it's finding it in the DB15:25
NobodyCamconductor only has two messages with that uuis15:25
dansmithso look elsewhere for logs, likely conductor15:25
NobodyCamuuids15:25
NobodyCamhttp://paste.openstack.org/show/hrQOgRtlb6g0GbZN1mfa/15:26
sean-k-mooneyNobodyCam: what state is the instance in by the way? is it still building or in error?15:26
NobodyCambuilding15:27
sean-k-mooneyand the task is still block_device_mapping?15:27
sean-k-mooneyor something similar15:27
NobodyCamtask-state is scheduling15:28
NobodyCamhttp://paste.openstack.org/show/g2rPJbBSCo4Aj2KufVFN/15:29
sean-k-mooneythat does not really make sense. https://docs.openstack.org/nova/rocky/reference/vm-states.html#create-instance-states15:31
sean-k-mooneythe condoctor is showing that it is creating the block device mappings in this case you were booting with epherial storage form an image15:31
dansmithwe really should have a condoctor service15:32
sean-k-mooneyso the vm shoudl be in in task state Block_device_mapping or spawning15:32
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event  https://review.openstack.org/63613215:33
sean-k-mooneyand a super condoctor15:33
NobodyCamyea, there is not ethereal requested with at flavor15:33
NobodyCamhttp://paste.openstack.org/show/y7eD1LLJIlvkldWKOqFd/15:33
NobodyCam*ephemeral15:34
sean-k-mooneyNobodyCam: no what i ment is you are not usign boot from volume as the block device mappings show the root disk is local15:34
NobodyCamahh yes!15:35
sean-k-mooneyand from the flavor i can now see you have a root disk of 10G15:35
NobodyCamyes!15:35
tssuryadansmith: whenever you have some time, your opinion on https://review.openstack.org/#/c/636132/ would be highly valued/needed :) thanks in advance15:36
sean-k-mooneyanyway form the sequence diagarm of the boot state transition there is definetly somthing wrong. the only time the task state shoudl be in Schduling after the conductor started setting up the disk would be a rechedule after a failed spawn i think15:38
sean-k-mooneyunfortunetly the diagram does not capture the error paths15:38
*** wolverineav has quit IRC15:42
*** ivve has quit IRC15:42
efriedstephenfin: You seem like an obvious choice for nova/docs liaison https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation -- can I put you down?15:44
dansmithtssurya: ack15:44
stephenfinefried: I've already been appointed the oslo one so why not15:44
efriedstephenfin: you mean the oslo/docs liaison or the oslo/nova liaison? Cause I could totally put you down for that too.15:45
NobodyCamthank you sean-k-mooney :) I will attempt to redeploy nova15:45
stephenfinoslo/docs15:45
stephenfinbut sure, oslo/nova maybe makes sense too15:45
efriedk15:45
efriedKevin_Zheng, nicolasbock: Y'all are currently down as the nova/docs liaisons https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation -- are you wanting to continue in that capacity?15:47
mriedemefried: i think you could replace15:48
efriedight15:49
efriedit seems pretty clear this list isn't used much for some of the categories. Not sure how much I ought to care about it.15:50
*** gyee has joined #openstack-nova15:57
*** belmoreira has quit IRC15:58
openstackgerritMerged openstack/nova stable/rocky: ironic: check fresh data when sync_power_state doesn't line up  https://review.openstack.org/64077215:59
openstackgerritMerged openstack/nova stable/rocky: pass endpoint interface to Ironic client  https://review.openstack.org/64309815:59
efriedjackding: Did you send out a ML post for https://review.openstack.org/#/c/621646/ warning of the ComputeDriver interface change?15:59
openstackgerritMerged openstack/nova master: Documentation for bandwidth support  https://review.openstack.org/64206415:59
openstackgerritMerged openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA  https://review.openstack.org/64441215:59
efriedmriedem: looks like ready to cut rocky --^ ?15:59
mriedemefried: yup i'll propose a release16:00
efriedk16:00
sean-k-mooneyjackding: the change you ping about before still looks good to me by the way16:02
gibiefried: do you need anything else regarding https://review.openstack.org/#/c/645084/ ?16:02
jackdingefried: no. Do I need to? it's an optional parameter that has a default value.16:03
*** BjoernT has joined #openstack-nova16:03
jackdingefried: not invoked by default16:03
efriedgibi: nope, just forgot. +A now16:03
gibiefried: coolio16:04
efriedjackding: Any time the signature changes, even for an optional kwarg, it breaks OOT drivers.16:04
efriedjackding: We're not supposed to care about them, but I still have a soft spot in my heart.16:04
efriedgibi: Should we wait for that --^ for RC1?16:05
efriedI guess so, since it's renos16:05
efriedmriedem: you see anything else we should hold rc1 for?16:07
mriedemefried: https://review.openstack.org/#/c/642863/16:08
gibiefried: yeah it is fixing the renos16:08
gibiefried: so I would wait for that16:08
mriedemthe release patch can depends-on the known stuff you want to hold up for and then just adjust the hash when they land16:10
efrieddon't see a lot of value in the depends-on if the content needs to be updated anyway. Just to stop them from automerging it?16:11
mriedemyup16:11
*** wwriverrat has quit IRC16:13
*** eharney has joined #openstack-nova16:14
*** sapd1_x has quit IRC16:16
*** imacdonn has joined #openstack-nova16:19
*** jaosorior has joined #openstack-nova16:27
*** ttsiouts has quit IRC16:30
*** ttsiouts has joined #openstack-nova16:31
*** lpetrut has quit IRC16:32
*** tobias-urdin has quit IRC16:32
*** tssurya has quit IRC16:34
*** ttsiouts has quit IRC16:35
*** BjoernT has quit IRC16:36
openstackgerritMerged openstack/nova master: Fix links to neutron QoS minimum bandwidth doc  https://review.openstack.org/64508416:41
*** mvkr has quit IRC16:48
*** ivve has joined #openstack-nova16:54
*** rpittau is now known as rpittau|afk16:55
*** helenafm has quit IRC16:58
mdboothCould this be a source of random SSH failures in the gate: https://bugzilla.redhat.com/show_bug.cgi?id=1689933 ?17:01
openstackbugzilla.redhat.com bug 1689933 in openstack-nova "[RFE] Add a simple way to enable random number generator on all flavor/image" [Unspecified,New] - Assigned to nova-maint17:01
*** luksky has quit IRC17:02
*** tesseract has quit IRC17:02
kashyapbauzas: mdbooth: efried: When you get a minute, please put this one out of its misery: https://review.openstack.org/#/c/641981/ (libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable)17:04
efriedkashyap: did you want that in RC1?17:05
bauzasI'm just wrapping my head with devstack atm17:05
efriedCause that's all we're gonna merge today.17:05
kashyapefried: Would certainly be useful to get some initial testing17:05
mdboothkashyap: That's a no ;)17:05
efriedmriedem: RC1 candidate?17:05
kashyapThe sooner the better, as we'd be doing a bit of a disservice to the users17:05
kashyapmdbooth: Hehe17:05
*** igordc has joined #openstack-nova17:06
* kashyap will be off the next week; and don't want to cache all this stuff in his brain when he comes back the week after, and still seeing a Zuul +1 staring at me :-)17:06
mdboothI think it's a backport candidate, though. We'll almost certainly take it downstream. It's not a regression, though, and it won't cause dataloss or any kind of error. It's just unnecessarily slow.17:06
mdbooths/I *don't* think/17:06
mdboothErm, I do think.17:06
* mdbooth is hungry and confused17:07
* kashyap gives mdbooth a glass of ... $beverage_of_choice :-)17:07
* mdbooth gets food17:07
sean-k-mooneykashyap: that is not a regression so it normally would not qualify for an rc right?17:08
kashyapmdbooth: Thanks for the review so far!  Appreciate it17:08
kashyapsean-k-mooney: Not a regression; but why inflict needless slowness?  This patch can (positively) impact all new instances17:09
sean-k-mooneykashyap: im also not sure its technically a bug. it sound more like a specless blueprint.17:09
sean-k-mooneykashyap: well you can just set the config option too17:09
sean-k-mooneyanyway this just feels like a feature that is filed as a bug which can be worked around via a config already so im not sure if it qualifes for RC incution but i also dont think you will be breaking anything17:11
kashyapThis is fixing existing tech debt.  The more it is delayed, the more I lose motivation to fix it.17:11
sean-k-mooneysure but when i looked at this earilar i assume this was targeting train not stien17:11
kashyapsean-k-mooney: Also, Huh?  This is not a "specless blueprint".  This is actually a misuse/bug.17:11
sean-k-mooneyeverything working but being slow is not a bug17:12
kashyapsean-k-mooney: True.  But I won't cry into my pillow if it doesn't make it to Stein, though17:12
kashyapJust that I'd "strongly suggest" to get this in -- also because the "other patch" (for `qemu-img convert` case) merged.17:12
sean-k-mooneykashyap: didnt that merge before feature freeze17:13
kashyapAnd it's not nice to have these splatter over two releases.17:13
kashyapsean-k-mooney: Yep17:13
kashyapFrankly, I was just so buried in actually digging the issue, that I lost track of all this time.  Most deadlines are arbitrary in my mind.17:13
kashyap(As in, wasn't paying attention whether it was merged before or after RC1)17:14
mriedemefried: i do not think that writeback patch is an rc1 candidate no17:14
mriedemit's extremely latent17:14
mriedemdamn it where is jaypipes17:14
efriedk, swhat I figured.17:14
mriedemdansmith: edleafe: cdent: i've dumped comments on surya's 'locked_reason' spec - specific feedback on (1) the data model changes and (2) rest api payload format would be appreciated https://review.openstack.org/#/c/638629/17:15
sean-k-mooneykashyap: once rc1 is cut tonight it can be merged tommorow after the stable/stien branch is cut17:15
* mriedem gets a haircut17:15
kashyapmriedem: Yes, it is latent.17:15
sean-k-mooneythe real question is is it backportable17:16
cdentmriedem: thanks queued17:16
*** mriedem is now known as mriedem_grooming17:16
kashyapI definitely think it is backport-worthy.  See mdbooth's comment earlier17:16
*** mvkr has joined #openstack-nova17:16
sean-k-mooneykashyap: in which case it can be proposed for backport to stable/stien and the other stable branches17:17
kashyapmriedem_grooming: I don't agree with your emphatic "no".  But whatever.  I have 1000 other things that need my attention17:17
sean-k-mooneyso its not really that much of an issue17:17
kashyapsean-k-mooney: Yep, so it's fine, if it's merged tomm.17:17
* mdbooth disagrees. Everything working but being *unnecessarily* slow is a bug, imho.17:17
sean-k-mooneymdbooth: do you consider qemu vert type to be a bug17:18
kashyapsean-k-mooney: But, I'd prefer it to be in Stein.  I didn't "plan" this work.17:18
sean-k-mooneymdbooth: you can say yes :)17:18
mdboothkashyap: I don't think it's worthy of Stein at this stage.17:18
kashyapmdbooth: Okido...17:18
mdboothkashyap: Focus on the backport.17:18
kashyapI don't know; I'll focus on dinner first17:19
mdboothkashyap: Good call :)17:19
kashyapsean-k-mooney: mdbooth: But as noted, The two volume drivers patches should _also_ merge at the same time17:19
kashyapFor the "minimum possible doc" to make sense.17:19
*** psachin has joined #openstack-nova17:23
mriedem_groominglisten guys, i didn't say it wasn't a bug, i sait it wasn't a regression in stein, it's latent, therefore it doesn't need to be held up for rc1 which is already stressful17:24
mriedem_groomingso we'll deal with backports17:24
mriedem_groomingif people don't like my input on it then don't ask17:24
kashyapmriedem_grooming: Hey, I do like your input very much :-)17:25
efriedI was content at :14:5217:26
kashyapmriedem_grooming: But yep, please go ahead with RC1 stuff (after your grooming)17:26
sean-k-mooneyefried: what change ad 14:5317:27
sean-k-mooney* at17:27
kashyapsean-k-mooney: If I have to guess it's the "not an RC1 candidate" remark :-)17:27
efried:14:52, as in 14 mins 52s after whatever hour you're in (Unless you're in one of those bizarre time zones that's off by a half hour)17:27
efriedwhen I said "k, swhat I figured".17:28
sean-k-mooneyoh ha i see17:28
efriedwhich was shorthand for, "I was pretty sure this wasn't a candidate for rc1, but I wasn't positive, so I asked mriedem. He voiced a similar opinion. So that is what we shall go with."17:29
*** psachin has quit IRC17:29
bauzashonestly, not a big deal (again)17:29
bauzaswe always cut RC1 after things we wanna wait17:29
*** dtantsur is now known as dtantsur|afk17:30
bauzasthe question is : should the bug we discuss be in the waitlist ? obviously not in my mind, period17:30
sean-k-mooneyefried: by the way have you looked at the nova ptg etherpad to see what should be moved to placemetn or nova placement cross project stuff17:30
efriedsean-k-mooney: Yes, I did that yesterday, but it will need constant mriedem_groominging17:30
efriedcould have been Tuesday17:31
*** psachin has joined #openstack-nova17:31
efriedno, yesterday: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004030.html17:31
sean-k-mooneyefried: i originally adde the resource provider yaml but topic but is that something that anyone is going to pursue in train?17:32
efriedsean-k-mooney: IMO that's a straight-up Nova topic, as it doesn't ask for any changes to the placement API.17:32
sean-k-mooneyoh sorry yes it is17:32
efriedI haven't felt a whole lot of excitement behind that effort, so I haven't been pushing it.17:32
efriedbut if you're excited, I'll get excited with you.17:33
efriedsince I proposed the thing17:33
sean-k-mooneyi partly context switch and was wondering if there was still a desire to discuss it17:33
*** psachin has quit IRC17:34
sean-k-mooneywell i think there is a pain point there but im not sure if that is the solution17:34
efriedHad this revelation recently when talking about https://etherpad.openstack.org/p/placement-inter-provider-affinity -- would rather do small, simple, easy-to-understand things that have limited scope and power than try to do a super generic one-size-fits-all thing.17:34
efriedand that yaml spec leans much more toward the latter.17:34
* efried bbiab17:35
sean-k-mooneyok. im going to grab lunch too.17:35
bauzasoh man, I'm getting mad at devstack deployments17:37
sean-k-mooneybauzas: something specificlly?17:37
bauzasneutron fails to install17:39
bauzasbut meh, I'll fix it17:39
sean-k-mooneyah ok17:39
bauzasyeah, it's a reqs thing17:40
bauzaslet's go for a RECLONE=yes17:41
*** gmann is now known as gmann_afk17:43
NobodyCamfyi incase anyone ever runs in to this again: issue was bad rabbit ip in nova_api/cell_mappings.transport_url17:45
*** mvkr has quit IRC17:46
*** tssurya has joined #openstack-nova17:47
dansmithefried: cdent: what's the status on this eventlet monkeypatch thing? I saw some discussion this morning, but when I looked the other day it had changed since my review for reasons I wasn't sure about17:52
efrieddansmith: tldr we think it's good, but wait for after rc117:52
dansmithefried: ah right, because they said it was okay in train, cool17:53
efrieddansmith: was gonna bug you tomorrow (after rc1 cut) to re-up your +217:53
efriedwell, they want it backported. We just don't want to drop it into rc117:53
dansmithright17:53
*** ivve has quit IRC17:54
melwittmriedem_grooming, efried: thanks for getting the cycle highlights updated17:59
efriedyw17:59
*** derekh has quit IRC18:02
*** ivve has joined #openstack-nova18:02
*** mrch_ has quit IRC18:04
efriedour last rc1 patch just hit the 2h mark unstarted in the check queue :(18:09
*** whoami-rajat has quit IRC18:23
*** ralonsoh has quit IRC18:28
openstackgerritMerged openstack/nova master: Move libvirt calculation of machine type to utils.py  https://review.openstack.org/64455418:29
*** ivve has quit IRC18:36
*** cfriesen has quit IRC18:39
*** gmann_afk is now known as gmann18:40
openstackgerritmelanie witt proposed openstack/nova master: Move creation of rpcapi.ComputeAPI object from __init__  https://review.openstack.org/64499818:41
openstackgerritmelanie witt proposed openstack/nova master: Move create of ComputeAPI object in websocketproxy  https://review.openstack.org/64499818:44
jrollafaik there is no way to limit the project(s) which can boot an instance on a given set of compute nodes, right? surely someone has proposed this before, is it a hard no?18:45
dansmithtenant isolation yo!18:49
dansmithjroll: new placementy way to do it: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-req-filter.html18:50
jrolloooo18:50
dansmithjroll: also an old filter-based approach (google for filter_tenant_id)18:50
* jroll reads18:50
jrolldansmith: this should work perfectly, thanks!18:51
dansmithfinally, FINALLY, I do something to make jroll happy.18:52
jrollit only took 5 years18:52
dansmithbetter late than never18:52
sean-k-mooneythe tenant isolation filter has some edgecases18:53
*** mriedem_grooming is now known as mriedem18:53
sean-k-mooneythe main one being it limits the set of host a project can boot instnace on but does not prevent other project form booting instnaces on those same host18:54
dansmithsean-k-mooney: you should read that spec18:54
dansmiththere's a provision (unlike the filter approach) that will reject if the tenant is not confined, so you can avoid that situation18:55
*** itlinux has quit IRC18:55
mriedemmelwitt: did you want to re-propose the counting quotas spec so we can line that up for landing early in train?18:56
sean-k-mooneyoh cool. well it was not really a edgecase in the old filter i guess as a desing choice18:56
mriedemthe code i mean, after the spec is re-approved18:56
sean-k-mooneydansmith: nice to know the placement version accounts fot that18:56
melwittmriedem: oh, yes, I do. thanks for reminding me18:56
melwittlet me do it now so I don't forget a third time18:57
jrolldansmith: the use case mentions segregate users into cells, but it sounds like the solution only depends on aggregates, not cells, am I reading that right?18:58
mriedemthe scheduler does might be more clear than the spec https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#tenant-isolation-with-placement18:59
mriedem*docs19:00
jrollmriedem: thanks, that answers it19:00
dansmithjroll: correct19:00
*** snevi has quit IRC19:01
sean-k-mooneyjroll: the original usecase was a cellv1 -> cellv2 perfromcne regration which is why the spec focused on cells but ya it just needs aggreates19:01
jrollsean-k-mooney: right, figured as much19:01
openstackgerritmelanie witt proposed openstack/nova-specs master: Re-propose count quota usage from placement  https://review.openstack.org/64530219:01
amodidansmith: mriedem additional question related to this: im currently developing a test case on this, im getting a Scheduling error, No Hosts found. Is tempest generated project/tenant not able to execute this? cz i can run the same from admin project and it works19:03
amodisorry this error: "No valid host was found. Scheduling failed: No hosts available for tenant"19:03
dansmithamodi: if the tenant is not allowed to any aggregate and the "require" flag is set, then that's expected yes19:04
dansmithsean-k-mooney: not really performance regression, but replicating the inate behavior/feature of being able to schedule to specific cells, yes19:05
amodiyes thats set placement_aggregate_required_for_tenants=True19:05
amodidansmith: i do set the filter_tenant_id metadata to the aggregate19:06
dansmithamodi: and is the tempest tenant mentioned in there?19:07
dansmithamodi: I'd have to see what all you have and the logs, but you can see from the functional tests how it's supposed to work (and that it does) so it must be config-related19:07
mriedemamodi: why do we need a tempest test for that placement request filter? we have in-tree functional testing which should be sufficient19:07
sean-k-mooneydansmith: well cern were using the tenant isolation filter to window a set of host down to a cell based on the teant then runing the rest of the filters on that reduced set or somthing like that right. so when the went the cells v2  + placement they had some scaling issue  where by if the use the placement limit feature they could get no valid host so you impmented this feature to give the same19:08
sean-k-mooneyfucntionaliy the previously had in a placement native way. at lest that is more or less my memory of events19:08
amodidansmith: yeah the  filter_tenant_id= $tempest_generated_tenant_id19:08
dansmithsean-k-mooney: because they look for a small number of placement results it was just not working, not really scale-related, although this does/should perform better yes19:09
dansmithamodi: yep, well, should be working then, if the host(s) are in that aggregate.. see the functional test for details :)19:10
amodimriedem: well im checking functional tests19:10
amodidansmith: sure19:10
sean-k-mooneydansmith: didnt the look at a small number of host because when they did not limit the got too much data back form placment and it was slowing down schduling19:10
*** awalende has joined #openstack-nova19:11
dansmithsean-k-mooney: okay, yes, they limit placement to a very small number for performance reasons. And then that affects the correctness of the multi-tenant filter.19:11
sean-k-mooneybasically the "this tiny vm fits on all host so return all host proablem"19:11
sean-k-mooneyya19:12
dansmithI'm *so* glad we hashed that out.19:12
sean-k-mooneysorry but this is likely to become more important in an edge cloud deployment too19:13
sean-k-mooneyor similar issues at anyrate19:13
*** cdent has quit IRC19:13
*** mvkr has joined #openstack-nova19:13
dansmithmost edge cloud configs I know of are set up so tenants can boot things in geo-local areas, and thus limiting them to specific aggregates by project isn't as common19:14
dansmithunless maybe you have really big edge sites with overlapping vertical AZs and horizontal non-AZ aggregates or something19:15
*** cdent has joined #openstack-nova19:15
sean-k-mooneyi was more thinking of the schduler prefilters in general rather then this one implmenation. as the number of host in singel cloud grows with edge deployment the mechanium you intoduce to solve this problem will like become more useful going forward19:16
dansmithindeed, and hence my desire to do the image type filtering in placement instead of after the fact19:18
cdentprefilters++19:19
mriedemspeaking of, i think i've got a hack for pre-filtering hosts that support multiattach volumes now19:21
sean-k-mooneymriedem: im also working on a spec for prefilting host based on virtual device modesl they support19:22
mriedemlet us all work on pre-filters19:22
sean-k-mooneyi mean they are the new placement that will solve all proablems that and traits19:23
sean-k-mooneythis is what i have so far but ill have a first draft up on gerrit tommorow or monday19:24
sean-k-mooneyhttps://etherpad.openstack.org/p/image-metadata-prefilters19:24
dansmithsean-k-mooney: and is this for places where you've passed a port in and it specifies some host model?19:25
dansmithI would expect the normal "just hook me up" request to not need such filtering19:25
*** whoami-rajat has joined #openstack-nova19:26
sean-k-mooneyno this is based on image metadata so if you select an image that says it ned hw_vif_type=e1000 then we should not schdule you to a hyperv host that does not support it19:27
dansmithoh from19:27
dansmithyeah19:27
* dansmith just read19:27
*** luksky has joined #openstack-nova19:29
*** cfriesen has joined #openstack-nova19:31
sean-k-mooneydansmith: i havent spell checked anything so before i submit it as a spec ill be running it true grammerly19:33
dansmithsean-k-mooney: oh I don't think you need to spell check it19:34
dansmithsean-k-mooney: =P19:34
sean-k-mooney:) your right i just need to add stephenfin or jay to the review and wait for the wall of comments19:35
dansmithhah, make gerrit OOM19:36
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Pre-filter hosts based on multiattach volume support  https://review.openstack.org/64531619:40
mriedemefried: cdent: dansmith: sean-k-mooney: ^ pretty hacky but it's also pretty easy building on top of the requested_resources stuff gibi added in stein19:40
dansmitheeeeeverybody wants into the prefilter game19:41
cdentsome people can follow trends but only dansmith can make them possible19:41
mriedempsh i was talking about this way back in https://review.openstack.org/#/c/538498/19:41
cdentnow that efried is ptl do we have to roll to resolve disputes?19:42
mriedemgonna go for a walk with the mrs while (1) it's nice out and (2) the neighbors and their annoying kids aren't outside mingling19:42
*** BjoernT has joined #openstack-nova19:45
*** sridharg has quit IRC19:46
openstackgerritMerged openstack/python-novaclient master: Remove deprecated options  https://review.openstack.org/64231219:47
* efried perks up19:51
efriedI've long thought the center of the square of tables would make a good "cage".19:52
mnasershould _local_delete() be called with instance.host == None ?19:55
mnaser"instance's host None is down, deleting from database" with "Ignoring volume cleanup failure due to 'NoneType' object has no attribute 'get'" afterwards, i'm assuming that volume clean up has to do with the fact that host is None19:56
mnaserhttps://github.com/openstack/nova/blob/5ca858eaa72acd0513e27a4c9518980b769f5d6e/nova/compute/api.py#L196719:57
mnaseri can only imagine that not possibly being evaluated properly because its hitting the local delete path19:57
sean-k-mooneymnaser: proably not19:57
sean-k-mooneyinstance.host==None would only happen if the inscate was in cell0 right19:57
mnaseror not scheduled yet19:57
mnaserif not instance.host and not may_have_ports_or_volumes <= the first part evaluates to True (as per the obvious warnings)19:58
mnasermay_have_ports_or_volumes = compute_utils.may_have_ports_or_volumes(instance) is probably evaluating the true (say this is a bfv instance)19:58
sean-k-mooney ya just read the code around it for context19:59
mnaserso it may seem that _local_delete() assumes that a host exists20:00
sean-k-mooneyi might be blind but wher is _local_delete() called in that function20:01
mnaserhttps://github.com/openstack/nova/blob/5ca858eaa72acd0513e27a4c9518980b769f5d6e/nova/compute/api.py#L2128-L212920:02
mnaserthe NoneType get happens inside here somewhere https://github.com/openstack/nova/blob/5ca858eaa72acd0513e27a4c9518980b769f5d6e/nova/compute/api.py#L2174-L219920:02
sean-k-mooneyah that funciton is a lot longer then i tought it was20:02
sean-k-mooneyproably form compute_utils.get_stashed_volume_connector20:05
mnaseri think so20:06
sean-k-mooneyyep https://github.com/openstack/nova/blob/a5e3054e1d6df248fc4c00b9abd7289dde160393/nova/compute/utils.py#L126220:06
mnaserwill LOG.error() print out the traceback or whats the best way to do it20:06
mnasersean-k-mooney: yeah but there is 'if connector:' before that20:06
mnaserwhich if connector is None then it should evaluate to false right off the bat)20:07
sean-k-mooneyi think there is a  log.exception() prints a nice traceback20:07
mnaserconnector = jsonutils.loads(bdm.connection_info).get('connector')20:11
mnaserAttributeError: 'NoneType' object has no attribute 'get'20:11
mnaserthe interesting thing is there is an if statement `bdm.connection_info is not None`20:12
sean-k-mooneyok so jsonutils.loads(bdm.connection_info) did not produce a dictionary20:12
mnaseryeah, i will log it's value20:12
sean-k-mooneyit could be the empty sting20:12
sean-k-mooney*string20:12
mnaserLOG.debug(bdm.connection_info) => null ?20:13
sean-k-mooneynull20:14
sean-k-mooneyas in that is what it litally printed20:14
mnaserand then json parsing null gives... None20:14
mnaserso bdm.connection_info is the literal value 'null'20:14
sean-k-mooneyya that would make sense20:14
mnaserweird20:14
sean-k-mooneywell i dont know why bdm.connection_info is null20:14
mnaserwell i see it in the db equal to null too hmm20:15
sean-k-mooneywell the litral null is a valid json type20:16
sean-k-mooneyhttps://www.json.org/20:16
mnaserhmm20:17
sean-k-mooneyso id the db colume is null becuae no conection info exists for this incance becasue it has never been schduled then it makes sense that it woudl be null when we parse it there20:17
mnaserQuota exceeded for 86bbbcfa8ad043109d2d7af530225c72, tried to create 80G volume (6080G of 6144G already consumed).: OverQuota: Quota exceeded for resources: ['gigabytes']20:17
mnaserso im wondering if when it tries to create bfv vol, it fails, instance tries to delete, poof20:18
sean-k-mooneyya that sound plasible20:18
sean-k-mooneywe could jsut add a none check there20:18
sean-k-mooneyso store teh value of jsonutils.loads(bdm.connection_info) then do a "if connection_info is not None: ...20:19
mnaserdoes nova get connection_info right away or does it poll till it gets it20:19
mnaserim assuming it polls20:19
*** awaugama has quit IRC20:20
mnaserlooks like we do json loading often so it would be good for us to store {} instead of null i guess20:20
sean-k-mooneyi wont have connection info untill after it has schduled to a host20:20
sean-k-mooneywe proably dont store {} to avoid updating all old instances when we first load them20:21
sean-k-mooneyin anycase we proably should not be doing random json loads in the code like that20:22
mnaserits happening a tons tho :X20:22
sean-k-mooneysure but that does not mean its a good thing :)20:23
mnaser++ yeah i agree20:24
*** cdent has quit IRC20:24
mnaserhttps://github.com/openstack/nova/blob/6efa3861a5a829ba5883ff191e2552b063028bb0/nova/volume/cinder.py#L575-L60520:24
edmondswI don't think openstack-tox-lower-constraints is working properly... I just had to put up a fix for nova-powervm that would appear to be needed for nova as well based on the lower-constraints.txt, but that check is passing...20:25
sean-k-mooneyif20:25
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L677-L68720:25
edmondswand it looks like it's passing because the job is actually using a newer version of psycopg2 (2.7.7) than what the lc txt file indicates (2.6.2)20:26
sean-k-mooneyedmondsw: cdent fixed some things in lower contratins a week or two ago20:26
edmondswhere's the nova-powervm fix for reference: https://review.openstack.org/#/c/64533020:26
sean-k-mooneyedmondsw: it may be using the system installed version20:26
edmondswwhatever it's doing, it's not right20:26
mnasersean-k-mooney: from oslo_serialization import jsonutils; jsonutils.dumps(None) => 'null'20:27
efriededmondsw: This may be a better question for #openstack-requirements, but I think whatever you have in l-c is not necessarily what the lower-constraints job will install, as it has to take the highest-low from all the projects it's installing.20:27
sean-k-mooneymnaser: ya mapping None to 'null' is what i would expect20:27
mnaserso what we should do is make sure that we do something like20:28
mnaserself.get('connection_info', {}) instead20:28
efriededmondsw: iow if nova-powervm has l-c for foo==1.5 and bar==X and bar at X has l-c for foo==1.7, you're gonna get 1.720:28
edmondswefried this is just an FYI... do with it what you will20:28
sean-k-mooneyedmondsw: if the issue is the one i think it is related to postgree it could also be donw to the desto the lower constratits job is using20:30
edmondswand whatever you do, you may want to bump to at least 2.7 for psycopg2 in nova's lc file, since 2.6.2 isn't going to work if it ever was to get used20:30
sean-k-mooneyedmondsw: well it will if you are not useing postgres20:31
edmondswif you're not using postgres then you don't need psycopg2 :)20:31
sean-k-mooneywell that was basically my point20:31
edmondswbut anyway... this is just a public service announcement20:32
sean-k-mooneyim not sure we can raise our lower constrants at this point can we?20:32
*** igordc has quit IRC20:32
*** mrch_ has joined #openstack-nova20:32
efriedfor stein? It would take an emergency.20:32
sean-k-mooneyedmondsw: we have see this issue downstream by the way too but we just used 2.7 instead20:33
mnaserhttps://bugs.launchpad.net/nova/+bug/1821244 im gonna work on this now.  it should be a simple fix.20:33
openstackLaunchpad bug 1821244 in OpenStack Compute (nova) "Failed volume creation can result in invalid `connection_info` field" [Undecided,New]20:33
edmondswsean-k-mooney negating the purpose of lower-constraints20:33
sean-k-mooneyedmondsw: well this show up in older release too20:34
sean-k-mooneythe root casue was the presence of postgres 10.X that broke the compatiblity20:34
sean-k-mooneyif you use an older postgres it also works20:35
sean-k-mooneybut ya we should bump it but tommorow20:35
*** tssurya has quit IRC20:38
sean-k-mooneyefried: the lower constratins job should use nova lower constratin as the upper constratin20:38
efriedsean-k-mooney: even if it installs some other dep that has a higher lower constraint? That doesn't make sense.20:39
sean-k-mooneypip transitive depencies via requirement.txt will not look at there upper or lower constratints20:39
sean-k-mooneyefried: it will fail to install if our constratin file say 2.0.0 and they request >= 3.0.020:40
sean-k-mooneyupper/lower constratins.txt is an openstack convention so pip/setuptools does not know about them20:41
sean-k-mooneypip just looks ate the requiremets.txt files20:42
efriedsure, but I would expect the l-c job to know about them.20:42
efried...about the lower constraints for the projects that have lower constraints.20:42
sean-k-mooneythe lower constratin job does pip install -r requriements.txt -c lower-constratints.txt20:43
sean-k-mooneyonly one constratint file. nova is passed when installing the deps20:43
efriedmm, okay, then yeah, I guess it should only be observing my own l-c huh20:43
* efried shrugs20:44
sean-k-mooneyfor what its worth the job does look broken20:46
sean-k-mooneyhttp://logs.openstack.org/46/621646/20/check/openstack-tox-lower-constraints/8b49dc9/tox/lower-constraints-1.log20:46
sean-k-mooneywe are passing bot an upper-constratins.txt and lower-constraints.txt to pip20:46
sean-k-mooneyok i see what going on20:48
sean-k-mooneyill see if i can fix that20:48
sean-k-mooneyour install command include upper-constratints20:49
*** mdbooth_ has joined #openstack-nova20:49
efriedsean-k-mooney: you mean L18 of tox.ini?20:51
sean-k-mooneyyes20:51
sean-k-mooneyim overriding hte install_command local to not do that in the lower-constraints env and ill see what hapens20:52
sean-k-mooneyi can see it endup using 2.7.7 in the gate20:52
sean-k-mooneyit should have been using 2.6.8 or whatever20:52
*** mdbooth has quit IRC20:52
sean-k-mooneywell that failed instantly20:53
efriedso there's nothing tox-magical about the "lower-constraints" name like there is for pyXX that would be smart enough to use a fresh install_command?20:53
efriedfailed instantly because a l-c is too low?20:53
sean-k-mooneyno lower-constraints is an openstack thing20:53
efriedokay.20:53
sean-k-mooneyit faild on the postgressql issue20:54
efriedso we've been borked for a while and real l-cs have been creeping past us.20:54
efriededmondsw: Thanks for the find there!20:54
sean-k-mooneyya for basicly ever i think looking at the git blame20:54
efriedwell, we've done quite a bit to tox.ini in the last release or two.20:54
sean-k-mooneythe install command predate adding lower constratints i think20:54
efried...but not sure if those have been touched.20:55
sean-k-mooneyill bump the lower constatin to 2.7 and push a patch shortly20:55
efriedsean-k-mooney: Well, that might not be the only transgressor20:55
efriedbut I guess you'll find out :)20:55
sean-k-mooneyi was trying not to say that out loud but yes20:55
sean-k-mooneyi should proably file a bug for this. ya the next issue is the zvm sdk20:57
sean-k-mooneyi think i fixed this error actully it complingin about the python version support20:57
sean-k-mooneyi shoudl proably file a bug for this. shoudl this be a RC2 thing20:58
openstackgerritMerged openstack/nova-specs master: Re-propose count quota usage from placement  https://review.openstack.org/64530221:00
mnaserim struggling to trace the path of failure but i have a fix for this :\21:04
openstackgerritMohammed Naser proposed openstack/nova master: wip: bdm: store empty object as connection_info by default  https://review.openstack.org/64535221:07
mnaserif someone has a few cycles to spare, i'm going to keep digging but i don't know the code that well to know why it's being saved with 'null'21:07
sean-k-mooneymnaser: if the value is ever set to None it will be serialised to 'null'21:08
sean-k-mooneyi can try and take a look at it in a bit but i also dont know the bdm code that well21:08
mnasersean-k-mooney: yeah.. but i am trying to figure out why it would either be a) set to None or b) .get('connection_info') fails and returns None21:08
mnaseroh interesting21:09
sean-k-mooneyif its trying to delete it before the block device mappings are constructed then that might be the issue21:09
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L284-L28821:10
mnaserby default, the connection_info field defaults to 'NULL'21:10
mnaserso that means self['connection_info'] = None ..21:10
mriedemisn't the instance.host set before that though?21:10
mriedemthe instance_claim sets the instance.host21:10
sean-k-mooney ya which just porpagates that default21:10
mriedemso you shouldn't get a local delete flow in the API21:10
mnasermriedem: this is a case where instance.host = None so i think what happens is that the build aborts a few times on the compute host21:11
mnaserand then when it fails to build it, instance.host goes to None21:11
mnaserbecause cinder blows up when it tries to create a volume and you're out of quota21:11
mnaserthis isnt a case of instance.host = None because we're in cell0, it's because we failed to build the instance N times and gave up21:11
mriedemanything failing in _prep_block_device automatically aborts the build21:12
mriedemthere is no reschedule21:12
mriedemhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/compute/manager.py#L231721:12
mriedemespecially if you hit overquota21:12
mnaseryeah im def hitting overquota because of the error logs21:12
mnaser"Failed to create block device for instance due to exceeding volume related resource quota. Error: VolumeSizeExceedsAvailableQuota: Requested volume or snapshot exceeds allowed gigabytes quota. Requested 80G, quota is 6144G and 6080G has been consumed.: OverQuota: VolumeSizeExceedsAvailableQuota: Requested volume or snapshot exceeds allowed gigabytes quota. Requested 80G, quota is 6144G and 6080G has been consumed."21:13
mnaserso that code is getting exercised21:13
mriedemthat should reset the instance.host to None here https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/compute/manager.py#L201821:13
mriedemthis is booting a volume from an image yeah?21:13
mnaserwhich means a follow up delete will result in a local delete path?21:13
mnaseryeah21:13
mriedemso it blows here https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L74121:14
mnaseryup, and the block device connection_info is set to null at this point21:14
mnasernote if i quickly hit the db, i see it flap from NULL (actual SQL null, when a new record is created) to null (json-ified null, when the save happens, with a missing connection_info)21:15
mriedemprobably b/c of this https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L68121:15
mriedemif connection_info_string != self._bdm_obj.connection_info:21:15
mriedemif '' != None:21:15
mnasermriedem: more accurately if 'null' != None afaik21:16
mriedemoh right yeah21:16
mnaserhence i think this will fix it https://review.openstack.org/#/c/645352/21:16
mriedemok and then this blows up right? https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/compute/utils.py#L109621:16
mriedemi mean, that is true,21:16
mriedemthen jsonutils.loads(bdm.connection_info).get('connector')21:16
mriedemblows up21:16
mnaseryeah21:17
mnaserthat's as far as i got, but i don't know what triggers a save() which pushes the json stuff in the db in the failing path21:17
mriedemthat code is rife with tricky decorators that save changes on methods21:18
mriedemso could be one of those21:18
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L64521:18
mnaserso if `refresh_connection_info` is called at any given moment21:18
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L648-L65021:18
mnaserwill return21:18
mnaserand then it will call the decorator to save21:18
mnaserself['connection_info'] by default is None21:19
mriedemi don't think refresh_connection_info would be getting called during spawn21:19
mnaserthe only place i noticed calls it is refresh_conn_infos21:19
mriedembut yeah that update_db decorator is what could be doing it21:19
sean-k-mooneyefried: .. we pin our lower constating for warlock to one explcitly blacklisted by python-glance client...21:20
mnaserah21:20
sean-k-mooneythe fun continues21:20
mriedemmnaser: i think that's only called here https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/compute/manager.py#L177921:20
mriedemon like move ops and such21:20
mnaserindeed thats the only reference to it that i find21:20
efriedsean-k-mooney: Presumably it doesn't hurt to elevate the warlock l-c to... whatever glanclient is using21:21
sean-k-mooneyit is useing an older version and there is no newer version21:21
mnaserah shit21:21
sean-k-mooneywe pin to 1.3.0 which was relwased in 201621:21
sean-k-mooneythey use 1.2.021:22
mriedemmnaser: which release is this?21:22
mnaserrocky21:22
mriedemit could be somewhere in here that the changes to connection_info get saved https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/compute/manager.py#L255421:23
sean-k-mooneyefried: im goint to try lowerering it21:23
sean-k-mooneythe constratin we have is from when we intoduced lower-constratits21:23
sean-k-mooneyso im not sure its actully the min version we need21:23
mnaserterminate_instance seems to get bdms21:24
mriedemmnaser: you wouldn't get there when the server is deleted,21:24
mriedembecause the instance.host is None21:24
mnaseryeah21:24
sean-k-mooneyefried: actully looking at requirements.txt we dont actully depend on it directly21:24
efriedNot surprising.21:25
*** SASAA has quit IRC21:27
mriedemmnaser: anyway, it's probably not worth trying to figure out where in that pile of spaghetting the bdm.save is getting called,21:28
mriedemwe shouldn't save 'null' in the connection_info21:28
mriedemso your change is probably sane on it's own21:28
mnasermriedem: yeah.. i was just trying to find a way to have some sort of tests but yeah21:29
mnaseralso i just realized that wouldn't even fix it21:29
mriedemget_stashed_volume_connector is very old so i'm kind of surprised someone is just hitting this now21:29
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L284-L28821:29
mnaserwhere i thought we were getting 'None' because .get("connection_info") was returning an empty field, it was actually set, but to 'null'.. so yeah21:30
mriedemi'm not sure what that has to do with it - that's code that runs before things blow up21:30
mnaserthe assumption in my fix that self['connection_info'] doesn't exist and the fact we get None is because there is no 'connection_info' key21:30
mriedem_transform is called to convert the BlockDeviceMapping object into a DriverVolImageBlockDevice object before the compute manager calls attach() on it21:31
mriedemfrom _prep_block_device21:31
mriedemit's extremely confusing21:31
mnaserbut it seems that 'connection_info' key always exists, but it can be set to None.  so the 'None' value comes from the fact that it's *actually* equal to 'None'21:31
mriedemloads(None) should raise the TypeError though21:31
*** pcaruana has quit IRC21:33
mnaserok so the ideal fix would be21:33
mnaserhttps://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L288 change that default to {}21:33
mnaserso if its null, it blows up and returns {}, if its an actual object, we keep it21:33
sean-k-mooneydumps(None) should return 'null' loads('null) shoudl return None21:33
sean-k-mooneyloads(None) shoudl be a type error yes21:34
mriedem_validate_existing_attachment_ids21:34
mriedemoops21:34
mriedemmnaser: connection_info can be None, and get_stashed_volume_connector handles it, so i'm not following you21:34
mnasermriedem: but if update_db happened, connection_info now is a literally 'null' (the string)21:34
mriedemi though https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L681 was the problem21:34
mnaserand json loads converts 'null' to 'None'21:35
mriedembut we can avoid the 'null' by changing https://github.com/openstack/nova/blob/67ac57b3258d4d7476fa544b3dfef7296e220ad2/nova/virt/block_device.py#L682 to default to {} yeah?21:35
sean-k-mooneymnaser: it convets the sting 'null' to the object None21:35
mnaseryes21:35
mriedemso you'd get '{}'21:35
mnaseryep, and that would fix it21:35
mriedemright, hence me saying "anyway, it's probably not worth trying to figure out where in that pile of spaghetting the bdm.save is getting called"21:36
mriedem"we shouldn't save 'null' in the connection_info"21:36
sean-k-mooney{} is an empty json object which is technically not the same thing but it will fix this case21:36
mnasermriedem: ah because my original 'fix' didn't actually fix it -- https://review.openstack.org/#/c/645352/1/nova/virt/block_device.py21:36
mnaserso i was referring to that, but, i will fix that now21:36
mnaserand will try to have some unit test for _transform21:36
mnaserto make sure it doesn't output connection_info = None21:37
mriedemi would think this could be easily reproducible if we just hit overquota when booting from volume and then try to delete the server21:37
mnaserprobably, but not sure if i can write that level of functional tests from my skillset so far21:38
mnaserunless you wanna a similar functional test that i can read and implement similar to21:38
mriedemi could write one21:38
mnasersure, let me push up this with a unit test too21:38
*** BjoernT has quit IRC21:40
openstackgerritMatt Riedemann proposed openstack/nova master: Pre-filter hosts based on multiattach volume support  https://review.openstack.org/64531621:41
mriedemefried: i went through and marked the deferred train blueprints that dont have specs re-approved as pending approval https://blueprints.launchpad.net/nova/train21:44
mriedemi forgot to do that when deferring from stein21:44
mriedemso we re-approve in LP once the spec is re-approved21:44
*** idlemind has joined #openstack-nova21:44
efriedmriedem: ack, thank you. I can see you saw I approved the quota one.21:44
mriedemyeah, i thought about it because you said on the review:21:45
mriedem"Blueprint in approved state [3] ✔"21:45
mriedemtechnically the blueprint shouldn't have been approved before the spec21:45
mriedembut i forgot to change those when deferring21:45
*** whoami-rajat has quit IRC21:45
openstackgerritGhanshyam Mann proposed openstack/nova master: Trivial: remove unused var from policies.base.py  https://review.openstack.org/64538021:47
mriedemdansmith: i've got this pretty much done, without using a pre-request filter https://review.openstack.org/#/c/645316/ but not sure if i need a blueprint or not, since i'm not adding a configurable filter, it's just going to always be required if you're booting from volume21:49
mriedemcuz it's kind of dumb to even try to boot with a multiattach volume if the scheduler isn't going to filter out hosts that won't support them21:50
efrieddoes that mean they would break further on down the line?21:51
efriedI mean, would initial spawn succeed or fail?21:51
mriedemit would fail,21:51
mriedemit's arguably a bug fix21:51
mriedemthe bare minimum we do today is check if the computes are new enough, but that was minimum of queens21:51
mriedemthat doesn't say bfv wo'nt work for vmware for exapmle21:52
mriedemif you're using vmware exclusively, you'd just have to never enable multiattach volumes on the cinder side via policy21:52
mriedemthat's a pain if you're doing multi-hypervisor though21:52
mriedemyou'd have to setup aggregates and filter using some flavor extra spec or something21:52
*** BjoernT has joined #openstack-nova21:54
*** xek_ has quit IRC21:55
mriedemanywho, idk, it's janky, i suppose you can't reasonably do bfv with vmware and libvirt mixed anyway because you have different volume types, and the libvirt driver isn't going to support vmware volumes and vice versa, so i'm not sure what if anything people do for mixed hypervisor - definitely at least aggregates/AZs21:55
sean-k-mooneyefried: ... this change https://github.com/openstack/nova/commit/6b844af57eebda6317b1ed3bf5a2f85dcba0bc13 does not work after i fix the lower constrating so im going to have to change it21:56
efriedmriedem: I say no bp, bug good, reno optional21:57
efriedsean-k-mooney: I'm on board with that. Long as you don't have to go changing the prod code, I say do what you gotta do to get this fixed.21:58
sean-k-mooneyim actully not sure why this is even working upstream honestly21:59
sean-k-mooneyi think it is depending on something having previously loaded messaging._drivers.impl_fake22:00
sean-k-mooney*imported22:00
sean-k-mooneyya it is22:02
sean-k-mooney>>> import oslo_messaging as messaging22:02
sean-k-mooney>>> messaging._drivers.impl_fake.FakeExchangeManager._exchanges22:02
sean-k-mooneyTraceback (most recent call last):22:02
sean-k-mooney  File "<stdin>", line 1, in <module>22:02
sean-k-mooneyAttributeError: 'module' object has no attribute 'impl_fake'22:02
sean-k-mooney>>> import oslo_messaging._drivers.impl_fake22:02
sean-k-mooney>>> messaging._drivers.impl_fake.FakeExchangeManager._exchanges22:02
sean-k-mooney{}22:02
sean-k-mooneyso there is a race based on the execution order of the tests22:03
*** yankcrime has quit IRC22:04
*** irclogbot_0 has quit IRC22:05
*** mgoddard has quit IRC22:08
*** marst has quit IRC22:09
*** mgoddard has joined #openstack-nova22:09
*** ivve has joined #openstack-nova22:11
openstackgerritSundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access  https://review.openstack.org/63124222:16
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec.  https://review.openstack.org/63124322:16
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs.  https://review.openstack.org/63124422:16
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML.  https://review.openstack.org/63124522:16
*** rcernin has joined #openstack-nova22:19
*** BjoernT has quit IRC22:24
dansmithmriedem: why is that not in request_filter.py, just without a conf flag?22:26
dansmiththat way all these "check a thing about the request and add a trait requirement" things are in one place22:27
sean-k-mooneyefried: so just as an fyi we have other dodgy test too that are wrong upstream :(22:27
efriedsean-k-mooney: I am not surprised at all.22:27
efriedsean-k-mooney: I wonder if we need to file a bug for this.22:27
sean-k-mooneyoh we do22:27
sean-k-mooneybut that is not what im concerned about22:28
sean-k-mooneythe test issue im finding shoudl be broken in other jobs22:28
sean-k-mooneyhttps://github.com/openstack/nova/blob/d2dc7549ce9a0c979fd319cf0332a861b9cd2000/nova/tests/unit/api/openstack/compute/test_serversV21.py#L512922:28
sean-k-mooney self.stub_out('uuid.uuid4', lambda: FAKE_UUID)22:28
sean-k-mooneythat stubs out uuid.uuid4 to return FAKE_UUID22:29
sean-k-mooneyFAKE_UUID is a string22:29
sean-k-mooneyoslo messaging does  unique_id = uuid.uuid4().hex'22:29
sean-k-mooney.hex is not defiend on a string22:29
sean-k-mooneyso it explodes22:29
efriedwhy isn't it exploding now?22:30
sean-k-mooneyoslo.messaging still does  unique_id = uuid.uuid4().hex on master22:30
sean-k-mooneyi think its another race in the tests22:31
*** erlon has joined #openstack-nova22:32
sean-k-mooneyhum running that test on its own on the py36 target passes but files in lower constratits22:32
efriedare you running stop-on-first-failure or do you have a sense of how many tests are broken?22:34
sean-k-mooneyok so my theory is that thing have moved and we are not mocking the right things when usign the older version of oslo.messaging22:34
openstackgerritMohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default  https://review.openstack.org/64535222:34
sean-k-mooneyi was running all the test but while i was getting many of the test to pass the lower-constratits job was hannging after running for a bit22:35
mnasermriedem: ^ this worked locally running the unit tests22:36
openstackgerritMohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default  https://review.openstack.org/64535222:37
cfriesenmriedem: I assume the vTPM blueprint status change is because it didn't make it in for Stein?22:38
*** phasespace has joined #openstack-nova22:39
sean-k-mooneycfriesen: mriedem mentioned he set the state back to pending approval for any blupritn that was approved last cycle but needs to have the spec reapproved22:39
cfriesenthx, figured as much22:39
mriedemcfriesen: right, re-propose the spec for train22:40
mriedemi forgot to switch the bp status when deferring22:40
mriedemmnaser: want to report a bug for this?22:40
mnasermriedem: oh dang i had one but i didnt add closes-bug22:45
openstackgerritMohammed Naser proposed openstack/nova master: bdm: store empty object as connection_info by default  https://review.openstack.org/64535222:45
openstackgerritsean mooney proposed openstack/nova master: make lower-constratints env use lower-constratins  https://review.openstack.org/64539222:46
mnaserok just noticed your reviews too ill try to address them after foodz22:46
sean-k-mooneyim going to keep working on ^22:46
efriedsean-k-mooney: Thanks for doing that.22:46
mriedemmnaser: ok i left some comments in PS3, not really worth -1ing over though22:47
sean-k-mooneyefried: i can fix the FAKE_UUID issue but i still suspect that our mocking is wrong in some of the tests and code that should not be run actully is being run22:48
mriedemdansmith: it's not a request filter because the request spec doesn't store the bdms, and during server create the bdms won't have multiattach information in them anyway, so to figure it out, i'd have to, within the filter, pull the list of bdms for the instance and for all with a volume_id, query cinder to figure out if the volume is multiattach or not22:48
sean-k-mooneyif the lower constraitn job explodes or times out then that is likely why22:48
mriedemif we actually had a BDM.multiattach field, that could maybe work - but we'd still have to get the bdms during scheduling...which might suck22:49
*** mriedem is now known as mriedem_afk22:50
dansmithmriedem_afk: okay, seemed like it was just examining the reqspec to determine what to do, which is exactly like the other filters, but I admittedly was skimming22:56
dansmithcan look again tomorrow22:56
*** tkajinam has joined #openstack-nova22:56
*** hongbin has quit IRC22:57
*** tosky has quit IRC22:59
*** igordc has joined #openstack-nova23:04
*** ivve has quit IRC23:27
*** awalende has quit IRC23:30
*** luksky has quit IRC23:32
sean-k-mooneymriedem_afk: dansmith melwitt  i have been talking to erric for the last hour or two about the fact our lower constrats job has been broken since we created it23:32
sean-k-mooneyim assuming we are not going to fix this in RC1 i can likely have it fixed tomorow or early next week once i figure out where we are not mocking the rpc bus in some test but is this something we would fix in RC2 or in train?23:34
sean-k-mooneyi assume we would want to fix lower constraitn on the stable branches too?23:34
sean-k-mooneyhttps://review.openstack.org/#/c/645392/123:34
melwittsean-k-mooney: I think you'll want to open a bug for that, yeah?23:36
sean-k-mooneyya i have left a todo in the review for that23:37
melwittI'm not sure this is an RC thing because it's our test job not working, not a user deliverable?23:37
sean-k-mooneybut ill do it when i start on this again tomorow23:37
sean-k-mooneytrue but the minium requirement we had listed were wrong23:37
melwittand then yes, I think we'd want to fix it on stable too. probably not pike since it's bound for EM in the next few weeks23:38
melwittsean-k-mooney: oh, I see. yeah, so maybe it would be RC23:38
sean-k-mooneylower-constrtis has only been a thing since queens i think so its only the last 2 release + stien23:39
melwittRC2, that is. I'll add it to the etherpad23:39
sean-k-mooneyya its not rc1 in anycase. but cool ill keep workign on this again tomorow23:40
*** wolverineav has joined #openstack-nova23:40
melwittsean-k-mooney: sounds good, thank you23:42
*** wolverineav has quit IRC23:45
sean-k-mooneycrap.. this same issue is in a bunch of repos23:46
sean-k-mooneyhttp://codesearch.openstack.org/?q=install_command%20%3D%20pip%20install%20-c%7Benv%3AUPPER_CONSTRAINTS_FILE%3A&i=nope&files=&repos=23:46
sean-k-mooneyi should also send a mail to the list about this tomorow23:46
*** lbragstad has quit IRC23:46
melwittsean-k-mooney: ++ good idea23:50
sean-k-mooneydoes this fall under the remite or the requireemtn team, qa team or relase team.23:50
sean-k-mooneyi think its the same people more or less on all of them but ill chat to them on irc too23:51
melwittsean-k-mooney: I would think #openstack-requirements23:52
sean-k-mooneyya so apparently lower-constraints is not actully requried by the PTI which explaing why many of the proejct with the prolematic install command have not seen this issue as they are not testing with lower constratints23:58

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