| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-15 | |||
| 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 | openstack | Launchpad bug 1862477 in OpenStack Compute (nova) "API returns 401 for /v2.1 (when no auth provided)" [Undecided,Confirmed] | |
| 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: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 | openstack | Launchpad bug 1862477 in OpenStack Compute (nova) "API returns 401 for /v2.1 (when no auth provided)" [Undecided,Confirmed] | |
| 14:17:11 | efried | Oh, yeah, https://bugs.launchpad.net/nova/+bug/1862477 should be resolved via the above patch. | |
| 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 | 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:05 | bauzas | gmann: that's a very old bug, right ? https://bugs.launchpad.net/nova/+bug/1871665 | |
| 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 | openstack | Launchpad bug 1863038 in OpenStack Compute (nova) "Nova need to consider ironic node as 'host'" [Wishlist,Confirmed] | |
| 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: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 | |
| 14:24:35 | gibi | I also would need to read the code to be sure about what we set node or host | |
| 14:27:25 | sean-k-mooney | looking at teh migration code we are using instance.host im looking now at some of the other code paths but we appear to be using instance.host in most case if not all | |
| 14:29:19 | sean-k-mooney | gibi: i guess allocate for instance delegates to the driver https://github.com/openstack/nova/blob/01da968978db8c01920616fe594bea6eda2cba57/nova/compute/manager.py#L1724 | |
| 14:30:14 | sean-k-mooney | which for ironic retuns none https://github.com/openstack/nova/blob/01da968978db8c01920616fe594bea6eda2cba57/nova/virt/ironic/driver.py#L1795 | |
| 14:30:47 | gmann | bauzas: correct, almost all of our admin_or_owner has this issue. founded and fixed in policy defaults work | |
| 14:32:11 | bauzas | gmann: I just rechecked the patch | |
| 14:33:09 | sean-k-mooney | gibi: they do the vif attach here https://github.com/openstack/nova/blob/01da968978db8c01920616fe594bea6eda2cba57/nova/virt/ironic/driver.py#L1545-L1546 | |
| 14:33:52 | gmann | thanks | |
| 14:34:11 | sean-k-mooney | also using the uuid so this fells like either an ironic bug or not a bug at all that said i have not traced all the codepaths so there still could be a nova bug but i doubt it. | |
| 14:35:33 | gibi | sean-k-mooney: thanks for the analysis. I deferr this to the PTG discussion. It is clearly not a regression to deal with now | |
| 14:35:49 | sean-k-mooney | gibi: well im not sure the bug report is valid | |
| 14:36:11 | sean-k-mooney | e.g. i dont know if we actully are using the host it looks like we shoudl be useing the ironic node uuid | |
| 14:37:51 | gibi | sean-k-mooney: I think the reporter also said that for ironic case neutron gets the node uuid and try to use that as a host for the nova host aggregate API | |
| 14:39:36 | sean-k-mooney | well there is some weirdnes with host aggreates and ironic node | |
| 14:40:12 | sean-k-mooney | its not clear to me if we expect each compute serivce to be a member of the host aggreate or each compute/ironic node | |
| 14:41:03 | sean-k-mooney | i think in the ironic case we would want each fo the ironic nodes to be set as member of the hsot aggreate | |
| 14:41:19 | sean-k-mooney | since they can move between compute services | |
| 14:41:52 | sean-k-mooney | they code they linked too however is querying placment | |
| 14:41:54 | sean-k-mooney | https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L253 | |
| 14:42:50 | gibi | sean-k-mooney: I think neutron creates a host aggregate that is then mapped to placement aggregate by nova and then neutron puts the IP RP to into that placement aggregate | |
| 14:43:15 | gibi | or something like that (it is pretty complicate) | |
| 14:43:30 | sean-k-mooney | gibi: neutron should be creating both a RP and hostaggreate makeing the RP a sharing resouce provider of ips | |
| 14:43:51 | hrw | bauzas: https://review.opendev.org/714425 (AMD SEV check) updated with tests | |
| 14:44:45 | sean-k-mooney | hrw: that looks like an optimiation | |
| 14:44:53 | sean-k-mooney | is this breaking something if so you shoudl file a bug | |
| 14:47:00 | gibi | sean-k-mooney: so for ironic neturon gets the node uuid for libvirt neutron gets the hostname and the neutron in both case use the given id as a member of an aggregate but in nova host aggregates works on compute host level not on compute node level | |
| 14:48:18 | sean-k-mooney | gibi: well this is all handeld at the compute manager level | |
| 14:48:33 | sean-k-mooney | for everythign other then ironic it gets the instance.host | |
| 14:48:37 | gibi | yepp | |
| 14:48:45 | gibi | this is the key difference | |
| 14:48:47 | sean-k-mooney | for ironic it gets the node uuid | |
| 14:48:57 | sean-k-mooney | the instance.host shoudl be the node uuid | |
| 14:49:05 | sean-k-mooney | in the ironic case | |
| 14:49:09 | sean-k-mooney | so it shoudl be the same | |
| 14:49:28 | gibi | yepp, but I don't think you can add a node to a nova host aggregate | |
| 14:49:35 | gibi | you can only add a host there | |
| 14:50:04 | sean-k-mooney | isnint instance.host always set to the hypervior hostname | |
| 14:50:35 | sean-k-mooney | so i think the neutron code only ever works in that case because for non ironic host the hypervior hostname and compute service host are the same | |
| 14:50:51 | gibi | yepp, that could be the case | |
| 14:51:24 | hrw | sean-k-mooney: it does not break anything. just looks weird when on aarch64 host I see checks of x86 features in log | |
| 14:51:39 | sean-k-mooney | hrw: its not an x86 feature | |
| 14:51:45 | sean-k-mooney | its not part of the instuction set | |
| 14:51:50 | sean-k-mooney | its an AMD extention | |
| 14:51:56 | hrw | sean-k-mooney: AMD SVE is not aarch64 feature as well ;D | |
| 14:52:12 | sean-k-mooney | yes but its incrrect to call it x86 | |
| 14:52:44 | hrw | sean-k-mooney: when you run 'lscpu' it is listed in features. along with 'I can run KVM' which is not part of ISA iirc too | |
| 14:53:29 | sean-k-mooney | sure but the feature are not instuctionsets | |
| 14:53:56 | sean-k-mooney | several of the security flaws are listed as "features" too | |