| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 13:05:00 | sean-k-mooney | probaly the profile_json | |
| 13:05:04 | sean-k-mooney | since nova owns that | |
| 13:05:45 | sean-k-mooney | that is what is stored in the vifs filed of the liveMigrateData | |
| 13:05:46 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L154 | |
| 13:06:30 | lyarwood | kk | |
| 13:06:34 | lyarwood | yeah that could work | |
| 13:06:44 | lyarwood | and you would want to populate that on the dest btw | |
| 13:07:00 | lyarwood | if it isn't set or True then the source would wire things up in the legacy way | |
| 13:07:04 | sean-k-mooney | we are doing it here too https://review.opendev.org/#/c/738432/ | |
| 13:07:19 | sean-k-mooney | lyarwood: yep | |
| 13:08:31 | lyarwood | and then once it's backported you can remove the logic in the next release | |
| 13:08:49 | sean-k-mooney | yes we coudl drop i in X | |
| 13:08:51 | lyarwood | X, not W to be clear | |
| 13:08:54 | lyarwood | yeah | |
| 13:09:11 | lyarwood | migrate_data hackarounds ftw! | |
| 13:09:49 | sean-k-mooney | im just glad we still have some dict of string fields in them or we would have to use system metadata which would be a pian | |
| 13:10:10 | sean-k-mooney | or just not backport i guess | |
| 13:10:43 | sean-k-mooney | in theory master should always be deployable and upgradeable however so we should fix this | |
| 13:10:56 | sean-k-mooney | patchset 27 it is | |
| 13:18:32 | sean-k-mooney | stephenfin: melwitt: lyarwood: summerised this in a toplevel comment on the review | |
| 13:19:42 | lyarwood | sean-k-mooney: ack thanks, LGTM | |
| 13:41:08 | sean-k-mooney | johnthetubaguy: if you see this are you working on unified limits this cycle or did you say you wont have time? | |
| 13:41:32 | sean-k-mooney | johnthetubaguy: just basically wondering since i dont think i have seen the spec repoposed althoguh i might have missed it | |
| 14:40:16 | f0o | Hi, I've a question about passwords in nova. On Horizon I keep getting that the password is not set. Which config option in nova.conf do I need to make it create a password? I see `#password_length=12` and `#enable_instance_password=true` in the default config, are these values not the default ones? | |
| 14:42:18 | sean-k-mooney | f0o: they might be but password injection only work if you have the qemu guest agent | |
| 14:42:32 | sean-k-mooney | in general its not recommended to use passwords | |
| 14:43:10 | f0o | I know but windows :/ | |
| 14:43:11 | sean-k-mooney | f0o: yes they are the defaults | |
| 14:43:21 | sean-k-mooney | you can use keypairs with windows | |
| 14:43:33 | sean-k-mooney | you just dont use ssh keys | |
| 14:43:54 | sean-k-mooney | you use x509 certs for winrm | |
| 14:43:56 | f0o | if I read Cloudbase's docs correctly, it does not rely on injection but onyl on the metadata endpoint | |
| 14:44:57 | f0o | I remeber having this working at my previous job (nova+vmware) basically out of the box, now with kvm I cant seem to get a password back | |
| 14:45:16 | f0o | or do I need to enable injection for it to return a password via api? | |
| 14:45:24 | sean-k-mooney | as i said you need the qemu geust agent for ti to work with libvirt/qemu | |
| 14:45:47 | f0o | k | |
| 14:45:52 | f0o | what throws me off is: | |
| 14:45:54 | f0o | The secure and proper way to set passwords in OpenStack Windows instances is by letting Cloudbase-Init generate a random password and post it encrypted on the Nova metadata service. | |
| 14:46:33 | f0o | to me this means that cloud-init in this case is actually not doing it's job because the password is not set. trying to find the issue here since it can be both sides | |
| 14:46:37 | sean-k-mooney | well the proper way to do it is via user-data yes | |
| 14:46:55 | sean-k-mooney | but that is different to what those config options do | |
| 14:47:37 | sean-k-mooney | f0o: https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html | |
| 14:48:07 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html#other-end-user-impact | |
| 14:48:14 | sean-k-mooney | that is what is missing | |
| 14:48:24 | sean-k-mooney | this is unrelated to cloudbase-init | |
| 14:48:28 | f0o | I'm not 100% sure tho | |
| 14:48:28 | openstackgerrit | Merged openstack/nova master: Add missing exception https://review.opendev.org/762898 | |
| 14:48:39 | f0o | but if they claim that the cloudbase-init creates and shoots the password to nova | |
| 14:48:45 | f0o | then injection shouldnt matter | |
| 14:48:55 | f0o | or am I off? | |
| 14:48:58 | sean-k-mooney | its not using injection and that is not what cloudbae does | |
| 14:49:13 | sean-k-mooney | cloudbase-init just reimplmente cloud-init for windows | |
| 14:49:19 | sean-k-mooney | it does not interact with nova at all | |
| 14:49:29 | sean-k-mooney | it just consumes the metadta generated by nova | |
| 14:49:42 | sean-k-mooney | its a one way comunication | |
| 14:49:42 | dansmith | gibi: looking through our install docs, | |
| 14:49:50 | f0o | >> Cloudbase-Init generate a random password and post it encrypted on the Nova metadata service. << that part is what makes me think it actually attempts to do something tho | |
| 14:50:14 | sean-k-mooney | we dont allow external things to add metadata that way | |
| 14:50:17 | dansmith | gibi: we already do provide quite a bit of sample config per compute and per "controller", and it's all seemingly duplicated in each doc, and for each distro flavor :/ | |
| 14:50:20 | sean-k-mooney | its not part of the api | |
| 14:50:28 | f0o | well that's a great lie from the vendor then lol | |
| 14:50:42 | sean-k-mooney | the only way to do that woudl be to set a property on server | |
| 14:51:05 | sean-k-mooney | but cloudbase-init is only installed in the vm image | |
| 14:51:16 | sean-k-mooney | it does not know about the openstack its one and has no credentials | |
| 14:51:22 | sean-k-mooney | so it cant set a property | |
| 14:51:49 | f0o | yeah that's exactly my thoughts as well | |
| 14:51:50 | lpetrut | sorry for stepping in, but you can in fact post changes to the metadata server | |
| 14:52:06 | f0o | hence why I got so massively confused when they write "oh dont worry, we post the password to nova" | |
| 14:53:26 | lpetrut | https://docs.openstack.org/api-ref/compute/?expanded=replace-metadata-items-detail#replace-metadata-items | |
| 14:54:16 | f0o | thanks for the clarifications tho :) | |
| 14:54:23 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/victoria: Add missing exception https://review.opendev.org/763389 | |
| 14:54:25 | f0o | I thought I was being blind or insane | |
| 14:54:42 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/ussuri: Add missing exception https://review.opendev.org/763390 | |
| 14:55:29 | lpetrut | cloudbase-init will just encrypt the generated password and post it to http://169.254.169.254/openstack, so you can then retrieve it and decrypt it. IIRC the nova client even accepts a key that decrypts that password. | |
| 14:56:36 | sean-k-mooney | lpetrut: you can i was not aware of that. i tought this was readonly | |
| 14:57:47 | sean-k-mooney | unless you used the property api. i guess not but i dont think we have any cli commnds for this | |
| 14:59:28 | lpetrut | well, the idea is that the netron metadata agent is also forwarding POST/PUT requests | |
| 14:59:28 | openstackgerrit | Elod Illes proposed openstack/nova stable/train: Test for disabling greendns https://review.opendev.org/761763 | |
| 14:59:48 | lpetrut | not just GET requests to http://169.254.169.254/openstack | |
| 14:59:50 | bauzas | dansmith: around for a RPC question ? | |
| 14:59:58 | dansmith | bauzas: yeah | |
| 15:00:37 | bauzas | dansmith: ack, just wondering why https://review.opendev.org/#/c/761452/ is getting the 6.0 version as the minor version | |
| 15:00:53 | bauzas | " Nov 13 10:14:02.664855 ubuntu-focal-rax-iad-0021755641 devstack@n-api.service[72892]: ERROR nova.api.openstack.wsgi [None req-dbe8b15b-bd32-46ab-93b4-b0097a6a86a3 None None] Unexpected exception in API method: oslo_messaging.rpc.client.RPCVersionCapError: Requested message version, 5.0 is incompatible. It needs to be equal in major version and less than or equal in minor version as the specified version cap 6.0." | |
| 15:01:22 | lpetrut | sean-k-mooney: so basically each guest can update its own metadata by just sending it to http://169.254.169.254/openstack | |
| 15:01:51 | sean-k-mooney | lpetrut: that might be a bug. i think that was only ment to be updated via the nova api | |
| 15:01:57 | bauzas | dansmith: but I provided an additional endpoint for the v5.0 proxy | |
| 15:03:10 | dansmith | bauzas: well, you haven't implemented 6.0 in the client, but all the servers are reporting that they support 6.0 (via the service version) and everything is new, so it's choosing to use 6.0 but the client doesn't support it, right? | |
| 15:04:11 | lpetrut | sean-k-mooney: fwiw here's where cloudbase-init is sending the password: https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/httpservice.py#L55-L80 | |
| 15:04:31 | dansmith | bauzas: remember, the client has to be able to speak both versions as well, depending on the version pin, but it's choosing to speak the new one based on the service version, and you only speak 5.x on the client side right now | |
| 15:04:41 | bauzas | dansmith: sure, but if the client is only supporting 5.0, the server should still accept it given the additional endpoint, nope ? | |
| 15:04:56 | lpetrut | sean-k-mooney: I wouldn't say it's a bug, it allows the guest to communicate back various metadata items. I'm not sure if it's filtered in any way. | |
| 15:04:57 | dansmith | bauzas: yes, but the auto pin will try to configure the client with 6.0 | |
| 15:04:59 | sean-k-mooney | lpetrut: i see well that is undocumented behavior that they are relying on i think | |
| 15:05:10 | dansmith | bauzas: because everything is new | |
| 15:05:30 | bauzas | dansmith: why this worked then with https://review.opendev.org/#/c/541005/6 ? | |
| 15:06:02 | sean-k-mooney | lpetrut: unless im mistaken and you can point me to docs or a spec to the controy i dont think that was ever intended to work | |
| 15:06:21 | dansmith | bauzas: were we auto calculating the pin then? we'd have to look at devstack config from back then to know | |
| 15:06:29 | lpetrut | sean-k-mooney: I'm sure I can find some docs on this, checking | |
| 15:07:01 | bauzas | dansmith: maybe, I dunno | |
| 15:09:43 | sean-k-mooney | lpetrut: this is the metadata docs https://docs.openstack.org/nova/latest/user/metadata.html | |