| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-17 | |||
| 12:42:58 | sean-k-mooney | they might | |
| 12:43:18 | sean-k-mooney | but then dont on x86 anyway as far as i know | |
| 12:43:19 | kashyap | For UEFI boot, q35 is mandatory; see the next patch, please, where we handle it | |
| 12:43:32 | sean-k-mooney | no its not | |
| 12:43:42 | sean-k-mooney | at least libvirt does not require that | |
| 12:44:05 | kashyap | Hmm, /me tries :-) | |
| 12:50:30 | kashyap | Modifying existing SB-enabled VMs to 'pc' is not a good idea; as the entire PCIe topo needs to change, etc. Will test on a diff. box later today | |
| 12:51:00 | sean-k-mooney | secure boot wont work for pc | |
| 12:51:06 | sean-k-mooney | but uefi should | |
| 12:51:11 | sean-k-mooney | imy trying it locally too | |
| 12:51:27 | sean-k-mooney | but im pretty sure i have done this in the past | |
| 12:51:31 | kashyap | Right, please try it. (Yeah, that's for sure: SB won't of course work for 'pc') | |
| 12:51:56 | kashyap | But I'm also 99.9999981% sure, UEFI with OVMF won't work with 'pc' | |
| 12:53:28 | sean-k-mooney | it boots with a black scree and 100% cpu usage so it does not look like its that happy | |
| 12:53:55 | sean-k-mooney | that said i am pretty sure i did use uefi with pc machine type in the past | |
| 12:53:56 | kashyap | Yep. OVMF is 'q35' only | |
| 12:54:05 | sean-k-mooney | maybe it was a different firmware image | |
| 12:54:06 | kashyap | I bet euros-to-croissants | |
| 12:56:00 | kashyap | sean-k-mooney: Thanks for the eyes so far. | |
| 13:01:32 | openstackgerrit | Sundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification. https://review.opendev.org/682637 | |
| 13:05:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test heal port allocations in nova-next https://review.opendev.org/669879 | |
| 13:17:47 | gibi | mriedem: fixed your nits in ^^ | |
| 13:18:06 | gibi | mriedem: and also in https://review.opendev.org/#/c/666857 | |
| 13:18:45 | gibi | ahh you already hit the heal port patch, thanks for that | |
| 13:20:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Only allow one scheduler service in tests https://review.opendev.org/682486 | |
| 13:21:46 | mriedem | oh no a full rebase on 666857 | |
| 13:21:50 | mriedem | means i can't diff to PS7 | |
| 13:21:53 | mriedem | why gibi why | |
| 13:22:25 | gibi | mriedem: there is a separate ps for the rebase but yeah I screewed up the order of those actions :/ | |
| 13:22:28 | gibi | sorry | |
| 13:22:39 | gibi | I should have pushed the fix then the rebase | |
| 13:23:54 | bauzas | I leave it here on purpose :) https://sbauza.wordpress.com/2014/11/14/how-to-compare-2-patchsets-in-gerrit/ | |
| 13:24:27 | bauzas | (pretty old but still accurate :) ) | |
| 13:24:36 | sean-k-mooney | bauzas gitreview -m does not always work | |
| 13:25:08 | sean-k-mooney | you need to do a 4 way diff | |
| 13:25:24 | sean-k-mooney | which i think is what you came up with later | |
| 13:25:48 | bauzas | sean-k-mooney: this post was made in 2014 | |
| 13:26:15 | bauzas | (and then I stopped writing stupid things) | |
| 13:27:01 | sean-k-mooney | vimdiff <(git diff ${MY_PS1_BRANCH}^ ${MY_PS1_BRANCH}) <(git diff ${MY_PS2_BRANCH}^ ${MY_PS2_BRANCH}) | |
| 13:27:12 | sean-k-mooney | is bassicaly a 4 way diff | |
| 13:27:24 | sean-k-mooney | so that will do what you want and eliminate rebase changes | |
| 13:29:33 | sean-k-mooney | i kind of want to add that to git review at some point | |
| 13:30:21 | sean-k-mooney | that said i more want it to be in gerrit which is thould be if/when we upgrade the openstack gerrirt to the polomer ui | |
| 13:30:59 | bauzas | sean-k-mooney: yeah, true and false, it's a diff of diffs | |
| 13:31:08 | sean-k-mooney | yes | |
| 13:31:25 | bauzas | I just use vimdiff because the UI makes the diff most easier to read and catch the differences | |
| 13:31:47 | sean-k-mooney | i dont use vimdiff but i like meld | |
| 13:31:58 | bauzas | but you could technically stick with diff (with -y, side-to-side) and just grep a few things | |
| 13:31:59 | stephenfin | sean-k-mooney: They won't accept it | |
| 13:32:00 | sean-k-mooney | i rarely use it but when i do it works well | |
| 13:32:02 | stephenfin | They being infra | |
| 13:32:10 | sean-k-mooney | stephenfin: why not | |
| 13:32:26 | stephenfin | Something about git-review being a dead simple tool that shouldn't grow any additional functionality | |
| 13:32:32 | stephenfin | which I kind of get | |
| 13:32:36 | bauzas | meld works too, I mean litterally any decent editor that supports merge diffs | |
| 13:32:39 | sean-k-mooney | it already has -m | |
| 13:32:46 | stephenfin | it probably shouldn't have that | |
| 13:32:48 | bauzas | -m has a very different behaviour | |
| 13:33:02 | sean-k-mooney | if you dont do the rebase in -m its the same | |
| 13:33:17 | bauzas | the 'if' makes the difference | |
| 13:33:32 | sean-k-mooney | as you said -m rebase both to master to elimitate the need to diff diffs | |
| 13:33:50 | sean-k-mooney | but both are trying to do the same thing | |
| 13:34:04 | sean-k-mooney | elimiate chagne that are not part of your actual patch | |
| 13:34:04 | bauzas | correct but then you have to handle merge conflicts if they occur | |
| 13:34:18 | bauzas | that's unnecessary work on my opinion | |
| 13:34:28 | sean-k-mooney | yes whcih is why i dont like how -m works | |
| 13:34:31 | sean-k-mooney | yep | |
| 13:35:16 | bauzas | anyway | |
| 13:35:25 | bauzas | just saying | |
| 13:36:02 | bauzas | this is a problem I've seen from 6 years ago, I bet someone would have come up with some stuff in git review if infra was happy with | |
| 13:36:12 | mriedem | gibi: ok comments in https://review.opendev.org/#/c/666857/ | |
| 13:36:45 | gibi | mriedem: looking | |
| 13:37:06 | stephenfin | sean-k-mooney: does glance have documentation for flavor extra specs? | |
| 13:37:09 | bauzas | snap, mriedem beated me | |
| 13:37:24 | mriedem | stephenfin: flavors != glance | |
| 13:37:31 | mriedem | you mean image properties? | |
| 13:37:40 | mriedem | https://docs.openstack.org/glance/latest/admin/useful-image-properties.html | |
| 13:37:50 | sean-k-mooney | stephenfin: it has metadefs for them | |
| 13:38:08 | stephenfin | mriedem: Nope, flavor extra specs. I know it's not their domain but sean-k-mooney had mentioned some about flavor definitions in glance before | |
| 13:38:09 | mriedem | it has metadefs for image properties | |
| 13:38:11 | sean-k-mooney | and it has the image properties that mriedem linked | |
| 13:38:11 | mriedem | not flavor extra specs | |
| 13:38:21 | sean-k-mooney | yes they do | |
| 13:38:53 | sean-k-mooney | the metadefs cover flavors image and host agrrates metatdata | |
| 13:39:17 | sean-k-mooney | https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json#L9-L14 | |
| 13:39:53 | sean-k-mooney | its where all the documenation in glance and heat comes form for those values | |
| 13:40:14 | sean-k-mooney | *horizon and heat | |
| 13:40:22 | mriedem | huh | |
| 13:40:40 | mriedem | i found https://github.com/openstack/glance/blob/master/etc/metadefs/compute-trust.json which we removed that filter from nova years ago...so it's good to know the information about this stuff is in glance and is stale | |
| 13:41:07 | sean-k-mooney | horizon and heat both autogenerat there ui from the glance metadef api | |
| 13:41:30 | sean-k-mooney | yes i have been slowly trying to update it every now and then | |
| 13:41:45 | sean-k-mooney | i would like to bring it fully up to date envtually | |
| 13:41:50 | stephenfin | IMO those definitions should live in nova and be thrown across the wall on a regular cadence to glance | |
| 13:42:11 | sean-k-mooney | they should live in a seperate project that is not part of either | |
| 13:42:16 | sean-k-mooney | but use by all services | |
| 13:42:52 | stephenfin | or we could just expose it via an API that glance could consume? | |
| 13:42:58 | sean-k-mooney | glance currentlly is our metadata defintion store/repositroy | |
| 13:43:10 | sean-k-mooney | glance already exposes this via an api | |
| 13:43:13 | sean-k-mooney | that others consume | |
| 13:43:22 | sean-k-mooney | we coudl move to all service exposing the same api | |