Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-17
09:01:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: move_allocations https://review.openstack.org/591810
09:01:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: support claim_resources https://review.openstack.org/583667
09:01:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: more tests for delete allocation cases https://review.openstack.org/591811
09:02:48 kashyap johnthetubaguy: Is there an Etherpad discusion about SEV at the PTG?
09:03:15 gibi bauzas: rebase for the consumer gen support is up ^^
09:03:17 johnthetubaguy kashyap: nothing much of interest, its in the main etherpad, I think it was clear non of us really know how to expose it yet
09:03:26 kashyap johnthetubaguy: On this I presume? -- https://etherpad.openstack.org/p/nova-ptg-stein
09:03:33 gibi bauzas: I continue with the nested a_c support rebase
09:03:35 johnthetubaguy kashyap: yeah, thats the one
09:04:09 kashyap johnthetubaguy: Damned if I can find the relevant line (`grep`ed for "SEV", "secure")
09:04:15 kashyap Ah, it's line-848
09:04:25 kashyap "Exposing encrypted virtualization to operators"
09:04:31 bauzas gibi: oh cool
09:04:39 johnthetubaguy kashyap: that sounds correct
09:04:42 bauzas gibi: don't worry with the a_c rebase
09:04:48 bauzas I'd like to upload it
09:04:57 kashyap johnthetubaguy: Is that aimed at "Stein" release?
09:05:26 gibi bauzas: I need the a_c rebase to rebase the bandwidht series top of it :)
09:05:32 johnthetubaguy well, only in the same way everything new is sort of aimed at stein
09:05:48 gibi bauzas: but if you working on that that is fine then I will wait
09:06:14 johnthetubaguy kashyap: is the intel SGX version going in soon, do you know?
09:06:57 kashyap johnthetubaguy: Afraid, I don't know.
09:07:13 gibi bauzas: just to be on the safe side. are you rebasing a_c on top of consumer gen support?
09:07:15 kashyap johnthetubaguy: I think what you're getting at is we need to take both Intel and AMD into consideration, obviously
09:07:31 johnthetubaguy kashyap: no worries, based on a blog I am reading, it sounds like SGX isn't that usable yet https://lwn.net/Articles/686808/
09:07:35 kashyap johnthetubaguy: (Assuming Intel is going to come up w/ a similar thing 'soon')
09:08:11 kashyap Ah, the venerable LWN
09:08:27 johnthetubaguy kashyap: FWIW, our customer's medical data processing probably needs this at some point, although per host allocation works in the meantime
09:08:33 kashyap johnthetubaguy: Seems to be from 2 years ago; wonder what's the state today. But anyway, I don't see this merging anytime soon in Nova
09:08:44 johnthetubaguy kashyap: yeah, totally
09:08:50 bauzas gibi: I was indeed
09:08:52 kashyap Given the complexity of it, and the "head-wrapping" required
09:08:59 johnthetubaguy +1
09:09:28 bauzas gibi: now I need to rebase on top of your last update, but that should be fine
09:09:40 gibi bauzas: cool
09:10:12 bauzas gibi: well, sorry I wasn't clear
09:10:14 johnthetubaguy kashyap: feels like it should work a bit like volume encryption, once its working correctly, but want to get my hands on it first, which is hard given my customer is an Intel only shop right now, this might change things I guess!
09:10:25 johnthetubaguy kashyap: will let you know if I hear any more
09:10:26 bauzas I was working on rebasing tetsuro's branch on top of master
09:11:01 kashyap johnthetubaguy: Sure. (And yeah, the use cases are definitely critical.)
09:11:24 bauzas gibi: most of the conflicts were due to the 1.30 microversion for reshapes
09:12:45 gibi bauzas: no problem. If nested a_c support ends up top of top of consumer_gen support then I'm OK.
09:13:07 bauzas gibi: yup, I just rebased the whole series
09:13:13 gibi bauzas: coolio
09:13:27 bauzas gibi: now, rebasing on top of your latest rev should be trivial hopefully
09:14:31 bauzas gibi: https://review.openstack.org/#/c/583667/ is the top patch of your series, right?
09:14:57 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'virt' as the default machine type for ARMv7 https://review.openstack.org/602592
09:15:15 kashyap bauzas: ^ If you want to put it out of its misery :-)
09:18:55 gibi bauzas: yes, it is
09:21:03 openstackgerrit Sylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672
09:23:38 bauzas gibi: ^
09:23:44 gibi bauzas: awesome
09:24:15 gibi bauzas: shall I rebase the functional tests for the change or you will do that too?
09:24:24 bauzas gibi: I can try
09:24:41 gibi bauzas: if you haven't started yet, then I can continue with the functionals
09:24:56 bauzas gibi: fair enough
09:25:05 bauzas I'll have to bail out by 11:35
09:25:15 gibi bauzas: then I will jump on the functionals
09:25:17 bauzas so I won't have time to fix this
09:25:31 bauzas wait a sec, I'll amend tetsuro's change based on your good commebnt
09:25:35 bauzas gibi: ^
09:25:38 gibi bauzas: sure
09:30:03 bauzas gibi: good news is that I checked the unittests with the rebase and they're good
09:32:04 kashyap Lately, I've begun doing this when running `git-review`, others too?
09:32:08 kashyap $ git review -R --no-custom-script
09:32:13 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic https://review.openstack.org/602805
09:33:26 openstackgerrit Sylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672
09:33:38 bauzas gibi: updated change ^
09:33:47 bauzas gibi: you can rebase functional tests on top of this
09:33:56 gibi bauzas: thanks, I will do that
09:47:36 openstackgerrit Brin Zhang proposed openstack/nova master: Resource retrieving: add changes-before filter https://review.openstack.org/599276
10:05:48 bauzas naichuans_: sorry, just saw your reply on the ML
10:06:15 bauzas naichuans_: I'm back but I'm off until 1140UTC
10:06:31 bauzas naichuans_: after that, I think you should be off too
10:06:42 bauzas naichuans_: so let's discuss tomorrow if you want
10:10:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: Functional test for booting with nested resources https://review.openstack.org/527728
10:10:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Functional test for moving with nested resources https://review.openstack.org/587350
10:12:35 bauzas gibi: just saw ^
10:12:50 bauzas coolio, that will allow me to add a new functional test
10:13:13 gibi bauzas: functional tests passes, but I have to think about what we can consider as enough test coverage
10:16:05 bauzas gibi: we need allocation candidates for creating a new instance
10:16:08 bauzas needed*
10:16:13 bauzas anyway, me is off now
10:39:40 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847
10:39:40 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267
10:39:40 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec.RequestGroup versioned object https://review.openstack.org/568840
10:39:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
10:39:43 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
10:39:43 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459
11:08:25 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications https://review.openstack.org/603079
11:16:45 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic https://review.openstack.org/602805
11:29:37 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor NeutronFixture https://review.openstack.org/588338
11:31:16 openstackgerrit Merged openstack/nova master: Fix docs and add functional test for AggregateMultiTenancyIsolation https://review.openstack.org/601835
11:31:42 openstackgerrit John Garbutt proposed openstack/nova master: Deprecate ComputeCapabilitiesFilter https://review.openstack.org/603102
11:45:26 openstackgerrit huanhongda proposed openstack/nova stable/pike: Fix bug case by none token context https://review.openstack.org/603044
12:23:03 Roamer` hi, possibly stupid question incoming :) If a company has two different physical datacenters, and an OpenStack setup in each of them, how would it be best to make it possible to (cold-)migrate instances (with attached volumes) between them? Is there a way to migrate an instance between two regions of the same cluster? The two options I've found so far is "openstack server image create" (which
12:23:09 Roamer` creates a zero-byte image for a volume-backed instance, though maybe I've configured something wrong) and cinder backup/restore; are there other options?
12:45:51 bauzas gibi: thanks for the updates
12:46:17 gibi bauzas: you are welcome
12:47:05 gibi bauzas: I think the series works as my bandwidth functional tests worked on top. But I wouldn't be surprised if migrate or evacuate would eventually be found broken

Earlier   Later