Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
15:24:13 jaypipes bauzas: yes. new CONF option, new way of behaving for the virt drivers. I would say yes.
15:24:35 openstackgerrit Merged openstack/nova master: tox: Remove unnecessary configuration https://review.openstack.org/556544
15:26:09 sean-k-mooney[m] stephenfin: most backend wont that this info so vhost-user is not something we should build on
15:26:36 stephenfin sean-k-mooney[m]: What other backends would there be?
15:26:54 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384
15:26:57 sean-k-mooney[m] stephenfin: for example kernel ovs with kernel vhost has kerne vhost-treads it spwans per interface, it dose not have pmds, so while we can taskset those threads we cant affinites them via looking a queues
15:27:18 bauzas jaypipes: fine by me
15:27:51 bauzas artom: had some concerns about the virt driver "calling" the conductor in https://review.openstack.org/#/c/552722/6
15:28:24 artom bauzas, replied on the patch, but we can continue here if you want. Basically, no new calls are added, it's just existing methods/returns with new data in them
15:28:30 bauzas artom: maybe I misunderstood but you mean that the compute service would call back the conductor ?
15:28:30 artom Should I clarify the spec?
15:28:31 alex_xu_ kashyap: np
15:28:45 bauzas artom: that would help
15:29:03 edmondsw mriedem I don't remember ever discussing a service-protected-server case in our RBAC discussions, but I don't think you need to use service tokens there... just have a role that's given permission to manage these
15:29:12 sean-k-mooney[m] stephenfin: in any case queue mapping or tasksetting of vhost threads i think is out of scope of nova
15:29:26 edmondsw that spec needs a lot of work if anything's to happen there
15:30:10 bauzas artom: also, on the fact we would check the compute version
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

Earlier   Later