| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 12:10:45 | stephenfin | *os-vif and neutron | |
| 12:11:34 | sean-k-mooney | without the neturon patch you just get erros in the neutron logs but it fixes its self | |
| 12:11:44 | sean-k-mooney | the os-vif change however would be needed first ya | |
| 12:13:05 | sean-k-mooney | lyarwood: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ff2/602432/26/check/nova-grenade-multinode/ff2bd9a/logs/new/tempest_conf.txt | |
| 12:13:12 | sean-k-mooney | live_migrate_back_and_forth = True | |
| 12:13:37 | sean-k-mooney | that is why its failing | |
| 12:14:06 | gibi | stephenfin: do you have a lauchpad bp filled for this? https://review.opendev.org/#/c/755109 | |
| 12:14:24 | sean-k-mooney | its off in live migration job and that all the new version so it passes the https://zuul.opendev.org/t/openstack/build/e2fa8ae7802f41309877b537f51ba660/log/controller/logs/tempest_conf.txt#76 | |
| 12:14:26 | stephenfin | gibi: I though I did but I'm not sure | |
| 12:14:39 | gibi | the bp link in the specs does not seem to work for me | |
| 12:16:28 | sean-k-mooney | ya cant find it either | |
| 12:16:45 | sean-k-mooney | but it should be a simple copy past of the into section | |
| 12:17:01 | stephenfin | gibi: Didn't look like it. Apologies. Have created one now https://blueprints.launchpad.net/nova/+spec/modernize-os-hypervisors-api | |
| 12:17:07 | gibi | thanks | |
| 12:19:13 | sean-k-mooney | weird i cant add the spec via the spec link so i put it in the whiteborad | |
| 12:19:34 | sean-k-mooney | i tought i could do that once i was on the bug team but i guess not | |
| 12:28:30 | gibi | sean-k-mooney: I guess we edited the whiteboard in parallel and my change overwrote yours, sorry. | |
| 12:30:52 | sean-k-mooney | no launchpad gave me a permission error | |
| 12:31:38 | gibi | Blueprint changed by sean mooney: | |
| 12:31:38 | gibi | interesting, I got the following mail from launchpad | |
| 12:31:39 | gibi | spec: https://review.opendev.org/#/c/755109 | |
| 12:31:39 | gibi | Whiteboard set to: | |
| 12:31:55 | gibi | so at least some part of your update went through | |
| 12:34:46 | openstackgerrit | Merged openstack/nova-specs master: [Trivial] update the upgrade release goal https://review.opendev.org/763294 | |
| 12:55:52 | lyarwood | sean-k-mooney: sorry had to go afk | |
| 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 | f0o | I'm not 100% sure tho | |
| 14:48:28 | openstackgerrit | Merged openstack/nova master: Add missing exception https://review.opendev.org/762898 | |