| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-15 | |||
| 12:50:57 | bauzas | the -backport tag ? yes | |
| 12:51:03 | bauzas | was that a question ? | |
| 12:51:30 | bauzas | like I said earlier "(14:49:59) bauzas: sean-k-mooney: gibi: the ussuri-backport-potential is mostly used for knowing whether it's a good backport candidate after GA" | |
| 12:51:32 | sean-k-mooney | yep im going to be reuploading it later today but i do not intend the patch to merge untill after ussuri is released then ill backport it | |
| 12:51:35 | bauzas | *after GA* | |
| 12:55:32 | bauzas | sean-k-mooney: a cyborg patch you mean ? I'm confused again :) | |
| 12:57:44 | gibi | bauzas: I'm releasing the bug lock for now, need to jump on a call | |
| 12:58:18 | bauzas | gibi: ack | |
| 13:08:50 | gibi | sean-k-mooney: do you have a feeling about https://bugs.launchpad.net/nova/+bug/1863038 ? For me it seems that the routed network feautre was never considered ironic in the first place. | |
| 13:08:50 | openstack | Launchpad bug 1863038 in OpenStack Compute (nova) "Nova need to consider ironic node as 'host'" [Undecided,New] | |
| 13:10:48 | bauzas | routed networks aren't a thing yet, right? | |
| 13:13:40 | gmann | stephenfin: chekcing.. | |
| 13:16:07 | gibi | bauzas: it works, in a narrow case | |
| 13:16:17 | bauzas | kk | |
| 13:16:21 | gibi | bauzas: when a port is pre-create with ip_allocation=deferred config | |
| 13:16:22 | bauzas | I missed that then | |
| 13:16:46 | gibi | for that case there was no need for nova change | |
| 13:17:19 | gibi | iff every network has a segment for every compute | |
| 13:18:24 | gibi | but overall you are right there is no real, good, tested routed net support in nova | |
| 13:22:06 | gmann | stephenfin: replied. please check | |
| 13:22:18 | gmann | stephenfin: https://review.opendev.org/#/c/662968/9 | |
| 13:23:10 | bauzas | gibi: ahah, now I understand why I never heard of this as 'implemented' | |
| 13:23:18 | bauzas | it was all proxied to neutron then | |
| 13:23:22 | bauzas | gotcha | |
| 13:24:22 | gibi | sean-k-mooney: bauzas: we will talk about route net support in nova during the PTG so this ironic case might be also a question for that discussion | |
| 13:25:32 | sean-k-mooney | sorry was distracted ill read scrollback | |
| 13:28:05 | sean-k-mooney | bauzas: well we jsut dont have schduling support | |
| 13:29:18 | sean-k-mooney | you can sort of force it to work by mapping AZs to routed segments but that is a pain and a hack | |
| 13:29:56 | sean-k-mooney | if you map an AZ to a segment then the fact we dont live migrate across AZs by default make it work fine provided you use ip_allocaiton=deffered | |
| 13:30:44 | efried | sean-k-mooney, gibi: I sure would like to see the provider yaml feature land. It's something we've talked about for years and years, and it's the first step toward being able to do PCI passthrough whitelisting+configuration properly. If you're still planning to represent PCI devices as child providers _ever_, you're going to want it or something like it. And the current work is *so* close. | |
| 13:31:19 | efried | tbc, my position on this is not related to employer, but to what I see as the right direction for nova | |
| 13:31:42 | sean-k-mooney | efried: yep althouhg i dont really like how we are doing to modeling if we are going to use it for pci if im being totally honest | |
| 13:31:54 | sean-k-mooney | that said its not awful either | |
| 13:32:09 | sean-k-mooney | its just missing the corralation to the actul devices | |
| 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 | |