Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-17
07:04:20 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/601047
07:28:33 bauzas good morning nova
07:40:20 gibi bauzas: good morning
07:40:44 gibi bauzas: I'm still working on the rebase of the nested allocation candidate patch series. I hope I can push it today
07:40:52 bauzas gibi: good morning, hope you're not too jetlaggued
07:41:03 bauzas gibi: no worries, I was doing the same
07:41:14 gibi bauzas: I'm pretty OK actually. Yesteday I slept 15 hours in a row
07:41:17 bauzas gibi: and I need to understand tetsuro's changes
07:41:20 bauzas wow
07:41:31 bauzas I'm happy for you
07:41:51 bauzas for me, I looked for 5 mins where my keys were in my car when going back from the school
07:42:30 bauzas but then I saw they were still on the door...
07:42:41 gibi :) jetlag is a nasty thing
07:42:57 bauzas :)
07:43:36 gibi I had my moment yesterday too. I forget like 3 times that I left half of the grocery in the car
07:44:02 gibi the first day is always about survival :)
07:44:05 bauzas lol
08:15:03 openstackgerrit huanhongda proposed openstack/nova stable/pike: Fix bug case by none token context https://review.openstack.org/603044
08:34:21 kashyap Does this require a release note, because we're changing the default? https://review.openstack.org/#/c/602592/ ("libvirt: Use 'virt' as the default machine type for ARMv7")
08:43:33 bauzas kashyap: I'd tend to say yes, there is an upgrade impact AFAICS
08:44:02 kashyap bauzas: Yeah, let me add a note. But I have no clue how many (if at all) use ARMv7
08:44:09 kashyap bauzas: Thanks for the view!
08:45:43 bauzas kashyap: existing guests wouldn't be changed tho, right?
08:46:02 kashyap bauzas: It will be *only* if:
08:46:25 kashyap (a) Upgrade Nova with this patch; (b) Start and stop the guest -- then, it will pick up this new machine type.
08:46:34 bauzas yeah of course
08:46:37 kashyap bauzas: So, it won't affect a running guest under its feet.
08:46:37 bauzas or rebuild
08:46:43 kashyap bauzas: Yep.
08:47:28 bauzas kashyap: I'm trying to put my feet into app developer shoes
08:47:53 bauzas kashyap: I imagine I would be surprised if my guest architecture would be different, hence the relnote
08:48:33 kashyap bauzas: Sure. So I'll add an upgrade note. Fine with you?
08:48:44 bauzas kashyap: yup
08:48:51 kashyap Thanks for looking.
08:58:09 johnthetubaguy +1 on the upgrade note, sounds like the correct call
09:00:27 johnthetubaguy kashyap: interesting questions came up at the PTG around SEV (https://libvirt.org/formatdomain.html#sev)
09:00:38 johnthetubaguy kashyap: I was wondering if you had plans around that already?
09:00:40 kashyap johnthetubaguy: Hi there, haven't seen you in a while
09:01:03 johnthetubaguy yeah, busy working with users these days, in a nice way
09:01:09 kashyap johnthetubaguy: I am peripherally aware of SEV, as I've seen those patches fly by on QEMU and libvirt lists
09:01:17 kashyap johnthetubaguy: Nice
09:01:31 kashyap johnthetubaguy: But I don't have plans for that, I'm afraid. My plate is just too full for the next two months.
09:01:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations https://review.openstack.org/591597
09:01:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen: remove_provider_from_instance_allocation https://review.openstack.org/591784
09:01:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations https://review.openstack.org/591647
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

Earlier   Later