Friday, 2021-05-21

*** mlavalle has quit IRC00:00
*** pmannidi has quit IRC00:01
*** pmannidi has joined #openstack-nova00:02
*** yonglihe has joined #openstack-nova00:50
*** sapd1 has quit IRC00:58
*** tbachman has quit IRC01:20
*** tbachman has joined #openstack-nova01:22
*** LinPeiWen77 has quit IRC02:09
*** ricolin has quit IRC02:33
*** tbachman_ has joined #openstack-nova02:41
*** tbachman has quit IRC02:41
*** tbachman_ is now known as tbachman02:42
*** mkrai has joined #openstack-nova03:04
*** rcernin has quit IRC03:20
*** rcernin has joined #openstack-nova03:23
*** mkrai has quit IRC03:42
*** mkrai has joined #openstack-nova03:45
*** ratailor has joined #openstack-nova04:44
*** sapd1 has joined #openstack-nova04:54
*** sapd1_y has quit IRC04:55
*** haleyb has quit IRC05:09
*** haleyb has joined #openstack-nova05:32
*** mkrai has quit IRC05:51
openstackgerritDaniel Bengtsson proposed openstack/nova stable/wallaby: Use the new type HostDomainOpt.  https://review.opendev.org/c/openstack/nova/+/79250105:54
*** mkrai has joined #openstack-nova06:11
*** slaweq has joined #openstack-nova06:18
*** benj_ has quit IRC06:19
*** ralonsoh has joined #openstack-nova06:28
*** ratailor_ has joined #openstack-nova06:32
*** ratailor has quit IRC06:34
*** ratailor_ has quit IRC06:35
*** slaweq has quit IRC06:39
*** ratailor has joined #openstack-nova06:45
*** ratailor_ has joined #openstack-nova06:49
*** ratailor has quit IRC06:51
*** ricolin has joined #openstack-nova06:54
*** jawad_axd has joined #openstack-nova06:54
*** dklyle has quit IRC07:02
gibibauzas: hi! How do you see, will you have time to get back to the pps spec today? If yes then I will wait with the update on that spec.07:05
*** andrewbonney has joined #openstack-nova07:10
*** ociuhandu has joined #openstack-nova07:26
*** xek has quit IRC07:36
*** LinPeiWen has joined #openstack-nova07:36
*** pmannidi has quit IRC07:39
*** pmannidi has joined #openstack-nova07:40
*** cgoncalves has quit IRC07:43
*** rpittau|afk is now known as rpittau07:43
*** cgoncalves has joined #openstack-nova07:44
*** ociuhandu has quit IRC07:48
*** ociuhandu has joined #openstack-nova07:54
*** tosky has joined #openstack-nova07:59
*** xek has joined #openstack-nova07:59
*** ociuhandu has quit IRC07:59
*** lucasagomes has joined #openstack-nova08:02
*** rcernin has quit IRC08:04
*** derekh has joined #openstack-nova08:12
openstackgerritLee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors  https://review.opendev.org/c/openstack/nova/+/78846708:15
*** ratailor_ has quit IRC08:15
openstackgerritLee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors  https://review.opendev.org/c/openstack/nova/+/78846708:16
*** ociuhandu has joined #openstack-nova08:20
bauzasgibi: sure, I'll take a look08:20
* bauzas was just taking popcorn for reading the libera/freenode chat08:21
*** ociuhandu has quit IRC08:23
*** ociuhandu has joined #openstack-nova08:24
*** benj_ has joined #openstack-nova08:27
*** ociuhandu has quit IRC08:30
*** sapd1_x has joined #openstack-nova08:32
*** rcernin has joined #openstack-nova08:37
*** rcernin has quit IRC08:38
*** rcernin has joined #openstack-nova08:38
openstackgerritYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136208:44
openstackgerritYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136308:44
openstackgerritYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894408:44
openstackgerritYongli He proposed openstack/nova master: smartnic support - reject server move and suspend  https://review.opendev.org/c/openstack/nova/+/77991308:44
openstackgerritYongli He proposed openstack/nova master: smartnic support - functional tests  https://review.opendev.org/c/openstack/nova/+/78014708:44
*** ociuhandu has joined #openstack-nova08:45
yongliheMerge conflict addressed(due to fixture cleanup.)08:47
*** ratailor has joined #openstack-nova08:51
*** mgoddard has quit IRC08:54
*** ignaziocassano has joined #openstack-nova08:54
*** mgoddard has joined #openstack-nova08:54
*** ociuhandu has quit IRC08:54
*** ociuhandu has joined #openstack-nova09:03
gibibauzas: based on the discussion so far it seems that we are mostly against having a separate OVS RP. would this work for you or is it something you would block on. I think the rest of the discussion is settled09:16
*** rcernin has quit IRC09:16
gibibauzas: also I wanted to ask you how do you feel about the bumping a API microversion in nova for this features. I can go both ways. There is no change in the nova API directly we just adapt to a neturon API change in nova09:17
bauzasgibi: call me stupid but I can't find my comments on the pps spec09:17
gibilet meg link you09:17
gibihttps://review.opendev.org/c/openstack/nova-specs/+/78501409:17
gibihttps://review.opendev.org/c/openstack/nova-specs/+/785014/7/specs/xena/approved/qos-minimum-guaranteed-packet-rate.rst#9809:18
bauzasyeah I was on the spec09:18
bauzasbut gerrit UI wasn't showing my comments09:18
bauzasanyway, found them09:18
bauzasbizarre...09:18
gibiwrong patchset maybe09:18
bauzascan't saty09:19
bauzassay*09:19
bauzasanyway, looking at PS709:19
openstackgerritQiu Fossen proposed openstack/nova-specs master: Allow migrating PMEM's data  https://review.opendev.org/c/openstack/nova-specs/+/78556309:19
*** rcernin has joined #openstack-nova09:22
bauzashmmmm, YAGNI... /me googles for it09:22
gibiYou arent gona needd it09:26
gibicdent used it a lot09:27
* gibi try not to go back to nostalgia land, yesterday was enough 09:27
bauzasgibi: OK, I think I captured the discussion09:32
bauzasaaaaand I don't know what to say09:33
bauzasthe point is, I feel we are more and more designing our 'high-performance' features based on a couple of assumptions which are virt-specific09:34
bauzaswhich makes sense as we honestly only have one major configuration using a couple of knobs we know (ovs, libvirt-qemu for the least)09:34
bauzasbut doing those shortcuts have a price to pay : we raise the barrier for newcomers09:35
bauzasif some company wants to develop a new neutron backend that would break the 1:1 mapping between the agent and the service itself, then this would require more work for them09:36
*** rcernin has quit IRC09:36
bauzasfor the moment, I'd say (except notably for QoS) that only the libvirt driver is impacted by such assumption09:36
gibibauzas: isn't part of the state of the project, we are slowing down, maturing, solidifying. So we don't really expect big new things, like a new virt driver, coming09:37
bauzaswhen sean-k-mooney say "a lot of changes for nova and neutron" , this would mean for nova the libvirt driver only, as I could tell09:37
bauzasgibi: right, I know09:37
bauzasgibi: and I'm pragmatic09:37
sean-k-mooneybauzas: ovs is supported wiht hyperv too09:38
bauzasbut I just want everyone to feel the price of such shortcomings09:38
bauzasbut again, I'm not *that* opiniated to block on this09:38
bauzasso I'll just leave it go09:38
sean-k-mooneyyes it woudl require more work09:39
bauzasgibi: fwiw, I wouldn't speak of a new virt driver09:39
bauzasgibi: that said, adding a new virt driver isn't a big deal in nova and you know09:39
bauzasgibi: I was more considering that some network people could think that multiple switches on an agent could be nice09:40
bauzasfor HA or whatever09:40
bauzasI'm no longer surprised by the creativity of the community09:41
sean-k-mooneyha09:41
sean-k-mooneylast time i suggested adding a new virt driver it got shot down quicker then adding cellsv1 back09:41
bauzas(that being said, I'm up with sean-k-mooney on the fact that I also feel that modeling the agent itself is pointless if no resources are really offered by it)09:42
bauzassean-k-mooney: I was just mentioning this is *technically* easy to develop a new driver :)09:42
sean-k-mooneywhat is the meaning of modelign the vswitch by the way09:42
sean-k-mooneygive the packet procesing rate is an atribute of the datapath instnace09:43
gibithe agent RP was added originally to have a clear root RP for the agent to handle.09:43
sean-k-mooneyand a singe ovs instance can have multipel datapath instances09:43
sean-k-mooneyyes we had form the start planned ot model packet rate on the agent rp09:44
bauzassean-k-mooney: huh to what you say, you'd say that we could want to have multiple SLAs on different datapaths ?09:44
sean-k-mooneyamong ohter things like port capasity09:44
*** dtantsur|afk is now known as dtantsur09:44
bauzaseither way, I don't want to bikeshed on this09:44
sean-k-mooneybauzas: wehn you create ovs bridge you set a data path on them "system" or netdev09:44
bauzasthis makes sens09:44
bauzassense*09:45
sean-k-mooneyso if you wanted you could have 1 bridge using dpdk and the other using the kernel datapath09:45
bauzasexactly like a qemu instance I guess09:45
sean-k-mooneyand they woudl have indepent capsities09:45
bauzasyeah, i can imagine that09:45
bauzasexactly like you could have a nova-compute using different qemu endpoints09:46
sean-k-mooneythere woudl still only be one ovs-vsiwwtch process in that case09:46
bauzasbut in this case, this would be easier to have one n-cpu per qemu endpoint, right?09:46
sean-k-mooneyyes it would09:46
sean-k-mooneyif you wnated to run ovs and ovs-dpdk on the same host09:46
bauzasokay, so making an analogy09:47
sean-k-mooneythe simplete way to do it woudl be to have 2 ovs isntances and dbs and 2 agents09:47
bauzasthis is easier to have one single ovs-vswitch per datapath instance09:47
bauzasyeah09:47
bauzasand then 2 agents09:48
sean-k-mooneywhich woudl mean 2 ovs agent RPs09:48
bauzaslike we do with a specific n-cpu service09:48
bauzasOK, gotcha09:48
bauzasok, by making this analogy, I feel better09:48
sean-k-mooneyfor what its worth i always treated the ovs agent and the ovs process as intercahngable when thinking about the resouce provider09:49
gibitoday there is a strong 1:1 mapping09:49
sean-k-mooneyi know thats a bit hand wavy butthat was the mental model i had to reason about this09:49
bauzaslike if anyone was asking for nova-libvirt to manage two different qemu endpoints and me saying 'heh, dude, just configure another n-cpu service instead', I'd then recommend configuring separate agents09:49
gibitechnically the vnic_type trait belongs to the agent and the pps capacity belongs to the OVS datapath09:50
gibias the agent is configurable which vnic_type to report09:50
sean-k-mooneyyes09:50
sean-k-mooneyi think that config option is used as a filter09:51
gibiyes09:51
sean-k-mooneyrather then just being able to speciay any vnic_type but yes09:51
bauzasok, but again, this doesn't hurt me09:51
bauzasin nova, we have specific resources that are tied to the compute service, while other resources are offered by the virt driver09:52
sean-k-mooneyso right now libvirt and os-vif can only be confirued to tlak to 1 ovs instance09:52
gibiI honestly don't want to prevent anybody starting to draw a plant to support two OVS per agent. With the current proposal we allocate certain extra cost on such a person sure, but until I don't see that that such plan is close to reality this is a future cost that might never be paid09:52
sean-k-mooneyif we wanted to support multipel on the same host we would need to have the ovs instnace connection infomathion pass form neutron to nova to tell use which one ot use09:52
* sean-k-mooney aw i have been trying to prevent two ovs for a long time :(09:53
sean-k-mooneywell on the same host09:53
sean-k-mooneyim totally ok with the idea of the neutorn agent managing multpile remote ovs agents09:53
elodgibi bauzas lyarwood : sorry for the interrupt o:) if any of you have time for a quick look at the train-em patch and +1 it, then it would be good. so that we can proceed with that as well. https://review.opendev.org/c/openstack/releases/+/79076109:54
gibisean-k-mooney: I'm not saying I would like to have two OVS on the same host, I just say that I don't want to prevent anybody planning it :)09:54
*** rcernin has joined #openstack-nova09:54
gibielod: ack09:54
bauzaselod: ack, will look09:54
sean-k-mooneybauzas: do you see any reason to have booth an ovs RP and and ovs agent RP09:54
elodthanks o/09:55
bauzassean-k-mooney: good question09:55
lyarwoodelod: looking09:55
bauzassean-k-mooney: your last sentence on the fact that an agent RP seems irrelevant puzzles me09:55
bauzassean-k-mooney: what exact resource classes do we have on the agent ?09:56
bauzasthe qos ones I guess ?09:56
bauzasgibi: ?09:56
sean-k-mooneyit was planned to have an inventory of PORTs there at one point09:56
gibibauzas: pps is on the agent as per the current proposal09:56
bauzasgibi: sure, that and what else ?09:57
sean-k-mooneyovs for stp reasons i belive normally has a limit of 4096 ports per bridge09:57
*** rcernin has quit IRC09:57
sean-k-mooneyovs dpdk used to be 1024 and at one point that was going to reduce to 3209:57
gibibauzas: I have no more plans :) but I defer to sean-k-mooney09:57
*** rcernin has joined #openstack-nova09:57
sean-k-mooneybauzas: that was the orgin resouce class that the agent was coing to model. on the traits side it was hopped we would report the network types suspported09:58
gibibauzas: I also imagine that the segment RP providign IP resources should be sharing the IP resource to the agent RP, but technically sharing with the compute RP is OK too I guess09:58
sean-k-mooneythe final case was incluing the agent RP in ^09:58
sean-k-mooneygibi: ya the root RP woudl work09:59
sean-k-mooneyalthoguh09:59
sean-k-mooneymaybe not in all cases09:59
sean-k-mooneyif you have sriov and ovs for example09:59
sean-k-mooneyyou might want to scope it to the agent?09:59
gibisean-k-mooney: I havent thought it through10:00
gibisean-k-mooney: maybe it belongs to the physnet bridge?10:00
sean-k-mooneysimilar to the physnet net which is scoped to the bridge10:00
sean-k-mooneywell the segment is mapped to a physnet10:00
sean-k-mooneyso perhaps10:00
gibiyeah then it make more sense to share the IP with the physnet birdge10:01
* bauzas was distracted by https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html#reporting-available-resources10:01
sean-k-mooneyoh br-tun for vxlan ectra10:01
bauzasso, we model a tree of an agent RP and the bridge RP10:01
sean-k-mooneyyes10:02
bauzasand since mimimum bandwidth SLAs are on the bridge, we have the egress/ingress RCs attached to the bridge RP10:03
gibiyes10:03
sean-k-mooneyone of the reason for havign the agent RP was also quick lookup of the RP by using the agent uuid10:03
bauzasgibi: then, I don't get the need of reparenting you mentioned10:03
bauzasoh10:03
bauzasthe bug10:03
sean-k-mooneybauzas: due to a bug they were moved to the root rp10:03
lyarwoodstephenfin: https://review.opendev.org/q/topic:bug/1928063 - could you hit this again?10:03
gibiagent RP -> OVS RP -> bridge RP would be the tree10:03
bauzasgotcha10:04
gibiand therefore the bridge would need to move under a new parent10:04
bauzasyeah10:04
bauzaswell10:04
sean-k-mooneygibi: i still come back to could we model the invetory on br-int and perhap even remvoe the agent rp10:05
* bauzas wonders whether it's just simplier to consider that the existing agent RP we created for the purpose of the bandwidth spec is just a OVS RP10:05
sean-k-mooneygibi: to avoid needing to move the bridge that were moved by the bug in neutorn10:05
bauzasand we would defer the creation of a parent RP, be the agent, if someone comes by with a plan of providing inventories of ports10:05
gibibauzas: basically that was sean-k-mooney does when mentally map the agent to the ovs process10:06
sean-k-mooneyalthough the main problem with that is we cant use same subtree10:06
gibisean-k-mooney: we need to move the bridges due to the bug as they are under the root RP now10:06
sean-k-mooneyright10:06
sean-k-mooneyi was suggesting maybe we leave them there10:06
gibisean-k-mooney: you are correct with the same_subtree issue too10:07
sean-k-mooneycrazy idea...10:07
gibiwe need to group the bw and pps resource provided by the same path under the same subtree10:07
sean-k-mooney we could have the br-int under the root rp and the other bridge under br-int10:07
sean-k-mooneyto model the bridge toplogy10:07
gibior in other words rename the agent rp to be the br-int10:08
sean-k-mooneymore or less10:08
sean-k-mooneyif you had 2 ovs in that case you woudl have 2 paralle trees of bridges10:09
bauzasto be the switch10:09
bauzasnot the bridge10:09
sean-k-mooneybauzas: no i mean the bridge10:10
bauzasyou lost me10:10
sean-k-mooneyi know10:10
sean-k-mooneyall data too and from the vm passes through br-int10:10
sean-k-mooneyregarless of if its vm to vm on same host or vxlan or vlan10:10
sean-k-mooneyso if we model the inventory there it models the datalane capsity10:11
sean-k-mooneyby puttign the other bridge under it10:11
sean-k-mooneywe can model the actully bridge toplogy10:11
sean-k-mooneyand make same subtree work10:11
bauzasah10:11
sean-k-mooneyif you want 3 ovs instaces just create a second tree10:11
sean-k-mooneyfo the second set of bridges and resrouses10:11
gibi(still it is technically equivalent to rename agent RP to br-int today)10:12
sean-k-mooneygibi: yes it is10:12
bauzasbr-int is a neutron notion10:12
bauzas(well, a nova-net too but...)10:12
sean-k-mooneyits the default name of the bridge we plug all the vms into10:12
bauzasthe neutron-agent seems to me more understandable from a x-project perspective10:12
sean-k-mooneyits also the name used with ovn and odl for what ites workth but its technically configurable10:12
sean-k-mooneyack10:13
sean-k-mooneyi said it was a slight crazy idea :)10:13
gibiinterestingly we don't have a similar structure for the sriov side. There we have independent PFs managed by the same agent10:13
sean-k-mooneywe could if we moded indevuate pci cards10:14
sean-k-mooneyeg grouped PF together if they were on the same add in card but that has limited usefullness10:15
sean-k-mooneythe main one woudl be pcie bandwith really10:15
bauzasdid I open a can of worms ?10:15
sean-k-mooneyno10:15
sean-k-mooneywell its netwrokign so yes by default10:15
bauzaslol10:16
bauzasjust trying to wrap up things in my mind10:16
sean-k-mooneyperhaps a call would also help?10:17
bauzaswith the minimum bandwidth model, we said "heh, we have an agent which has bridges for inter-node communication' so we are going to put resources to track on those bridges10:17
bauzascorrect ?10:18
sean-k-mooneyyes mainly because the bandwith is an aspect of a nic which is attached to at most 1 of thoes briges10:18
gibiyepp10:18
sean-k-mooneythe standard name for the bridge with the nice is generally br-ex10:19
bauzasso, local vm-to-vm communication thru br-int isn't guaranteed, right?10:19
openstackgerritBrin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs  https://review.opendev.org/c/openstack/nova/+/76531110:19
openstackgerritBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API  https://review.opendev.org/c/openstack/nova/+/76638010:19
sean-k-mooneybauzas: it does not consume any nic bandeith for kernel ovs10:19
bauzassean-k-mooney: I know, I just want to make things clear10:19
sean-k-mooneybauzas: ovs's internal bandwith generally exceeed your nic bandwith10:19
sean-k-mooneybut technically no its not10:19
sean-k-mooneywe are jsut reserving inter host bandwith10:20
bauzascool10:20
bauzashere, back to the pps spec10:20
bauzas(and gosh, we should find an acronym for the minimum bandwidth spec)10:20
gibibw spec :)10:20
bauzasmin b/w, sorted it10:20
sean-k-mooney:)10:20
bauzasok, so, back to the pps spec10:20
sean-k-mooneybrb continue and ill catch up10:21
bauzashere, we want to guarantee the process rate of the internal ovs switch that's on... br-int ?10:21
* gibi free until the top of the hour, then need to jump to two consecutive calls 10:21
* bauzas had to skip his usual Friday gym session :p10:21
gibiin theory I we can rename the OVS Agent RP to br-int. It would help with some mental modelling. But this can be done any time independently of my work. So I would like to push this work to be a burden of the person who proposes the multiple OVS per agent spec. You can hate me for it, but I don't believe we ever get there. So I spare some effort not to do someting that will not be needed.10:25
gibiI will documet the renameing idea in the spec10:26
bauzasgibi: honestly, I feel we can just leave as it is, after 1 hour of brainstorming10:27
*** bbowen_ has joined #openstack-nova10:27
gibiI feel the same. but I think we gained some insights during that hour10:28
bauzasthe main difference between pps and bw features is that one cares about inter-host communication while the other cares about the agent itself10:28
*** ignaziocassano has quit IRC10:28
gibibauzas: this is coming from the fact that the bottlenecks are in different places regarding bw or pps10:29
bauzasyup, that's what I figured10:29
sean-k-mooneybauzas: kind of yes. one is inter host and the other is any traffic that passes though ovs bot inter and intra host traffic10:29
bauzasok, I'll reply to the spec10:29
gibibauzas: thank you10:29
gibisean-k-mooney: thank you10:29
gibiI appreciate your time spent on these topics10:30
bauzasby saying that for the good or bad, we've already created a beast called "the agent"10:30
bauzaswhich is actually something between br-int and other things10:30
bauzasby adding resources to this "beast", we're making it clear this is the *switch*10:30
sean-k-mooneyyes like the compute node it currenlty modesl multiple things10:30
*** bbowen has quit IRC10:31
bauzasif someone pops up with wanting to monitor the number of ports per agent, we could then say "mmmm, maybe create a parent RP"10:31
bauzasbut this is unfair to ask gibi to pay the price now10:31
sean-k-mooneyor just add it to the beast10:31
bauzaswe just internally defined this as an agent, but this is untrue10:32
bauzassean-k-mooney: yup, another spec, another day of discussions10:32
sean-k-mooneywe shoudl add in scare quotes "the beast" beside all mentions of the agent rp and just not say why10:32
gibiuntil the agent and the switch has 1:1 relationship you can attach resources to the RP for both reasons10:32
gibiit is a beast10:33
gibibut we are taming it with our 1:1 assumption10:33
sean-k-mooneyyes im tryiing to avoid discussign the added complxity hardware offload adds10:33
sean-k-mooneywe have adress that via the different resouce classes however10:34
gibiwhich might be a compromise but as far as I see it is an acceptable one10:34
bauzastechnically we created a beast in nova too10:34
bauzasit is called a "compute RP"10:34
gibisure it modells mutliple thing10:34
*** ignaziocassano has joined #openstack-nova10:34
sean-k-mooneyyes but its a natural starting point10:35
gibi:)10:35
bauzasok, I don't wanna hold us so long10:35
sean-k-mooneyuntill you need to decompose it it all in one RP10:35
bauzasI'll just comment the spec and mention this very worthy eavesdrop10:35
ignaziocassanohello, seems patches for bug 1815989 are for python3. I am using centos 7 train :-(10:36
openstackbug 1815989 in neutron ussuri "OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky" [Undecided,In progress] https://launchpad.net/bugs/1815989 - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)10:36
sean-k-mooneygibi are you happy you have all the answer to your question to proceed with the next version10:36
gibiI have one more open thing10:36
sean-k-mooneyignaziocassano: posibly but they shoudl be simple to adapt10:36
gibido we need a microversion bump in nova for it?10:36
bauzasah10:36
sean-k-mooneygibi: i do not think so10:37
sean-k-mooneygibi: what api has changed10:37
gibinova adapts to the neutron API change10:37
gibino direct nova API has changed10:37
sean-k-mooneyright so i dont think we need a nova api change10:37
sean-k-mooneyand since neutron does not use microversion i think we are good?10:37
ignaziocassanosean-k-mooney : there is no hope that they will be reported on the rdo trunk?10:38
gibiI'm OK not bumping the microversion, but I would like to get bauzas view on it10:38
sean-k-mooneywe need the palcment microverion for the reparenting but that is a spereate spec10:38
gibisean-k-mooney: yepp placement is spearate and that is only for a bugfix10:38
gibithe pps feature does not need reparenting now10:38
gibi(the bugfix needs)10:38
sean-k-mooneyignaziocassano: it can be wehn we backprot it upstream we will make it python 2 compatiable10:39
ignaziocassanothks10:39
bauzasgibi: which kind of signal this microversion would tell ?10:40
gibibauzas: nova supports the new neutron API10:40
sean-k-mooneyignaziocassano: i rarely do this howver but the topic on the channel clearly states the chanel is for nova developemnt not technical support. if i or rodoflo have tiem we may be able to work on this backport but currently im tying to focus on a different discsusion10:40
bauzas"heh, you can use the fancy pps feature" ?10:40
gibibauzas: yes and no10:41
gibibauzas: both nova and neutron changes are needed to use pps10:41
bauzasexactly like bw10:41
gibibauzas: so simply having the nova upgraded and the microversion available does not mean you can use pps10:41
sean-k-mooneyright10:41
bauzasgibi: 'you can use pps', the 'you' being the enduser, right,10:41
bauzas?10:42
sean-k-mooneyso we could maybe model this as a compute capablity trait that was conditional on the neutron extenion being presnt10:42
bauzaswait wait10:42
sean-k-mooneybut i dont think this should be a microverion sicne that on its own woudl not tell you it will work10:42
sean-k-mooneybauzas: i was just trying to come up with any signel that could be useful10:42
sean-k-mooneybauzas: i dont think we actully need that10:42
bauzasI think we have a loose contract on the features a cloud supports10:43
sean-k-mooneygibi you just wanted a way to tell form the api if you could use this yes?10:43
bauzasas an end user, especially when you wanna use scheduler hints, you're absolutely blind whether the API endpoint will support it10:44
gibiespecially as this is an optinal feature as the admin needs to configure pps resources10:44
sean-k-mooneygibi: is the presnce of the QOS policy created by the admin not enough10:44
bauzasgibi: why can't the user request the neutron extension to see whether this is configured ?10:44
sean-k-mooneybauzas: they could but they would not know if nova was new enough10:45
sean-k-mooneybut since qos policy create is admin only10:45
sean-k-mooneylisting the qos polices seams like a better approch10:45
gibibauzas: from API perspective both the extension list and the nova microversion is needed to guarantee that this works10:45
bauzasgibi: remind me, have you written a new API microversion for bw ?10:45
gibisean-k-mooney: yes, if the admin created a new pps QoS policy then the user should assume that it is usable10:46
gibibauzas: for the first step yes,10:46
gibibauzas: then all the later support for lifecycle operations we did not bump10:46
sean-k-mooneygibi: right and since a user cant create the policy i dont think they need a way to check if the cloud could supprot it10:46
sean-k-mooneyah your right10:46
bauzasgibi: that's what I recall, then10:46
sean-k-mooneywe did add an inital bump10:47
bauzasgibi: I'd honestly consider mocking this approach10:47
*** mkrai has quit IRC10:47
sean-k-mooneyi dont really like bumping the microverion if there is no api change though10:47
bauzasagreed10:47
sean-k-mooneyi mean do we really want to force user to use the new microverion10:47
sean-k-mooneywehn they do a server create10:47
gibiit don't see why a user would use an old microversion if we bumped one for this.10:49
*** sapd1_x has quit IRC10:49
sean-k-mooneywell the process is openstack server create --port <uuid> <name>10:49
sean-k-mooneyi dont think they shoudl have to specify a new microverion just becasue the port has a pps qos policy10:50
gibime neither10:50
gibibut we have a history of bumping for bw and also we bumped for volume multiattach too. So I had to ask10:50
kashyapsean-k-mooney: dtantsur: You both fell for the "flame-bait" on the IRC topic from Artem Goncharov10:50
sean-k-mooneyvolume multi attach had a chagne to the api10:50
kashyapHe successfully distracted you all.10:50
sean-k-mooneykashyap: not really10:51
gibisean-k-mooney: I don't think we changed anyithing in the nova api10:51
gibibauzas: sean-k-mooney: but anyhow then I will not propose a microversion bump for pps10:51
sean-k-mooneyfor multi atach did we not add a flag to the bdms?10:51
sean-k-mooneyor was that all cinder side10:51
gibisean-k-mooney: at least our api history does not mention that flag10:52
gibihttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-queens10:52
sean-k-mooneyah ok i tought there was one for read only vs read write monthing10:52
gibisean-k-mooney, bauzas: thanks again for talking this through. I will update the spec later today, after my fancy friday calls10:53
bauzasgibi: can you recall *why* you had to create a microversion for bw ?10:53
sean-k-mooneyi gues not https://github.com/openstack/nova/commit/7e6ae9afd9f6f6bb1bf4289c598fbc95dfd5261210:54
*** ratailor_ has joined #openstack-nova10:57
sean-k-mooneybauzas: i suspect discoverablity10:58
sean-k-mooneylikely the same reason for multi attach10:58
bauzaswe absolutely need another way to express a cloud capabilities other but by microversions...10:59
sean-k-mooneyalthogh we shoudl think about addign a different way to do that10:59
sean-k-mooneyyep10:59
bauzasjohnthetubaguy had one tought very earlier10:59
gibibauzas: I guess discoverability10:59
bauzasbut we haven't pursued10:59
*** ratailor has quit IRC11:00
sean-k-mooneyyep i brough it up 2 ptgs ago too11:00
sean-k-mooneyhaving a simple staic api endpoint where we report feature and required microverison or simialr11:00
sean-k-mooneykind of like the extension list but not quite11:01
sean-k-mooneythe other thing that woudl be nice is discorablity for policy11:01
sean-k-mooneyi mentioned before that i would like to create an api midelware that would allow a client to discover what operation they can perform with there current token11:02
sean-k-mooneyor just in general as right now if you use custom policy there is nothing an end user can do to figure that out11:03
* gibi has to jump on calls11:03
*** k_mouza has joined #openstack-nova11:05
dtantsurkashyap: my comment was earlier than gtema's11:09
dtantsurI think we should keep revisiting this topic from time to time11:09
* bauzas goes lunching11:15
*** ociuhandu has quit IRC11:15
*** rcernin has quit IRC11:16
*** ignaziocassano has quit IRC11:16
*** ociuhandu has joined #openstack-nova11:17
*** sapd1_x has joined #openstack-nova11:22
*** ociuhandu has quit IRC11:23
*** ociuhandu has joined #openstack-nova11:37
*** ociuhandu has quit IRC11:42
*** ociuhandu has joined #openstack-nova11:42
*** k_mouza has quit IRC11:42
*** k_mouza has joined #openstack-nova11:45
*** ociuhandu has quit IRC11:48
*** sapd1_x has quit IRC11:52
*** damien_r has joined #openstack-nova11:53
*** ociuhandu has joined #openstack-nova12:15
*** ociuhandu has quit IRC12:20
sean-k-mooneydtantsur: you saw my mail pointing out how to use the matrix bridge by the way12:20
sean-k-mooney[m]dtantsur:  it seam to work pretty well using the web client at app.element.io12:21
sean-k-mooney[m]this has been possible for 2-3 years for what its worth12:22
sean-k-mooneydtantsur: there is also a bridge to OFTC from matirx too12:24
*** ociuhandu has joined #openstack-nova12:24
sean-k-mooneygibi: you need to auth with nickserv but make sure its a dm12:27
gibisean-k-mooney: yeah I figured :)12:27
*** gibi[m] has joined #openstack-nova12:32
gibi[m].12:32
gibi\o/12:32
sean-k-mooney[m]interesting i can see that you are typing in matix12:32
gibime too12:33
sean-k-mooney[m]not sure if thats uesful or not but good to know12:33
gibiit works pretty well without any extra setup except for the NickServ step12:33
sean-k-mooney[m]yep its not always supper responsive but its pretty quick12:34
sean-k-mooney[m]also it notes when i miss spell things....12:34
gibi[m]that would be helpful for me too12:35
gibi[m]to fix my spellings12:35
sean-k-mooney[m]i'm just afraid ill run out of red dots :)12:35
*** mgariepy has quit IRC12:36
lyarwoodwhich clients are you using?12:36
sean-k-mooney[m]https://app.element.io12:36
gibime too12:37
sean-k-mooney[m]there are a bunch12:37
gibisean-k-mooney: you can turn off sending typing notification in the preferences12:37
sean-k-mooneyah ok that good to know12:37
sean-k-mooneymatrix also has video and audio chat built in if you want it12:38
sean-k-mooneyand it look like url previews12:38
gibi[m]probably anim gifs too :)12:39
*** ratailor_ has quit IRC12:39
sean-k-mooney... probably i guess that the cost12:40
gibi[m]<sean-k-mooney "... probably i guess that the co"> :)12:42
sean-k-mooney[m]lyarwood:  first try that just showing off not even kicked by nick serv12:42
sean-k-mooney[m]ah there we go12:42
sean-k-mooneythe qoutes dont look bad in irc12:43
lyarwoodslightly confused, how do I auth with nickserv if I can't connect?12:43
gibilyarwood: https://github.com/matrix-org/matrix-appservice-irc/wiki/Guide:-How-to-use-Matrix-to-participate-in-IRC-rooms12:43
sean-k-mooneyyou cant connet to the openstack channels12:43
gibilyarwood: open a private message with NickServ and auth there before joining to the room12:44
sean-k-mooneyyou can dm freenods nickserv directly12:44
sean-k-mooneyyou really just need to do the IDENTIFY <nickname> <password> bit12:45
sean-k-mooneyi havent bother to save my password but i could i guess12:45
gibiyeah I only did idenity myself too12:45
sean-k-mooneyit will just depend on if i use matix or not12:45
sean-k-mooneylyarwood: what client do you use for irc12:46
*** lyarwood[m] has joined #openstack-nova12:46
lyarwoodweechat12:47
lyarwood[m]finally12:47
sean-k-mooneysame12:47
sean-k-mooneyweechat has a matix plugin too12:47
lyarwood[m]cool I might check that out later12:47
sean-k-mooneyi have not tried it but if you wanted to stay in a terminal its an option which is nice12:48
*** mgariepy has joined #openstack-nova12:49
*** lyarwood[m] has quit IRC12:53
*** lyarwood[m]1 has joined #openstack-nova12:54
*** lyarwood[m]1 is now known as lyarwood[m]12:55
*** lyarwood has quit IRC12:55
*** lyarwood[m] is now known as lyarwood12:55
dtantsuryeah, I'd rather stick to weechat12:57
* dtantsur is sad the slack plugin didn't work out for him12:57
*** k_mouza has quit IRC13:01
*** k_mouza has joined #openstack-nova13:03
*** ociuhandu has quit IRC13:06
*** ociuhandu has joined #openstack-nova13:07
*** jamesdenton has quit IRC13:07
*** jamesdenton has joined #openstack-nova13:09
*** jamesdenton has quit IRC13:09
*** jamesdenton has joined #openstack-nova13:10
*** ociuhandu has quit IRC13:11
*** ociuhandu has joined #openstack-nova13:11
*** ociuhandu has quit IRC13:12
*** ociuhandu has joined #openstack-nova13:13
gibielod: regarding the train-em patch https://review.opendev.org/c/openstack/releases/+/79076113:16
gibielod: we have some test related patches top of the last release and therefore top of the eol tag13:16
elodyou mean -em tag :)13:17
gibiooo13:17
lyarwoodyeah we aren't removing the branch just yet :d13:17
gibithis is not eol13:17
elodwe won't delete train. yet... :]13:17
gibioh13:17
gibisorry13:17
gibiI've mixed up13:17
gibithen sure no problem13:17
gibi /o\13:17
gibiI had coffee but I think it did not helped my brain13:18
*** ociuhandu has quit IRC13:18
elodit's friday afternoon, isn't it? :D13:18
elodsame here, actually... maybe it's because of the weather... :]13:18
gibielod: I still need to update ~2 specs before I can leave :D13:19
elod:S poor you13:19
gibipoor others who have to read what I will type now :D13:19
elod:D13:20
gibistephenfin: lyarwood lost your +2 on these patches due to my request, but I'm +2 now so you can send them through https://review.opendev.org/q/topic:%22bug%252F1928063%22+(status:open%20OR%20status:merged)13:20
lyarwoodI think he might be AFK today, I've not seen him online.13:21
*** k_mouza has quit IRC13:22
*** k_mouza_ has joined #openstack-nova13:22
gibiahh, ok13:23
gibibtw, Monday is a public holiday in Hungary so I will be off13:24
*** ociuhandu has joined #openstack-nova13:26
bauzasFrance too13:26
bauzas(Whit Monday)13:26
gibiyepp13:26
*** supamatt has joined #openstack-nova13:27
bauzasand next Friday will be public company holiday at Red Hat13:27
bauzasso, short week :(13:27
*** Underknowledge has quit IRC13:39
*** Underknowledge has joined #openstack-nova13:40
*** pmannidi has quit IRC13:44
*** pmannidi has joined #openstack-nova13:46
openstackgerritsean mooney proposed openstack/nova master: fix sr-iov support on Cavium ThunderX hosts.  https://review.opendev.org/c/openstack/nova/+/77767913:48
*** k_mouza_ has quit IRC13:55
*** pmannidi has quit IRC13:59
*** Underknowledge has quit IRC14:04
*** k_mouza has joined #openstack-nova14:04
*** pmannidi has joined #openstack-nova14:05
*** Underknowledge has joined #openstack-nova14:09
openstackgerritBalazs Gibizer proposed openstack/nova-specs master: QoS minimum guaranteed packet rate  https://review.opendev.org/c/openstack/nova-specs/+/78501414:09
*** k_mouza has quit IRC14:09
openstackgerritBalazs Gibizer proposed openstack/nova-specs master: [pps] Move the alternatives to separate section  https://review.opendev.org/c/openstack/nova-specs/+/79263414:10
*** jangutter_ has joined #openstack-nova14:15
*** Underknowledge has quit IRC14:17
*** jangutter has joined #openstack-nova14:19
*** tbachman has quit IRC14:20
*** Underknowledge has joined #openstack-nova14:20
*** pmannidi has quit IRC14:21
*** tbachman has joined #openstack-nova14:23
*** jangutter_ has quit IRC14:23
*** Underknowledge has quit IRC14:26
*** rpittau is now known as rpittau|afk14:27
*** Underknowledge has joined #openstack-nova14:27
*** tbachman_ has joined #openstack-nova14:44
*** tbachman has quit IRC14:45
*** tbachman_ is now known as tbachman14:45
*** dklyle has joined #openstack-nova14:52
openstackgerritMerged openstack/python-novaclient master: Refactor constructing request body  https://review.opendev.org/c/openstack/python-novaclient/+/79001714:59
*** mlavalle has joined #openstack-nova15:05
openstackgerritBalazs Gibizer proposed openstack/nova master: Fix RequestLevelParams persistence handling in RequestSpec  https://review.opendev.org/c/openstack/nova/+/79150215:14
openstackgerritBalazs Gibizer proposed openstack/nova master: [func test] create pps resource on OVS agent RP  https://review.opendev.org/c/openstack/nova/+/78720515:14
openstackgerritBalazs Gibizer proposed openstack/nova master: [func test] move port creation to the NeutronFixture  https://review.opendev.org/c/openstack/nova/+/78720615:14
openstackgerritBalazs Gibizer proposed openstack/nova master: [func test] refactor assertPortMatchesAllocation  https://review.opendev.org/c/openstack/nova/+/79245815:14
*** ociuhandu has quit IRC15:15
*** ociuhandu has joined #openstack-nova15:15
openstackgerritBalazs Gibizer proposed openstack/nova master: Add same_subtree field to RequestLevelParams  https://review.opendev.org/c/openstack/nova/+/79150315:18
openstackgerritBalazs Gibizer proposed openstack/nova master: Bump min placement microversion to 1.36  https://review.opendev.org/c/openstack/nova/+/79150415:19
*** ociuhandu has quit IRC15:19
openstackgerritBalazs Gibizer proposed openstack/nova master: Support same_subtree in allocation_canadidate query  https://review.opendev.org/c/openstack/nova/+/79150515:22
openstackgerritBalazs Gibizer proposed openstack/nova master: Support the new port resource_request format  https://review.opendev.org/c/openstack/nova/+/78720815:23
openstackgerritBalazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling  https://review.opendev.org/c/openstack/nova/+/79150615:23
openstackgerritMerged openstack/python-novaclient master: Change minversion of tox to 3.18.0  https://review.opendev.org/c/openstack/python-novaclient/+/79196915:27
*** jawad_axd has quit IRC15:31
*** k_mouza has joined #openstack-nova15:32
*** jangutter has quit IRC15:33
*** jangutter has joined #openstack-nova15:33
*** ociuhandu has joined #openstack-nova15:36
*** jangutter_ has joined #openstack-nova15:36
*** jangutter has quit IRC15:40
*** ociuhandu has quit IRC15:41
*** k_mouza has quit IRC15:55
*** lucasagomes has quit IRC15:56
*** Underknowledge has quit IRC15:57
*** k_mouza has joined #openstack-nova15:58
*** Underknowledge has joined #openstack-nova15:58
*** eharney has quit IRC16:07
*** gmann is now known as gmann_afk16:11
*** dtantsur is now known as dtantsur|afk16:25
*** tristanC has left #openstack-nova16:39
*** derekh has quit IRC17:00
*** dave-mccowan has quit IRC17:08
*** k_mouza has quit IRC17:16
*** andrewbonney has quit IRC17:25
*** __ministry has joined #openstack-nova17:44
*** __ministry has quit IRC17:49
*** bbowen has joined #openstack-nova17:58
openstackgerritMerged openstack/nova stable/wallaby: libvirt: Remove dead error handling code  https://review.opendev.org/c/openstack/nova/+/78872417:58
*** bbowen_ has quit IRC17:58
*** whoami-rajat has quit IRC17:59
*** ociuhandu has joined #openstack-nova18:21
*** ociuhandu has quit IRC18:27
*** dave-mccowan has joined #openstack-nova18:32
*** eharney has joined #openstack-nova18:35
*** lbragstad has quit IRC18:50
*** coreycb has quit IRC18:50
*** ociuhandu has joined #openstack-nova18:57
openstackgerritDmitrii Shcherbakov proposed openstack/nova-specs master: Introduce Transport Nodes  https://review.opendev.org/c/openstack/nova-specs/+/78745819:02
*** ociuhandu has quit IRC19:04
*** ociuhandu has joined #openstack-nova19:09
*** ociuhandu has quit IRC19:15
*** k_mouza has joined #openstack-nova19:32
*** k_mouza has quit IRC19:37
*** ralonsoh has quit IRC19:49
*** supamatt has quit IRC21:01
*** artom has quit IRC21:10
*** Underknowledge has quit IRC21:14
*** david-lyle has joined #openstack-nova21:15
*** tosky has quit IRC21:15
*** dklyle has quit IRC21:15
*** tosky has joined #openstack-nova21:16
*** Underknowledge has joined #openstack-nova21:16
*** jawad_axd has joined #openstack-nova21:43
*** jawad_axd has quit IRC21:52
*** jawad_axd has joined #openstack-nova21:52
*** rpioso has quit IRC21:54
*** csatari has quit IRC21:54
*** knikolla has quit IRC21:56
*** jawad_axd has quit IRC21:57
*** knikolla has joined #openstack-nova21:59
*** rpioso has joined #openstack-nova21:59
*** csatari has joined #openstack-nova21:59
*** ociuhandu has joined #openstack-nova22:02
*** ociuhandu has quit IRC22:11
*** jawad_axd has joined #openstack-nova22:23
*** jmlowe has quit IRC22:45
*** jmlowe has joined #openstack-nova22:48
*** jawad_axd has quit IRC22:57
*** tosky has quit IRC23:03
*** k_mouza has joined #openstack-nova23:32
*** k_mouza has quit IRC23:36
*** viks____ has quit IRC23:42
*** mlavalle has quit IRC23:57

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