Monday, 2018-09-24

*** hoangcx has joined #openstack-nova00:41
*** fried_rolls1 has joined #openstack-nova00:48
*** fried_rolls has quit IRC00:50
*** fried_rolls1 is now known as fried_rolls00:50
*** fried_rolls is now known as efried01:07
*** mhen has quit IRC01:15
*** mhen has joined #openstack-nova01:16
*** imacdonn has quit IRC01:17
*** imacdonn has joined #openstack-nova01:17
*** mrsoul has joined #openstack-nova01:22
*** brinzhang has joined #openstack-nova01:34
*** rcernin has quit IRC01:40
*** rcernin has joined #openstack-nova01:40
*** hongbin has joined #openstack-nova01:49
*** Bhujay has joined #openstack-nova02:04
*** Bhujay has quit IRC02:12
openstackgerritJack Ding proposed openstack/nova master: Correct instance port binding for rebuilds/reboots  https://review.openstack.org/60384402:15
*** imacdonn has quit IRC02:35
*** psachin has joined #openstack-nova02:40
*** imacdonn has joined #openstack-nova02:50
*** sapd1 has joined #openstack-nova03:05
*** vivsoni has joined #openstack-nova03:25
*** hongbin has quit IRC03:39
*** psachin has quit IRC03:48
*** udesale has joined #openstack-nova03:50
*** jdillaman1 has quit IRC03:55
*** icey has quit IRC03:56
*** icey has joined #openstack-nova03:57
*** kevinbenton has quit IRC04:00
*** kevinbenton has joined #openstack-nova04:00
*** psachin has joined #openstack-nova04:00
*** vivsoni has quit IRC04:10
*** pooja_jadhav has joined #openstack-nova04:14
*** vivsoni has joined #openstack-nova04:30
*** vivsoni has quit IRC04:37
*** vivsoni has joined #openstack-nova04:37
*** vivsoni has quit IRC04:43
*** vivsoni has joined #openstack-nova04:46
*** whoami-rajat has joined #openstack-nova04:46
*** Bhujay has joined #openstack-nova04:58
*** spsurya has joined #openstack-nova05:02
*** dave-mccowan has joined #openstack-nova05:36
*** jiapei has joined #openstack-nova05:46
*** Bhujay has quit IRC05:53
*** Bhujay has joined #openstack-nova05:59
*** dpawlik has joined #openstack-nova06:03
*** ajo has joined #openstack-nova06:03
*** pcaruana has joined #openstack-nova06:05
openstackgerritBrin Zhang proposed openstack/nova master: Add volume_type field to BlockDeviceMapping object  https://review.openstack.org/60468706:23
*** Luzi has joined #openstack-nova06:28
*** belmoreira has joined #openstack-nova06:36
*** belmoreira has quit IRC06:45
*** belmoreira has joined #openstack-nova06:47
*** ralonsoh has joined #openstack-nova06:48
*** giblet is now known as gibi06:53
*** sahid has joined #openstack-nova06:55
*** sahid has quit IRC06:55
*** sahid has joined #openstack-nova06:56
openstackgerritBrin Zhang proposed openstack/nova master: Add volume_type field to BlockDeviceMapping object  https://review.openstack.org/60468706:57
gibimriedem: thanks for the review, I'm planning to focus on that patch series this week06:58
gibicdent: bedisdes the use-nested-allocation-candidates I think bauzas working on the vgpu support that will utilize nested scheduling too06:59
*** maciejjozefczyk has joined #openstack-nova07:00
gibis/bedisdes/besides/ :)07:05
*** rcernin has quit IRC07:06
*** ircuser-1 has joined #openstack-nova07:20
*** holser_ has joined #openstack-nova07:23
*** helenafm has joined #openstack-nova07:26
*** dtantsur|afk is now known as dtantsur07:46
*** jpena|off is now known as jpena07:49
*** alexchadin has joined #openstack-nova07:51
openstackgerritLee Yarwood proposed openstack/nova master: placement: Always reset conf.CONF when starting the wsgi app  https://review.openstack.org/60469308:03
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: placement: Always reset conf.CONF when starting the wsgi app  https://review.openstack.org/60469408:03
*** lyarwood has joined #openstack-nova08:10
*** alexchadin has quit IRC08:14
*** openstackgerrit has quit IRC08:22
bauzasgood morning nova08:31
bauzasI wave a bit late tho08:31
*** janki has joined #openstack-nova08:33
*** janki has quit IRC08:34
*** janki has joined #openstack-nova08:34
*** holser_ has quit IRC08:35
*** holser_ has joined #openstack-nova08:36
*** holser_ has left #openstack-nova08:36
*** Bhujay has quit IRC08:38
*** finucannot is now known as stephenfin08:38
*** alexchadin has joined #openstack-nova08:42
*** derekh has joined #openstack-nova08:44
gibibauzas: good morning08:46
*** openstackgerrit has joined #openstack-nova08:52
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222608:52
*** ratailor has joined #openstack-nova08:52
*** openstackgerrit has quit IRC09:05
*** zioproto has joined #openstack-nova09:05
zioprotohello09:05
zioprotoI am upgrading my cluster from Newton to Ocata, and I see weird failures in Nova like this http://paste.openstack.org/show/730608/09:06
zioprotodoes anyone had such problems with database foreign keys ?09:06
zioprotothis seems to be related to heat09:06
*** s10 has joined #openstack-nova09:08
*** kukacz has quit IRC09:10
*** jaosorior has quit IRC09:11
*** kukacz has joined #openstack-nova09:12
*** rpittau has joined #openstack-nova09:20
*** Bhujay has joined #openstack-nova09:32
*** openstackgerrit has joined #openstack-nova09:34
openstackgerritBrin Zhang proposed openstack/nova master: Add volume_type field to BlockDeviceMapping object  https://review.openstack.org/60468709:34
*** Bhujay has quit IRC09:37
*** sapd1__ has quit IRC09:54
*** ondrejme has joined #openstack-nova09:56
ondrejmeHello, I am trying to build Rocky from source and deploy with Kolla-ansible. I have tried to create image for nova (rhel-based), but there's a version requirement for qemu - a "qemu-img-ev". I don't want to use -ev so i built it with older version called "qemu-img". What problems can I encounter? Thanks ahead.09:57
*** sapd1_ has joined #openstack-nova09:59
openstackgerritMerged openstack/osc-placement master: import zuul job settings from project-config  https://review.openstack.org/60137409:59
openstackgerritBrin Zhang proposed openstack/nova master: Specifies the storage backend to boot instance  https://review.openstack.org/57936010:04
egonzalezondrejme better use #openstack-kolla channel, sort question is to remove package and append your with template overrides {% set nova_compute_packages_remove = ['qemu-img-ev'] %} {% set nova_compute_packages_append = ['qemu-img'] %}10:06
openstackgerritMerged openstack/osc-placement master: switch documentation job to new PTI  https://review.openstack.org/60137510:06
openstackgerritMerged openstack/osc-placement master: add python 3.6 unit test job  https://review.openstack.org/60137610:06
*** brinzhang has quit IRC10:08
johnthetubaguygibi: I had thoughts on this one, but really close to approve, what do you think, if you have time to take a peak at that? https://review.openstack.org/#/c/476459/2910:09
ondrejmeegonzales: thats what I did, and I managed to deploy as well with successful instance launch, that instance is up and running just fine, I was just wondering if you know of any functions that will not work that way10:11
*** janki is now known as janki|lunch10:14
*** sean-k-mooney has quit IRC10:14
*** sean-k-mooney has joined #openstack-nova10:15
*** jaosorior has joined #openstack-nova10:22
gibijohnthetubaguy: looking10:23
*** jiapei has quit IRC10:23
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222610:34
*** Bhujay has joined #openstack-nova10:40
gibijohnthetubaguy: responeded inline. I think you raised the same issue melwitt raised in PS21 then had some back and forth and ended up passing delete_type instead on NotificationAction10:41
*** erlon has joined #openstack-nova10:50
*** sapd1 has quit IRC10:55
johnthetubaguygibi: cool, I was struggling to work out all the context in the previous revisions10:57
johnthetubaguygibi: I am OK with add the host param, but wasn't sure what you thought, can be a follow up patch10:58
gibijohnthetubaguy: yeah I can do a followup right away10:58
johnthetubaguygibi: sounds good, I wasn't 100% if my reading of that was correct10:59
gibijohnthetubaguy: I double checked and I think you are correct10:59
johnthetubaguygibi: given its been cooking since jun17, lets just merge where we are now!10:59
gibijohnthetubaguy: I totally agree11:00
johnthetubaguycool11:00
*** Bhujay has quit IRC11:02
*** Bhujay has joined #openstack-nova11:05
*** Bhujay has quit IRC11:06
*** Bhujay has joined #openstack-nova11:07
*** Bhujay has quit IRC11:08
*** Bhujay has joined #openstack-nova11:08
*** Bhujay has quit IRC11:09
*** janki|lunch is now known as janki11:10
*** Bhujay has joined #openstack-nova11:10
*** jpena is now known as jpena|lunch11:10
*** Bhujay has quit IRC11:11
openstackgerritBalazs Gibizer proposed openstack/nova master: Follow up for Ib6f95c22ffd3ea235b60db4da32094d49c2efa2a  https://review.openstack.org/60474311:11
gibijohnthetubaguy: thanks for the reviews, here is the followup ^11:11
*** Bhujay has joined #openstack-nova11:11
*** mvkr has quit IRC11:17
*** alexchadin has quit IRC11:20
*** udesale has quit IRC11:25
*** mvkr has joined #openstack-nova11:29
kashyapgibi: Thanks for the review here: https://review.openstack.org/#/c/562313/311:36
* kashyap is a bit embarrassed11:37
gibikashyap: don't worry, it is easy to mix those variables11:37
kashyapSo two things there: (a) first bump the version for Stein, as advertized in commit: 28d337b (Pick next minimum libvirt / QEMU versions for "Stein")11:38
openstackgerritVladyslav Drok proposed openstack/nova stable/pike: Fix resize_instance rpcapi call  https://review.openstack.org/60343911:38
*** Roamer` has quit IRC11:39
kashyapgibi: ... (b) Need to pick version for the 'T' release.11:39
kashyapgibi: Can't bump without first picking the future MIN versions for the 'T' release.11:39
kashyapjohnthetubaguy: ^ You have a comment here?11:39
gibikashyap: so you will propose a patch that set MIN based on NEXT_MIN but for that we have to figure out what will be the new value of NEXT_MIN11:43
kashyapgibi: Yes.  First we need to pick NEXT_MIN_* versions11:44
kashyapgibi: Like I sent out an email to 'operators' list in the past: http://lists.openstack.org/pipermail/openstack-operators/2018-April/015089.html11:44
gibikashyap: OK this make sense11:44
kashyap(Operators + Dev list)11:44
kashyapDo we have a name for the 'T' release yet?11:44
gibikashyap: I think we are in the name suggestion phase11:45
kashyapgibi: I just need to spend some tedious time to go through all distros that matter / upstream cares about, and arrive at the new enough version that is supported by all distros..11:45
gibikashyap: sounds like fun11:46
kashyapgibi: It is mind-warpingly tedious, but necessary :D11:46
gibikashyap: OK, that is a better description than "fun" :D11:46
kashyapHeh11:47
* kashyap in the middle of different context (to deprecate a command in QEMU), will get to this, once he 'flushes' that cache to 'disk'11:48
*** zul has joined #openstack-nova11:53
kashyapgibi: 'T' will be at the end of 2019, isn't it?11:56
*** alexchadin has joined #openstack-nova11:59
gibikashyap: autumn 201912:00
kashyapYeah.  So I'm writing an email to the list, to see if we even want to pick MIN_ versions so far out (one year ahead)12:00
kashyapThere will be 13+ libvirt releases (including maintenance streams), IIRC.  And some 4 QEMU releases12:01
kashyapI'll just write the email to the list; MattR will definitely have an opinion.  As he also did this work in the past.12:02
*** alexchadin has quit IRC12:05
gibikashyap: I agree that it is a good way forward12:06
kashyapgibi: What do you mean?  I think you mean "let's write to the list and talk there"?12:06
*** alexchadin has joined #openstack-nova12:06
gibikashyap: yeah, lets describe the issue as you descibed above (e.g. we need a new NEXT_MIN but there will be still a lot of libvirt release until 2019 autumn) on the ML12:07
kashyapYeah, almost half-way through the e-mail12:08
gibicool12:08
*** psachin has quit IRC12:13
*** jpena|lunch is now known as jpena12:14
*** zul has quit IRC12:15
*** Bhujay has quit IRC12:15
*** Bhujay has joined #openstack-nova12:16
*** ratailor has quit IRC12:16
*** leakypipes is now known as jaypipes12:24
johnthetubaguykashyap: from the wiki page, looks like the question is basically when do we drop Ubuntu 16.04 support?12:27
kashyapjohnthetubaguy: Is it just that?12:28
kashyapjohnthetubaguy: Or we can just stick to the next LTS release, that is 18.04, Bionic?12:28
kashyapjohnthetubaguy: But I like your phrasing, which gives a much simplified view of the problem :-)12:30
johnthetubaguykashyap: yeah, I just reading through the wiki page12:30
kashyapjohnthetubaguy: Based on that, I think we can simply just go with 'Bionic'.12:30
kashyapI'll double-check all the other distros, too12:31
*** mdbooth has joined #openstack-nova12:32
johnthetubaguyso, I think we said 3.0.0 and 2.8.0 which is Debian Stretch being the lower bound next, so its jump from Ubuntu Xenial to Debian Stretch as the lowest (including dropping SUSE leap 42.2)12:33
johnthetubaguyhttps://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix12:33
mdboothJust debugging a functional test where I'm trying to force an instance to a particular host. I'm getting NoValidHost. It seems we always ask placement for candidates even if we're forcing a specific host, is that correct?12:33
johnthetubaguykashyap: I just updated that for Rocky12:33
*** zul has joined #openstack-nova12:34
kashyapjohnthetubaguy: Ah, thanks!12:34
johnthetubaguykashyap: hmm, KVM for IBM Z... that seems to be a problem12:34
kashyapjohnthetubaguy: Hmm, so we can't settle with Bionic12:35
johnthetubaguywell, unless they updated or we don't care about them12:35
*** sambetts_ is now known as sambetts12:35
kashyapjohnthetubaguy: Yeah.  I'll ask on the list about what their plan is12:36
*** Bhujay has quit IRC12:39
*** Bhujay has joined #openstack-nova12:40
*** Bhujay has quit IRC12:41
*** Bhujay has joined #openstack-nova12:41
kashyapjohnthetubaguy: For Stein we are yet to bump to the advertized versions, as you may have noticed.12:42
*** jaosorior has quit IRC12:42
*** alexchadin has quit IRC12:43
*** jaosorior has joined #openstack-nova12:44
johnthetubaguykashyap: so we often do that every other cycle, historically12:45
kashyapjohnthetubaguy: Yeah.  I was just trying to stick to what we said in this commit:12:45
kashyaphttp://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=28d337b ("Pick next minimum libvirt / QEMU versions for "Stein"")12:45
*** udesale has joined #openstack-nova12:46
*** jiapei has joined #openstack-nova12:47
*** tbachman has joined #openstack-nova12:50
*** jdillaman has joined #openstack-nova12:53
*** alexchadin has joined #openstack-nova12:53
johnthetubaguykashyap: I found this: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=OC&subtype=NA&htmlfid=897/ENUS5648-KVM&appname=totalstorage#lifecycl12:57
*** icey3 has joined #openstack-nova12:58
* kashyap clicks12:58
*** afazekas has quit IRC12:58
kashyapjohnthetubaguy: It doesn't tell us version info of QEMU and libvirt, does it?12:59
johnthetubaguykashyap: seems to suggest it is discontinued, and no longer supported though12:59
kashyapjohnthetubaguy: Oh, yeah.13:01
*** icey3 has quit IRC13:01
kashyapFor completeness' sake I'll ask the open question for KVM for IBM folks.13:01
*** zul has quit IRC13:01
kashyapIf there's no response, we can pick with a version that aligns with the rest of all the distros.13:01
*** awaugama has joined #openstack-nova13:01
johnthetubaguykashyap: http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html13:02
* kashyap clicks13:02
kashyapAh, it's the blurb13:02
johnthetubaguykashyap: I think we can ignore it now, basically its all upstream, use a regular distro, appears to be the message13:02
kashyapOkay, then.  We're good.13:03
kashyapThanks for digging!13:03
johnthetubaguyI was curious what it was13:03
johnthetubaguykashyap: next question is specify the next next, if you get me, seems like Oracle and SLES need a dig13:06
kashyapjohnthetubaguy: Right, I'll ask the SLES and Oracle folks to comment13:07
kashyapjohnthetubaguy: I'm pretty damn sure they'll also align, if I see their historical releases13:07
kashyapThe community edition, openSUSE, already ships the desired "Bionic" versions.13:07
* johnthetubaguy nods13:08
*** mriedem has joined #openstack-nova13:09
kashyapThanks for helping me dig!13:11
*** lbragstad has joined #openstack-nova13:18
bauzasmriedem: quick question, when calling update_provider_tree_for_vgpus() we pass a mutable dict of allocations, and then we modify the allocations directly13:22
bauzasmriedem: that means that we will call the placement API with the allocations dict once we call it ?13:22
bauzasI mean, it means that the method will have to modify directly the allocations dict13:23
bauzas?13:23
kashyapjohnthetubaguy: gibi: As promised: http://lists.openstack.org/pipermail/openstack-operators/2018-September/015929.html13:23
bauzasmriedem: so we expect to have the allocations dict to be modified ?13:23
mriedembauzas: yes https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L94313:24
bauzasmriedem: cool13:24
openstackgerritMerged openstack/nova master: nova-status - don't count deleted compute_nodes  https://review.openstack.org/60449513:29
openstackgerritMerged openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/60457713:29
*** belmorei_ has joined #openstack-nova13:30
mriedemimacdonn: you want to backport https://review.openstack.org/#/c/604495/ as well?13:30
*** zul has joined #openstack-nova13:30
*** cfriesen has joined #openstack-nova13:31
*** belmoreira has quit IRC13:32
*** icey has quit IRC13:34
*** SteelyDan is now known as dansmith13:34
*** munimeha1 has joined #openstack-nova13:42
openstackgerritVlad Gusev proposed openstack/nova stable/rocky: nova-status - don't count deleted compute_nodes  https://review.openstack.org/60478513:48
openstackgerritVlad Gusev proposed openstack/nova stable/queens: nova-status - don't count deleted compute_nodes  https://review.openstack.org/60478613:48
*** alex_xu has joined #openstack-nova13:48
*** edmondsw has joined #openstack-nova13:48
mriedems10: thanks13:50
dansmithmriedem: no test on this? https://review.openstack.org/#/c/554380/13:53
openstackgerritVlad Gusev proposed openstack/nova stable/pike: nova-status - don't count deleted compute_nodes  https://review.openstack.org/60478813:54
bauzasmriedem: just another point, you reshape first and then you only update the child inventories after that13:55
mriedemi guess not? i wrote it in march.13:55
dansmith...and march is the month of no tests? :D13:55
*** jaosorior has quit IRC13:55
bauzasmriedem: is this because you don't want to have a child inventory in case the reshape provides an exception ?13:55
mriedemthat's what we agreed in dublin13:55
dansmithI didn't realize it was a backport so was about to -1 it out of existence13:55
efriedn-sch/placement meeting in 5 minutes in #openstack-meeting-alt13:55
openstackgerritMerged openstack/nova master: Transform libvirt.error notification  https://review.openstack.org/48485113:56
*** beekneemech is now known as bnemec13:57
mriedemdansmith: before you are gone for the rest of the week, we should probably figure out what we expect users to pass for the bdm volume_type value in the compute API,13:59
mriedembecause cinder's volume create API allows passing the volume type name or ID13:59
mriedemi was thinking the compute API would just take volume type name14:00
dansmithit would suck to not take either14:00
dansmithjust name?14:00
mriedemi didn't realize the volume create API took either14:00
mriedemuntil 30 seconds ago14:00
dansmithwhy is it hard for us to take either?14:00
mriedemit's not14:00
mriedemit came up while reviewing the db model changes for nova b/c he had originally restricted the volume_type column to 36 characters for volume type id14:01
mriedemi got him to change it to 255 to allow name14:01
dansmithah14:01
mriedemanyway, i asked the question on https://review.openstack.org/#/c/604687/14:01
dansmithand that's their name restriction?14:01
mriedemyes14:01
dansmiththat _is_ the downside of proxy apis I suppose, but .. :)14:01
dansmithokay14:01
dansmithsurely we're not merging that until the rest of the patches are stacked on top right?14:02
mriedemyes he split this out b/c i asked him to14:02
mriedemand i asked him to rebase the rest back on top14:02
dansmithokay cool14:02
*** Luzi has quit IRC14:03
mriedemthe other thing is if nova-api is going to validate that the requested volume type exists, we'll need to know if it's an id or a name, which kind of sucks14:07
mriedemwe can do is_uuid_like for that, but ...14:07
s10mriedem: can I ask to add volume_name in https://review.openstack.org/#/c/604687/ or it would be too much?14:09
*** icey has joined #openstack-nova14:09
mriedems10: and eventually description and az and hints and metadata...14:10
*** ondrejme has quit IRC14:14
mriedems10: if people are going to want to also pass volume name for the next several years, i'd rather us just add that now in the same microversion,14:15
mriedemdansmith: ^ what do you think?14:15
mriedemthis is the definition of the slippery slope with these proxy apis14:15
dansmithI think I said name+volume already right?14:16
dansmithdid I miss other discussion?14:16
dansmithoh14:16
dansmithvolume name?14:16
mriedemname + volume_type?14:16
mriedemyes, he's asking that we also proxy a volume name,14:16
dansmithffs14:17
mriedemtoday nova-compute doesn't give name/description to any volumes it creates14:17
mriedemftersin had a patch to at least name the volumes that nova created14:17
s10mriedem: that's what we are doing :( we have our patch for volume name since 2014 and volume type since 2015. I will be happy to drop it and make our OpenStack more close to the upstream...14:17
openstackgerritStephen Finucane proposed openstack/python-novaclient master: docs: Add redirects  https://review.openstack.org/60479614:18
dansmithand we have to handle the multi-create case where they can't be the same name yeah?14:18
mriedemdepends on what cinder allows, checking the cinder db model14:18
dansmithpresumably that means we have to have all the handling for races even against volumes we didn't reate14:18
dansmithI guess duplicate names may be allowed as long as we refer to them by uuid14:19
*** belmorei_ has quit IRC14:19
dansmithbut still...14:19
mriedemyeah i don't see any unique constraint on volume names in the cinder db14:19
dansmithwe're five minutes into this and already inches are being given14:19
mriedemnova has that weird config to restrict server names by project or global14:19
mriedemi suppose that's more for fqdns14:19
*** mrjk_ has joined #openstack-nova14:20
*** mrjk has quit IRC14:20
*** ratailor has joined #openstack-nova14:22
dansmithwell, I dunno14:23
dansmithtbh, taking name or setting it is not something I've heard asked before14:23
dansmithI would tend to think that if we have no real restrictions we could name it after the instance without another param14:24
dansmithbut14:24
openstackgerritSylvain Bauza proposed openstack/nova master: WIP: libvirt: implement reshaper for vgpu  https://review.openstack.org/59920814:25
mriedemhttps://review.openstack.org/#/c/213433/14:26
mriedem^ ftersin's old patch to name the volumes that nova creates14:26
dansmithyeah, you said that, but... what about the volume/14:26
dansmithmeaning, lots of people ask for volume_type, but was that the only one ask for name14:26
dansmith?14:26
mriedemidk14:27
mriedemi wouldn't be surprised if others would come out of the woodwork asking for proxying the name later14:27
dansmithwhere does it end?14:28
mriedemthat's what i said above14:29
dansmithI know14:29
*** belmoreira has joined #openstack-nova14:30
*** mlavalle has joined #openstack-nova14:34
*** dpawlik has quit IRC14:37
*** dulek has quit IRC14:38
*** dulek has joined #openstack-nova14:39
*** dpawlik has joined #openstack-nova14:40
*** mchlumsky has joined #openstack-nova14:40
*** dpawlik has quit IRC14:40
*** mchlumsky has quit IRC14:45
*** mchlumsky has joined #openstack-nova14:47
*** dave-mccowan has quit IRC14:50
efriedjaypipes: "efried: I specifically left out the "identification of the provider before you need it" because the clients of such a descriptor file would undoubtedly have different ideas of how to map local identifiers to RP identifiers."15:02
efriedjaypipes: If we're talking about RPs representing devices, yeah, which is what those last two specs are trying to define.15:02
efriedjaypipes: And those specs are attempting to account for the differences in hypervisors etc.15:03
efriedjaypipes: But what about e.g. NUMA node RPs?15:03
jaypipesefried: yes. that is why I didn't put multiple providers in a single provider descriptor file and left it up to the caller to determine whether they use something like a directory with descriptor files named for the provider UUID or the provider's "local name" (NUMA0, compute_node, some PCI address, whatever...)15:03
jaypipesefried: each hypervisor (or thing like Cyborg) is going to have its own way of identifying local devices.15:04
efriedI guess the same thing applies: as long as we've specified/documented how those RPs are going to be named, presumably the consumer can figure out what the names are going to be beforehand.15:04
jaypipesefried: and therefore each hypervisor needs to "own" the mapping of its local device name to the resource provider UUID15:04
jaypipesefried: yes, exactly my point.15:05
efriedwell, yeah, but not everything is a device.15:05
bauzasmmmm15:05
jaypipesefried: if libvirt wants to call its root compute node provider "compute_node_{hostname}" cool. but Xen might call it, e.g. "dom0_{hostname}"15:05
jaypipesefried: my point being we don't want to hard-code the names of things.15:06
bauzasso the problem is to know which is which, right?15:06
efriedcdent's concern was that we don't want to require the consumer to go get a report from placement in order to figure out what's named what and then populate the file. His point was that that would be a PITA for deployment tools like ansible.15:06
efriedjaypipes: Oh, certainly don't want to hardcode the name of anything - couldn't if we wanted to.15:06
*** _hemna has quit IRC15:07
efriedbut I guess we *do* need to make sure that the names are generated in a deterministic fashion that an operator can reproduce.15:07
jaypipesefried: well, that's essentially what cdent's gripe involves: hard-coding the name of the compute node resource provider so tools like ansible can have a stable way of calling things like `openstack provider-inventory $HOSTNAME`15:07
*** Bhujay has quit IRC15:07
efriedWe've got to have a starting point.15:08
efriedand we've already established that part, I thought.15:08
jaypipesefried: what part?15:08
efriedThe root compute RP's UUID (the host UUID) and name (the node UUID) - right?15:08
efriedin non-ironic those are the same15:09
jaypipesefried: yes, that ship is sailed.15:09
efriedokay, and I don't think that's a bad thing.15:09
jaypipesefried: even for ironic.15:09
jaypipesit's just the compute_nodes.uuid value that is used.15:09
efriedum, I thought for ironic the node UUID was different because multiple nodes managed by one host.15:09
jaypipesefried: hold up, that's not true.15:09
efriedyeah15:10
efriedanyway, beside the point15:10
jaypipesefried: we use compute_nodes.hypervisor_hostname15:10
efriedpoint is that we've already established a rule15:10
jaypipesas the RP name.15:10
jaypipeshttps://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L141715:10
jaypipesefried: ^15:11
*** ratailor has quit IRC15:12
efriedyeah, but didn't we decide hypervisor_hostname was actually the node UUID in the ironic case?15:12
jaypipesefried: so we already use hypervisor_hostname as RP name.15:12
mriedemefried: yes it is15:12
jaypipesefried: oh, I see what you mean.15:12
jaypipesefried: yes, that is true.15:12
*** dave-mccowan has joined #openstack-nova15:12
jaypipesit's the Ironic node UUID.15:12
efriedright, okay, so I was wrong before that the RP UUID and name were the same for non-ironic; the name is actually the hypervisor hostname which is like text.15:13
efriedanyway, point is, we've got an established rule for both the name and the UUID of the root RP.15:13
efriedAnd in Denver we talked about using the parent RP's UUID as part of the child RP's name, to ensure name uniqueness15:13
efriedSo that's one part of the naming rules15:14
efriedFor each type of child RP as long as we make the remainder of the naming convention deterministic *and document it*, that should allow consumers to figure out how to identify them for purposes of their inventory file.15:14
efriedIt may be kind of brittle in practice, but I can't think of a better solution.15:15
jaypipesefried: I guess I'd prefer to use the root provider's *name*, not UUID, in the child provider's name.15:16
jaypipesefried: and yes, I realize for Ironic, any child providers would have a UUID-based name since the root provider name is a UUID.15:16
efriedif we want the convention to be extensible, we should use something about the parent provider, not the root provider15:17
*** dave-mccowan has quit IRC15:17
efriedwhich only gets different when we have >2 levels of tree15:17
jaypipesefried: yes, the parent.15:17
efriedbut if we use the name, then we'll have N-1 UUIDs in the name for a provider at the Nth level down, which is :(15:17
jaypipesefried: so for a SRIOV NIC under the first NUMA node on a compute node might be cn1_numa0_sriovpf0 or something like that?15:18
jaypipesefried: I don't understand your last comment. could you elaborate?15:18
efriedSorry, I wasn't being as clever as you.15:19
efriedI was thinking dumbly $PARENT_NAME - $MY_NAME15:19
efriedWhich means your example would have ended up being cn1_cn1_numa0_sriovpf015:19
efriedum15:20
jaypipesah. no, just use the parent name, not the concat of the ancestry tree15:20
efriedthat's not even right.15:20
efriedyeah15:20
jaypipesso, the "formula" would be just: {$PARENT_NAME}_{$CHILD_NAME}15:20
efriedwell, since names have to be unique, that should work just fine.15:21
jaypipesor whatever separator you wanted to use instead of _15:21
efriedSo we have to establish the naming convention for $CHILD_NAME, which will be different for any given type of provider x hypervisor/virt15:21
efriedand document it15:21
efriedand then operators ought to be able to figure it out from there15:21
efriedif they need to15:21
jaypipesefried: do we really though?15:21
efriedwell, if we don't, then they have to do the two-step15:22
efriedask placement, figure it out, use that to populate the file, which then gets used to update placement.15:22
openstackgerritAditya Vaja proposed openstack/nova stable/queens: fix typo in IVS related privsep method  https://review.openstack.org/60481715:22
jaypipesefried: I mean if the "use case" is just for deployment tooling to be able to list the inventory for a compute node and its children, we already have the one heuristic that would be needed.15:22
jaypipesefried: i.e. ansbile would always call `openstack provider inventory list $HYPERVISOR_HOSTNAME`15:22
efriedisn't there a chicken/egg though?15:23
jaypipesefried: and to find the child providers it would be:15:23
*** dave-mccowan has joined #openstack-nova15:23
jaypipes`openstack provider list --in-tree $HYPERVISOR_HOSTNAME`15:23
jaypipesefried: well, of course, there's not going to be any inventory or provider records until the nova-compute runs, but I don't think that's any different from today's landscape for ansible/deploy tools15:24
efriedit is15:24
efriedbecause in today's tooling, you can set cpu_allocation_ratio beforehand15:24
jaypipesand?15:25
efriedWell, I don't know if we really care enough to feel it's worth the hoops of fire it would take to make this new world similarly configurable-before-deployment.15:25
efriedBut if I'm understanding cdent's concern correctly, that was it.15:25
jaypipeswhat regarding the provider descriptor file format would prevent ansible from writing out an allocation ratio override for the compute node?15:25
efriedoh, that's exactly the point. The allocation ratio for CPU may not *live* in the compute node provider.15:26
efriedIt may live in the (multiple) NUMA node providers15:26
efriedwhich ansible would need a way to figure out how to identify before deployment, if we're wanting to keep this paradigm of pre-deployment configurability.15:26
jaypipesefried: right, but we don't currently set any allocation ratio for NUMA node providers anywhere (certainly not in any config file)15:26
efriedNUMA is just an example.15:27
efriedand15:27
efriedwe don't today, but might tomorrow15:27
jaypipesefried: this is why I think setting data for inventory records using configuration files is silly.15:27
efriedyou think it should be done by invoking placement after all the auto setup is done?15:27
jaypipesas opposed to setting them en-masse after the records have been created.15:28
jaypipesyes.15:28
jaypipesbut we have deployers who are insisting on the configuration files... soo....15:28
efriedI'd be cool with that. Requires a fundamental shift in the philosophy15:28
efriedbasically each virt's update_provider_tree would have to agree to only muck with total and reserved.15:34
efriedwhich is not what we're doing today - today we overwrite everything.15:34
efriedbut there's still the concern about how to set initial values.15:34
efriedThe difficult part of that being how to tell that it's initial.15:34
efriedcdent suggested something about making use of the updated_at field.15:35
efriedbbar (that's "be back after reboot" - something's slowly eating up all my swap space)15:36
*** efried has quit IRC15:37
*** dpawlik has joined #openstack-nova15:38
*** efried has joined #openstack-nova15:39
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222615:40
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222615:42
*** dpawlik has quit IRC15:42
efriedbelmoreira: did you get past your max_unit snafu from last week?15:43
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222615:44
belmoreiraefried: we decided to not change it for now15:46
efriedbelmoreira: Meaning you still can't deploy those flavors to those nodes?15:47
*** alexchadin has quit IRC15:47
belmoreiraefried: correct. People with these flavors can't use them. We're informing the users for now and suggesting smaller flavors15:48
efriedokey15:48
efriedbelmoreira: Have you crystallized any sense of how you'd ideally like to see this handled big-picture/long-term?15:49
belmoreiraefried: our main issue is that our compute nodes may be very overcommited (CPU) and for now is saffer to stop scheduling these large flavors15:49
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222615:50
belmoreiraefried: last week I was debugging and we just realised the issue in the channel... I believe that letting the operator decide is a good practice. In my specific use case this is not a priority. If we allow these flavors again this is small downstream patch15:52
*** sapd1 has joined #openstack-nova15:53
efriedroger that. Thanks for the update.15:53
mriedemdansmith: so circling back on https://review.openstack.org/#/c/604687/3/nova/db/sqlalchemy/migrate_repo/versions/391_add_volume_type_to_bdm.py - you're cool with the compute API taking volume type name or ID yes?15:53
dansmithmriedem: yes,  but I'm not sure what that has to do with that migration.. it already has char(255) right?15:54
mriedemyes15:54
mriedemthat's just what initiated the question15:54
belmoreiraefried cdent also was testing if there's any limitation creating VMs with more vcpus than cpus available in the node and can't find any issue15:54
efriedgood to know.15:55
openstackgerritBalazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations  https://review.openstack.org/59159716:02
*** helenafm has quit IRC16:03
*** lbragstad has quit IRC16:10
bauzasgibi: I'll start review your series tomorrow morning, can I ?16:13
gibibauzas: sure. There are comment already that I need to fix through the series but the content of the patches are ready for review16:13
bauzasall cool then ++16:14
bauzasaaaand then, calling it a day !16:14
gibibauzas: have a nice evening16:16
*** lbragstad has joined #openstack-nova16:18
openstackgerritBalazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations  https://review.openstack.org/59159716:18
*** janki has quit IRC16:20
*** spotz is now known as spotz_16:25
*** spotz_ is now known as spotz16:25
*** icey has quit IRC16:29
*** adrianc has joined #openstack-nova16:30
*** icey has joined #openstack-nova16:33
*** dave-mccowan has quit IRC16:38
*** ttsiouts has joined #openstack-nova16:38
*** s10 has quit IRC16:40
*** sahid has quit IRC16:41
*** jiapei has quit IRC16:43
melwitto/16:45
*** ttsiouts has quit IRC16:45
sean-k-mooneyo/16:45
*** s10 has joined #openstack-nova16:47
s10https://bugs.launchpad.net/nova/+bug/1209101 - please, reopen this bug16:48
openstackLaunchpad bug 1209101 in OpenStack Compute (nova) "Non-public flavor cannot be used in created tenant" [High,Fix released] - Assigned to Sumanth Nagadavalli (sumanth-nagadavalli)16:48
*** s10 has quit IRC16:53
*** hamzy_ has joined #openstack-nova16:58
*** adrianc has quit IRC16:59
*** derekh has quit IRC16:59
*** hamzy has quit IRC16:59
*** adrianc has joined #openstack-nova16:59
*** dpawlik has joined #openstack-nova17:00
cfriesenmriedem: stephenfin: any chance you could take a look at a robustness fix around port binding in rebuild/reboot?  https://review.openstack.org/60384417:02
*** belmoreira has quit IRC17:04
*** alex_xu has quit IRC17:05
openstackgerritMerged openstack/nova stable/pike: Fix message for unexpected external event  https://review.openstack.org/58950317:06
openstackgerritMerged openstack/nova master: Rename "polling_changes-since_parameter.rst"  https://review.openstack.org/60460617:06
*** adrianc has quit IRC17:06
*** udesale has quit IRC17:10
*** jpena is now known as jpena|off17:21
*** mvkr has quit IRC17:25
*** ralonsoh has quit IRC17:34
*** dave-mccowan has joined #openstack-nova17:35
*** sambetts is now known as sambetts|afk17:39
openstackgerritMatthew Booth proposed openstack/nova master: Always check return of wait_for_versioned_notifications  https://review.openstack.org/60485917:42
mdbooth^^^ took me all day :/17:43
mdboothThe failure in my test, that is. I haven't actually checked locally if the above patch works.17:43
mdboothI wonder if it should just raise an exception instead, tbh. Would make it harder to misuse.17:45
*** munimeha1 has quit IRC17:47
*** dpawlik has quit IRC17:51
*** dtantsur is now known as dtantsur|afk17:56
efriedmdbooth: "it" the fixture or "it" the original method?18:10
efriedoh. it's only in the fixture18:12
*** coreycb has joined #openstack-nova18:13
*** mvkr has joined #openstack-nova18:15
*** dpawlik has joined #openstack-nova18:17
*** dpawlik_ has joined #openstack-nova18:17
efriedmakes sense for it to raise on None, I reckon. But if you're going that far, you may as well make _Sub.wait_n raise on timeout too.18:18
*** dpawlik has quit IRC18:18
*** AJaeger has joined #openstack-nova18:23
AJaegermriedem, bauzas, melwitt , lyarwood, could you help reviewing the stable python3-first changes, please? https://review.openstack.org/#/q/topic:python3-first+status:open+(openstack/nova+OR+project:openstack/nova-specs+OR+openstack/os-traits+OR+openstack/os-vif+OR+openstack/osc-placement+OR+openstack/python-novaclient) gives list of open changes18:25
sean-k-mooneyAJaeger: looking at the list everything that is left is for stable branches18:27
sean-k-mooneyAJaeger: the trove change is likely the wrong channel18:27
AJaegersean-k-mooney: yeah, don't know why the query includes that one ;( Adn yes, it's all stable changes...18:27
lyarwoodAJaeger: ack will do18:27
AJaegerthanks, lyarwood. If you have questions, feel free to ask ...18:28
AJaegerlyarwood: and ignore the trove one, please18:28
lyarwoodAJaeger: ack, I can't +2 that anyway :)18:28
openstackgerritAlessandro Pilotti proposed openstack/python-novaclient master: Fixes Python3 issue in decoding password  https://review.openstack.org/60487018:29
melwittAJaeger: thanks for the heads up18:31
AJaegermelwitt: once those 15 changes are in, the python3-first goal is done for nova ;)18:32
AJaegerOnly 13, I miscounted18:33
melwittcoolness, I'll make sure we get those in18:33
AJaegergreat18:33
AJaegeryou have at least changes that pass everywhere - compared to other projects ;/18:33
melwittthat's fortunate :)18:34
AJaegerindeed18:35
openstackgerritLee Yarwood proposed openstack/nova master: Add regression for bug 1787606  https://review.openstack.org/59307318:38
openstackbug 1787606 in OpenStack Compute (nova) "Multi instance creation rescheduling fails due to a lack of alternates" [Medium,In progress] https://launchpad.net/bugs/1787606 - Assigned to Lee Yarwood (lyarwood)18:38
openstackgerritLee Yarwood proposed openstack/nova master: scheduler: Increase alternate count in smaller environments  https://review.openstack.org/59307418:38
openstackgerritLee Yarwood proposed openstack/nova master: fixtures: Track volume attachments within CinderFixtureNewAttachFlow  https://review.openstack.org/58701318:45
openstackgerritLee Yarwood proposed openstack/nova master: Add regression test for bug#1784353  https://review.openstack.org/58701418:45
openstackgerritLee Yarwood proposed openstack/nova master: conductor: Recreate volume attachments during a reschedule  https://review.openstack.org/58707118:45
AJaegerall approved - thanks, mriedem and lyarwood !18:54
*** panda has quit IRC18:56
openstackgerritMerged openstack/os-traits stable/rocky: import zuul job settings from project-config  https://review.openstack.org/60140319:11
openstackgerritMerged openstack/os-traits stable/queens: import zuul job settings from project-config  https://review.openstack.org/60139819:11
openstackgerritMerged openstack/os-traits stable/pike: import zuul job settings from project-config  https://review.openstack.org/60139319:11
karimullmreidem : thanks for the info..will look into hooks.19:13
openstackgerritMatt Riedemann proposed openstack/python-novaclient master: Add support changes-before for microversion 2.66  https://review.openstack.org/60354919:14
*** sapd1 has quit IRC19:15
*** pcaruana has quit IRC19:17
*** s10 has joined #openstack-nova19:17
karimullmreidem : efried: is there a way in nova I can branch out of normal processing of instance launch and try to work on the image before libvirt is called or with in libvirt  is also fine19:19
karimullmreidem:efried : basically I'm looking to decrypt an image before it is launched...19:20
efriedkarimull: I have way more questions than answers.19:22
efriedAre you the only one who has ever wanted to work with encrypted images?19:22
efriedIs the image encrypted in glance, and then you want to decrypt it while/after you copy it to the instance's boot disk?19:22
karimullmay be :)19:23
karimullefried : exactly19:23
efriedI guess what I'm getting at is, either what you're doing is wild and crazy and you shouldn't be doing it - upstream or down - or it's something that more people want to do and is either already supported or should be proposed formally upstream.19:23
efriedMe, I don't know anything about it, I'm afraid.19:24
efriedseems weird that you're maintaining the image encrypted in glance, but want it decrypted *before* you boot the instance.19:25
efriedIt's as if you trust glance less than you trust instances19:25
karimullefried :I could see volume encryption blue but nothing on image19:25
karimullefried : I'm making sure if this is feasible before proposing a formal blue print19:28
efriedkarimull: Okay, so you do intend to propose it upstream?19:29
karimullefried : yes19:29
efriedI see. Have you talked to the glance folks about it?19:29
karimullefried : not yet19:30
melwittwe added support for trusted image certificate validation in rocky https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/nova-validate-certificates.html19:31
dansmithpresumably they want encryption19:31
dansmithbut that came before, AFAIK19:31
melwittbut I don't know of any support for encrypted images in glance19:32
melwittyeah, was just mentioning it in case it might be useful19:32
melwittthat's the extent of the handling of "untrusted glance" that I know about19:33
dansmithoh I thought the encryption support was already there19:33
dansmithmaybe I'm thinking of encrypted block19:33
melwittI'm not sure, it might be there. trying to find out. an earlier iteration of the trusted certs stuff mentioned image encryption19:34
dansmithyeah19:35
dansmithlooks like just signatures though in the tree19:35
karimullI have not seen any support for encrypted image in glance..19:35
efriedassuming the decrypt would happen chunk-wise, it's not in the nova glance code.19:35
karimullwanted to support user defined encryption of image at nova compute for more flexibility19:36
efriedkarimull: Point is, assuming it's not already there, you would likely be looking to make your changes in a lot of the same places as the bp melwitt mentioned ( https://review.openstack.org/#/q/topic:bp/nova-validate-certificates+(status:open+OR+status:merged) )19:36
*** panda has joined #openstack-nova19:37
karimullby using Castellan which support key manager interface and by having a plugin in nova to perform user defined decryption process it will be  more transparent..just a thought still framing on all possibilities19:39
karimullefried: will look into that blueprint..19:39
melwittkarimull: are you thinking this would be transparent to glance? like you would encrypt the image before uploading to glance using your nova keypair, for example, and then you'd like nova to decrypt it? we would need the private key for that though and we don't store them19:39
karimullyes19:40
dansmiththat's where castellan or barbican comes in19:40
dansmithnova gets a key the user provides there to decrypt19:41
melwittright.. ok19:41
dansmithAFAIK, glance needs to look at the image when you upload it so it's not like you can do this without glance at all I think19:41
dansmithunless there is some way to tell glance not to look at the image, but I'm not sure19:41
karimulluser will get the key from either barbican or from their own KMS and encrypt and upload the image with information in meta data , using that information and castellan libraries key will be retrieved for decryption of image19:42
dansmithunless you care about hiding the boot content from everything other than nova, this is pretty easy to do internal to the image without a lot of fanfare19:42
dansmithalso, you'd probably want to make sure we don't cache the decrypted image, especially if the cache is on shared storage19:43
dansmithgets out of hand pretty quick :)19:43
karimullok19:43
karimulldansmith: wanted to decrypt the image at compute host before it is launched..is this possible?..if we can have hooks at libvirt or nova-compute level wanted to make it a plugin19:46
dansmithkarimull: we don't have plugins19:46
dansmithwe have some aging hooks that are slowly being removed from the code19:47
dansmithbut obviously doing the decryption on the compute host is where it would need to happen19:47
karimull having a plugin kind of functionality will give user flexibility to use their own decryption process..hence look in that way..do we have any similar way to do it in Nova19:49
karimulldansmith : looking*19:50
dansmithwe don't have plugins19:50
*** dpawlik_ has quit IRC19:51
*** dpawlik has joined #openstack-nova19:55
dansmithmriedem: jaypipes: what's the fix for this? https://bugs.launchpad.net/nova/+bug/179374719:55
openstackLaunchpad bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] - Assigned to Neha Alhat (nehaalhat)19:55
*** mlavalle has quit IRC19:56
*** dpawlik has quit IRC19:56
dansmithI don't even think I get what the problem is19:58
*** mlavalle has joined #openstack-nova19:58
openstackgerritMerged openstack/nova stable/ocata: Cleanup RP and HM records while deleting a compute service.  https://review.openstack.org/60374919:59
dansmithoh, I see, I was looking at the wrong thing.. we're lower()ing all the hostnames19:59
dansmiths10: okay I got all those backports you tagged me on20:02
s10dansmith: thank you, finally we will get this fixes in queens after two month of waiting :)20:04
dansmiths10: we just got a queens release this morning though right?20:04
dansmithmight already be time to queue up another one :)20:04
*** erlon has quit IRC20:05
mriedemand we just released that blazar regression https://review.openstack.org/#/c/585334/20:06
mriedemdansmith: i don't know what the fix is for that bug20:07
jaypipesdansmith: the fix for this is not having such fragile friggin code? :(20:07
jaypipesfix one thing, breaks another. :(20:07
dansmithjaypipes: yeah we should totes just depend on our backend database ignoring case for us :)20:07
dansmithmriedem: we could try to lower() the hostname everywhere else, but I kinda think the original "fix" was broken20:07
jaypipesdansmith: the user expects a case-insensitive search.20:08
dansmithif they pass a hostname that is different from what the machine reports, they should expect it to not work20:08
dansmithjaypipes: I don't20:08
dansmiththe aggregate code must not be validating hostnames when you go to add one right?20:08
dansmithin which case maybe the fix is just to make host-add fail if you specify something wrong?20:09
jaypipesdansmith: this isn't about that. this is about the collection of host aggregate states in the scheduler (in Python, not in the DB)20:09
dansmithjaypipes: the original20:09
jaypipesand Python is case-sensitive, as we know.20:09
dansmithfix and the new regression are all about us allowing you to add a host with a non-matching case,20:09
dansmithand then us not also ignoring case when we go to join it up right?20:09
dansmithif we just refuse to let them add non-matching hostnames in the first place, everything else can be consistent right?20:10
jaypipesI need to look (again) at the code. it's a giant ball of turds.20:10
jaypipesdansmith: I don't think this is about them adding non-case-matching hostnames.20:11
dansmithI don't expect to have case ignored. what I do expect is for nova to tell me "that's, like, not a host maan" when I go to add one to an aggregate20:11
mriedemnon-matching by looking up the host from the compute_nodes table?20:11
dansmithjaypipes: it is.. the original fix says "accidentally typed COMPUTE0 instead of compute0"20:11
jaypipesdansmith: no, I'm talking about the bug 179374720:11
openstackbug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] https://launchpad.net/bugs/1793747 - Assigned to Neha Alhat (nehaalhat)20:11
dansmithjaypipes: and the regression is that blazar is taking the mixed-case hostname from the hypervisors api, and using that to add the host to an aggregate20:11
jaypipesdansmith: there's no indication that that bug reporter has used non-matching hostname...20:12
dansmithjaypipes: they're the same thing20:12
dansmithjaypipes: blazar is looking at hypervisors and using that value..20:12
mriedemfwiw, bug 1709260 wouldn't be possible by default if they were using postgresql :P20:12
dansmithblazar host-create Openstack-VirtualBox20:12
openstackbug 1709260 in OpenStack Compute (nova) queens "Addition of host to host-aggregate should be case -sensitive" [Low,Fix committed] https://launchpad.net/bugs/1709260 - Assigned to Rajesh Tailor (ratailor)20:12
jaypipesdansmith: that's the correct hostname.20:12
dansmithjaypipes: right exactrly20:13
dansmithjaypipes: but we're mangling it internally by lower()ing it20:13
dansmithand they can't see that20:13
*** dpawlik has joined #openstack-nova20:13
jaypipesdansmith: where are we mangling it internally other than the host manager's host aggregate state internal map?20:13
dansmithexactly there20:13
dansmiththat's the problem right?20:14
jaypipesdansmith: and how exactly would PG vs. MySQL "solve" this problem?20:14
dansmithjaypipes: mriedem said that not me20:14
dansmithI don't think it would20:14
dansmithunless PG honors case, but rejects duplicates that differ only by case20:14
jaypipes"<dansmith> jaypipes: yeah we should totes just depend on our backend database ignoring case for us :)"20:14
mriedemPG is case sensitive by default20:14
openstackgerritMerged openstack/python-novaclient stable/queens: Switch to stestr  https://review.openstack.org/60193320:15
openstackgerritMerged openstack/python-novaclient stable/queens: import zuul job settings from project-config  https://review.openstack.org/60140020:15
mriedemso fat fingering COMPUTE0 should result in HostNotFound20:15
dansmithmriedem: I don't think it would if we're not checking20:15
mriedem170926020:15
mriedemoops20:15
dansmithor maybe you mean we're "checking" by just looking it up?20:15
mriedemmapping = objects.HostMapping.get_by_host(context, host_name)20:15
mriedemyes20:15
dansmithgotcha20:15
dansmiththen yeah, mysql _is_ hurting us here20:15
dansmith(IMHO)20:15
mriedemthere are lots of things like this in the api20:16
dansmithyup20:16
jaypipesI still don't see how MySQL is hurting us20:16
mriedembecause adding the host to the aggregate with the wrong name doesn't puke in the api20:16
jaypipesthe user expects a case-insenstive API.20:17
dansmithI don't and I'm a user20:17
mriedemyou keep saying that but i'm not sure why20:17
dansmithyeah20:17
jaypipesthe user that reported all these bugs.20:17
mriedemheh20:17
dansmiththat user would be fine if nova told it it was wrong20:17
mriedemif i create a server with name Foo i don't expect to find it using FOO20:17
openstackgerritMerged openstack/os-vif stable/queens: import zuul job settings from project-config  https://review.openstack.org/60139920:17
openstackgerritMerged openstack/os-vif stable/pike: import zuul job settings from project-config  https://review.openstack.org/60139420:17
openstackgerritMerged openstack/os-vif stable/ocata: import zuul job settings from project-config  https://review.openstack.org/60138820:17
dansmiththe original bug even said "accidentally typed"20:17
mriedemyeah i think rajesh's patch / bug report was saying he expected HostNotFound20:18
*** dpawlik has quit IRC20:18
dansmithlike because they haven't properly mapped caps lock to control like everyone should20:18
mriedem"While adding compute0 to host-aggregate, if I provide hostname as "COMPUTE0.example.com", instead of20:18
mriedemthrowing HostNotFound error, it is added to host-aggregate."20:18
dansmithface it jaypipes, PG rules and mysql drools20:18
jaypipesperhaps that is because URIs and hostnames are case-insensitive and always have been? ...20:19
* dansmith is TOTALLY joking20:19
jaypipesGOOGLE.com == goOGle.com20:19
dansmithDNS is case insensitive20:19
mriedemso one fix for https://bugs.launchpad.net/nova/+bug/1793747 is to revert https://review.openstack.org/#/q/Iee4b9bbf412adfdc6fdc62ea3429fb960d6ac2a2 right?20:19
openstackLaunchpad bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] - Assigned to Neha Alhat (nehaalhat)20:19
dansmithURIs are not, AFAIK, in apache20:19
jaypipesbut whatevers, I need to go puke on chef again.20:19
dansmithmriedem: yes I think we should revert rajesh's patch and fix the NotFound on original add20:20
mriedemor, we need to lowercase aggregate members everywhere...?20:20
mriedemhow do we fix the not found on original add if the db is case insensitive?20:20
dansmithwe just check the result20:21
dansmithif host_name == compute.host20:21
dansmithor whatever20:21
jaypipesdansmith: and you'd need to fix PG manually since it will undoubtedly have allowed 2 records, one for compute0 and one for COMPUTE020:21
mriedemjaypipes: mysql manually20:21
mriedemPG won't allow this by default20:21
jaypipesin the host_aggregate_hosts table (or whatever the heck it's named)20:21
dansmithyeah PG is already fine20:21
dansmithno20:21
dansmithyou won't have ever found COMPUTE020:21
jaypipeswhat are you guys talking about?20:21
dansmithso we would fail20:21
dansmithjaypipes: we look up the host before we add the aggegate_host20:22
jaypipesPG will allow multiple records to be created, one for agg -> COMPUTE0 and one for agg -> compute020:22
dansmithin mysql we find it wrongly, case insensitive20:22
dansmithin PG, we never find it,20:22
jaypipesah. if that fetch is done in the API layer...20:22
jaypipesis it?20:22
dansmithso we won't add the aggregate_host20:22
dansmithwe don't need the constraint to help us in PG,20:22
dansmithbecause we never get that far20:22
dansmithright20:22
dansmithmriedem says it is20:22
dansmith[13:15:46]  <mriedem>mapping = objects.HostMapping.get_by_host(context, host_name)20:23
mriedemhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L528920:23
mriedemdansmith: so you want to add: if mapping.host == host_name? in the api?20:24
mriedemfor the case check?20:24
dansmithyeah20:24
mriedemyeah that seems easy enough20:24
dansmithwait, are you asking if I want to write that patch?20:24
dansmithor just if I like that approach?20:24
mriedemi was confirming that was your idea20:24
dansmithindeed20:24
mriedemi expect you're already half dressed for vacation20:24
dansmithindeed :)20:25
mriedem(un)dressed20:25
mriedemdansmith: are you going to propose the revert at least?20:25
melwittwill this change in anyway cause existing tooling to stop working? that is, do we need a microversion?20:25
dansmithI can if you want20:25
mriedemwe already regressed existing tooling20:25
mriedemhttps://bugs.launchpad.net/nova/+bug/179374720:25
openstackLaunchpad bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] - Assigned to Neha Alhat (nehaalhat)20:25
dansmithmelwitt: this is making the api consistent with the database, if your database is PG20:25
dansmithright20:26
openstackgerritMerged openstack/python-novaclient stable/pike: import zuul job settings from project-config  https://review.openstack.org/60139520:26
openstackgerritMerged openstack/python-novaclient stable/ocata: Use generic user for both zuul v2 and v3  https://review.openstack.org/60193220:26
openstackgerritMerged openstack/python-novaclient stable/ocata: import zuul job settings from project-config  https://review.openstack.org/60139120:26
melwittI mean the addition of the case sensitive check, not the revert20:26
dansmiththe check is ^20:26
mriedemshouldn't need to opt out of broken behavior20:26
mriedemso this isn't a microversion20:26
dansmithright20:26
melwittok, just wondering if this might somehow break anyone's existing automation20:26
dansmithwe already broke it20:27
dansmiththis makes it work again20:27
dansmithanyone's automation is going to be using the actual hostname,20:27
dansmitheither from the system or from our own API20:27
dansmiththose things would have broken silently just now20:27
dansmiththis will unbreak them20:27
jaypipesthis is partly why I hate even reviewing anything like that patch any more... always seems that they get reverted.20:27
dansmiththe combo20:28
mriedemi should have sniffed this out sooner on the backports given i knew about the earlier work from HPE to try and solve the case insensitivity issues in the api20:28
mriedemmdbooth was also working on something related to this recently20:29
mriedemhttp://lists.openstack.org/pipermail/openstack-dev/2018-August/thread.html#13320220:29
melwittyeah, that was the metadata keys case insensitive thing20:29
dansmithmriedem:20:29
mriedembeware then https://review.openstack.org/#/c/504885/20:30
openstackgerritDan Smith proposed openstack/nova master: Revert "Make host_aggregate_map dictionary case-insensitive"  https://review.openstack.org/60489820:30
melwittit was confusing thinking about it, but the proposal was to make the key column case sensitive by changing the collation, but that would break anyone who was relying on the case insensitive behavior. and then I got fatigued thinking about it20:30
dansmithyep,20:31
melwittso I was trying to determine whether there would be any similar thing here20:31
dansmiththe difference here is that a hostname with a different name is not legit20:31
dansmithin an aggregate mapping20:31
dansmithsince metadata is free-form, it is legit (although silly) to use two keys that differ only by case20:31
dansmither, "hostname with a different case"20:32
melwittok, I see20:32
dansmithmriedem: I can stack the check on top of this if you'll write the tests when I run out of time20:33
dansmithmriedem: we could also just use the name from the mapping instead of the one they asked for,20:35
dansmithwhich means they won't get a NotFound, and we'll add the mapping they intended20:35
dansmithbut they may fail similarly later if they keep using the wrong name20:35
dansmithso I tend to err on the side of fail fast,20:35
dansmithespecially since PG will already cause us to behave that way20:35
dansmiththoughts?20:35
mriedemagree on the api being explicitly20:35
mriedem*explicit20:35
melwittyeah it sounds like fail fast would be better20:38
*** dpawlik has joined #openstack-nova20:40
openstackgerritJack Ding proposed openstack/nova master: Correct instance port binding for rebuilds/reboots  https://review.openstack.org/60384420:40
jaypipesyeah, I definitely won't be reviewing 504885. Tired of approving these patches and then needing them to be reverted.20:47
jaypipesI'll just stick to reviewing anything that isn't in the API layer I guess.20:47
jaypipessince our API layer is so friggin eggshells.20:47
openstackgerritDan Smith proposed openstack/nova master: Enforce case-sensitive hostnames in aggregate host add  https://review.openstack.org/60490620:49
dansmithmriedem: all yours if that fails other tests20:49
openstackgerritDan Smith proposed openstack/nova master: Enforce case-sensitive hostnames in aggregate host add  https://review.openstack.org/60490620:50
mriedemack20:55
*** slaweq has quit IRC21:01
melwittreminder to everyone: forum topic submission deadline is Wed Sep 2621:05
melwitthttps://etherpad.openstack.org/p/nova-forum-stein21:06
*** dpawlik has quit IRC21:12
openstackgerritDan Smith proposed openstack/nova master: Enforce case-sensitive hostnames in aggregate host add  https://review.openstack.org/60490621:15
mriedemi don't know if we're going to do a placement extraction session at the forum21:15
mriedemkind of a big thing *not* to have a session about it for at least a status check and fyi21:16
mriedemfor people that weren't at the ptg21:16
melwittthat's fair enough21:18
*** awaugama has quit IRC21:18
melwitta status check would be good, at the least21:18
mriedemso i guess i'm submitting that one21:20
* dansmith readies his voting finger21:20
melwittif you could, that would be greeeeaaat21:21
melwitthonestly, it's kinda hard to be thinking about what we need to talk about at the forum when we literally were just at the ptg21:22
melwittother than picking out, which of these topics should be a repeat at summit time21:23
melwittor a generic "nova ops/users feedback session"21:23
mriedemhttps://www.openstack.org/summit/berlin-2018/vote-for-speakers#/2278021:31
melwittthanks21:33
openstackgerritMerged openstack/osc-placement stable/queens: import zuul job settings from project-config  https://review.openstack.org/60139721:44
*** takashin has joined #openstack-nova21:48
*** mriedem is now known as mriedem_away21:57
*** elod has quit IRC22:04
*** AJaeger_ has joined #openstack-nova22:10
*** elod has joined #openstack-nova22:11
*** AJaeger has quit IRC22:11
*** dpawlik has joined #openstack-nova22:16
*** dpawlik has quit IRC22:20
*** mgariepy has quit IRC22:20
*** mgariepy has joined #openstack-nova22:33
*** panda is now known as panda|off22:38
*** rcernin has joined #openstack-nova22:45
*** mgariepy has quit IRC22:49
*** pooja-jadhav has joined #openstack-nova22:51
*** owalsh_ has joined #openstack-nova22:53
*** kukacz_ has joined #openstack-nova22:55
*** dims_ has joined #openstack-nova22:59
*** jamiec_ has joined #openstack-nova22:59
*** mmedvede_ has joined #openstack-nova23:00
*** _d34dh0r53_ has joined #openstack-nova23:00
*** stephenfin_ has joined #openstack-nova23:00
*** kukacz has quit IRC23:00
*** pooja_jadhav has quit IRC23:00
*** mhen has quit IRC23:00
*** owalsh has quit IRC23:00
*** dims has quit IRC23:00
*** d34dh0r53 has quit IRC23:00
*** jlvillal has quit IRC23:00
*** jamiec has quit IRC23:00
*** sorrison has quit IRC23:00
*** cburgess has quit IRC23:00
*** naichuans_ has quit IRC23:00
*** fanzhang has quit IRC23:00
*** bandini has quit IRC23:00
*** wznoinsk has quit IRC23:00
*** mmedvede has quit IRC23:00
*** stephenfin has quit IRC23:00
*** ujjain has quit IRC23:00
*** mmedvede_ is now known as mmedvede23:00
*** andreykurilin has quit IRC23:03
*** purplerbot has quit IRC23:04
*** mgariepy has joined #openstack-nova23:04
*** andreykurilin has joined #openstack-nova23:05
*** tetsuro has joined #openstack-nova23:24
*** mgariepy has quit IRC23:26
*** hshiina has joined #openstack-nova23:37
*** s10 has quit IRC23:38
*** s10 has joined #openstack-nova23:39
*** mgariepy has joined #openstack-nova23:39
*** s10 has quit IRC23:39
*** s10 has joined #openstack-nova23:39
*** s10 has quit IRC23:40
*** s10 has joined #openstack-nova23:40
*** s10 has quit IRC23:41
*** s10 has joined #openstack-nova23:41
*** s10 has quit IRC23:41
*** s10 has joined #openstack-nova23:42
*** s10 has quit IRC23:42
*** erlon has joined #openstack-nova23:46
*** mgariepy has quit IRC23:47
*** mgariepy has joined #openstack-nova23:59

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