| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-31 | |||
| 13:00:14 | bauzas | and say that we need to work on a solution in V or W | |
| 13:00:18 | johnthetubaguy | sean-k-mooney: till they remove it, yep | |
| 13:00:41 | johnthetubaguy | not saying its bad, just different | |
| 13:00:47 | johnthetubaguy | they have a different context | |
| 13:01:42 | johnthetubaguy | sounds like if we wait a few more releases, it will sort its-self out one way or the other | |
| 13:01:44 | sean-k-mooney | yes and no, they have a different approch. we have similar but not idential scopes. they do applciation lifecyle management better and openstack is better sutied to infrastuture | |
| 13:01:48 | johnthetubaguy | like gibi said, maybe the cost isn't that high | |
| 13:02:05 | johnthetubaguy | sean-k-mooney: agreed | |
| 13:02:45 | johnthetubaguy | personally, running something on every compute node sounds a lot like starting up n-cpu | |
| 13:02:58 | johnthetubaguy | so really we just shouldn't do that kind of thing | |
| 13:03:37 | sean-k-mooney | well if your calling if FFU | |
| 13:03:48 | sean-k-mooney | i like how kolla-ansible does there upgrades | |
| 13:03:52 | johnthetubaguy | so we need some comprimise where the easy thing (just reshape after upgrade) works for most folks, and the last few folks have some workaround (supply info about the shape of their hosts to some nova-manage) | |
| 13:03:59 | johnthetubaguy | but that's just my take | |
| 13:04:07 | bauzas | gibi: I know you're on a meeting, but do we already have an etherpad for the virtual Victoria PTG ? | |
| 13:04:20 | gibi | bauzas: yes, https://etherpad.openstack.org/p/nova-victoria-ptg | |
| 13:04:24 | bauzas | thanks | |
| 13:04:53 | sean-k-mooney | gibi: one thing i think we need to plan for are some cross project sessions too | |
| 13:05:27 | gibi | sean-k-mooney: true. Do you have topic for cross-project discussion? | |
| 13:05:51 | sean-k-mooney | not specifcally but i was concerned that that topic had not come up | |
| 13:05:58 | gibi | sean-k-mooney: I think you can simply add that to the current etherpad (just start a new section that indicate that this is a cross project topic that needs anohter team) | |
| 13:06:21 | gibi | you mean people are not thinking about cross project topics because there is no place to put them? | |
| 13:06:22 | sean-k-mooney | ther are things like the unified limits work johnthetubaguy et al are working on that i think needs to continue but i did not really have anything i wanted to drive | |
| 13:07:05 | sean-k-mooney | gibi: i think when we talk about a virtual ptg many teams are just thinking about there team, not the collabative cross team stuff we also do at the ptg | |
| 13:07:11 | gibi | sean-k-mooney: OK, I hope the affected people will propose topics | |
| 13:07:53 | bauzas | that reminds me I have to provide my toughts on two ML threads from gibi | |
| 13:10:15 | gibi | sean-k-mooney: added a Cross project topics section | |
| 13:11:20 | sean-k-mooney | gibi: one topic that comes to mind actully is the schduling supprot for routed networks | |
| 13:11:30 | sean-k-mooney | or network aware schduling in general | |
| 13:11:51 | sean-k-mooney | that said im not sure i plan to work on that in the near term so im not going to add it | |
| 13:12:07 | sean-k-mooney | but i know the neuton team are interested in that topic | |
| 13:13:12 | gibi | sean-k-mooney: ack, that is actually one thing I can add as I started looking at that from nova perspective | |
| 13:15:14 | gibi | sean-k-mooney: added one item for routed nets | |
| 13:16:15 | sean-k-mooney | gibi: cool, i kind of wrote up how i think it should work in the comment on matts poc | |
| 13:16:36 | sean-k-mooney | but that was more involed then the minium viable change | |
| 13:17:46 | gibi | sean-k-mooney: if you have input then do not hesitate to write it up, I kept that patch on the minimum viable change level but we can agree to do a bigger change in V | |
| 13:18:02 | gibi | sean-k-mooney: my idea was that the current minimum viable patch does not need neutron change | |
| 13:18:05 | sean-k-mooney | unless you are doing sriov nova just assumes that the destination host will be able to support the networking that is requested. this has always been the case and has worked because for the most part ops make there vxlan and vlans span the datacenter but it has never really been a correct assumtion to make. | |
| 13:19:42 | johnthetubaguy | routed networks make the opposite assumption, you usually don't get to pick the IP until you know where has compute resources (unless you are re-using a port, when there are other issues in play). | |
| 13:20:11 | sean-k-mooney | johnthetubaguy: correct and nova currently is not aware of those constraints | |
| 13:20:34 | sean-k-mooney | which is why live migration basially does not work unless you spcify a host in the same segment | |
| 13:20:50 | johnthetubaguy | yeah, only does a safety check | |
| 13:21:17 | sean-k-mooney | my toughts on the topic are partly summerised in https://review.opendev.org/#/c/656885/ in my top comment on 25 of feb | |
| 13:21:20 | johnthetubaguy | live-migration scheduling is an interesting one... I don't really see a use case for it, but I hey. | |
| 13:22:00 | sean-k-mooney | johnthetubaguy: you dont see a usecase for allowing live migration to move the vm to another host in the same network segment where it can keep its ip | |
| 13:23:10 | johnthetubaguy | operationally, for our customers, its super rare you want it "to go somewhere the scheduler picks", sure we can make up cases where its needed | |
| 13:23:45 | sean-k-mooney | well that is the oppisite feedback we are geting from the neutron folks | |
| 13:24:07 | johnthetubaguy | I think there is a bigger issue there, you want to define live-migratable pools, etc, etc. | |
| 13:24:18 | johnthetubaguy | well I look forward to better understanding those folks use cases | |
| 13:25:06 | sean-k-mooney | johnthetubaguy: yes i tired to adress the more generic case to include vlan awarenes and ip pools modeled in placment in my comment | |
| 13:26:39 | sean-k-mooney | basically using placment aggreates to model pool affinity with sharing resouce providers modelign ip capsity,vlan/vxlan ids(as segmenation_ids) ectra and traits modeling the type of network | |
| 13:27:15 | johnthetubaguy | I still think folks most likely want host aggregate style live-migratable "zones", etc | |
| 13:29:50 | sean-k-mooney | well peole used to use AZs for that to take advandgte of the fact we dont migrate across AZs by defualt | |
| 13:30:14 | gibi | johnthetubaguy, sean-k-mooney: It would be good to get feedback on the use cases I collected as functional tests https://review.opendev.org/#/c/656885/7/nova/tests/functional/test_servers.py and https://review.opendev.org/#/c/711071/1/nova/tests/functional/test_servers.py | |
| 13:30:39 | sean-k-mooney | johnthetubaguy: but that is essically what you would get, the vm would migrate withing the placmenet aggreate with the current poc | |
| 13:31:03 | sean-k-mooney | e.g. the placment aggreate created by neutron that mapes to the ip segment | |
| 13:32:22 | johnthetubaguy | sean-k-mooney: targeting a placement aggregate rather than a host, with some way of defaulting to the "current" live-migration tagged placement aggregate, would be crazy useful, but its not just network concerns | |
| 13:33:07 | johnthetubaguy | I have a bunch of use cases around that area, but often its independent of xvlan reach, etc. | |
| 13:39:32 | pooja_pf9 | Hello.. has anyone run into this os-brick issue with multipath failure reported in https://bugs.launchpad.net/nova/+bug/1414527? | |
| 13:39:33 | openstack | Launchpad bug 1414527 in OpenStack Compute (nova) "The multipath device descriptors remove failed when the volume has partition" [Undecided,Confirmed] | |
| 13:40:09 | pooja_pf9 | Is there any known workaround for this issue or plan to fix it in nova? | |
| 13:54:52 | huaqiang | stephenfin: my new patches are based on your patches, I haven't changed most of them, but my operations changed the commit hash for most of your pathes, | |
| 13:55:02 | huaqiang | hope it will not trouble you | |
| 14:12:00 | sean-k-mooney | johnthetubaguy: yes it also matters for storage/cinder az and well jsut general falut domains although you can model that via host aggregates | |
| 14:12:41 | dansmith | brinzhang: are you addressing feedback on that patch? | |
| 14:13:11 | sean-k-mooney | johnthetubaguy: what i wanted to do was build on the resouce requests in the neutron port and have neutron pass traits and aggreates as constratins via the same mechanisum | |
| 14:17:12 | johnthetubaguy | sean-k-mooney: sure, it just seems boring compared to the wider use cases | |
| 14:18:18 | artom | Anyone seens https://zuul.opendev.org/t/openstack/build/e0e47deeb33b476db792fd8b83680fbb before? | |
| 14:18:27 | artom | rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1] | |
| 14:18:27 | artom | rsync: link_stat "/var/lib/zuul/builds/e0e47deeb33b476db792fd8b83680fbb/work/ca-bundle.pem" failed: No such file or directory (2) | |
| 14:18:27 | artom | Warning: Permanently added '198.72.124.121' (ECDSA) to the list of known hosts. | |
| 14:18:46 | artom | Asking here because... not really sure where Zuul job questions belong | |
| 14:19:05 | artom | I guess I'm doing something wrong in my .zuul.yml | |
| 14:22:11 | sean-k-mooney | no i dont think that is related to your job | |
| 14:22:31 | sean-k-mooney | i think its an issue win one of the other playbooks | |
| 14:39:38 | artom | sean-k-mooney, inorite? | |
| 14:39:49 | artom | Except it's consistently reproducible | |
| 14:51:12 | spatel | sean-k-mooney: is it possible that SR-IOV support security group? (i did google and didn't find any vendor who provide that card/nic) | |
| 14:54:12 | openstackgerrit | Merged openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls. https://review.opendev.org/704227 | |
| 14:54:21 | openstackgerrit | Corey Bryant proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages https://review.opendev.org/716328 | |
| 14:54:46 | sean-k-mooney | the nics dont in generally but you can sometimes use a heriachical port binding driver to implement security groups at the top of rack switch | |
| 14:55:45 | sean-k-mooney | if your using hardware offloade ovs which use ovs as the contol plane and sriov as the dataplane then it can technically do security groups | |
| 14:55:55 | sean-k-mooney | but normally if you use sriov then no | |
| 14:58:11 | spatel | sean-k-mooney: thanks for the explanation :) | |
| 15:12:54 | openstackgerrit | Merged openstack/python-novaclient master: Update to hacking 3.0 https://review.opendev.org/716228 | |
| 15:14:42 | gibi | sean-k-mooney: do you happen to know if we support booting with UEFI + PXE over IPv6? | |
| 15:14:57 | sean-k-mooney | in ironic? | |
| 15:15:10 | gibi | in nova + libvirt + qemu kvm | |
| 15:15:14 | sean-k-mooney | gibi: i dont think we support pxe boot in nova | |
| 15:15:41 | sean-k-mooney | gibi: i know we can enable the boot menu but i dont think we support pxe booting officaly | |
| 15:16:20 | gibi | thanks | |
| 15:38:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add microversion 2.85, extra spec validation https://review.opendev.org/708436 | |
| 15:38:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs https://review.opendev.org/716222 | |
| 15:38:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037 | |
| 16:10:58 | dansmith | gibi: around? | |
| 16:11:14 | gibi | dansmith: yes | |
| 16:11:43 | dansmith | gibi: "doh" and "duh" on the rpc cast, thanks for that | |
| 16:12:17 | dansmith | gibi: what do you want to do about it? we can move the non-swap parameter updates before the swap | |
| 16:12:52 | dansmith | which means we'll update those values and then if the swap fails, we will have made part of the changes but not all, but given how swap works, there isn't much choice | |
| 16:14:27 | gibi | hm hm | |