Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
15:30:32 bauzas artom: does a live migration work with two different compute versions already ?
15:30:34 openstackgerrit Merged openstack/nova master: Move placement test cases from db to placement https://review.openstack.org/553149
15:30:40 mriedem bauzas: yes
15:30:48 mriedem we support mixed version computes for live migration
15:30:49 artom bauzas, I didn't see anything in the code that would suggest it wouldn't
15:30:58 bauzas mriedem: context is https://review.openstack.org/#/c/552722/6/specs/rocky/approved/numa-aware-live-migration.rst@244
15:30:59 sean-k-mooney[m] linux bridge, sriov, hardware offloaded ovs, vpp, iovision(ebpf), mini net, calico and macvtap are the main ones used beyond ovs/ovs-dpdk
15:30:59 mriedem we have a grenade + live migratoin job that also does this back and forth
15:31:25 bauzas mriedem: then, I was claiming we could microversion the behavioural change artom is going to introduce
15:31:26 sean-k-mooney[m] oh there is also snabb switch
15:31:27 mriedem that's a bit drastic
15:31:32 artom bauzas, also, we'd only fail it if the instance has "NUMA" characteristics
15:31:36 mriedem sec
15:31:50 artom Which is currently broken anyways, so not as drastic as it sounds
15:31:55 mriedem see https://review.openstack.org/#/c/522537/13/nova/conductor/tasks/live_migrate.py
15:31:55 bauzas artom: I agree, and we don't test that AFAIK
15:32:06 mriedem you only need to know if the source and dest computes can do the new hotness
15:32:35 mriedem otherwise it's a novalidhost if you can't find a pair
15:32:42 bauzas mriedem: yeah I remember that change
15:33:29 sean-k-mooney[m] stephenfin: on and NTT have a dpdk soft patch panel thing , the point is nova cant have special case code for all of these
15:35:21 bauzas mriedem: if the implementation of artom's spec would go into that direction, then yes we wouldn't need a microversion
15:35:35 mriedem i think we can agree that we don't want to add subnet to the requested network turducken in the compute api https://review.openstack.org/#/c/518227/
15:37:11 bauzas mriedem: oh please, yes
15:37:33 bauzas just create the port in neutron and pass it to nova
15:37:50 bauzas aha, jinxed by mriedem's comment
15:37:58 artom mriedem, that link you posted in my NUMA migration spec, that's basically just checking min compute version, right?
15:38:04 artom So the same thing I was suggesting?
15:38:35 artom Just for clarity in my head, because I feel like we're talking about the same thing as though they were different
15:39:00 gibi jaypipes: I'm open to debate to simulate or not the neutron backend ordering preference via a scheduler weigher but for that debate we need some neutron heavy guys, like mlavalle
15:39:45 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Handle nested providers for allocation candidates https://review.openstack.org/556873
15:39:47 bauzas artom: yeah basically
15:39:55 bauzas artom: it's for a different usage tho
15:39:56 jaypipes mriedem, bauzas: ^^ added not about microversion.
15:40:05 artom bauzas, right, but the mechanism is the same
15:40:08 stephenfin sean-k-mooney[m]: Well damn. That's unfortunate
15:40:08 kashyap Darn, lost edits to wiki.openstack.org, as it logged me out mid-way. And didn't give me a way to get the changes back.
15:40:27 bauzas artom: yup, the pattern should be the same
15:40:29 artom (We might eventually standardise that in a utils somewhere, since we seem to be doing a lot of it, btw)
15:40:39 mriedem artom: kind of, but it depends on where you're using it,
15:41:01 mriedem if it's the API and you're checking min compute service version across the entire cell, that's different than just comparing the source and candidate dest host
15:41:16 bauzas at least, we can assume we run a pre-flight check on the conductor that checks both compute versions
15:41:27 bauzas that could be generalized
15:41:38 artom mriedem, ah, so you're saying we should be more granular and just check the (source, dest) pair
15:41:41 artom Hrmm
15:41:46 artom Could we do that in the scheduler?
15:41:48 mriedem artom: yes, see that patch i linked
15:41:51 bauzas but that's an implementation detail, IHMO
15:41:58 artom So that straight away we have a dest that supports it?
15:42:07 mriedem artom: we could if we exposed the capability as a trait on the compute and added a pre-request filter
15:42:19 bauzas artom: the scheduler doesn't know whether it's a migration or a boot
15:42:26 bauzas but what mriedem wrote
15:42:34 mriedem artom: that would be an optimization imo
15:42:40 mriedem worth noting in the spec though
15:42:41 bauzas zactly
15:42:45 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660
15:42:45 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472
15:42:46 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820
15:42:46 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819
15:42:54 artom Mmmm, forbidden traits
15:42:58 artom /homer
15:42:59 gibi mriedem: I will be available during the notification subteam meeting timeslot or before that but I have nothing to really talk about so we can simply skip the meeting if you agree
15:43:11 SamYaple so i just ran into an annoying time consuming issue. i was going an upgrade and my nova-osapi_compute service changed to reporting its hostname to the database. this created new nova-osapi_compute services in the services table. the old service entires had version 9 and this was causing all GETs to instances to fail with instance not found
15:43:20 SamYaple code in question https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/compute/api.py#L2268
15:43:31 SamYaple no logs anywhere describing the issue :/
15:43:52 mriedem gibi: yes let's skip
15:44:01 SamYaple would a check for old osapi_compute service versions be appropriate to add to `nova-status upgrade check` ?
15:44:12 gibi mriedem: ack, let's focuse on spec reviews
15:44:17 artom mriedem, bauzas, the optimization would be the scheduler doing the version checking? And for now we let the conductor do it?
15:44:52 bauzas jaypipes: should we also discuss in https://review.openstack.org/#/c/556873/2/specs/rocky/approved/nested-resource-providers-allocation-candidates.rst about how the scheduler would pass the root RP ?
15:45:10 bauzas jaypipes: because atm, it just says "which compute node is having that UUID ?"
15:45:15 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
15:45:15 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
15:45:16 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857
15:45:17 jaypipes gibi: I'm happy to speak with mlavalle or anyone else about this. I just feel like the network-bandwidth spec has gotten way over-engineered.
15:45:34 mriedem SamYaple: a bit confused,
15:45:41 mriedem you said it started creating service entries in the db,
15:45:46 mriedem but that there were also old entries?
15:46:13 mriedem SamYaple: also, this sounds vaguely familiar to https://review.openstack.org/#/c/556670/
15:46:18 gibi jaypipes: I understand that it is a long spec and this part of it seems minor
15:46:20 mlavalle jaypipes, gibi: I am planning to go over the spec today
15:46:52 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Make everything work with Python 3 https://review.openstack.org/556894
15:46:52 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Remove 'tools/releasenotes_tox.sh' https://review.openstack.org/534383
15:46:52 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Speed things up and document them https://review.openstack.org/534382
15:46:56 jaypipes bauzas: the scheduler simply does a ComputeNode.get_all_by_uuid(), passing all the UUIDs of all providers it sees in the provider_summaries section of the allocation_candidates response. Nothing about that will be changing.
15:47:11 mlavalle I also have the impression that we can / should simplify a bit, jaypipes
15:47:15 mriedem SamYaple: at this point, if not CONF.cells.enable and we're in here https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/compute/api.py#L2268 we likely should be puking out a warning
15:47:16 jaypipes gibi: no, it's not the length of the spec that I have issues with.
15:47:18 bauzas jaypipes: sec
15:47:29 jaypipes mlavalle: it's the crossing of scope boundaries that I have issue with.
15:47:35 SamYaple mriedem: http://paste.openstack.org/show/715421/
15:47:40 gibi mlavalle: cool, then could you please add your view about the backend selection in https://review.openstack.org/#/c/502306/21/specs/rocky/approved/bandwidth-resource-provider.rst@610
15:48:00 SamYaple the first three services inthat list were the originals. i deleted them and everything started working
15:48:08 bauzas jaypipes: say some child RP is accepting the query, the placement API call to allocation_candidates will return the root RP UUIDs in the provider_summaries ?
15:48:28 bauzas jaypipes: is that already the case or is that requiring some implementation change ?
15:48:35 jaypipes gibi: the thing we are attempting to consume is a chunk of network (ingress or egress) bandwidth for a physical network. I don't really see how vNIC type nor network "backend" selection is relevant to that.
15:48:37 bauzas because I want to understand what's missing
15:48:38 gibi mlavalle: if we want to have what is described in that subsection then we have to convince jaypipes to have backend specific traits in the RP tree
15:48:53 jaypipes bauzas: yes. and it already does that.
15:48:57 SamYaple mriedem: with the old services not deleted, GETs on instances (nova show's) would fail
15:48:58 bauzas \o/

Earlier   Later