Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-24
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
10:42:25 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Don't detach volumes when RescheduledException raised without retry https://review.opendev.org/c/openstack/nova/+/757894
10:42:29 lyarwood stephenfin / gibi ; ^ added some additional context to this review btw, I still think it's better to be consistant here and let users clean things up by deleting their ERROR'd out instances.
10:42:51 bauzas gibi: owalsh: I've seen the superconductor proposal, this is way not good at all
10:43:01 bauzas because sometimes operators need flexibility
10:43:14 bauzas and a project shouldn't be opiniating about the service grouping
10:43:25 gibi lyarwood: ack
10:43:27 bauzas (I mean, the service deployment grouping)
10:43:51 kashyap gibi: Wow, impacting seven separate groups with that ML thread ... bold decision ;-)
10:44:33 bauzas gibi: owalsh: I personnally feel that a "superconductor" option could be a thing for operators as a way to group a set of project options
10:44:40 gibi bauzas: while I agree, ML threads has a wider reach than IRC and gerrit
10:44:45 bauzas but it shouldn't be a thing for the project itself
10:45:01 bauzas gibi: I'm not saying ML threads are unnecessary

Earlier   Later