| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-15 | |||
| 13:32:18 | sean-k-mooney | which could be added in a later schema version | |
| 13:32:35 | efried | oh, as written it's not ready for PCI yet, for sure. | |
| 13:33:04 | efried | we dialed back to the bare bones to get a mvp that would fit in a cycle | |
| 13:33:52 | sean-k-mooney | efried: my alternitve spec for this feature start with pci modeling as the MVP with what the current feature does as out of scope | |
| 13:34:02 | sean-k-mooney | well kind of | |
| 13:34:14 | sean-k-mooney | anyway i do think its worth completing give how close it is | |
| 13:34:42 | sean-k-mooney | efried: would you remind removing your -2 on the bottom patch and maybe gibi could add his | |
| 13:35:06 | sean-k-mooney | so that we dont need to find you to do that when we get to victoria | |
| 13:35:16 | bauzas | stephenfin: i'd appreciate some reviews of https://review.opendev.org/#/c/712741/2 btw. | |
| 13:35:38 | efried | oh, I have a -2? Fixing... | |
| 13:35:59 | sean-k-mooney | efried: it was a procedual one | |
| 13:36:13 | bauzas | efried: my only concers with the providers YAML file is that it makes the DSL so placement-specific... | |
| 13:36:31 | bauzas | I'd have appreciate some kind of abstraction | |
| 13:36:38 | sean-k-mooney | well its a yaml file for modeling things in placement | |
| 13:36:47 | sean-k-mooney | but that is a fair observation | |
| 13:36:56 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64 https://review.opendev.org/714425 | |
| 13:37:01 | sean-k-mooney | efried: https://review.opendev.org/#/c/673341/42 | |
| 13:37:14 | bauzas | sean-k-mooney: I know | |
| 13:37:22 | hrw | fixed pep8 | |
| 13:37:28 | bauzas | sean-k-mooney: and I reviewed the spec, I think i even left a +2 on it | |
| 13:37:35 | bauzas | sean-k-mooney: but my concern remains | |
| 13:37:49 | efried | sean-k-mooney, gibi: removed the -2 | |
| 13:37:58 | gibi | efried: tanks | |
| 13:38:01 | gibi | thanks | |
| 13:38:11 | bauzas | i think we mostly have a consensus about to leaking all the request group syntax into our flavor extraspecs | |
| 13:38:16 | bauzas | about not* | |
| 13:38:32 | bauzas | I'd appreciate if we could do the same for inventories | |
| 13:38:33 | sean-k-mooney | gibi: want to replace it with a procedual one since we are past code freeze and this need to be reporposed | |
| 13:38:56 | sean-k-mooney | or we can just leave it since we all know its for Victoria at this point | |
| 13:39:02 | efried | bauzas: well, it's not really that provider yaml is using a placement abstraction. It's that we designed placement with an abstraction and are using that same abstraction for other things (including cyborg and bw). Also worth noting that the *provider* yaml is completely targeted at *providers* which are a placement thing... | |
| 13:39:35 | sean-k-mooney | bauzas: well i want to remove the request groups form the flavor extra specs entirely | |
| 13:39:39 | bauzas | efried: I don't disagree hence my +2 on the spec | |
| 13:39:49 | efried | there's no request group syntax in provider yaml. That wouldn't make sense. | |
| 13:39:53 | bauzas | efried: I'm just saying we need to keep it crystal-clear for ops | |
| 13:39:57 | efried | ++ | |
| 13:40:14 | sean-k-mooney | efried: ya i think bauzas was just concerned about how the resouce would be consumed | |
| 13:40:32 | sean-k-mooney | they may be tempeted to use the request group syntax in the falvor | |
| 13:40:53 | bauzas | efried: the request group syntax was an example about how things could become difficult if we expose them thru extrasepcs | |
| 13:41:06 | bauzas | sean-k-mooney: correct | |
| 13:41:44 | gibi | sean-k-mooney: I will simply leave it as is, I trust the cores that they will not approve it | |
| 13:42:38 | efried | Yes, I agree it would be nice if we could close the door on direct rg syntax in extra specs. (Recall I advocated hard for using flavor-ese rather than placement-ese wherever possible. Dan pushed back at least wrt non-granular and I capitulated; but granular is still worth fighting for imo.) | |
| 13:42:50 | gibi | bauzas: re-acquire the bug triage lock for bugs in New state | |
| 13:43:18 | bauzas | gibi: I had to jump on a mandatory training course I have to do by today EOB | |
| 13:43:27 | bauzas | about 'open hybrid cloud' | |
| 13:43:46 | bauzas | where I'm teached about what is 'cloud' and 'cloud computing' | |
| 13:43:57 | gibi | I'm sorry for you | |
| 13:44:06 | sean-k-mooney | for what its worth this was my proposal for how to do this which had much less of a direct use of placmenet semantics https://review.opendev.org/#/c/603805/2/specs/stein/approved/device-discovery-policy-lib.rst | |
| 13:44:19 | bauzas | gibi: honestly, it's not really for today, I'm exagerating | |
| 13:44:20 | sean-k-mooney | still used resouce classes and trait but that was it | |
| 13:44:37 | bauzas | gibi: but I don't like having paperwork like this to slip over time | |
| 13:54:55 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in servers attributes Policies https://review.opendev.org/719729 | |
| 13:57:43 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in servers attributes policies https://review.opendev.org/719730 | |
| 14:10:51 | gibi | nova API experts I need help what would be the expected behavior for the quering GET /v2.1 and GET /v2.1/ without a token. As per https://bugs.launchpad.net/nova/+bug/1862477 | |
| 14:10:51 | openstack | Launchpad bug 1862477 in OpenStack Compute (nova) "API returns 401 for /v2.1 (when no auth provided)" [Undecided,Confirmed] | |
| 14:11:13 | gibi | alex_xu, gmann, dansmith ^^ | |
| 14:11:28 | bauzas | gibi: AFAIK you get the routes | |
| 14:11:53 | bauzas | gibi: lemme find the right thing | |
| 14:12:22 | gibi | I think we have an inconsistency between /v2.1 and / and between with token and without token | |
| 14:12:29 | gibi | see my comment in the review | |
| 14:12:30 | bauzas | gibi: yeah you're right with the triage I think | |
| 14:12:33 | gibi | in the bug | |
| 14:12:50 | bauzas | actually sec | |
| 14:12:58 | gibi | bauzas: is this something we broke recently? | |
| 14:13:06 | bauzas | gibi: no I don't think | |
| 14:13:13 | dansmith | I think efried and mordred just changed something about this, no? | |
| 14:13:17 | bauzas | gibi: I just wonder whether we should return 401 by design or no | |
| 14:13:36 | dansmith | fwiw, I've never understood why we should return *anything* to an unauthorized client | |
| 14:13:44 | bauzas | but I tend to say we should accept the root page even for the /v2.1 document | |
| 14:14:18 | efried | dansmith: yes, we recently merged a couple of fixes related to getting version discovery docs unauthenticated. Finding... | |
| 14:14:21 | bauzas | / et /v2.1 are two different resources in my mind | |
| 14:14:37 | efried | dansmith: https://review.opendev.org/#/c/685181/ | |
| 14:14:42 | dansmith | gibi: ^ | |
| 14:14:46 | gibi | thanks | |
| 14:14:47 | bauzas | / is the root page, I'm okay with not asking to be auth'd to see it | |
| 14:15:04 | efried | The versioned discovery docs also need to not require auth. | |
| 14:15:07 | bauzas | /v2.1 is an endpoint, I could understand we would require to be auth'd | |
| 14:15:30 | gibi | hold on, that patch is newer than my devstack | |
| 14:15:56 | sean-k-mooney | bauzas: i dont think we should assume that all endpoint need auth | |
| 14:16:06 | bauzas | I don't know what to say | |
| 14:16:15 | bauzas | it's just a design decision | |
| 14:16:20 | sean-k-mooney | bauzas: we should contol it via policy | |
| 14:16:36 | sean-k-mooney | and i think the default policy for /2.1 should be no auth | |
| 14:16:45 | sean-k-mooney | for version discovery to work | |
| 14:16:46 | bauzas | I think I entered a rathole, STEP BACK, STEP BACK !!! | |
| 14:16:53 | gibi | I will test those queries with the above patch applied | |
| 14:17:11 | efried | Oh, yeah, https://bugs.launchpad.net/nova/+bug/1862477 should be resolved via the above patch. | |
| 14:17:11 | openstack | Launchpad bug 1862477 in OpenStack Compute (nova) "API returns 401 for /v2.1 (when no auth provided)" [Undecided,Confirmed] | |
| 14:17:18 | bauzas | sean-k-mooney: yeah you make sense | |
| 14:17:46 | efried | ...as well as the two bugs tagged in the commit message. | |
| 14:17:56 | bauzas | gibi: mark it as duplicate of https://bugs.launchpad.net/nova/+bug/1862477 AFAICS | |
| 14:18:20 | bauzas | gibi: want me to do it ? | |
| 14:18:31 | gibi | bauzas, efried: thanks. I will quickly test it then mark it dublicate | |
| 14:18:43 | bauzas | ack | |
| 14:20:05 | bauzas | gmann: that's a very old bug, right ? https://bugs.launchpad.net/nova/+bug/1871665 | |
| 14:20:05 | openstack | Launchpad bug 1871665 in OpenStack Compute (nova) "servers actions (many) API policy is allowed for everyone even policy defaults is admin_or_owner " [Undecided,In progress] - Assigned to Ghanshyam Mann (ghanshyammann) | |
| 14:20:09 | bauzas | gmann: I never remember this worked once | |
| 14:20:39 | bauzas | (that surprised me like 5 years ago when I was trying to understand how oslo.policy was in use with nova) | |
| 14:21:20 | sean-k-mooney | gibi: regarding https://bugs.launchpad.net/nova/+bug/1863038 nova should be seting the instanace.host to the ironic node uuid right and we should be setting the instance.host in the neutron port binding profie to | |
| 14:21:20 | openstack | Launchpad bug 1863038 in OpenStack Compute (nova) "Nova need to consider ironic node as 'host'" [Wishlist,Confirmed] | |
| 14:22:12 | sean-k-mooney | i can go check that but i would be suprised if we are pasing the comput node host instead of the hypervior host in the call to neutron | |