Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-25
14:41:49 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Name Enums https://review.opendev.org/708707
15:29:48 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.libvirt' https://review.opendev.org/703147
15:29:48 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.vmwareapi' https://review.opendev.org/703148
15:29:49 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.hyperv' https://review.opendev.org/703149
15:29:49 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.powervm' https://review.opendev.org/703150
15:29:50 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.xenapi' https://review.opendev.org/703151
15:29:50 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve final issues with 'nova.virt' https://review.opendev.org/703153
15:29:51 openstackgerrit Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.cmd', 'nova.console', 'nova.db' https://review.opendev.org/703154
15:44:14 openstackgerrit Stephen Finucane proposed openstack/nova master: Unplug VIFs as part of cleanup of networks https://review.opendev.org/663382
15:44:14 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix incorrect vm and task state after build failure race https://review.opendev.org/689388
16:52:13 rm_work gibi: hey, thanks for taking a look at the routed_segments patch
16:52:27 rm_work I responded a bit, I am hoping it is clearer what the goal is
16:52:49 rm_work especially after sean's latest response on the other routed-networks patch
16:53:31 rm_work that work seems a LONG way off
16:54:22 gibi rm_work: ack, I will check back tomorrow
16:54:24 mriedem gibi: dansmith: be aware https://review.opendev.org/#/c/694428/
16:54:43 gibi mriedem: hi! what is up? :)
16:55:06 gibi mriedem: thanks for the heads up
16:55:41 mriedem if you'd like to avoid a CVE...
16:55:44 mriedem heed my warning!
16:55:53 dansmith okay yeah I think there's another patch to do this as well, IIRC
16:55:53 mriedem ooo booo
16:57:10 mriedem the event reporter stuff passes exc_val through as a kwarg i think which formats the exception message before we store it, something like that - it's been awhile, but that could result in storing sensitive info unlike how instance faults work for non-nova exceptions
16:59:26 gibi no I definitly don't want CVEs
17:02:29 rm_work gibi: cool thanks
17:03:27 rm_work mriedem: coincidentally it's your routed-net patch that I've got a similar CR up for, and am having to justify why/how it's different, lol
17:03:49 rm_work Curious if you'd mind taking a look and giving your 2c
17:04:54 rm_work https://review.opendev.org/#/c/709280/
17:07:04 rm_work Enabling use cases like this one in Octavia: https://review.opendev.org/#/c/706153/
17:07:54 rm_work Or a very simple patch to let live migrate work:
17:08:26 rm_work https://www.irccloud.com/pastebin/L3Y68sS2/live_migrate.patch
17:09:28 rm_work (which if I get any traction on the filter, I'll formalize as a follow-up CR with tests and all)
17:23:08 mriedem rm_work: i wip'ed that patch up sitting in the last denver ptg nearly a year ago and have lost pretty much all context on it
17:23:41 mriedem my gripe with the routed networks feature in neutron for years has been we have no integrated CI job testing it since there are moving parts between nova/placement/neutron
17:24:05 mriedem table stakes (as i think i've said before) for hacking on that feature would be to get a CI job going to make sure that what exists today works before adding more complexity
17:24:13 mriedem but that's my $.02
17:24:22 mriedem which is basically $.00 now
17:28:08 gibi and there is an attempt to add CI coverage to routed-net but https://review.opendev.org/#/c/665155/
17:28:32 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Avoid circular reference during serialization https://review.opendev.org/709798
17:28:35 gibi but it is going along slowly
17:29:01 mriedem how does that not depend on configuration changes to devstack though?
17:29:15 mriedem i thought there was host aggregate stuff that had to be all synced up, or is that done as part of the test setup?
17:29:56 gibi doen in the tempest test
17:30:01 gibi at least the aggregate part
17:30:42 gibi based on the test doc :)
17:31:08 gibi honestly I still don't know how this feature supposed to work
17:32:25 gibi stephenfin: do you have any power over oslo.serialization? I have filed a bug where I might need some support about how we should fix it https://bugs.launchpad.net/oslo.serialization/+bug/1864678
17:32:25 openstack Launchpad bug 1864678 in oslo.serialization "jsonutils.to_primitive does not follow the protocol required by json.dump" [Undecided,New]
17:33:53 gibi o/
19:28:49 openstackgerrit Merged openstack/nova master: Remove unnecessary parentheses https://review.opendev.org/709652
19:29:03 openstackgerrit Merged openstack/nova master: Functional test for UnexpectedDeletingTaskStateError https://review.opendev.org/689278
19:29:19 openstackgerrit Merged openstack/nova master: Use reasonable name for provider mapping https://review.opendev.org/698735
20:03:59 efried prometheanfire, dansmith: https://review.opendev.org/#/c/708707/ seems to be working. Unless there's something else we need to do to it (dansmith?) I assume the process is:
20:03:59 efried - update the commit message to remove the dep
20:03:59 efried - merge it
20:03:59 efried - recheck and merge the dep
20:11:30 prometheanfire sgtm
20:15:55 dansmith efried: recheck to make sure the change works on the old/current version too you mean?
20:16:00 dansmith but yeah, I guess that's the process
20:33:07 sean-k-mooney am i right in thinkin that https://review.opendev.org/#/c/699554/17 or actully the patch before it are technically all that are need to boot a vm with a cyborg deivce
20:33:59 sean-k-mooney the rpc bump patch is in merge conflict so i cant currently test my multinode job with that so i was temporaly going to depend on the earlier patch to get a ci run tonight
20:35:24 sean-k-mooney the patches after https://review.opendev.org/#/c/699554/17 while important are reall just nice to haves in terms of actully executing tempest full to check the job runs correctly
20:38:45 sean-k-mooney ill assume yes and kick off a run. ill be away for an hour or so and check in with it later o/
20:38:47 openstackgerrit Merged openstack/nova stable/train: Create instance action when burying in cell0 https://review.opendev.org/701279
20:46:58 efried dansmith: recheck because currently it is running against nova that doesn't have this patch
20:52:16 openstackgerrit Jason Anderson proposed openstack/nova master: Update resource tracker to use per-hypervisor lock https://review.opendev.org/709832
21:41:10 openstackgerrit Eric Fried proposed openstack/nova master: Name Enums https://review.opendev.org/708707
#openstack-nova - 2020-02-26
00:48:54 sean-k-mooney dansmith: efried just heading to bed but my multinode cyborg tempest full job https://review.opendev.org/#/c/709641/5 just completed https://48ef08cde8cc22034a1d-8011a2266d21f0c09baf1c83d6d5002e.ssl.cf5.rackcdn.com/709641/5/check/cyborg-multinode-tempest-full/e4d260f/testr_results.html
00:49:40 sean-k-mooney i have only skimmed them quickly but i belive it shows that vms can be booted with cyborg flavor initail since tempest.api.compute.servers.test_create_server.ServersTestJSON.test_host_name_is_same_as_server_name passed i change the default flavor to request a fake deivce
00:50:21 sean-k-mooney it also repoduced teh 401 issue where the keystone middelware eventually starts rejecting the token because it think it expires
00:51:19 sean-k-mooney and i can see the live migration operations fail with Details: {'code': 400, 'message': 'No valid host was found. Unable to move instance 229ab495-b151-4522-b8dd-fa5818e302dd to host ubuntu-bionic-vexxhost-sjc1-0014809343. The instance has complex allocations on the source host so move cannot be forced.'}
00:52:24 sean-k-mooney so i think that is implying that 1 the vm was created with the cybrog resouces and two live migration is being rejected before we get to the driver which is good
00:52:45 sean-k-mooney that was from test_live_block_migration
00:54:45 sean-k-mooney anyway im calling it a night o/ hopefully that will be useful as it is repoducing the same issues i was seeing and its now automated so easy to rerun
01:55:13 openstackgerrit Brin Zhang proposed openstack/nova master: Add test coverage of existing os-volumes-attachments policies https://review.opendev.org/709929
02:00:51 openstackgerrit Brin Zhang proposed openstack/nova master: Introduce scope_types in os-volumes-attachments policy https://review.opendev.org/709388
06:51:48 openstackgerrit Brin Zhang proposed openstack/nova master: Fix os-volumes-attachments policy to be admin_or_owner https://review.opendev.org/709955
07:35:32 brinzhang melwitt, gmann, stephenfin: is bug 1864776 real? can you all check?
07:35:32 openstack bug 1864776 in OpenStack Compute (nova) "os-volumes-attachments API policy is allowed for everyone even policy defaults is admin_or_owner" [Undecided,In progress] https://launchpad.net/bugs/1864776 - Assigned to Brin Zhang (zhangbailin)
07:40:08 brinzhang gmann: the new policy of admin_api is {self.legacy_admin_context, self.system_admin_context, self.project_admin_context}, and new policy of the admin_or_owner is {self.legacy_admin_context, self.system_admin_context, self.project_admin_context, self.project_member_context, self.system_member_context, self.system_reader_context, self.system_foo_context, self.project_foo_context, self.project_reader_context, self.other_project_member_context},
07:40:08 brinzhang it's all of the author contexts.}
07:40:29 brinzhang gmann: Understand of this right?
10:04:37 openstackgerrit Kevin Zhao proposed openstack/nova master: Add default cpu model for aarch64 https://review.opendev.org/709494
10:16:28 openstackgerrit Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811
10:16:29 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812
10:16:29 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429
10:16:30 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.82 allowing boot from volume rescue https://review.opendev.org/701430
10:16:30 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212
10:16:30 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Support boot from volume stable device instance rescue https://review.opendev.org/701431
10:18:18 gibi rm_work: responded in https://review.opendev.org/#/c/709280 I'm happy to help with technicalities but I missing the what the feature is supposed to achive and how the existing impl in neutron works
10:19:51 rm_work gibi: just read it, thanks!
10:20:07 rm_work so, the key is that it's not really a feature for end users at all -- it's for service integration cases
10:20:37 rm_work the octavia use-case is here: https://review.opendev.org/#/c/706153/
10:21:07 rm_work gibi: as it is, neutron has been creating aggregates for each segment_it in a routed network automatically, for like... 3 cycles already maybe?
10:24:12 rm_work so for example, if i take a look at my Staging environment's aggregate list, it looks like this: http://paste.openstack.org/show/7YyK5FtL2OiXgErAjMbM/
10:24:41 rm_work that aggregate was automatically created by neutron because it was configured as a routed network with a segment and those HVs were assigned to that segment in neutron
10:25:56 rm_work gibi: i don't think there's really any further work to be done -- this filter *just works* already for the intended purpose -- allowing services to hint to nova which aggregate to schedule to, based on network segment
10:26:05 rm_work the real challenge is just getting it merged :)
10:26:51 rm_work I know of at least two companies running this filter on live clouds already, one of them for many years
10:27:57 rm_work the second use-case is live-migrate, and I already have the basic patch for it (again, has been running for quite a while in some clouds) but I'm not spending the effort to get it all prettified yet until I have some confidence that this filter might be accepted

Earlier   Later