| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-23 | |||
| 11:27:50 | kashyap | Just say 'fix-up'. | |
| 11:28:08 | kashyap | Clear writing is a sign of clear thinking. Don't use mindless acronyms. | |
| 11:28:19 | kashyap | But that requires hardwork, and it's easy to be lazy | |
| 11:28:36 | kashyap | [Not saying it anyone in particular, BTW :D, just saying it out loud.] | |
| 11:28:57 | zigo | DMT TLA ... :P | |
| 11:30:02 | zigo | TMD TLA I mean. | |
| 11:41:42 | bauzas | zigo: Follow-Up Patch ;) | |
| 11:46:35 | zigo | :) | |
| 12:29:01 | lyarwood | stephenfin: random question, any idea where _get_vcpu_total was removed in the libvirt driver? I'm trying to rebase a series from mdbooth and I can't find where it was removed and what it was replaced with. | |
| 12:29:23 | stephenfin | it would have been in Train | |
| 12:29:24 | lyarwood | stephenfin: looks like you refactored things around here for the pcpu stuff | |
| 12:29:31 | stephenfin | git log -S _get_vcpu_total | |
| 12:29:43 | lyarwood | TIL | |
| 12:31:00 | lyarwood | odd that tig couldn't find it | |
| 12:31:17 | lyarwood | I thought the searching in tig did the same tbh | |
| 12:31:46 | lyarwood | I guess it's just looking at the subject, meh. | |
| 12:43:47 | zigo | Are you guys planning the RC1 for today or tomorrow? | |
| 12:58:32 | gibi | zigo: today | |
| 12:59:57 | gibi | zigo: do you have a critical thing? | |
| 13:03:26 | zigo | gibi: No, just wonder when I'll be able to package it for Debian ! :P | |
| 13:03:55 | gibi | zigo: cool. I will ping you when the release patch merges | |
| 13:04:09 | gibi | zigo: and please let us know if somehing breaks for you | |
| 13:04:41 | zigo | It's gona take some time until I can spawn a first VM with Ussuri. It's going to be maybe next week... | |
| 13:04:49 | zigo | I guess some of my puppet stuff will break, etc. | |
| 13:11:35 | gibi | zigo: we have 2 weeks for additional RC if needed | |
| 13:12:19 | zigo | Usually, I can install the release between the first rc and the final releases. | |
| 13:12:28 | gibi | cool | |
| 13:12:36 | gmann | bauzas: thanks | |
| 13:30:25 | artom | sean-k-mooney, re - your point about changing the default machine type downstream/in ooo only | |
| 13:30:37 | artom | I'll be honest, I only trust upstream's CI with this :P | |
| 13:36:46 | sean-k-mooney | artom: we are chaning nova-next to use q35 | |
| 13:37:04 | sean-k-mooney | and we could change the default in devstack too if we want too | |
| 13:37:12 | sean-k-mooney | but i just am not sure we should change it in nova | |
| 13:38:06 | sean-k-mooney | if we change it in nova and you cold migrate or you live migrate and then hard reboot the machine type would change | |
| 13:38:10 | sean-k-mooney | and that can break things | |
| 13:39:34 | lyarwood | sean-k-mooney: if we don't stash and use the original somehow | |
| 13:39:42 | sean-k-mooney | so without recording the machine type in the instance which we dont do today when its not set in the image its not really safe from an upgrades perspective to change the default. | |
| 13:39:47 | sean-k-mooney | lyarwood: yes we dont | |
| 13:39:57 | lyarwood | yup | |
| 13:40:00 | sean-k-mooney | we also dont schdule on this today | |
| 13:40:10 | sean-k-mooney | which is less then ideal | |
| 13:40:36 | lyarwood | so this is less about setting defaults and more about proving support? | |
| 13:40:48 | lyarwood | and allowing it to be used in new deployments | |
| 13:40:59 | sean-k-mooney | no not really | |
| 13:41:11 | sean-k-mooney | i think in our product we should make the switch for new deployments | |
| 13:41:18 | sean-k-mooney | upstream im not sure if we can in nova | |
| 13:41:25 | lyarwood | right but we can in devstack | |
| 13:41:33 | lyarwood | I didn't mean that Nova would change behaviour | |
| 13:41:40 | lyarwood | it would just support deployment tooling that did | |
| 13:41:40 | sean-k-mooney | yep we can in any install tool | |
| 13:41:54 | sean-k-mooney | because on upgrade they can just set the old default or not set it at all | |
| 13:42:30 | sean-k-mooney | lyarwood: kashyap's spec is chaning the nova defaults | |
| 13:42:42 | sean-k-mooney | lyarwood: which is what i was talking to artom about | |
| 13:42:48 | sean-k-mooney | its why i -1'd it | |
| 13:43:10 | sean-k-mooney | i would like to supprot have default be configureable via a new hw:profile extra spec | |
| 13:43:28 | sean-k-mooney | so you can opt in to different defaults but not actully change them | |
| 13:43:52 | sean-k-mooney | my understanding is kashyap was advocating for changing the default in the libvirt driver directly | |
| 13:44:01 | sean-k-mooney | kind of like we did for the random number generator | |
| 13:44:17 | sean-k-mooney | but i dont think we can really do that for machine_type safely | |
| 13:44:48 | sean-k-mooney | well unless we recored the current machine type when an instance first boots | |
| 13:45:06 | sean-k-mooney | which would rereuie an online data migration to backfile existing instnaces | |
| 13:47:03 | sean-k-mooney | welll im not sure online data migration is the correct term but init_host would have to be extended to iterate over the domain on the host and populate the value in the db for all instance on the host if it is not already set | |
| 13:47:29 | sean-k-mooney | so we would have to start the virtdriver at a minium | |
| 13:48:14 | sean-k-mooney | anyway i need to bring my furniture in form my drive so ill be back in a few minutes | |
| 13:48:47 | kashyap | sean-k-mooney: As I said on my change, I'm very much open to the "important Plan-B" | |
| 13:48:52 | kashyap | artom: lyarwood: ^ | |
| 13:49:10 | kashyap | Where "Plan-B" being [/me goes to get copy/paste text from the change ...] | |
| 13:49:38 | kashyap | - Make installer tools set the precise q35 versioned machine types on all Compute nodes —they anyway have to do this to live migration compatibility. | |
| 13:49:38 | kashyap | - Have all major Nova CI jobs be 'q35' based and passing. | |
| 13:50:52 | artom | sean-k-mooney, yeah, I bring this up on the spec, in upgrade impact - we're likely to "break" windows guests if we change the hardware under them | |
| 14:10:47 | artom | Didn't we have something more recent for "force no local disk/force boot from volume" than https://review.opendev.org/#/c/267673/? | |
| 14:20:49 | lyarwood | artom: we've discussed it since but I didn't think anything actually landed | |
| 14:23:25 | artom | lyarwood, I tracked down https://review.opendev.org/#/c/561284/ | |
| 14:23:34 | artom | Which achieves the same thing | |
| 14:25:07 | francoisp | lyarwood, stephenfin, when you get a chance: https://review.opendev.org/#/c/722142/ | |
| 14:25:38 | lyarwood | ah right I think I missed that actually landing | |
| 14:25:45 | lyarwood | francoisp: looking | |
| 14:26:03 | stephenfin | francoisp: I'm not stable core so I can't help, unfortunately :( | |
| 14:30:42 | sean-k-mooney | artom: we are likely to break linux guest too if they have set thing like hw_vif_model=e1000 | |
| 14:30:52 | sean-k-mooney | or enabled any other pci only device model | |
| 14:31:07 | sean-k-mooney | hw_disk_bus=ide would also break | |
| 14:31:27 | sean-k-mooney | unless we did extra work to add an ide conttoler | |
| 14:32:43 | sean-k-mooney | kashyap: well in also not sure about using the versionded q35 machine type in the installeer unelss the ones that support multiple distos have a different one from each | |
| 14:32:55 | sean-k-mooney | for devstack we should use the unversioned one e.g. q35 | |
| 14:33:01 | sean-k-mooney | so it just works on all distros | |
| 14:33:34 | sean-k-mooney | osp could use the versioned one but ooo likely will want to not as it would have to be updated with ever rhel/centos minor verions | |
| 14:37:21 | kashyap | sean-k-mooney: I mean whatever installer tool a given distro uses | |
| 14:37:47 | kashyap | sean-k-mooney: TripleO works on RPM-based distributions (CentOS, RHEL, Scientific) probably - they can set whatever they want | |
| 14:37:58 | kashyap | sean-k-mooney: If Ubuntu-based distros use a different installer, they will use their own | |
| 14:38:14 | kashyap | sean-k-mooney: For DevStack, of course, we should use unversioned - the plain alias | |
| 14:38:40 | kashyap | The whole point of versioned machie types is, as you might already know, to guarantee live migration compatibility | |
| 14:38:59 | kashyap | sean-k-mooney: TripleO upstream already does that | |
| 14:39:16 | kashyap | sean-k-mooney: Also, note: even for CentOS, the machine types have 'rhel' in their name. | |
| 14:39:38 | lyarwood | elod: could you hit https://review.opendev.org/#/c/722142/ as well please? | |
| 14:40:17 | kashyap | sean-k-mooney: Because CentOS obviously does not have "CentOS QEMU developers" to make the needless effort of making CentOS-based machine types. :) | |
| 14:40:34 | kashyap | sean-k-mooney: To summarize: | |
| 14:40:43 | kashyap | - DevStack -- unversioned, plain 'q35' | |
| 14:41:20 | kashyap | - Installers -- versioned 'q35', based on the QEMU versions your installer + Linux distro can handle | |
| 14:49:17 | sean-k-mooney | kashyap: i assume ooo is using the minium version supported by the os major version then in that case | |
| 14:49:38 | sean-k-mooney | so it will have one version that is never updated for all fo rhel/centos 8/x | |