| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-24 | |||
| 12:53:54 | gibi | sean-k-mooney: cool | |
| 13:37:35 | Qianbiao | Hello, Nova. | |
| 13:37:56 | Qianbiao | Hello, i build a customer vendor_data metadata service. | |
| 13:38:18 | Qianbiao | And i can get vendor through "curl http://169.254.169.254/openstack/2018-08-27/vendor_data2.json" | |
| 13:38:43 | Qianbiao | But cloud-init does not try to load this file, it seems it only loads http://169.254.169.254/openstack/2018-08-27/vendor_data.json | |
| 13:38:48 | Qianbiao | what config should i update? | |
| 13:59:22 | Qianbiao | and i do not see how it works, from the source code: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py#L230-L255 | |
| 13:59:35 | Qianbiao | it seems vendor_data2.json is never loaded. | |
| 14:40:11 | bauzas | dansmith: do you have time for a quick question about the RPC API bump ? | |
| 14:41:13 | bauzas | dansmith: could I just drop https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L786 now (and all the nova-network methods) or should I wait until X ? | |
| 14:42:17 | bauzas | dansmith: afaicu, if the operator would like to pin the RPC API to 5.x, then we would still need to support the method in the manager, but not in the rpcapi since nobody would use this method, right ? | |
| 14:42:47 | bauzas | as only computes would be in Victoria but none of the conductors | |
| 15:10:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 15:22:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Drop models for removed services, features https://review.opendev.org/c/openstack/nova/+/698706 | |
| 15:31:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: virt: Remove 'get_all_bw_counters' API https://review.opendev.org/c/openstack/nova/+/749312 | |
| 15:31:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Remove 'BandwidthUsage', 'BandwidthUsageList' https://review.opendev.org/c/openstack/nova/+/759114 | |
| 15:31:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Drop models for removed services, features https://review.opendev.org/c/openstack/nova/+/698706 | |
| 15:31:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Remove KeyPair model from main DB https://review.opendev.org/c/openstack/nova/+/763989 | |
| 15:31:49 | stephenfin | gibi: Resolved that pep8 issue, if you've a chance to revisit https://review.opendev.org/c/openstack/nova/+/749312 | |
| 15:51:56 | gibi | stephenfin: done | |
| 15:52:02 | stephenfin | ty | |
| 15:52:51 | gibi | I will get back to the db model drop patches later | |
| 15:53:28 | stephenfin | yup, no panic on those :) | |
| 15:56:10 | gibi | I'm far from panic :D | |
| 16:39:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/c/openstack/nova/+/756552 | |
| 17:24:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Merge 'test_hypervisor_status' into 'test_hypervisors' https://review.opendev.org/c/openstack/nova/+/764039 | |
| 17:24:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Drop statistics-style fields from os-hypervisors https://review.opendev.org/c/openstack/nova/+/764040 | |
| 17:33:32 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Update modernize-os-hypervisors-api spec https://review.opendev.org/c/openstack/nova-specs/+/763043 | |
| 17:33:33 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'vcpus', 'vcpus_used' to modernize-os-hypervisors-api spec https://review.opendev.org/c/openstack/nova-specs/+/764041 | |
| 18:30:59 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: update live migration defaults https://review.opendev.org/c/openstack/nova/+/760050 | |
| 18:32:58 | sean-k-mooney | oh i need to update nova.tests.unit.virt.libvirt.test_driver.LibvirtConnTestCase.test_live_migration_monitor_completion | |
| 18:43:02 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: update live migration defaults https://review.opendev.org/c/openstack/nova/+/760050 | |
| 20:38:39 | openstackgerrit | Daniel de Oliveira Pereira proposed openstack/nova master: Avoid changing transport_url when updating Cell0 https://review.opendev.org/c/openstack/nova/+/762433 | |
| 20:42:52 | artom | Is `sync-devstack-data : Push the CA certificate` failing a new thing? | |
| 20:43:17 | artom | I'm hitting it on a whitebox patch, but can't for the life of me figure out how my change could possibly be causing it | |
| 20:43:25 | artom | So I'm wondering if it's maybe unrelated and a known issue? | |
| 20:43:56 | sean-k-mooney | im not aware of it | |
| 20:44:03 | sean-k-mooney | did it fail on my job too? | |
| 20:44:24 | sean-k-mooney | also #openstack-qa might know | |
| 20:46:55 | artom | sean-k-mooney, https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/764042 | |
| 20:47:09 | artom | The controller times out waiting for the compute n-cpu to come up | |
| 20:47:24 | artom | And no n-* logs on the compute, just that devstack CA error that I can see | |
| 20:48:05 | gmann | artom: at least not happening on other patches, at least it running fine on some latest patches run | |
| 20:48:36 | sean-k-mooney | nternal error: Unknown CPU feature sse3 | |
| 20:48:44 | sean-k-mooney | https://zuul.seanmooney.info/t/openstack/build/2ab2af1df163459e9b88aecce13a59d3/log/controller/logs/screen-n-cpu.txt#1961 | |
| 20:48:53 | gmann | k moving to qa | |
| 20:49:27 | sean-k-mooney | same upstream | |
| 20:49:29 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/c6152ded026647dbb76c9d95721832f2/log/controller/logs/screen-n-cpu.txt#1946 | |
| 20:49:37 | sean-k-mooney | so i guess it sse not sse3 | |
| 20:49:55 | sean-k-mooney | oh | |
| 20:49:58 | sean-k-mooney | its ssse3 | |
| 20:50:02 | artom | sean-k-mooney, huh, it doesn't directly explain the devstack CA thing | |
| 20:50:09 | artom | But definitely needs fixing | |
| 20:50:23 | sean-k-mooney | right but that is why n-cpu did not start | |
| 20:50:32 | artom | gmann, ^^ I'll push a new version, we'll see if the CA thing as well | |
| 20:50:37 | artom | It would indeed | |
| 20:50:45 | sean-k-mooney | ill swap to qa | |
| #openstack-nova - 2020-11-25 | |||
| 00:57:11 | openstackgerrit | norman shen proposed openstack/nova-specs master: Adds spec for instance live resize https://review.opendev.org/c/openstack/nova-specs/+/141219 | |
| 04:16:36 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Correct some spell errors https://review.opendev.org/c/openstack/nova-specs/+/764117 | |
| 05:09:51 | openstackgerrit | Merged openstack/os-vif master: Fix hacking min version to 3.0.1 https://review.opendev.org/c/openstack/os-vif/+/755168 | |
| 07:45:16 | openstackgerrit | wushiming proposed openstack/os-vif master: Remove the unused coding style modules https://review.opendev.org/c/openstack/os-vif/+/760491 | |
| 10:18:38 | openstackgerrit | Merged openstack/nova-specs master: Correct some spell errors https://review.opendev.org/c/openstack/nova-specs/+/764117 | |
| 10:21:32 | gibi | I feel that the discussion about the DB creds for the nova-compute ML thread is going nowhere. I'm getting fustrated about it as I feel I just wasting time thinking about it. | |
| 10:22:53 | stephenfin | amen :( | |
| 10:25:36 | lyarwood | I've honestly kept away from it given the number of people already involved. | |
| 10:25:58 | lyarwood | That said it is turkey week in the US so I assume that might be causing things to slow somewhat? | |
| 10:26:11 | lyarwood | stephenfin: https://news.ycombinator.com/item?id=25202143 - something to think about for the next in person PTG | |
| 10:26:36 | stephenfin | so what you're saying is, no better time to ram through whatever we want... 😈 | |
| 10:27:00 | stephenfin | Hahahaha | |
| 10:27:25 | gibi | I like bonfire so I support the code burn | |
| 10:27:57 | stephenfin | It's effectively a book burning. Who doesn't love a good book burning. | |
| 10:28:30 | gibi | the thing is that we already agreed (I think) that we don't merge the breaking change in W we wait for X. So I don't thing we can use Turkey week to sabotage everybody | |
| 10:28:49 | gibi | but these are the "wrong books" so we have to burn them! | |
| 10:28:56 | stephenfin | Oh, I was joking :-D That would be a terrible idea, heh | |
| 10:29:16 | gibi | stephenfin: I know, hence the word sabotage :D | |
| 10:29:29 | lyarwood | stephenfin: now you tell me, I've already +W'd everything | |
| 10:29:34 | stephenfin | phew | |
| 10:30:38 | gibi | btw dansmith is out for the rest of the year and he was really active and helping in the ML thread so it is fully possible that if I ignore the thread for a while it will simply die out | |
| 10:30:59 | gibi | but I'm not sure it looks good for a PTL to ignore this :/ | |
| 10:37:03 | bauzas | gibi: my personal take on this is that we made our responsibility in explaining the security risk | |
| 10:38:12 | bauzas | the WSGI app issue is reasonable to fix | |
| 10:38:57 | gibi | yes, I'm fully supportive to fix the sys.argv usage in WSGI regardless of the ML thread | |
| 10:39:12 | bauzas | but then, if you feel you're entering a rathole, make a big signal in the Wallaby release that DB creds are exposed and tell we'll make it hardstop in X | |
| 10:39:13 | gibi | that was a nice thing come out of the thread | |
| 10:39:28 | owalsh | gibi: hey, I'm a bit confused by the conductor [api_database]connection discussion.... | |
| 10:39:47 | bauzas | from a project perspective, we're just verifying the security exposure, that's it | |
| 10:39:53 | gibi | bauzas: this is exaclty what Dan proposed on the ML and I now implemented in code | |
| 10:40:12 | bauzas | gibi: this long talkative thread prevented me to read | |
| 10:40:15 | gibi | bauzas: so in W it is just a warning, in X it is hard fail. | |
| 10:40:24 | bauzas | then, we have actions | |
| 10:40:33 | gibi | but we are getting push back on the hard fail still | |
| 10:40:39 | owalsh | we need api db set for cell conductors for affinity checks, so how can we use it to determine if it's a cell/super conductor? | |
| 10:40:48 | bauzas | gibi: we could revisit then on X | |
| 10:41:10 | gibi | bauzas: yes, but I don't know how the discussion will be differnt :) | |
| 10:41:14 | bauzas | gibi: don't waste your energy on it, and the patch in question that would turn hardstop would just be a gerrit change | |
| 10:41:35 | gibi | owalsh: if you specify [api_database]connection to a nova-conductor service the it becomes a super conductor | |
| 10:41:47 | bauzas | I'm personnally convinced that in terms of productivity, gerrit wins over IRC which itsels wins over emails | |
| 10:41:57 | owalsh | gibi: dansmith and sean-k-mooney1 said it needs to be set on the cell conductor too | |
| 10:42:02 | bauzas | never ever expect good things to happen from a long ML thread | |
| 10:42:17 | gibi | owalsh: if your deployment needs affinity support and you are affraid of race condition in affinity then you need to make each conductor a super conductor | |