*** mlavalle has quit IRC | 00:00 | |
*** pmannidi has quit IRC | 00:01 | |
*** pmannidi has joined #openstack-nova | 00:02 | |
*** yonglihe has joined #openstack-nova | 00:50 | |
*** sapd1 has quit IRC | 00:58 | |
*** tbachman has quit IRC | 01:20 | |
*** tbachman has joined #openstack-nova | 01:22 | |
*** LinPeiWen77 has quit IRC | 02:09 | |
*** ricolin has quit IRC | 02:33 | |
*** tbachman_ has joined #openstack-nova | 02:41 | |
*** tbachman has quit IRC | 02:41 | |
*** tbachman_ is now known as tbachman | 02:42 | |
*** mkrai has joined #openstack-nova | 03:04 | |
*** rcernin has quit IRC | 03:20 | |
*** rcernin has joined #openstack-nova | 03:23 | |
*** mkrai has quit IRC | 03:42 | |
*** mkrai has joined #openstack-nova | 03:45 | |
*** ratailor has joined #openstack-nova | 04:44 | |
*** sapd1 has joined #openstack-nova | 04:54 | |
*** sapd1_y has quit IRC | 04:55 | |
*** haleyb has quit IRC | 05:09 | |
*** haleyb has joined #openstack-nova | 05:32 | |
*** mkrai has quit IRC | 05:51 | |
openstackgerrit | Daniel Bengtsson proposed openstack/nova stable/wallaby: Use the new type HostDomainOpt. https://review.opendev.org/c/openstack/nova/+/792501 | 05:54 |
---|---|---|
*** mkrai has joined #openstack-nova | 06:11 | |
*** slaweq has joined #openstack-nova | 06:18 | |
*** benj_ has quit IRC | 06:19 | |
*** ralonsoh has joined #openstack-nova | 06:28 | |
*** ratailor_ has joined #openstack-nova | 06:32 | |
*** ratailor has quit IRC | 06:34 | |
*** ratailor_ has quit IRC | 06:35 | |
*** slaweq has quit IRC | 06:39 | |
*** ratailor has joined #openstack-nova | 06:45 | |
*** ratailor_ has joined #openstack-nova | 06:49 | |
*** ratailor has quit IRC | 06:51 | |
*** ricolin has joined #openstack-nova | 06:54 | |
*** jawad_axd has joined #openstack-nova | 06:54 | |
*** dklyle has quit IRC | 07:02 | |
gibi | bauzas: 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-nova | 07:10 | |
*** ociuhandu has joined #openstack-nova | 07:26 | |
*** xek has quit IRC | 07:36 | |
*** LinPeiWen has joined #openstack-nova | 07:36 | |
*** pmannidi has quit IRC | 07:39 | |
*** pmannidi has joined #openstack-nova | 07:40 | |
*** cgoncalves has quit IRC | 07:43 | |
*** rpittau|afk is now known as rpittau | 07:43 | |
*** cgoncalves has joined #openstack-nova | 07:44 | |
*** ociuhandu has quit IRC | 07:48 | |
*** ociuhandu has joined #openstack-nova | 07:54 | |
*** tosky has joined #openstack-nova | 07:59 | |
*** xek has joined #openstack-nova | 07:59 | |
*** ociuhandu has quit IRC | 07:59 | |
*** lucasagomes has joined #openstack-nova | 08:02 | |
*** rcernin has quit IRC | 08:04 | |
*** derekh has joined #openstack-nova | 08:12 | |
openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788467 | 08:15 |
*** ratailor_ has quit IRC | 08:15 | |
openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788467 | 08:16 |
*** ociuhandu has joined #openstack-nova | 08:20 | |
bauzas | gibi: sure, I'll take a look | 08:20 |
* bauzas was just taking popcorn for reading the libera/freenode chat | 08:21 | |
*** ociuhandu has quit IRC | 08:23 | |
*** ociuhandu has joined #openstack-nova | 08:24 | |
*** benj_ has joined #openstack-nova | 08:27 | |
*** ociuhandu has quit IRC | 08:30 | |
*** sapd1_x has joined #openstack-nova | 08:32 | |
*** rcernin has joined #openstack-nova | 08:37 | |
*** rcernin has quit IRC | 08:38 | |
*** rcernin has joined #openstack-nova | 08:38 | |
openstackgerrit | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | 08:44 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | 08:44 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | 08:44 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | 08:44 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | 08:44 |
*** ociuhandu has joined #openstack-nova | 08:45 | |
yonglihe | Merge conflict addressed(due to fixture cleanup.) | 08:47 |
*** ratailor has joined #openstack-nova | 08:51 | |
*** mgoddard has quit IRC | 08:54 | |
*** ignaziocassano has joined #openstack-nova | 08:54 | |
*** mgoddard has joined #openstack-nova | 08:54 | |
*** ociuhandu has quit IRC | 08:54 | |
*** ociuhandu has joined #openstack-nova | 09:03 | |
gibi | bauzas: 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 settled | 09:16 |
*** rcernin has quit IRC | 09:16 | |
gibi | bauzas: 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 nova | 09:17 |
bauzas | gibi: call me stupid but I can't find my comments on the pps spec | 09:17 |
gibi | let meg link you | 09:17 |
gibi | https://review.opendev.org/c/openstack/nova-specs/+/785014 | 09:17 |
gibi | https://review.opendev.org/c/openstack/nova-specs/+/785014/7/specs/xena/approved/qos-minimum-guaranteed-packet-rate.rst#98 | 09:18 |
bauzas | yeah I was on the spec | 09:18 |
bauzas | but gerrit UI wasn't showing my comments | 09:18 |
bauzas | anyway, found them | 09:18 |
bauzas | bizarre... | 09:18 |
gibi | wrong patchset maybe | 09:18 |
bauzas | can't saty | 09:19 |
bauzas | say* | 09:19 |
bauzas | anyway, looking at PS7 | 09:19 |
openstackgerrit | Qiu Fossen proposed openstack/nova-specs master: Allow migrating PMEM's data https://review.opendev.org/c/openstack/nova-specs/+/785563 | 09:19 |
*** rcernin has joined #openstack-nova | 09:22 | |
bauzas | hmmmm, YAGNI... /me googles for it | 09:22 |
gibi | You arent gona needd it | 09:26 |
gibi | cdent used it a lot | 09:27 |
* gibi try not to go back to nostalgia land, yesterday was enough | 09:27 | |
bauzas | gibi: OK, I think I captured the discussion | 09:32 |
bauzas | aaaaand I don't know what to say | 09:33 |
bauzas | the point is, I feel we are more and more designing our 'high-performance' features based on a couple of assumptions which are virt-specific | 09:34 |
bauzas | which 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 |
bauzas | but doing those shortcuts have a price to pay : we raise the barrier for newcomers | 09:35 |
bauzas | if 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 them | 09:36 |
*** rcernin has quit IRC | 09:36 | |
bauzas | for the moment, I'd say (except notably for QoS) that only the libvirt driver is impacted by such assumption | 09:36 |
gibi | bauzas: 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, coming | 09:37 |
bauzas | when sean-k-mooney say "a lot of changes for nova and neutron" , this would mean for nova the libvirt driver only, as I could tell | 09:37 |
bauzas | gibi: right, I know | 09:37 |
bauzas | gibi: and I'm pragmatic | 09:37 |
sean-k-mooney | bauzas: ovs is supported wiht hyperv too | 09:38 |
bauzas | but I just want everyone to feel the price of such shortcomings | 09:38 |
bauzas | but again, I'm not *that* opiniated to block on this | 09:38 |
bauzas | so I'll just leave it go | 09:38 |
sean-k-mooney | yes it woudl require more work | 09:39 |
bauzas | gibi: fwiw, I wouldn't speak of a new virt driver | 09:39 |
bauzas | gibi: that said, adding a new virt driver isn't a big deal in nova and you know | 09:39 |
bauzas | gibi: I was more considering that some network people could think that multiple switches on an agent could be nice | 09:40 |
bauzas | for HA or whatever | 09:40 |
bauzas | I'm no longer surprised by the creativity of the community | 09:41 |
sean-k-mooney | ha | 09:41 |
sean-k-mooney | last time i suggested adding a new virt driver it got shot down quicker then adding cellsv1 back | 09: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 |
bauzas | sean-k-mooney: I was just mentioning this is *technically* easy to develop a new driver :) | 09:42 |
sean-k-mooney | what is the meaning of modelign the vswitch by the way | 09:42 |
sean-k-mooney | give the packet procesing rate is an atribute of the datapath instnace | 09:43 |
gibi | the agent RP was added originally to have a clear root RP for the agent to handle. | 09:43 |
sean-k-mooney | and a singe ovs instance can have multipel datapath instances | 09:43 |
sean-k-mooney | yes we had form the start planned ot model packet rate on the agent rp | 09:44 |
bauzas | sean-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-mooney | among ohter things like port capasity | 09:44 |
*** dtantsur|afk is now known as dtantsur | 09:44 | |
bauzas | either way, I don't want to bikeshed on this | 09:44 |
sean-k-mooney | bauzas: wehn you create ovs bridge you set a data path on them "system" or netdev | 09:44 |
bauzas | this makes sens | 09:44 |
bauzas | sense* | 09:45 |
sean-k-mooney | so if you wanted you could have 1 bridge using dpdk and the other using the kernel datapath | 09:45 |
bauzas | exactly like a qemu instance I guess | 09:45 |
sean-k-mooney | and they woudl have indepent capsities | 09:45 |
bauzas | yeah, i can imagine that | 09:45 |
bauzas | exactly like you could have a nova-compute using different qemu endpoints | 09:46 |
sean-k-mooney | there woudl still only be one ovs-vsiwwtch process in that case | 09:46 |
bauzas | but in this case, this would be easier to have one n-cpu per qemu endpoint, right? | 09:46 |
sean-k-mooney | yes it would | 09:46 |
sean-k-mooney | if you wnated to run ovs and ovs-dpdk on the same host | 09:46 |
bauzas | okay, so making an analogy | 09:47 |
sean-k-mooney | the simplete way to do it woudl be to have 2 ovs isntances and dbs and 2 agents | 09:47 |
bauzas | this is easier to have one single ovs-vswitch per datapath instance | 09:47 |
bauzas | yeah | 09:47 |
bauzas | and then 2 agents | 09:48 |
sean-k-mooney | which woudl mean 2 ovs agent RPs | 09:48 |
bauzas | like we do with a specific n-cpu service | 09:48 |
bauzas | OK, gotcha | 09:48 |
bauzas | ok, by making this analogy, I feel better | 09:48 |
sean-k-mooney | for what its worth i always treated the ovs agent and the ovs process as intercahngable when thinking about the resouce provider | 09:49 |
gibi | today there is a strong 1:1 mapping | 09:49 |
sean-k-mooney | i know thats a bit hand wavy butthat was the mental model i had to reason about this | 09:49 |
bauzas | like 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 agents | 09:49 |
gibi | technically the vnic_type trait belongs to the agent and the pps capacity belongs to the OVS datapath | 09:50 |
gibi | as the agent is configurable which vnic_type to report | 09:50 |
sean-k-mooney | yes | 09:50 |
sean-k-mooney | i think that config option is used as a filter | 09:51 |
gibi | yes | 09:51 |
sean-k-mooney | rather then just being able to speciay any vnic_type but yes | 09:51 |
bauzas | ok, but again, this doesn't hurt me | 09:51 |
bauzas | in nova, we have specific resources that are tied to the compute service, while other resources are offered by the virt driver | 09:52 |
sean-k-mooney | so right now libvirt and os-vif can only be confirued to tlak to 1 ovs instance | 09:52 |
gibi | I 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 paid | 09:52 |
sean-k-mooney | if 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 use | 09:52 |
* sean-k-mooney aw i have been trying to prevent two ovs for a long time :( | 09:53 | |
sean-k-mooney | well on the same host | 09:53 |
sean-k-mooney | im totally ok with the idea of the neutorn agent managing multpile remote ovs agents | 09:53 |
elod | gibi 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/+/790761 | 09:54 |
gibi | sean-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-nova | 09:54 | |
gibi | elod: ack | 09:54 |
bauzas | elod: ack, will look | 09:54 |
sean-k-mooney | bauzas: do you see any reason to have booth an ovs RP and and ovs agent RP | 09:54 |
elod | thanks o/ | 09:55 |
bauzas | sean-k-mooney: good question | 09:55 |
lyarwood | elod: looking | 09:55 |
bauzas | sean-k-mooney: your last sentence on the fact that an agent RP seems irrelevant puzzles me | 09:55 |
bauzas | sean-k-mooney: what exact resource classes do we have on the agent ? | 09:56 |
bauzas | the qos ones I guess ? | 09:56 |
bauzas | gibi: ? | 09:56 |
sean-k-mooney | it was planned to have an inventory of PORTs there at one point | 09:56 |
gibi | bauzas: pps is on the agent as per the current proposal | 09:56 |
bauzas | gibi: sure, that and what else ? | 09:57 |
sean-k-mooney | ovs for stp reasons i belive normally has a limit of 4096 ports per bridge | 09:57 |
*** rcernin has quit IRC | 09:57 | |
sean-k-mooney | ovs dpdk used to be 1024 and at one point that was going to reduce to 32 | 09:57 |
gibi | bauzas: I have no more plans :) but I defer to sean-k-mooney | 09:57 |
*** rcernin has joined #openstack-nova | 09:57 | |
sean-k-mooney | bauzas: 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 suspported | 09:58 |
gibi | bauzas: 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 guess | 09:58 |
sean-k-mooney | the final case was incluing the agent RP in ^ | 09:58 |
sean-k-mooney | gibi: ya the root RP woudl work | 09:59 |
sean-k-mooney | althoguh | 09:59 |
sean-k-mooney | maybe not in all cases | 09:59 |
sean-k-mooney | if you have sriov and ovs for example | 09:59 |
sean-k-mooney | you might want to scope it to the agent? | 09:59 |
gibi | sean-k-mooney: I havent thought it through | 10:00 |
gibi | sean-k-mooney: maybe it belongs to the physnet bridge? | 10:00 |
sean-k-mooney | similar to the physnet net which is scoped to the bridge | 10:00 |
sean-k-mooney | well the segment is mapped to a physnet | 10:00 |
sean-k-mooney | so perhaps | 10:00 |
gibi | yeah then it make more sense to share the IP with the physnet birdge | 10:01 |
* bauzas was distracted by https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html#reporting-available-resources | 10:01 | |
sean-k-mooney | oh br-tun for vxlan ectra | 10:01 |
bauzas | so, we model a tree of an agent RP and the bridge RP | 10:01 |
sean-k-mooney | yes | 10:02 |
bauzas | and since mimimum bandwidth SLAs are on the bridge, we have the egress/ingress RCs attached to the bridge RP | 10:03 |
gibi | yes | 10:03 |
sean-k-mooney | one of the reason for havign the agent RP was also quick lookup of the RP by using the agent uuid | 10:03 |
bauzas | gibi: then, I don't get the need of reparenting you mentioned | 10:03 |
bauzas | oh | 10:03 |
bauzas | the bug | 10:03 |
sean-k-mooney | bauzas: due to a bug they were moved to the root rp | 10:03 |
lyarwood | stephenfin: https://review.opendev.org/q/topic:bug/1928063 - could you hit this again? | 10:03 |
gibi | agent RP -> OVS RP -> bridge RP would be the tree | 10:03 |
bauzas | gotcha | 10:04 |
gibi | and therefore the bridge would need to move under a new parent | 10:04 |
bauzas | yeah | 10:04 |
bauzas | well | 10:04 |
sean-k-mooney | gibi: i still come back to could we model the invetory on br-int and perhap even remvoe the agent rp | 10: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 RP | 10:05 | |
sean-k-mooney | gibi: to avoid needing to move the bridge that were moved by the bug in neutorn | 10:05 |
bauzas | and we would defer the creation of a parent RP, be the agent, if someone comes by with a plan of providing inventories of ports | 10:05 |
gibi | bauzas: basically that was sean-k-mooney does when mentally map the agent to the ovs process | 10:06 |
sean-k-mooney | although the main problem with that is we cant use same subtree | 10:06 |
gibi | sean-k-mooney: we need to move the bridges due to the bug as they are under the root RP now | 10:06 |
sean-k-mooney | right | 10:06 |
sean-k-mooney | i was suggesting maybe we leave them there | 10:06 |
gibi | sean-k-mooney: you are correct with the same_subtree issue too | 10:07 |
sean-k-mooney | crazy idea... | 10:07 |
gibi | we need to group the bw and pps resource provided by the same path under the same subtree | 10:07 |
sean-k-mooney | we could have the br-int under the root rp and the other bridge under br-int | 10:07 |
sean-k-mooney | to model the bridge toplogy | 10:07 |
gibi | or in other words rename the agent rp to be the br-int | 10:08 |
sean-k-mooney | more or less | 10:08 |
sean-k-mooney | if you had 2 ovs in that case you woudl have 2 paralle trees of bridges | 10:09 |
bauzas | to be the switch | 10:09 |
bauzas | not the bridge | 10:09 |
sean-k-mooney | bauzas: no i mean the bridge | 10:10 |
bauzas | you lost me | 10:10 |
sean-k-mooney | i know | 10:10 |
sean-k-mooney | all data too and from the vm passes through br-int | 10:10 |
sean-k-mooney | regarless of if its vm to vm on same host or vxlan or vlan | 10:10 |
sean-k-mooney | so if we model the inventory there it models the datalane capsity | 10:11 |
sean-k-mooney | by puttign the other bridge under it | 10:11 |
sean-k-mooney | we can model the actully bridge toplogy | 10:11 |
sean-k-mooney | and make same subtree work | 10:11 |
bauzas | ah | 10:11 |
sean-k-mooney | if you want 3 ovs instaces just create a second tree | 10:11 |
sean-k-mooney | fo the second set of bridges and resrouses | 10:11 |
gibi | (still it is technically equivalent to rename agent RP to br-int today) | 10:12 |
sean-k-mooney | gibi: yes it is | 10:12 |
bauzas | br-int is a neutron notion | 10:12 |
bauzas | (well, a nova-net too but...) | 10:12 |
sean-k-mooney | its the default name of the bridge we plug all the vms into | 10:12 |
bauzas | the neutron-agent seems to me more understandable from a x-project perspective | 10:12 |
sean-k-mooney | its also the name used with ovn and odl for what ites workth but its technically configurable | 10:12 |
sean-k-mooney | ack | 10:13 |
sean-k-mooney | i said it was a slight crazy idea :) | 10:13 |
gibi | interestingly we don't have a similar structure for the sriov side. There we have independent PFs managed by the same agent | 10:13 |
sean-k-mooney | we could if we moded indevuate pci cards | 10:14 |
sean-k-mooney | eg grouped PF together if they were on the same add in card but that has limited usefullness | 10:15 |
sean-k-mooney | the main one woudl be pcie bandwith really | 10:15 |
bauzas | did I open a can of worms ? | 10:15 |
sean-k-mooney | no | 10:15 |
sean-k-mooney | well its netwrokign so yes by default | 10:15 |
bauzas | lol | 10:16 |
bauzas | just trying to wrap up things in my mind | 10:16 |
sean-k-mooney | perhaps a call would also help? | 10:17 |
bauzas | with 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 bridges | 10:17 |
bauzas | correct ? | 10:18 |
sean-k-mooney | yes mainly because the bandwith is an aspect of a nic which is attached to at most 1 of thoes briges | 10:18 |
gibi | yepp | 10:18 |
sean-k-mooney | the standard name for the bridge with the nice is generally br-ex | 10:19 |
bauzas | so, local vm-to-vm communication thru br-int isn't guaranteed, right? | 10:19 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311 | 10:19 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380 | 10:19 |
sean-k-mooney | bauzas: it does not consume any nic bandeith for kernel ovs | 10:19 |
bauzas | sean-k-mooney: I know, I just want to make things clear | 10:19 |
sean-k-mooney | bauzas: ovs's internal bandwith generally exceeed your nic bandwith | 10:19 |
sean-k-mooney | but technically no its not | 10:19 |
sean-k-mooney | we are jsut reserving inter host bandwith | 10:20 |
bauzas | cool | 10:20 |
bauzas | here, back to the pps spec | 10:20 |
bauzas | (and gosh, we should find an acronym for the minimum bandwidth spec) | 10:20 |
gibi | bw spec :) | 10:20 |
bauzas | min b/w, sorted it | 10:20 |
sean-k-mooney | :) | 10:20 |
bauzas | ok, so, back to the pps spec | 10:20 |
sean-k-mooney | brb continue and ill catch up | 10:21 |
bauzas | here, 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 :p | 10:21 | |
gibi | in 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 |
gibi | I will documet the renameing idea in the spec | 10:26 |
bauzas | gibi: honestly, I feel we can just leave as it is, after 1 hour of brainstorming | 10:27 |
*** bbowen_ has joined #openstack-nova | 10:27 | |
gibi | I feel the same. but I think we gained some insights during that hour | 10:28 |
bauzas | the main difference between pps and bw features is that one cares about inter-host communication while the other cares about the agent itself | 10:28 |
*** ignaziocassano has quit IRC | 10:28 | |
gibi | bauzas: this is coming from the fact that the bottlenecks are in different places regarding bw or pps | 10:29 |
bauzas | yup, that's what I figured | 10:29 |
sean-k-mooney | bauzas: kind of yes. one is inter host and the other is any traffic that passes though ovs bot inter and intra host traffic | 10:29 |
bauzas | ok, I'll reply to the spec | 10:29 |
gibi | bauzas: thank you | 10:29 |
gibi | sean-k-mooney: thank you | 10:29 |
gibi | I appreciate your time spent on these topics | 10:30 |
bauzas | by saying that for the good or bad, we've already created a beast called "the agent" | 10:30 |
bauzas | which is actually something between br-int and other things | 10:30 |
bauzas | by adding resources to this "beast", we're making it clear this is the *switch* | 10:30 |
sean-k-mooney | yes like the compute node it currenlty modesl multiple things | 10:30 |
*** bbowen has quit IRC | 10:31 | |
bauzas | if 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 |
bauzas | but this is unfair to ask gibi to pay the price now | 10:31 |
sean-k-mooney | or just add it to the beast | 10:31 |
bauzas | we just internally defined this as an agent, but this is untrue | 10:32 |
bauzas | sean-k-mooney: yup, another spec, another day of discussions | 10:32 |
sean-k-mooney | we shoudl add in scare quotes "the beast" beside all mentions of the agent rp and just not say why | 10:32 |
gibi | until the agent and the switch has 1:1 relationship you can attach resources to the RP for both reasons | 10:32 |
gibi | it is a beast | 10:33 |
gibi | but we are taming it with our 1:1 assumption | 10:33 |
sean-k-mooney | yes im tryiing to avoid discussign the added complxity hardware offload adds | 10:33 |
sean-k-mooney | we have adress that via the different resouce classes however | 10:34 |
gibi | which might be a compromise but as far as I see it is an acceptable one | 10:34 |
bauzas | technically we created a beast in nova too | 10:34 |
bauzas | it is called a "compute RP" | 10:34 |
gibi | sure it modells mutliple thing | 10:34 |
*** ignaziocassano has joined #openstack-nova | 10:34 | |
sean-k-mooney | yes but its a natural starting point | 10:35 |
gibi | :) | 10:35 |
bauzas | ok, I don't wanna hold us so long | 10:35 |
sean-k-mooney | untill you need to decompose it it all in one RP | 10:35 |
bauzas | I'll just comment the spec and mention this very worthy eavesdrop | 10:35 |
ignaziocassano | hello, seems patches for bug 1815989 are for python3. I am using centos 7 train :-( | 10:36 |
openstack | bug 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-mooney | gibi are you happy you have all the answer to your question to proceed with the next version | 10:36 |
gibi | I have one more open thing | 10:36 |
sean-k-mooney | ignaziocassano: posibly but they shoudl be simple to adapt | 10:36 |
gibi | do we need a microversion bump in nova for it? | 10:36 |
bauzas | ah | 10:36 |
sean-k-mooney | gibi: i do not think so | 10:37 |
sean-k-mooney | gibi: what api has changed | 10:37 |
gibi | nova adapts to the neutron API change | 10:37 |
gibi | no direct nova API has changed | 10:37 |
sean-k-mooney | right so i dont think we need a nova api change | 10:37 |
sean-k-mooney | and since neutron does not use microversion i think we are good? | 10:37 |
ignaziocassano | sean-k-mooney : there is no hope that they will be reported on the rdo trunk? | 10:38 |
gibi | I'm OK not bumping the microversion, but I would like to get bauzas view on it | 10:38 |
sean-k-mooney | we need the palcment microverion for the reparenting but that is a spereate spec | 10:38 |
gibi | sean-k-mooney: yepp placement is spearate and that is only for a bugfix | 10:38 |
gibi | the pps feature does not need reparenting now | 10:38 |
gibi | (the bugfix needs) | 10:38 |
sean-k-mooney | ignaziocassano: it can be wehn we backprot it upstream we will make it python 2 compatiable | 10:39 |
ignaziocassano | thks | 10:39 |
bauzas | gibi: which kind of signal this microversion would tell ? | 10:40 |
gibi | bauzas: nova supports the new neutron API | 10:40 |
sean-k-mooney | ignaziocassano: 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 discsusion | 10:40 |
bauzas | "heh, you can use the fancy pps feature" ? | 10:40 |
gibi | bauzas: yes and no | 10:41 |
gibi | bauzas: both nova and neutron changes are needed to use pps | 10:41 |
bauzas | exactly like bw | 10:41 |
gibi | bauzas: so simply having the nova upgraded and the microversion available does not mean you can use pps | 10:41 |
sean-k-mooney | right | 10:41 |
bauzas | gibi: 'you can use pps', the 'you' being the enduser, right, | 10:41 |
bauzas | ? | 10:42 |
sean-k-mooney | so we could maybe model this as a compute capablity trait that was conditional on the neutron extenion being presnt | 10:42 |
bauzas | wait wait | 10:42 |
sean-k-mooney | but i dont think this should be a microverion sicne that on its own woudl not tell you it will work | 10:42 |
sean-k-mooney | bauzas: i was just trying to come up with any signel that could be useful | 10:42 |
sean-k-mooney | bauzas: i dont think we actully need that | 10:42 |
bauzas | I think we have a loose contract on the features a cloud supports | 10:43 |
sean-k-mooney | gibi you just wanted a way to tell form the api if you could use this yes? | 10:43 |
bauzas | as an end user, especially when you wanna use scheduler hints, you're absolutely blind whether the API endpoint will support it | 10:44 |
gibi | especially as this is an optinal feature as the admin needs to configure pps resources | 10:44 |
sean-k-mooney | gibi: is the presnce of the QOS policy created by the admin not enough | 10:44 |
bauzas | gibi: why can't the user request the neutron extension to see whether this is configured ? | 10:44 |
sean-k-mooney | bauzas: they could but they would not know if nova was new enough | 10:45 |
sean-k-mooney | but since qos policy create is admin only | 10:45 |
sean-k-mooney | listing the qos polices seams like a better approch | 10:45 |
gibi | bauzas: from API perspective both the extension list and the nova microversion is needed to guarantee that this works | 10:45 |
bauzas | gibi: remind me, have you written a new API microversion for bw ? | 10:45 |
gibi | sean-k-mooney: yes, if the admin created a new pps QoS policy then the user should assume that it is usable | 10:46 |
gibi | bauzas: for the first step yes, | 10:46 |
gibi | bauzas: then all the later support for lifecycle operations we did not bump | 10:46 |
sean-k-mooney | gibi: right and since a user cant create the policy i dont think they need a way to check if the cloud could supprot it | 10:46 |
sean-k-mooney | ah your right | 10:46 |
bauzas | gibi: that's what I recall, then | 10:46 |
sean-k-mooney | we did add an inital bump | 10:47 |
bauzas | gibi: I'd honestly consider mocking this approach | 10:47 |
*** mkrai has quit IRC | 10:47 | |
sean-k-mooney | i dont really like bumping the microverion if there is no api change though | 10:47 |
bauzas | agreed | 10:47 |
sean-k-mooney | i mean do we really want to force user to use the new microverion | 10:47 |
sean-k-mooney | wehn they do a server create | 10:47 |
gibi | it don't see why a user would use an old microversion if we bumped one for this. | 10:49 |
*** sapd1_x has quit IRC | 10:49 | |
sean-k-mooney | well the process is openstack server create --port <uuid> <name> | 10:49 |
sean-k-mooney | i dont think they shoudl have to specify a new microverion just becasue the port has a pps qos policy | 10:50 |
gibi | me neither | 10:50 |
gibi | but we have a history of bumping for bw and also we bumped for volume multiattach too. So I had to ask | 10:50 |
kashyap | sean-k-mooney: dtantsur: You both fell for the "flame-bait" on the IRC topic from Artem Goncharov | 10:50 |
sean-k-mooney | volume multi attach had a chagne to the api | 10:50 |
kashyap | He successfully distracted you all. | 10:50 |
sean-k-mooney | kashyap: not really | 10:51 |
gibi | sean-k-mooney: I don't think we changed anyithing in the nova api | 10:51 |
gibi | bauzas: sean-k-mooney: but anyhow then I will not propose a microversion bump for pps | 10:51 |
sean-k-mooney | for multi atach did we not add a flag to the bdms? | 10:51 |
sean-k-mooney | or was that all cinder side | 10:51 |
gibi | sean-k-mooney: at least our api history does not mention that flag | 10:52 |
gibi | https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-queens | 10:52 |
sean-k-mooney | ah ok i tought there was one for read only vs read write monthing | 10:52 |
gibi | sean-k-mooney, bauzas: thanks again for talking this through. I will update the spec later today, after my fancy friday calls | 10:53 |
bauzas | gibi: can you recall *why* you had to create a microversion for bw ? | 10:53 |
sean-k-mooney | i gues not https://github.com/openstack/nova/commit/7e6ae9afd9f6f6bb1bf4289c598fbc95dfd52612 | 10:54 |
*** ratailor_ has joined #openstack-nova | 10:57 | |
sean-k-mooney | bauzas: i suspect discoverablity | 10:58 |
sean-k-mooney | likely the same reason for multi attach | 10:58 |
bauzas | we absolutely need another way to express a cloud capabilities other but by microversions... | 10:59 |
sean-k-mooney | althogh we shoudl think about addign a different way to do that | 10:59 |
sean-k-mooney | yep | 10:59 |
bauzas | johnthetubaguy had one tought very earlier | 10:59 |
gibi | bauzas: I guess discoverability | 10:59 |
bauzas | but we haven't pursued | 10:59 |
*** ratailor has quit IRC | 11:00 | |
sean-k-mooney | yep i brough it up 2 ptgs ago too | 11:00 |
sean-k-mooney | having a simple staic api endpoint where we report feature and required microverison or simialr | 11:00 |
sean-k-mooney | kind of like the extension list but not quite | 11:01 |
sean-k-mooney | the other thing that woudl be nice is discorablity for policy | 11:01 |
sean-k-mooney | i 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 token | 11:02 |
sean-k-mooney | or just in general as right now if you use custom policy there is nothing an end user can do to figure that out | 11:03 |
* gibi has to jump on calls | 11:03 | |
*** k_mouza has joined #openstack-nova | 11:05 | |
dtantsur | kashyap: my comment was earlier than gtema's | 11:09 |
dtantsur | I think we should keep revisiting this topic from time to time | 11:09 |
* bauzas goes lunching | 11:15 | |
*** ociuhandu has quit IRC | 11:15 | |
*** rcernin has quit IRC | 11:16 | |
*** ignaziocassano has quit IRC | 11:16 | |
*** ociuhandu has joined #openstack-nova | 11:17 | |
*** sapd1_x has joined #openstack-nova | 11:22 | |
*** ociuhandu has quit IRC | 11:23 | |
*** ociuhandu has joined #openstack-nova | 11:37 | |
*** ociuhandu has quit IRC | 11:42 | |
*** ociuhandu has joined #openstack-nova | 11:42 | |
*** k_mouza has quit IRC | 11:42 | |
*** k_mouza has joined #openstack-nova | 11:45 | |
*** ociuhandu has quit IRC | 11:48 | |
*** sapd1_x has quit IRC | 11:52 | |
*** damien_r has joined #openstack-nova | 11:53 | |
*** ociuhandu has joined #openstack-nova | 12:15 | |
*** ociuhandu has quit IRC | 12:20 | |
sean-k-mooney | dtantsur: you saw my mail pointing out how to use the matrix bridge by the way | 12:20 |
sean-k-mooney[m] | dtantsur: it seam to work pretty well using the web client at app.element.io | 12:21 |
sean-k-mooney[m] | this has been possible for 2-3 years for what its worth | 12:22 |
sean-k-mooney | dtantsur: there is also a bridge to OFTC from matirx too | 12:24 |
*** ociuhandu has joined #openstack-nova | 12:24 | |
sean-k-mooney | gibi: you need to auth with nickserv but make sure its a dm | 12:27 |
gibi | sean-k-mooney: yeah I figured :) | 12:27 |
*** gibi[m] has joined #openstack-nova | 12:32 | |
gibi[m] | . | 12:32 |
gibi | \o/ | 12:32 |
sean-k-mooney[m] | interesting i can see that you are typing in matix | 12:32 |
gibi | me too | 12:33 |
sean-k-mooney[m] | not sure if thats uesful or not but good to know | 12:33 |
gibi | it works pretty well without any extra setup except for the NickServ step | 12:33 |
sean-k-mooney[m] | yep its not always supper responsive but its pretty quick | 12:34 |
sean-k-mooney[m] | also it notes when i miss spell things.... | 12:34 |
gibi[m] | that would be helpful for me too | 12:35 |
gibi[m] | to fix my spellings | 12:35 |
sean-k-mooney[m] | i'm just afraid ill run out of red dots :) | 12:35 |
*** mgariepy has quit IRC | 12:36 | |
lyarwood | which clients are you using? | 12:36 |
sean-k-mooney[m] | https://app.element.io | 12:36 |
gibi | me too | 12:37 |
sean-k-mooney[m] | there are a bunch | 12:37 |
gibi | sean-k-mooney: you can turn off sending typing notification in the preferences | 12:37 |
sean-k-mooney | ah ok that good to know | 12:37 |
sean-k-mooney | matrix also has video and audio chat built in if you want it | 12:38 |
sean-k-mooney | and it look like url previews | 12:38 |
gibi[m] | probably anim gifs too :) | 12:39 |
*** ratailor_ has quit IRC | 12:39 | |
sean-k-mooney | ... probably i guess that the cost | 12: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 serv | 12:42 |
sean-k-mooney[m] | ah there we go | 12:42 |
sean-k-mooney | the qoutes dont look bad in irc | 12:43 |
lyarwood | slightly confused, how do I auth with nickserv if I can't connect? | 12:43 |
gibi | lyarwood: https://github.com/matrix-org/matrix-appservice-irc/wiki/Guide:-How-to-use-Matrix-to-participate-in-IRC-rooms | 12:43 |
sean-k-mooney | you cant connet to the openstack channels | 12:43 |
gibi | lyarwood: open a private message with NickServ and auth there before joining to the room | 12:44 |
sean-k-mooney | you can dm freenods nickserv directly | 12:44 |
sean-k-mooney | you really just need to do the IDENTIFY <nickname> <password> bit | 12:45 |
sean-k-mooney | i havent bother to save my password but i could i guess | 12:45 |
gibi | yeah I only did idenity myself too | 12:45 |
sean-k-mooney | it will just depend on if i use matix or not | 12:45 |
sean-k-mooney | lyarwood: what client do you use for irc | 12:46 |
*** lyarwood[m] has joined #openstack-nova | 12:46 | |
lyarwood | weechat | 12:47 |
lyarwood[m] | finally | 12:47 |
sean-k-mooney | same | 12:47 |
sean-k-mooney | weechat has a matix plugin too | 12:47 |
lyarwood[m] | cool I might check that out later | 12:47 |
sean-k-mooney | i have not tried it but if you wanted to stay in a terminal its an option which is nice | 12:48 |
*** mgariepy has joined #openstack-nova | 12:49 | |
*** lyarwood[m] has quit IRC | 12:53 | |
*** lyarwood[m]1 has joined #openstack-nova | 12:54 | |
*** lyarwood[m]1 is now known as lyarwood[m] | 12:55 | |
*** lyarwood has quit IRC | 12:55 | |
*** lyarwood[m] is now known as lyarwood | 12:55 | |
dtantsur | yeah, I'd rather stick to weechat | 12:57 |
* dtantsur is sad the slack plugin didn't work out for him | 12:57 | |
*** k_mouza has quit IRC | 13:01 | |
*** k_mouza has joined #openstack-nova | 13:03 | |
*** ociuhandu has quit IRC | 13:06 | |
*** ociuhandu has joined #openstack-nova | 13:07 | |
*** jamesdenton has quit IRC | 13:07 | |
*** jamesdenton has joined #openstack-nova | 13:09 | |
*** jamesdenton has quit IRC | 13:09 | |
*** jamesdenton has joined #openstack-nova | 13:10 | |
*** ociuhandu has quit IRC | 13:11 | |
*** ociuhandu has joined #openstack-nova | 13:11 | |
*** ociuhandu has quit IRC | 13:12 | |
*** ociuhandu has joined #openstack-nova | 13:13 | |
gibi | elod: regarding the train-em patch https://review.opendev.org/c/openstack/releases/+/790761 | 13:16 |
gibi | elod: we have some test related patches top of the last release and therefore top of the eol tag | 13:16 |
elod | you mean -em tag :) | 13:17 |
gibi | ooo | 13:17 |
lyarwood | yeah we aren't removing the branch just yet :d | 13:17 |
gibi | this is not eol | 13:17 |
elod | we won't delete train. yet... :] | 13:17 |
gibi | oh | 13:17 |
gibi | sorry | 13:17 |
gibi | I've mixed up | 13:17 |
gibi | then sure no problem | 13:17 |
gibi | /o\ | 13:17 |
gibi | I had coffee but I think it did not helped my brain | 13:18 |
*** ociuhandu has quit IRC | 13:18 | |
elod | it's friday afternoon, isn't it? :D | 13:18 |
elod | same here, actually... maybe it's because of the weather... :] | 13:18 |
gibi | elod: I still need to update ~2 specs before I can leave :D | 13:19 |
elod | :S poor you | 13:19 |
gibi | poor others who have to read what I will type now :D | 13:19 |
elod | :D | 13:20 |
gibi | stephenfin: 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 |
lyarwood | I think he might be AFK today, I've not seen him online. | 13:21 |
*** k_mouza has quit IRC | 13:22 | |
*** k_mouza_ has joined #openstack-nova | 13:22 | |
gibi | ahh, ok | 13:23 |
gibi | btw, Monday is a public holiday in Hungary so I will be off | 13:24 |
*** ociuhandu has joined #openstack-nova | 13:26 | |
bauzas | France too | 13:26 |
bauzas | (Whit Monday) | 13:26 |
gibi | yepp | 13:26 |
*** supamatt has joined #openstack-nova | 13:27 | |
bauzas | and next Friday will be public company holiday at Red Hat | 13:27 |
bauzas | so, short week :( | 13:27 |
*** Underknowledge has quit IRC | 13:39 | |
*** Underknowledge has joined #openstack-nova | 13:40 | |
*** pmannidi has quit IRC | 13:44 | |
*** pmannidi has joined #openstack-nova | 13:46 | |
openstackgerrit | sean mooney proposed openstack/nova master: fix sr-iov support on Cavium ThunderX hosts. https://review.opendev.org/c/openstack/nova/+/777679 | 13:48 |
*** k_mouza_ has quit IRC | 13:55 | |
*** pmannidi has quit IRC | 13:59 | |
*** Underknowledge has quit IRC | 14:04 | |
*** k_mouza has joined #openstack-nova | 14:04 | |
*** pmannidi has joined #openstack-nova | 14:05 | |
*** Underknowledge has joined #openstack-nova | 14:09 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: QoS minimum guaranteed packet rate https://review.opendev.org/c/openstack/nova-specs/+/785014 | 14:09 |
*** k_mouza has quit IRC | 14:09 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: [pps] Move the alternatives to separate section https://review.opendev.org/c/openstack/nova-specs/+/792634 | 14:10 |
*** jangutter_ has joined #openstack-nova | 14:15 | |
*** Underknowledge has quit IRC | 14:17 | |
*** jangutter has joined #openstack-nova | 14:19 | |
*** tbachman has quit IRC | 14:20 | |
*** Underknowledge has joined #openstack-nova | 14:20 | |
*** pmannidi has quit IRC | 14:21 | |
*** tbachman has joined #openstack-nova | 14:23 | |
*** jangutter_ has quit IRC | 14:23 | |
*** Underknowledge has quit IRC | 14:26 | |
*** rpittau is now known as rpittau|afk | 14:27 | |
*** Underknowledge has joined #openstack-nova | 14:27 | |
*** tbachman_ has joined #openstack-nova | 14:44 | |
*** tbachman has quit IRC | 14:45 | |
*** tbachman_ is now known as tbachman | 14:45 | |
*** dklyle has joined #openstack-nova | 14:52 | |
openstackgerrit | Merged openstack/python-novaclient master: Refactor constructing request body https://review.opendev.org/c/openstack/python-novaclient/+/790017 | 14:59 |
*** mlavalle has joined #openstack-nova | 15:05 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix RequestLevelParams persistence handling in RequestSpec https://review.opendev.org/c/openstack/nova/+/791502 | 15:14 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: [func test] create pps resource on OVS agent RP https://review.opendev.org/c/openstack/nova/+/787205 | 15:14 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: [func test] move port creation to the NeutronFixture https://review.opendev.org/c/openstack/nova/+/787206 | 15:14 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: [func test] refactor assertPortMatchesAllocation https://review.opendev.org/c/openstack/nova/+/792458 | 15:14 |
*** ociuhandu has quit IRC | 15:15 | |
*** ociuhandu has joined #openstack-nova | 15:15 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add same_subtree field to RequestLevelParams https://review.opendev.org/c/openstack/nova/+/791503 | 15:18 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Bump min placement microversion to 1.36 https://review.opendev.org/c/openstack/nova/+/791504 | 15:19 |
*** ociuhandu has quit IRC | 15:19 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support same_subtree in allocation_canadidate query https://review.opendev.org/c/openstack/nova/+/791505 | 15:22 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support the new port resource_request format https://review.opendev.org/c/openstack/nova/+/787208 | 15:23 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling https://review.opendev.org/c/openstack/nova/+/791506 | 15:23 |
openstackgerrit | Merged openstack/python-novaclient master: Change minversion of tox to 3.18.0 https://review.opendev.org/c/openstack/python-novaclient/+/791969 | 15:27 |
*** jawad_axd has quit IRC | 15:31 | |
*** k_mouza has joined #openstack-nova | 15:32 | |
*** jangutter has quit IRC | 15:33 | |
*** jangutter has joined #openstack-nova | 15:33 | |
*** ociuhandu has joined #openstack-nova | 15:36 | |
*** jangutter_ has joined #openstack-nova | 15:36 | |
*** jangutter has quit IRC | 15:40 | |
*** ociuhandu has quit IRC | 15:41 | |
*** k_mouza has quit IRC | 15:55 | |
*** lucasagomes has quit IRC | 15:56 | |
*** Underknowledge has quit IRC | 15:57 | |
*** k_mouza has joined #openstack-nova | 15:58 | |
*** Underknowledge has joined #openstack-nova | 15:58 | |
*** eharney has quit IRC | 16:07 | |
*** gmann is now known as gmann_afk | 16:11 | |
*** dtantsur is now known as dtantsur|afk | 16:25 | |
*** tristanC has left #openstack-nova | 16:39 | |
*** derekh has quit IRC | 17:00 | |
*** dave-mccowan has quit IRC | 17:08 | |
*** k_mouza has quit IRC | 17:16 | |
*** andrewbonney has quit IRC | 17:25 | |
*** __ministry has joined #openstack-nova | 17:44 | |
*** __ministry has quit IRC | 17:49 | |
*** bbowen has joined #openstack-nova | 17:58 | |
openstackgerrit | Merged openstack/nova stable/wallaby: libvirt: Remove dead error handling code https://review.opendev.org/c/openstack/nova/+/788724 | 17:58 |
*** bbowen_ has quit IRC | 17:58 | |
*** whoami-rajat has quit IRC | 17:59 | |
*** ociuhandu has joined #openstack-nova | 18:21 | |
*** ociuhandu has quit IRC | 18:27 | |
*** dave-mccowan has joined #openstack-nova | 18:32 | |
*** eharney has joined #openstack-nova | 18:35 | |
*** lbragstad has quit IRC | 18:50 | |
*** coreycb has quit IRC | 18:50 | |
*** ociuhandu has joined #openstack-nova | 18:57 | |
openstackgerrit | Dmitrii Shcherbakov proposed openstack/nova-specs master: Introduce Transport Nodes https://review.opendev.org/c/openstack/nova-specs/+/787458 | 19:02 |
*** ociuhandu has quit IRC | 19:04 | |
*** ociuhandu has joined #openstack-nova | 19:09 | |
*** ociuhandu has quit IRC | 19:15 | |
*** k_mouza has joined #openstack-nova | 19:32 | |
*** k_mouza has quit IRC | 19:37 | |
*** ralonsoh has quit IRC | 19:49 | |
*** supamatt has quit IRC | 21:01 | |
*** artom has quit IRC | 21:10 | |
*** Underknowledge has quit IRC | 21:14 | |
*** david-lyle has joined #openstack-nova | 21:15 | |
*** tosky has quit IRC | 21:15 | |
*** dklyle has quit IRC | 21:15 | |
*** tosky has joined #openstack-nova | 21:16 | |
*** Underknowledge has joined #openstack-nova | 21:16 | |
*** jawad_axd has joined #openstack-nova | 21:43 | |
*** jawad_axd has quit IRC | 21:52 | |
*** jawad_axd has joined #openstack-nova | 21:52 | |
*** rpioso has quit IRC | 21:54 | |
*** csatari has quit IRC | 21:54 | |
*** knikolla has quit IRC | 21:56 | |
*** jawad_axd has quit IRC | 21:57 | |
*** knikolla has joined #openstack-nova | 21:59 | |
*** rpioso has joined #openstack-nova | 21:59 | |
*** csatari has joined #openstack-nova | 21:59 | |
*** ociuhandu has joined #openstack-nova | 22:02 | |
*** ociuhandu has quit IRC | 22:11 | |
*** jawad_axd has joined #openstack-nova | 22:23 | |
*** jmlowe has quit IRC | 22:45 | |
*** jmlowe has joined #openstack-nova | 22:48 | |
*** jawad_axd has quit IRC | 22:57 | |
*** tosky has quit IRC | 23:03 | |
*** k_mouza has joined #openstack-nova | 23:32 | |
*** k_mouza has quit IRC | 23:36 | |
*** viks____ has quit IRC | 23:42 | |
*** mlavalle has quit IRC | 23:57 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!