| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 12:56:53 | lyarwood | sean-k-mooney: so old to new works, it's just new to old that's failing right? | |
| 12:57:04 | sean-k-mooney | lyarwood: yep | |
| 12:57:19 | lyarwood | sean-k-mooney: do we care in that case, I know we don't downstream | |
| 12:57:21 | sean-k-mooney | new to old nova uses type ethernet | |
| 12:57:54 | sean-k-mooney | but does not tell os-vif to plug the interface by passing crate-port=true | |
| 12:58:15 | sean-k-mooney | well once i do the backport it will alos work but we do allow rolling upgrades | |
| 12:58:22 | sean-k-mooney | so we kind of do care yes | |
| 12:58:50 | lyarwood | yeah I was thinking of major upgrades where we don't allow you to return to the older computes | |
| 12:58:59 | lyarwood | minor upgrades I guess do allow this | |
| 13:00:01 | sean-k-mooney | ya i would basiclaly need to know the version of nova on the dest | |
| 13:00:16 | sean-k-mooney | but i cant just do a normal compute service check if im backporting | |
| 13:00:41 | lyarwood | could we use something in migrate_data? | |
| 13:00:51 | lyarwood | like I did with LUKS volumes | |
| 13:01:06 | sean-k-mooney | we coudl if we dont change the object | |
| 13:01:29 | sean-k-mooney | i could stash something in the port profile or something | |
| 13:01:48 | sean-k-mooney | but i then need to supprot both in the code | |
| 13:01:56 | lyarwood | https://github.com/openstack/nova/blob/60071a2c83ad1d7ed6fd50f8af0bb4d92aa84bea/nova/virt/libvirt/driver.py#L9301-L9311 | |
| 13:02:00 | sean-k-mooney | i ripped out the bridge way of doing things so would have to put it back in | |
| 13:02:23 | lyarwood | that's not the best example as it does need an object change | |
| 13:02:33 | sean-k-mooney | ya but i get the point | |
| 13:02:48 | lyarwood | but yeah if the src can look for something stashed in there it might help | |
| 13:02:50 | sean-k-mooney | i could put it into one of the unversioned dict of string fields | |
| 13:03:14 | sean-k-mooney | ya so stash it n pre-live-migrate | |
| 13:03:24 | sean-k-mooney | and read it on the souce when updating the xml | |
| 13:03:47 | sean-k-mooney | ok ill have to think about it | |
| 13:04:06 | sean-k-mooney | i know more or less how to do that but need to find where makes the most sense | |
| 13:04:15 | lyarwood | kk | |
| 13:04:52 | sean-k-mooney | im thing in here https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L30-L59 | |
| 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 | openstackgerrit | Merged openstack/nova master: Add missing exception https://review.opendev.org/762898 | |
| 14:48:28 | f0o | I'm not 100% sure tho | |
| 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 | dansmith | gibi: looking through our install docs, | |
| 14:49:42 | sean-k-mooney | its a one way comunication | |
| 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 | |