| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-07 | |||
| 19:50:22 | mriedem | pick your poison | |
| 19:51:07 | mriedem | it's probably premature to say in a release note what our minimum required version of placement is at this point | |
| 19:51:08 | efried | mriedem Nice. But FYI, I believe that ship already sailed. | |
| 19:51:11 | mriedem | since that's likely to change | |
| 19:51:28 | efried | That's what we discovered with that grenade bug. | |
| 19:51:46 | mriedem | so we currently say we require 1.10 | |
| 19:51:54 | mriedem | what do we actually require? | |
| 19:52:01 | mriedem | or were we just using 1.10? | |
| 19:52:02 | efried | Yuh, that's a lie at this point. I believe it's 1.14. | |
| 19:52:10 | mriedem | yes, ^ requires 1.14 | |
| 19:52:12 | mriedem | my point is, | |
| 19:52:24 | mriedem | was anything in nova before this change using something higher than 1.10? | |
| 19:52:29 | mriedem | because if not, grenade was doing it's job | |
| 19:52:30 | efried | Oh, I thought it was the patch before that one. Never mind, you're right. | |
| 19:52:59 | efried | Does that mean cdent's change was incorrect? | |
| 19:53:01 | mriedem | we are essentially side stepping any form of version discovery still with placement and doing the ironic thing and saying you just have to have external services upgraded first, period | |
| 19:53:13 | mriedem | not necessarily, | |
| 19:53:21 | mriedem | we'll need grenade upgrading things for us to have sane CI | |
| 19:53:32 | mriedem | e.g. queens nova doesn't test against pike cinder | |
| 19:54:11 | efried | mriedem So what are our actual options here, since we don't yet know what the minimum microversion will be? We create the reno with 1.14 and just remember to bump it with each patch that uses something higher? | |
| 19:54:16 | mriedem | i think my point is just we aren't doing a good job about being careful with versions | |
| 19:54:34 | mriedem | unlike we do with other external services | |
| 19:54:57 | mriedem | regarding a release note, i said i think that's premature right now | |
| 19:55:04 | mriedem | since it's likely to bump again before we release queens | |
| 19:55:15 | mriedem | so https://github.com/openstack/nova/blob/master/nova/cmd/status.py#L202 needs to change in a follow up | |
| 19:55:26 | mriedem | and we should start working on Queens notes for https://docs.openstack.org/nova/latest/user/placement.html#upgrade-notes, in a follow up | |
| 19:55:28 | mriedem | agreed? | |
| 19:55:42 | jaypipes | works for me. | |
| 19:55:43 | cdent | that sounds right | |
| 19:56:30 | mriedem | ok, +W the | |
| 19:56:31 | mriedem | *then | |
| 19:56:33 | cdent | i agree we’ve not been careful about versions, but I’m not sure it is a huge problem in reality | |
| 19:56:40 | melwitt | mriedem: FYI I added some test coverage here and stacked the remove old quotas code follow up on top https://review.openstack.org/#/c/526270 | |
| 20:00:56 | mriedem | melwitt: comments inline | |
| 20:02:46 | jaypipes | mriedem: reviewed https://review.openstack.org/#/c/525787/. +Wd | |
| 20:03:18 | melwitt | mriedem: I didn't have access to self.flags in fixtures.py, I assumed it's on the base TestCase class. but let me check | |
| 20:04:22 | mriedem | melwitt: you likely have to pass the test's self into the fixture | |
| 20:04:27 | mriedem | like we do in some other fixtures | |
| 20:04:37 | mriedem | i care less about the self.flags thing | |
| 20:04:46 | mriedem | and more about doing the cleanup after the thing you change, and removing the unused CONF in the sample test | |
| 20:04:54 | melwitt | oh, got it. I can do that then | |
| 20:05:04 | mriedem | jaypipes: thanks, replied about the setup thing | |
| 20:05:11 | melwitt | k | |
| 20:08:09 | mriedem | jaypipes: btw, i haven't dealt with that much mox in a long time... | |
| 20:08:29 | mriedem | the strictness with which mox makes sure you hit bdm.save() cost me about 2 hours | |
| 20:08:58 | jaypipes | mriedem: I know, right? :) | |
| 20:09:54 | cdent | good night | |
| 20:12:56 | mriedem | jaypipes: efried: want me to do the doc and nova-status stuff from https://review.openstack.org/#/c/385693/ ? | |
| 20:13:25 | efried | mriedem I would welcome that. Were you planning to do it in isolation or add it somewhere in this series? | |
| 20:13:31 | mriedem | isolation | |
| 20:13:35 | mriedem | i'm not touching that mess | |
| 20:13:36 | efried | Perfect | |
| 20:13:39 | efried | Yeah, you shouldn't. | |
| 20:19:13 | melwitt | I don't know why but using self.flags causes the concurrent test fail for the NoopQuotaDriver | |
| 20:19:36 | mriedem | huh, maybe not global enough? | |
| 20:23:41 | melwitt | oh because self.flags doesn't clear the conf override. weird, I thought it would have to so it works with multiple tests | |
| 20:24:29 | efried | melwitt I have a bug for that. | |
| 20:24:30 | efried | Stand by... | |
| 20:24:47 | james_li_ | Hi nova devs, a quick question: is it possible to attach a volume of another tenant to my server? | |
| 20:25:24 | mriedem | james_li_: depends on the policy configuration, but not by default | |
| 20:25:25 | melwitt | gah, what other channel did I accidentally leave by pressing ctrl-w in the wrong window | |
| 20:25:47 | efried | melwitt Sorry, different bug, probably not related: https://bugs.launchpad.net/oslo.config/+bug/1709728 | |
| 20:25:48 | openstack | Launchpad bug 1709728 in oslo.config "CONF.set_override doesn't alias deprecated opts" [Undecided,Confirmed] | |
| 20:26:13 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: vSCSI https://review.openstack.org/526094 | |
| 20:26:44 | james_li_ | mriedem: cool so its possible if policy enables, e.g. admin user? | |
| 20:27:09 | mriedem | james_li_: the default rule is admin_or_owner, | |
| 20:27:13 | mriedem | if that were changed to @ | |
| 20:27:16 | mriedem | then anything goes | |
| 20:27:56 | mriedem | https://docs.openstack.org/nova/latest/configuration/sample-policy.html | |
| 20:28:03 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: vSCSI https://review.openstack.org/526094 | |
| 20:28:04 | james_li_ | mriedem: thanks, just wanted to make sure if any code changes are needed for that. | |
| 20:28:09 | mriedem | #"os_compute_api:os-volumes-attachments:create": "rule:admin_or_owner" | |
| 20:28:30 | mriedem | james_li_: shouldn't require code changes | |
| 20:28:36 | mriedem | but policy is a funny thing so you'd have to test it | |
| 20:28:46 | james_li_ | :) | |
| 20:31:51 | melwitt | api samples tests run super ugly under py3 | |
| 20:32:12 | melwitt | lots of warnings emitted to the screen | |
| 20:32:36 | melwitt | and clearing the override didn't seem to help. gdi | |
| 20:33:50 | efried | jaypipes Do we have db constraints or other checks that prevent traits, aggs, and children from existing against a provider UUID that doesn't exist? | |
| 20:34:08 | jaypipes | efried: nope. | |
| 20:34:39 | mriedem | melwitt: just use set_override, it's fine | |
| 20:34:41 | efried | jaypipes So theoretically I could create RP traits first, then create the RP they're associated with? | |
| 20:34:57 | mriedem | and yes on the py35 warnings - i was seeing that in the functional tests earlier today, oslo.contet and oslo.policy warnings | |
| 20:34:57 | efried | Or create an agg with orphan RP UUIDs, then create the RPs associated with those UUIDs? | |
| 20:35:01 | mriedem | we should consider ignoring those | |
| 20:35:35 | jaypipes | efried: yes, manually executing SQL statements. of course, the object layer won't allow you to do that, though. | |
| 20:36:04 | jaypipes | efried: since a TraitNotFound or ResourceProviderNotFound would be raised when attempting to do that via ResourceProvider.set_traits() | |
| 20:36:25 | jaypipes | efried: because there's a lookup of trait ID to names supplied in set_traits() | |
| 20:36:28 | efried | jaypipes oh, okay, phew. So the answer from the perspective of a REST API consumer is that we're strict about that stuff. | |
| 20:36:36 | jaypipes | efried: yes. | |
| 20:36:40 | efried | Good. | |
| 20:36:53 | jaypipes | efried: except for aggregates, which are just UUIDs and we have nothing to "check" against. | |
| 20:37:10 | efried | jaypipes Right, but you can't *associate* a random anonymous UUID with an aggregate? | |
| 20:37:34 | jaypipes | efried: no. but you *can* associated a random UUID to a known resource provider. | |
| 20:37:43 | jaypipes | efried: it's the aggregate UUID we have no way of checking. | |
| 20:37:50 | efried | jaypipes Got it, cool, thanks. | |
| 20:37:55 | jaypipes | pas de probleme | |
| 20:38:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update nova-status and docs for nova-compute requiring placement 1.14 https://review.openstack.org/526505 | |
| 20:38:41 | efried | jaypipes FYI this is coming from a place where I'm refactoring _ensure_resource_provider: In the _create_resource_provider path I can actually skip refresh_aggregate_map | |
| 20:38:44 | mriedem | efried: jaypipes: ^ | |