Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-31
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
16:15:00 gibi if changing the order does not mean that we update the d-o-t on the old volume attachment the swap that with a new attachement with default d-o-t then I'm OK with it
16:15:04 dansmith or go back to what I had, which was swap or d-o-t, but not both, although I definitely get the argument that you'd expect to be able to update all at once
16:15:31 dansmith gibi: I think because it looks up the BDM and updates it with the new volume that it should be fine
16:16:40 gibi OK, then I suggest to do the reordeing. If swap fails then we need to accept a partial PUT
16:16:47 gibi as swap is async
16:16:51 dansmith ack
16:16:59 dansmith gibi: by the way, on your comment about the notification test,
16:17:19 dansmith when enabling debug, I did not see the compute manager code logging the messages that should have come out
16:17:44 dansmith so I'm not sure the compute manager code is really running, even though that *seems* to be where the finish notification comes from
16:17:50 gibi with 2.85 you don't as the whole test failed before the compute had a chance to progress with the message
16:18:05 dansmith but I ran out of time trying to trace that down and the logs weren't coming..
16:18:14 dansmith ahh, that makes sense
16:18:35 gibi yeah, it was not a trivial thing. I spent at least an hour figuring it out why it behaves differently
16:18:56 dansmith the notification stuff is too confusing in general so I didn't trust myself
16:19:13 dansmith and with no logs from compute manager... I tried putting castascall on there, butI got many more errors
16:19:50 dansmith gibi: can you check my reply here? https://review.opendev.org/#/c/693828/22/nova/api/openstack/compute/schemas/volumes.py
16:19:55 gibi looking
16:21:14 gibi dansmith: you copy the POST req schema, but that is different from the schema of the GET response
16:21:47 gibi if we want that the client GET the current attachment, change a field in it, then PUT it back, then PUT needs to accept the format of the GET response

Earlier   Later