| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-13 | |||
| 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. | |
| 20:06:20 | dansmith | does ProviderTree.update(<not including things that were in the child>) blow those away? or are you saying the virt driver needs to look and include those things in its update? | |
| 20:07:24 | efried | ProviderTree.update_[thingy](rp_uuid) for thingy in (inventory, traits, aggregates) will replace thingy for just the RP indicated by rp_uuid. | |
| 20:07:50 | efried | E.g. if you replace inventory via that method, but not traits, then traits stay whatever they were before. | |
| 20:08:02 | efried | Also, those update_* methods don't muck with children. | |
| 20:08:06 | dansmith | yeah but that's not the question | |
| 20:08:12 | dansmith | okay, _that_ is the quesation | |
| 20:08:19 | dansmith | whether update() touches the children | |
| 20:08:22 | dansmith | um | |
| 20:08:26 | dansmith | "affects the children" | |
| 20:08:28 | efried | To muck with hierarchy, you have to ProviderTree.remove(), .new_root(), .new_child()... | |
| 20:08:33 | efried | There is no update(). | |
| 20:08:39 | dansmith | I know, I'm saving letters | |
| 20:08:45 | dansmith | I think that's his question | |
| 20:08:54 | dansmith | so I had assumed it would only affect the level you're on, and was replying, | |
| 20:09:04 | dansmith | but then re-read the bit of your text he's taking exception to and wasn't sure | |
| 20:09:10 | dansmith | so I think you just need to tighten that up a smidge | |
| 20:09:42 | efried | Okay. That's a true statement ("...only affects the level you're on"). *except* that if you .remove(rp), you also remove all of rp's descendants. That's what the sentence is saying. | |
| 20:09:48 | dansmith | sure | |
| 20:09:50 | dansmith | and, | |
| 20:10:15 | dansmith | I was going to say that if the compute node thinks it needs to remove its provider, then it _should_ affect the external thing that still thinks it is reporting resources for that provider | |