Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-13
16:48:45 gibi mriedem: I have to run now but if the problem still open then I can look at it again tomorrow
17:04:50 hegemoOn hello there
17:05:04 hegemoOn is it possible to define the number of queue in an image metadata
17:05:15 hegemoOn when using virtion-scsi ?
17:09:05 mriedem stephenfin: on https://review.openstack.org/#/c/531413/ - i think i might decouple the re-wording part so we can backport that, since i see some other config guide docs that reference that option
17:11:00 stephenfin mriedem: Sure thing. The reservation was because we haven't removed deprecated aliases before, that I'm aware of (there's little cost in keeping them). Worth making sure it was intentional
17:11:13 mriedem i'm sure we've removed deprecated aliases before
17:11:29 mriedem maybe not recently, but it was pretty common cleanup back in the day
17:12:01 stephenfin :D
17:12:15 stephenfin numa-aware-vswitches has me plenty busy :)
17:14:44 hegemoOn in virsh xml you have <driver queues='n'>
17:14:56 hegemoOn for virtio-scsi
17:15:09 hegemoOn i cannot see a way to define n in nova
17:16:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix and update compute schedulers config guide https://review.openstack.org/544010
17:19:28 openstackgerrit Chris Dent proposed openstack/nova master: Move db MAX constants to own file https://review.openstack.org/543469
17:21:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove the deprecated scheduler_driver_task_period option https://review.openstack.org/531413
17:21:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Clarify the help text for [scheduler]periodic_task_interval https://review.openstack.org/544015
17:24:50 stephenfin mriedem: Should I have +Wd this, given that you've a -2 on the following patch? https://review.openstack.org/#/c/539738/
17:25:00 stephenfin I can rebase and take it out of the gate if not
17:25:32 mriedem it's a bug fix
17:25:35 mriedem so i don't think so
17:25:48 stephenfin Phew. Okidok
17:25:53 mriedem i mean, it's not a problem
17:27:57 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove warning in feature support matrix page https://review.openstack.org/544017
17:30:59 openstackgerrit Matt Riedemann proposed openstack/nova master: Check for leaked server resource allocations in post_test_hook https://review.openstack.org/538510
17:31:14 openstackgerrit James E. Blair proposed openstack/python-novaclient stable/ocata: Zuul: Remove project name https://review.openstack.org/544018
17:32:00 openstackgerrit Merged openstack/nova stable/pike: Query all cells for service version in _validate_bdm https://review.openstack.org/541036
17:33:03 openstackgerrit Eric Berglund proposed openstack/nova master: Use correct arguments in task inits https://review.openstack.org/543571
17:34:42 mriedem lyarwood: dansmith: bauzas: so before i request the next pike release, do i have to bump the minor version to 16.1.0 for https://review.openstack.org/#/c/528330/ because it's a schema migration; i will forever remember the red hat product team lashing i got for *not* doing something like that back in newton
17:35:49 dansmith um
17:35:51 dansmith okay
17:36:02 dansmith bump the minor _to_ what?
17:36:10 mriedem 16.0.4 -> 16.1.0
17:36:15 dansmith oh I see
17:36:18 mriedem i would normally just do 16.0.5
17:36:23 mriedem but caught hell for doing that once
17:36:24 dansmith I don't think I know anything about that
17:40:47 mriedem alright 16.1.0 it is https://review.openstack.org/#/c/544020/
18:29:43 lyarwood mriedem: 16.1.0 is fine by me, this is still an optional schema migration until queens anyway right so anyone not running migrations after updating nova during stable/pike will pick it up when they upgrade to queens.
18:31:15 lyarwood mriedem: FWIW with TripleO/RDO I can't see us ever running schema migrations with each minor update (16.0.4 to 16.1.0 etc)
18:31:48 dansmith lyarwood: apparently a minor version change kicks the "do the db sync" flag on
18:32:21 lyarwood dansmith: not in any of our tooling
18:32:32 lyarwood dansmith: just the poor ops guy who notices the change
18:32:46 dansmith lyarwood: supposedly bauzas beat up mriedem about it last time on that basis
18:34:29 lyarwood owalsh: ^ re minor updates on TripleO, we don't run schema migrations at all right?
18:35:30 dansmith if not then bauzas should pay for mriedem's therapist bills
18:35:50 lyarwood dansmith: I can only assume his point was that we should still highlight to ops etc that the update contains a schema migration by bumping the minor release or something
18:39:49 owalsh lyarwood: correct, just restart services
18:40:11 lyarwood owalsh: cool thanks
18:40:24 dansmith death match round 2, dublin
18:53:36 mriedem fork in the kidneys, check
19:55:15 openstackgerrit Merged openstack/nova master: Replace Chinese quotes to English quotes https://review.openstack.org/543349
19:56:31 dansmith efried: jaypipes: seen the question on this? https://review.openstack.org/#/c/540111/3
19:56:45 dansmith I was about to reply, but then realized I was misunderstanding his concern and I think it's probably valid
19:57:06 dansmith hoping that there's some detail of how you see that working that wouldn't actually break it
19:57:46 efried dansmith: It's been on my list to look at, but was rapidly getting buried. Thanks for bringing it back to the top. Looking....
19:58:58 mriedem been wondering the same type of thing with traits,
19:59:12 mriedem the ironic driver will blow away any traits that aren't on the ironic node
19:59:16 mriedem rather than try to merge the
19:59:18 mriedem *them
19:59:27 dansmith well, there needs to be some amount of that I think,
19:59:36 dansmith although we can't blow them all away in this case I think
19:59:49 dansmith was hoping there was some "only blows away at the given level" detail or something
20:00:09 efried mriedem: I remember that being discussed at length (for ironic traits), and the conclusion in that case was that the ironic inspector was the Source Of Truth, so it was kosher to blow away anything that crept in from elsewhere.
20:00:26 mriedem idk, it seems quite limiting
20:00:41 dansmith efried: it is for sure until the compute service starts needing to do some too, like for capabilities
20:00:52 mriedem if we have an external system to model resources that other services outside of nova can interact with, it seems wrong to completely trample them
20:00:53 dansmith in that case compute might be able to do its own merging,
20:01:05 dansmith but for this inventory thing, nic bandwidth is probably a good example
20:01:06 mriedem dansmith: yeah that's what i had to do in my poc patch for the capabilities thing
20:01:10 dansmith yeah
20:01:29 efried So I agree that we don't want to make it a rule that virt blows away children it doesn't recognize.
20:01:32 dansmith so maybe for this we could get the inventory from the vif modeling somehow?
20:01:44 mriedem trying to balance the stance we've had in the past against things like metrics providers in-tree saying that's all best served outside of nova,
20:01:54 efried But the design (and imple) is flexible enough that we don't need to make that rule at this level.
20:02:00 efried s/impl/implementation/
20:02:03 mriedem and now we appear to have something that's outside of nova for external services, but we're saying we'll overwrite what they do
20:02:05 efried vay
20:02:25 efried (Sorry, that was /me frustrated at own inability to spell, twice)
20:02:37 efried Okay, I get the concern.
20:02:50 dansmith efried: so you're saying I can have a child of compute node and the update_tree() won't blow those away, just inveentory for the level I'm updating, yeah?
20:02:58 openstackgerrit Merged openstack/nova master: Invalid query parameter could lead to HTTP 500 https://review.openstack.org/539164
20:03:32 efried dansmith: We'll make placement look *exactly* like whatever comes out the other side of update_provider_tree.
20:03:41 efried But I still think that's okay.
20:04:03 dansmith efried: not if that means we blow away stuff we didn't return.. so now I'm confused
20:04:10 efried Because 1) virt gets to be the (primary) source of truth for the provider tree rooted at the compute node.
20:04:33 efried And 2) virt kinda needs to know whether there's some other entity "out there" that's allowed to mess with some level of its tree.
20:04:49 dansmith well, that's what I'm saying,
20:04:51 efried If it knows that, then it can preserve those pieces of the tree unchanged.
20:04:53 dansmith if we go that route,
20:05:07 efried Because it receives them as part of the tree it gets on input.
20:05:15 dansmith then we need to have the virt drvier capable of collecting external things we support, like bandwidth on a nic
20:05:20 efried nononono
20:05:22 dansmith oh,
20:05:31 efried It doesn't need to be able to collect them, cause we already gave it to... yeah.
20:05:32 dansmith you're saying ProviderTree already has the child things,
20:05:37 efried yes, exactly.
20:05:43 dansmith that's the confusion though:
20:05:45 efried It has the whole picture as Placement knows about it right now.
20:05:58 efried ...at least the picture that's rooted at the compute host RP.

Earlier   Later