Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-19
15:12:38 lpetrut sean-k-mooney: fwiw, here's an explicit handler for "POST": https://github.com/openstack/nova/blob/master/nova/api/metadata/password.py#L62
15:12:54 sean-k-mooney lpetrut: right that is for the nova api
15:13:06 sean-k-mooney it supproted if you call the nova api with an authenicated token
15:13:21 sean-k-mooney but doing it form the guest vai the 169 adress is not as far as i know
15:14:22 lpetrut nope, that specific request doesn't require a token
15:14:41 lpetrut https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L214-L225
15:14:49 sean-k-mooney so this is something ill have to bring up with the security team
15:15:07 sean-k-mooney we have discussed it publicly at this point but its potentially an issue
15:15:10 lpetrut from what I can tell, the guest can only update specific fields, the password being one of them
15:16:38 f0o sean-k-mooney: actually it seems that /password accepts POST on the metadata service... The issue was that the sshkey used was ECDSA and cloudbase-init went bananas. I get the password posted correctly if I load it up with an RSA key
15:16:38 lpetrut I've just checked, so actually the "password" field is the only one that can be updated
15:17:16 sean-k-mooney f0o: ecdsa need a newer version of pycyrptography to work
15:17:21 lpetrut tbh I'm a bit surprised that the nova metadata docs don't mention this, this feature has been there since forever (<2014 I think)
15:17:48 sean-k-mooney as i said im not sure it has been
15:17:55 sean-k-mooney i think this was unitnetional
15:18:01 sean-k-mooney there is no spec for it
15:18:05 lpetrut here it is: https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89
15:18:08 sean-k-mooney i checked
15:18:15 lpetrut 2012, pre nova specs era :)
15:19:03 sean-k-mooney this is only nova v1 api behavior
15:19:30 sean-k-mooney actully no its liberty which is not pre sepecs
15:20:01 lpetrut I guess it seemed simple enough not to mandate a spec, but it's definitely intentional
15:20:23 lpetrut and it's not just nova v1
15:20:42 sean-k-mooney lpetrut: we require specs for all api cahnge regradless of how trivial it is
15:21:20 sean-k-mooney lpetrut: yes the nova v1 comment was because you said it was pre specs
15:21:32 sean-k-mooney we have specs for similar feature in libvirt https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html
15:21:37 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Add missing exception https://review.opendev.org/763393
15:21:40 lpetrut oh, got it
15:22:54 lpetrut I think that libvirt driver feature is slightly different than https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89
15:23:29 sean-k-mooney we are missing an api microverion bump for this too
15:23:52 lpetrut bump the microversion for what?
15:23:59 sean-k-mooney the metadata api
15:24:08 lpetrut https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89 this is there since 2012 :)
15:24:30 lpetrut it's not something that was added now
15:24:41 sean-k-mooney yep and it was not documented and did not follow our spec proceducer and did not do an api microverion bump to the metadata api
15:25:08 sean-k-mooney lpetrut: sure imjust not sure it shoudl continue to be supported unless we at least fix the docs
15:25:40 lpetrut well, just because it wasn't properly documented doesn't mean that it should become unsupported, there are projects relying on it
15:25:41 sean-k-mooney if its just this field it might be ok. if other fiels can be arbitrally updated then it could be a an issue
15:26:03 lpetrut sean-k-mooney: indeed. well, it's ok, it's just this field
15:26:15 sean-k-mooney lpetrut: not that im aware of other the cloudbase-init
15:27:24 lpetrut well, since virtually all Windows Openstack instances use it, I'd say breaking it wouldn't be desired, even though it's just one project
15:27:25 sean-k-mooney apparently it was for hyperv https://blueprints.launchpad.net/nova/+spec/hyper-v-metadata-password-post
15:27:36 sean-k-mooney but it was not appoved
15:28:09 sean-k-mooney thre is no https://blueprints.launchpad.net/nova/+spec/get-password blueprit
15:28:18 sean-k-mooney oh there is
15:28:22 sean-k-mooney it did not come up
15:28:26 lpetrut https://blueprints.launchpad.net/nova/+spec/hyper-v-metadata-password-post seems like an extension of this feature
15:29:20 sean-k-mooney this was first added as an api extention https://review.opendev.org/#/c/17273/
15:29:41 sean-k-mooney before we removed those
15:30:36 sean-k-mooney so this was nota catully part of the metadata api
15:30:52 sean-k-mooney it was a vendor extntion https://review.opendev.org/#/c/17273/15/nova/api/openstack/compute/contrib/server_password.py
15:30:55 lpetrut nice. thanks for checking. this was an interesting lesson of Nova history :)
15:31:25 sean-k-mooney so ya i think we moved it into the metrada service wehn we got rid fo extensions
15:33:31 lpetrut sorry for mentioning the server actions, that's completely unrelated. it took a while since I last had contact with this code so I was a bit confused.
15:36:52 sean-k-mooney so this changed in liberty
15:37:05 sean-k-mooney that is when we remvod the contib folder
15:38:04 sean-k-mooney ah it move to legacy_v2 contrib
15:41:03 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/api-no-more-extensions.html
15:42:08 sean-k-mooney so this was deprecated in libvirty and removed in newton
15:43:55 lpetrut yep, API extensions were deprecated but then got included in the nova api
15:44:24 sean-k-mooney they were not just all accpeted
15:44:33 sean-k-mooney they needed to be upstreamed
15:44:52 lpetrut makes sense. well, this specific one is part of the nova tree. seems upstream to me :)
15:46:35 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Reproducer for unpinned to pinned resize bug https://review.opendev.org/763399
15:46:44 sean-k-mooney it got moved by https://github.com/openstack/nova/commit/003c868da73d84d33fba81ee9b033b8ae321e7ab
15:46:55 artom stephenfin, sean-k-mooney, ^^ sanity check that for me pretty please? I feel like I've missed something obvious
15:47:02 artom And yet...
15:47:46 sean-k-mooney what are yo trying to check?
15:47:54 sean-k-mooney unpinned to pinned works fine
15:47:55 stephenfin artom: You need to disable the workaround option
15:47:59 sean-k-mooney or at least it used too
15:48:14 stephenfin artom: '[workarounds] disable_fallback_pcpu_query'
15:48:29 stephenfin and then it'll fail
15:48:34 sean-k-mooney ah yes
15:48:38 sean-k-mooney so it uses pcpus
15:49:06 sean-k-mooney artom: the current behavior with the fallback enabeld is expected
15:49:18 artom stephenfin, can I be lazy and ask you to remind me what the fallback query actually queries for?
15:49:23 artom Ah, just VCPUs?
15:49:27 gibi dansmith: re: install doc. So those docs could be the place where we define the minimal config. As a first look at leat the compute doc did not ask for a DB config :)
15:49:36 sean-k-mooney artom: yep vcpus
15:49:38 dansmith gibi: yeah
15:49:47 artom Wouldn't it fail on the host though?
15:49:54 sean-k-mooney artom: no
15:49:59 dansmith gibi: I dunno about you, but I'm not sure that having three separate docs for three separate distro flavors is really necessary,
15:50:13 sean-k-mooney artom: it should
15:50:17 gibi dansmith: I did not diff them but they look similar
15:50:18 stephenfin artom: when that's configured, the scheduler will make a second, fallback request for VCPU inventory, yeah
15:50:22 dansmith gibi: especially since the ubuntu one (at least) already has some stale stuff I can see (not using systemctl)
15:50:26 sean-k-mooney but im not sure stephenfin pach has been merged
15:50:35 dansmith gibi: yeah there are a couple tweaks made to one that aren't in the other, unrelated to distro stuff
15:50:45 dansmith gibi: having them separate makes that a real likely possibility
15:50:48 stephenfin as for failing on the host, I'm trying to recall...
15:50:49 sean-k-mooney artom: if they dont have cpu_dedicate_set configure then it should boot on the host
15:51:20 sean-k-mooney stephenfin: it should only fail on the host if cpu_dedicated_set is defiend
15:51:20 gibi dansmith: so we could merge them and just add notes about the destro specific things
15:51:27 stephenfin sean-k-mooney: yeah, correct
15:51:29 artom stephenfin, I'd expect virt.hardware to not pin CPUs if neither vcpu_pin_set or cpu_dedicated_set is configured...
15:51:41 stephenfin artom: we can't do that - we'd break upgrades
15:51:43 dansmith gibi: or we could merge them and try to stay out of the distro business
15:51:44 sean-k-mooney artom: your expectiojn is wrong

Earlier   Later