Friday, 2021-04-23

« Thursday, 2021-04-22 Index Saturday, 2021-04-24 »
*** gyee has quit IRC00:05
*** sapd1 has quit IRC00:05
*** hamalq has quit IRC00:13
*** k_mouza has joined #openstack-nova00:32
*** k_mouza has quit IRC00:32
*** k_mouza has joined #openstack-nova00:33
*** k_mouza has quit IRC00:41
*** xinranwang has joined #openstack-nova01:25
*** brinzhang0 has joined #openstack-nova01:28
*** brinzhang_ has quit IRC01:31
*** k_mouza has joined #openstack-nova01:39
*** k_mouza has quit IRC01:39
*** k_mouza has joined #openstack-nova01:40
*** k_mouza_ has joined #openstack-nova01:43
*** k_mouza has quit IRC01:47
*** k_mouza_ has quit IRC01:47
*** k_mouza has joined #openstack-nova01:57
*** k_mouza has quit IRC02:01
openstackgerritliuzhuangzhuang proposed openstack/nova master: Fix RBD timeout  https://review.opendev.org/c/openstack/nova/+/78658802:07
*** k_mouza has joined #openstack-nova02:15
*** sapd1 has joined #openstack-nova02:18
*** k_mouza has quit IRC02:19
*** sapd1 has quit IRC03:15
*** xinranwang has quit IRC03:33
*** mkrai has joined #openstack-nova03:36
*** zzzeek has quit IRC03:37
*** zzzeek has joined #openstack-nova03:38
*** k_mouza has joined #openstack-nova04:16
*** ratailor has joined #openstack-nova04:18
*** k_mouza has quit IRC04:21
*** vishalmanchanda has joined #openstack-nova04:36
*** priteau has joined #openstack-nova05:29
*** belmoreira has joined #openstack-nova06:02
*** brinzhang_ has joined #openstack-nova06:12
*** brinzhang0 has quit IRC06:15
*** k_mouza has joined #openstack-nova06:17
*** slaweq has joined #openstack-nova06:20
*** k_mouza has quit IRC06:21
*** ralonsoh has joined #openstack-nova06:26
*** luksky has joined #openstack-nova06:32
openstackgerritBalazs Gibizer proposed openstack/placement stable/wallaby: Add a reproduction test for bug story/2008831  https://review.opendev.org/c/openstack/placement/+/78752506:37
openstackgerritBalazs Gibizer proposed openstack/placement stable/wallaby: Make sure the policy upgrade check get a valid config  https://review.opendev.org/c/openstack/placement/+/78752606:37
*** ratailor_ has joined #openstack-nova06:47
*** ratailor has quit IRC06:50
*** mkrai has quit IRC07:10
*** rpittau|afk is now known as rpittau07:12
*** whoami-rajat_ has joined #openstack-nova07:17
*** rcernin has quit IRC07:25
*** whoami-rajat_ is now known as whoami-rajat07:25
*** andrewbonney has joined #openstack-nova07:49
*** rcernin has joined #openstack-nova07:52
*** tosky has joined #openstack-nova07:53
*** rcernin has quit IRC07:57
*** derekh has joined #openstack-nova08:07
*** rcernin has joined #openstack-nova08:09
*** mgoddard has joined #openstack-nova08:12
*** rcernin has quit IRC08:14
*** hemanth_n has joined #openstack-nova08:16
*** dtantsur|afk is now known as dtantsur08:17
*** k_mouza has joined #openstack-nova08:19
*** k_mouza has quit IRC08:23
*** mkrai has joined #openstack-nova08:27
*** rcernin has joined #openstack-nova09:00
*** k_mouza has joined #openstack-nova09:02
*** macz_ has joined #openstack-nova09:10
*** macz_ has quit IRC09:15
*** rcernin has quit IRC09:18
*** rcernin has joined #openstack-nova09:21
*** dtantsur is now known as dtantsur|bbl09:30
*** tesseract has joined #openstack-nova09:36
*** k_mouza has quit IRC09:40
*** k_mouza has joined #openstack-nova09:42
*** k_mouza has quit IRC09:43
*** k_mouza has joined #openstack-nova09:45
*** k_mouza_ has joined #openstack-nova09:50
*** k_mouza has quit IRC09:53
*** martinkennelly has joined #openstack-nova09:57
*** vdrok has quit IRC10:04
*** vdrok has joined #openstack-nova10:04
*** k_mouza_ has quit IRC10:07
*** k_mouza has joined #openstack-nova10:19
*** dklyle has quit IRC10:42
*** rcernin has quit IRC10:43
*** viks____ has joined #openstack-nova11:02
*** mkrai has quit IRC11:04
*** lucasagomes has joined #openstack-nova11:10
*** rcernin has joined #openstack-nova11:15
*** k-s-dean has quit IRC11:27
*** bbowen has quit IRC11:28
openstackgerritLee Yarwood proposed openstack/nova master: guestfs: With libguestfs >= v1.41.1 decode returned bytes to string  https://review.opendev.org/c/openstack/nova/+/78771211:31
lyarwood^ hopefully an easy one if anyone has time11:36
*** sapd1 has joined #openstack-nova11:43
*** mgoddard has quit IRC11:43
gibilyarwood: I have a question about the fakeguestfs change in ^^11:46
*** rcernin has quit IRC11:49
sean-k-mooneygibi: i think that is what lyarwood  was saying changed in the new version11:58
sean-k-mooneygibi: i.e. it now returns bytes when you call read_file in libguestfs?11:58
sean-k-mooneylyarwood: is that right i was not fully following what you said in the commit message11:58
sean-k-mooneygibi: so i think lee is emulating the new behavior11:59
lyarwoodgibi: gibi  thanks replied12:01
lyarwoodsean-k-mooney: yeah sorry that's correct12:02
lyarwoodthat's the new behaviour, I'm not testing the older behaviour here but I'm not sure if that's worth it tbh12:02
gibisean-k-mooney, lyarwood: thanks. now I got it. I was confused about what the fakeguestfs replaces12:06
lyarwoodyeah sorry it needed calling out in the commit12:08
gibino worries12:10
artomstephenfin, gibi, so I've been thinking about that online data migration for the unshelve with SRIOV port bug...12:21
artomIt's not a slam dunk. Could we take some PTG minutes to discuss it? Or hash it out in the review?12:21
*** tesseract has quit IRC12:23
sean-k-mooneyi orginally suggested adding it a a nova manage command by the way12:23
gibiartom plug it to the end of the etherpad and lets see if we can make it to the end today,12:23
sean-k-mooneynot an online data migration12:23
gibiartom: if not then we can continue here or in the review12:23
gibiI don't have the necessary context right now, I have to read the patch first12:23
sean-k-mooneywell it is one just not one that you would always run12:23
* artom has taken it as a given that we'll never get to the end of the agenda ;)12:24
artomSo in the review then!12:24
artom:P12:24
sean-k-mooneyif we do it as a one off nova manage command it will be backporatble too12:24
gibireview works fine by me12:24
*** hemanth_n has quit IRC12:25
kashyapsean-k-mooney: gibi: stephenfin: A quick point (which I also noted on the Etherpad, but it can get lost) from yesterday on that emulation thing:12:25
sean-k-mooneygibi im going to move my topics to the end of the etherpad. the last ones i have left are less important so if we get to them great12:25
kashyapQEMU explicitly does *not* consider emulation to be a secure production scenario — "Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees."12:25
gibisorry, I don't actually know how to move faster in the agenda without shutting down some people in the room12:25
gibisean-k-mooney: that helps, thanks12:25
kashyapIt could be okay for private cloud setup, if the admin trusts their tenants.  The rest of it is in the Etherpad.12:25
sean-k-mooneykashyap: tell rackspace that12:27
sean-k-mooneykashyap: as i said most of there cloud ran x86 on power of 5+ years with xen/qemu12:27
gibikashyap: I see belmoreira's answer to your point in the etherpad. I think I agree. We can warn our users in the doc that emulation is not for public production, but for private validation12:27
sean-k-mooneygibi: i think it can be use for both12:28
sean-k-mooneywe can warn that its considered less secure sure12:28
gibisean-k-mooney: can be used does not mean it is not dangerous from security perspective ;)12:28
gibiit can be used but the consequnces should be clear12:28
*** dtantsur|bbl is now known as dtantsur12:29
sean-k-mooneykashyap: can you provide a link to a public staement form QEMU to that effect12:29
sean-k-mooneyif we are going to put it in our docs i would like somehting beter then an email or irc transcript12:29
kashyapsean-k-mooney: I don't have to say it to Rackspace, BTW.  They can read the doc I linked in there :)12:29
kashyapsean-k-mooney: https://qemu-project.gitlab.io/qemu/system/security.html#non-virtualization-use-case12:30
kashyapgibi: Yeah.  It can be easily missed w/o loud and clear documentation on that point.12:30
sean-k-mooneykashyap: cool then we can reference that12:30
sean-k-mooneyit seams clear that while it should in principal provide similar protection due to the legacy of not reviewing for security its not considerd as secure as using kvm12:31
sean-k-mooneyso really you would need to use selinux and other security mechanisms to provide guest isolation byond qemu12:32
sean-k-mooneythe same selinux rules we apply in the kvm case should add some messure of addtional protection12:32
kashyapSELinux and sVirt will provide protection beyond what QEMU may do.  But not all distros are SELinux-capable12:33
sean-k-mooneyture although apparmor will also provide some protectsion on the debina/ubuntu side12:33
*** sapd1 has quit IRC12:34
sean-k-mooneyby the way i assume we are just going to warn for this whenever using virt-type=qemu too12:35
sean-k-mooneybasically a note for virt_type=qemu and then when we add emulation support refrecne that it will fallback to qemu and that note applies to the emulation case12:35
sean-k-mooneywe have not warned agaisnt the use of the qemu virt type up to this point and the emulation case is no different to that so if we add something it shoudl be consitent12:36
*** k_mouza has quit IRC12:40
*** k_mouza has joined #openstack-nova12:41
*** bbowen has joined #openstack-nova12:42
*** mgoddard has joined #openstack-nova12:44
kashyapsean-k-mooney: Yeah; that's a valid point - warning for 'virt_type=qemu' is beneficial for the operator12:45
kashyapAs sometimes they use it unwittingly12:45
*** ratailor_ has quit IRC12:46
*** priteau has quit IRC12:48
lyarwoodhttps://review.opendev.org/c/openstack/nova/+/787712 - stephenfin / bauzas ; would either of you mind hitting this before we get started with PTG stuff today?12:53
stephenfinsure12:53
*** slaweq has quit IRC12:53
*** slaweq has joined #openstack-nova12:53
*** priteau has joined #openstack-nova12:54
*** slaweq has quit IRC12:56
*** slaweq has joined #openstack-nova12:56
stephenfinlyarwood: left a comment - could you address that one (happy with the rest being done in a follow-up, as with gibi)12:56
lyarwoodack looking12:59
openstackgerritLee Yarwood proposed openstack/nova master: guestfs: With libguestfs >= v1.41.1 decode returned bytes to string  https://review.opendev.org/c/openstack/nova/+/78771213:03
stephenfinthanks13:03
lyarwoodnp13:04
lyarwoodthanks for review13:04
*** k_mouza_ has joined #openstack-nova13:10
*** k_mouza has quit IRC13:13
*** vishalmanchanda has quit IRC13:26
bauzaswow, so Zoom is eating 5GB of my RAM13:28
bauzas...13:28
sean-k-mooneywhat browser are you using13:29
sean-k-mooneyit prefers chrome13:29
sean-k-mooneyor are you using the zoom app13:29
sean-k-mooneybrowser seams to work better for me at least13:29
bauzasI directly use the zoom app13:31
* bauzas tests a few things before the last PTG day13:31
sean-k-mooneyya i had audio issue with that i could hear but people could not hear me13:31
bauzashopefully this will be our last virtual PTG...13:31
sean-k-mooneyso now im using it in google chrome not chromium13:31
*** ratailor has joined #openstack-nova13:37
*** priteau has quit IRC13:43
*** ratailor has quit IRC13:44
*** priteau has joined #openstack-nova13:46
artomsean-k-mooney, you mean an entirely new nova-manage command? As in `nova-manage sriov-ports add-requester-id`?13:53
sean-k-mooneyalmost13:55
sean-k-mooneynew yes but i was suggesting that it would be automatic13:55
sean-k-mooneyi.e. you would not have to specify the requester id manually13:56
sean-k-mooneyit would try and work it out by looking at teh pci claims and the port profile13:56
artomI guess...13:56
sean-k-mooneyand if they agreed then setting the value13:56
artomThat would not apply to any instances that are not ACTIVE though13:56
sean-k-mooneyif not it would out put a list of port that were potnetally broken and say hay you might need to fix these13:56
artomWhich is also my beef with the data migration (currently writing a para of text in the review)13:57
sean-k-mooneyhow do you mean13:57
* lyarwood is going to miss the first 20mins of the nova track talking to the manila folks13:57
sean-k-mooneyit woul apply to any vm that is not currently in shleve offloaed or error13:57
artomWell, for instances that are SHELVED(_OFFLOADED) for example...13:57
sean-k-mooneyya one that are shleve offloaded currently cant really be fixed without manual intervention13:58
artomAnd don't we get into weird race conditions for instances in MIGRATING?13:58
gibilyarwood: do you have any hard opinion about droping eventlet? (we will start with that topic in nova)13:58
sean-k-mooneymaybe we could determin what subset are valid in the reivew13:58
artomAs in, depending on when you run the data migration, we might have already updated the port binding, or maybe we haven't13:58
sean-k-mooneybut basically any migration or command shoudl be a sperate patch after the fix13:59
sean-k-mooneywe have prescende downstream for backporting only the fix without the data migration13:59
sean-k-mooneythat is what we did for the network info cache force refresh13:59
artomOh, I remember that13:59
artomI'd argue that it can also be useful upstream13:59
artomIts still fixes an issue, even if any of your pre-existing instances don't get it14:00
sean-k-mooneyyes14:00
sean-k-mooney i would too14:00
sean-k-mooneythat is why i want the data mighation or command in a sperate patch that is after the fix14:00
sean-k-mooneyso we can backport the fix only if we chosse too14:00
artomstephenfin, you cool with that? ^^ I can push the fixes that I have for your comments, and we can figure out the online data migration thing in a separate patch?14:00
sean-k-mooneyto prevent new vms form breaking14:00
sean-k-mooneythen we can see how the stable team feals about backporting the nova manage command or the data migration after its fixed on master14:01
lyarwoodgibi: I don't :)14:02
gibilyarwood: ack14:02
openstackgerritArtom Lifshitz proposed openstack/nova master: Test SRIOV port move operations with PCI conflicts  https://review.opendev.org/c/openstack/nova/+/78308414:07
openstackgerritArtom Lifshitz proposed openstack/nova master: Update SRIOV port pci_slot when unshelving  https://review.opendev.org/c/openstack/nova/+/78416814:07
gibikashyap: after the current eventlet topic we will try to take your stuff from the nova etherpad14:08
kashyapgibi: Hi, I'll join in a few mins.  Thanks!  It's nothing super-pressing, though14:10
gibikashyap: ack, thanks14:10
*** rpittau is now known as rpittau|afk14:15
*** sapd1 has joined #openstack-nova14:28
*** k_mouza_ has quit IRC14:36
*** k_mouza has joined #openstack-nova14:36
*** lbragstad_ has joined #openstack-nova14:38
kashyapgibi: Feel free to do the time-check :)14:39
*** lbragstad has quit IRC14:42
*** dklyle has joined #openstack-nova14:43
kashyapHow much time we have left?  I'm not paying attention to the clock14:49
*** macz_ has joined #openstack-nova14:50
*** macz_ has quit IRC14:50
*** sapd1 has quit IRC14:52
*** sapd1 has joined #openstack-nova14:53
lyarwoodbrb15:02
*** k_mouza_ has joined #openstack-nova15:12
*** k_mouza has quit IRC15:16
*** k_mouza has joined #openstack-nova15:20
melwittbauzas: when you suggested documenting use of the os-assisted-volume-snapshots API, did you intend that for an out of tree driver? https://review.opendev.org/c/openstack/nova/+/78741515:23
*** k_mouza_ has quit IRC15:23
bauzasmelwitt: in the etherpad ? I thought lpetrut was mentioning some in-tree driver that was supporting it15:24
bauzasbut nevermind my point then15:25
bauzasI was confused15:25
bauzasmelwitt: actually, apologies for the silly question but do you know the difference between https://github.com/openstack/nova/tree/master/nova/virt/hyperv and https://github.com/openstack/compute-hyperv/ ?15:27
melwittbauzas: I don't really but lpetrut explains the differences in the patch comment and etherpad. the in tree driver doesn't use os-assisted-volume-snapshots but the out of tree driver does, which is just one example15:28
bauzasmelwitt: okay, then I'll fence the patch above15:28
melwittI kind of wish we could just remove in tree drivers in these cases where "no one is using it", seems pointless to have it in the code15:31
lyarwoodagreed15:33
bauzasthat's a reasonable concern and we should somehow understand what are the benefits of keeping such code15:33
bauzaslooking at the compute-hyperv repo, this sounds a fork15:34
*** mlavalle has joined #openstack-nova15:47
artomsean-k-mooney, so for my own education - if the MTU is going down, telling the guest OS via some means (DHCP?) is enough, no? Because incoming packets will presumably have the new smaller MTU, and so will "fit" on the tap device. So the guest just needs to know to reduce the size of what it sends.16:10
artomThe problem comes if the MTU goes up. In that case, the tap device does need to have its MTU increased, to accommodate the larger incoming packets.16:10
sean-k-mooneyartom: it will be eventually16:13
sean-k-mooneyartom: but we already do this16:13
sean-k-mooneyartom: neutron advertises the mtu to the guest in dhcp for quite a long time16:14
sean-k-mooneyand it will update the value when you update it in the api16:14
sean-k-mooneybut the guest wont ask for a dhcp update until half its remaining lease is avaible16:14
sean-k-mooneya normal leas is between 1-7 days16:14
artomAh, and there's no "gratuitous DHCP"16:15
sean-k-mooneyso it would be multiple days typeicaly until it was informed16:15
sean-k-mooneyartom: not that im aware of16:15
sean-k-mooneybrb getting a drink16:15
*** k_mouza has quit IRC16:16
artom"There is a FORCERENEW message that your DHCP server can issue to clients:16:17
artomhttps://www.ietf.org/rfc/rfc3203.txt16:17
artomYour clients have to support this mechanism, of course."16:17
artomhttps://networkengineering.stackexchange.com/questions/25618/dhcp-option-26-mtu-queries16:17
artomsean-k-mooney, err, the query string is encrypted in SSL16:22
artomThe host isn't for SNI16:23
artomBut the query stirng is16:23
*** hamalq has joined #openstack-nova16:27
sean-k-mooneyoh ok16:30
sean-k-mooneyso ssl is the fix?16:30
*** hamalq_ has joined #openstack-nova16:33
artomsean-k-mooney, for MTIM snooping, yes16:34
artom*MITM16:35
*** hamalq has quit IRC16:36
*** lucasagomes has quit IRC16:38
lyarwoodmelwitt: https://review.opendev.org/c/openstack/nova/+/757307 - would you mind checking this out today if you have time after ptg?16:48
melwittlyarwood: sure16:51
lyarwoodthanks16:58
*** andrewbonney has quit IRC17:00
*** derekh has quit IRC17:01
*** dtantsur is now known as dtantsur|afk17:22
*** ralonsoh has quit IRC17:23
*** lbragstad_ is now known as lbragstad17:23
*** slaweq has quit IRC17:38
*** gyee has joined #openstack-nova18:05
-openstackstatus- NOTICE: The Gerrit service on review.openstack.org is being restarted to pick up some updates, and should be available again momentarily19:02
*** bbowen has quit IRC20:03
*** belmoreira has quit IRC20:20
*** swp20 has quit IRC20:38
*** elod has quit IRC20:40
*** elod has joined #openstack-nova20:42
*** whoami-rajat has quit IRC20:59
*** bbowen has joined #openstack-nova21:17
*** ociuhandu has joined #openstack-nova21:45
*** ociuhandu has quit IRC21:49
openstackgerritDmitrii Shcherbakov proposed openstack/nova-specs master: Introduce Transport Nodes  https://review.opendev.org/c/openstack/nova-specs/+/78745822:00
*** slaweq has joined #openstack-nova22:09
*** slaweq has quit IRC22:20
*** amodi has quit IRC22:29
*** bbowen has quit IRC22:43
*** luksky has quit IRC23:02
*** tosky has quit IRC23:58
« Thursday, 2021-04-22 Index Saturday, 2021-04-24 »

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!