Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-04
12:35:50 sean-k-mooney jaypipes i have no doubt gibi has reasoned about this and the edgecase far better then i :) espcially since i jsut stared looking at the patch but ya just providing my assumtions in case that help with any that might have been made :) my assumetion of how this should work likely diverge hevily form how it does
12:36:02 gibi jaypipes: there is stuctural change between 1.12-1.28 but there is no strucutral change when we step from 1.28 to 1.29 in a_c but I don't know what you want to suggest
12:37:46 jaypipes gibi: I was questioning the need to "pin" the claim_resources() API microversion to 1.29 since there was no change to the allocation_request part of the a_c response.
12:39:14 gibi jaypipes: sure claim_resources can work with 1.28 even if a_c used 1.29. I think we are not even bumping claim_resources to 1.29 when we bump a_c to 1.29
12:39:57 gibi jaypipes: this path bumps a_c to 1.29 https://review.openstack.org/#/c/585672 but not the claim_resources
12:41:13 jaypipes gibi: k, cool.
12:41:41 jaypipes gibi: again, I was just responding to your comments on https://review.openstack.org/#/c/583667/25/nova/scheduler/client/report.py where you said this:
12:41:42 jaypipes "Therefore scheduler passes down >= 1.29 when calling claim_resources with the selected allocation candidate. So by supporting nested a_c we implicitly force nova to at least support 1.29 >= in claim_resources too. "
12:42:11 jaypipes gibi: but, no worries, I'll stop bothering you and get back to reviewing the last revision in that patch :)
12:42:30 gibi jaypipes: so you suggets to drop the logic that passes version from a_c to claim_resources?
12:42:51 jaypipes gibi: yeah, might be useful...
12:42:53 gibi jaypipes: that logic is the one that forces claim_resources to adapt to 1.29
12:43:06 jaypipes gibi: since technically there's nothing about 1.29 that affects claim_resources.
12:43:34 jaypipes gibi: and the allocation_request_version that gets passed to claim_resources() is all about the structure of the allocation_request part of the payload.
12:43:57 jaypipes gibi: but it's really not a huge deal :)
12:44:05 gibi jaypipes: jeah for 1.29 we don't need that but for the bump of 1.12 - 1.28 we need to know that the a_c was used with 1.28
12:44:10 jaypipes gibi: like I said, I'll go back to my last revision review :)
12:44:30 gibi jaypipes: I let you review :)
12:44:48 jaypipes gibi: elnézést a zavarásért!
12:45:38 jaypipes I imagine gibi laughing at Google Translate's poor translation
12:45:58 gibi jaypipes: what was the English expression you translated?
12:46:01 gibi :)
12:46:05 jaypipes "Sorry to bother"
12:46:08 jaypipes lol
12:46:18 jaypipes what does it mean? :)
12:46:32 jaypipes "Happy cows love coding" or something wacky like that?
12:47:57 gibi no it is not that far
12:50:27 gibi jaypipes: what you used is more for the case when you want to approach a stranger, e.g. as a first sentence before you ask for direction
12:51:03 gibi so it is super polite
12:51:52 gibi but yeah you basically asked for forgiveness for the interruption
12:52:06 gibi so the intention is clear
12:54:42 jaypipes hehe
12:58:43 bauzas jaypipes: gibi: https://www.duolingo.com/course/hu/en/
12:58:57 bauzas I did that for German \o/
12:59:21 bauzas und jetzt I spreche Deutch
12:59:25 bauzas Ich*
13:00:10 sean-k-mooney bauzas: if you ever want to lean a languge that no one will under stand they have an irish course too
13:03:23 bauzas sean-k-mooney: I saw this
13:03:33 bauzas there is also High Valeryan and Klingon
13:06:54 sean-k-mooney bauzas: both are proably more useful then irish that said it was nice to have a language you could use to gossip about people abroad on school trips lol only use of irish i have ever had
13:07:03 efried jetzt spreche ich <== with an adjective in the mix, you put the verb before the subject. Or something.
13:07:27 efried or whatever "jetzt" is, not an adjective
13:22:10 jaypipes gibi: +2 from me on claim_resources(). I will let efried or mriedem +W.
13:22:45 gibi jaypipes: thanks a lot. efried had a bunch of comments so I feel he is the one who can +W it
13:31:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor allocation checking in functional tests https://review.openstack.org/607287
13:31:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Run ServerMovingTests with nested resources https://review.openstack.org/604084
13:31:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ignore forcing of live migration for nested instance https://review.openstack.org/605785
13:31:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consider nested allocations during allocation cleanup https://review.openstack.org/606050
13:31:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ignore forcing of evacuation for nested instance https://review.openstack.org/606111
13:31:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Run negative server moving tests with nested RPs https://review.openstack.org/604125
13:33:20 gibi bauzas: FYI, the nested series now up to date all the way to the top https://review.openstack.org/#/c/604125/
13:43:19 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934
13:50:13 openstackgerrit Jack Ding proposed openstack/nova master: Handle missing marker during online data migration https://review.openstack.org/605164
14:02:19 dansmith did I miss that the meeting this week was canceled or something?
14:03:06 gibi dansmith: I think I did not get a request from melwitt to chair it but I can
14:03:25 dansmith meh
14:03:26 gmann not sure. I was also checking meeting channel
14:03:32 efried we have an important topic to discuss, HPET for libvirt.
14:03:34 bauzas hah, I just asked the question in -meeting
14:03:36 efried they're expecting it.
14:03:45 bauzas efried: and what about HCATTLE ?
14:03:56 efried oy vay
14:04:06 sean-k-mooney efried: so #openstack-meeting time i guess
14:04:24 efried yup
14:11:10 mrch_ can i prevent the nova.compute.resource_tracker spaming this: nova.compute.resource_tracker [req-e23cf459-506f-42d3-ac5d-73d87b1e5ba9 - - - - -] [instance: 8ecbbdb1-bad7-434b-8d09-265964ca9c7e] Instance not resizing, skipping migration. when 5 hosts spam this about one an the same vm, an i got 10 vms of that kind, its annoying as f
14:12:57 efried mrch_: We're in the nova meeting atm; can you ask again at the top of the hour?
14:13:43 efried It looks like this is happening because you have some stale migrations in the database; can you clean those up?
14:15:56 mrch_ efried
14:15:56 mrch_ efried: shure
14:18:05 mrch_ efried
14:18:06 mrch_ efried: concidering db, but i cant wait, i stay in chat just write ill see it tomorrow
14:18:50 efried mrch_: Okay. I personally don't know how to clean up the db, but hopefully one of the wizards can advise once the meeting is over.
14:58:22 melwitt gibi: thank you for running the nova meeting, it completely slipped my mind this time. apologies
15:00:26 gibi melwitt: no worries
15:00:35 mhen o/
15:01:46 mrch_ can i prevent the nova.compute.resource_tracker spaming this: nova.compute.resource_tracker [req-e23cf459-506f-42d3-ac5d-73d87b1e5ba9 - - - - -] [instance: 8ecbbdb1-bad7-434b-8d09-265964ca9c7e] Instance not resizing, skipping migration. when 5 hosts spam this about one an the same vm, an i got 10 vms of that kind, its annoying as f
15:02:37 mhen as already mentioned in the ML we want to propose the introduction of image encryption in OpenStack
15:02:42 mhen #link ML thread on proposal for image encryption http://lists.openstack.org/pipermail/openstack-dev/2018-September/135167.html
15:02:53 mhen as advised on the ML, we are currently writing individual specs for the components involved, including Nova
15:03:01 mhen in Nova we would like to add the decryption of images, which are converted into servers using ephemeral storage and the encryption of images created from such servers
15:03:22 mhen at first we want to focus on LibVirt and its LVM backend, because it is the only backend for encrypted ephemeral storage in LibVirt (ignoring the ineffectiveness of the encryption due to missing native LUKS support for now)
15:03:45 mhen we would be interested in Nova's opinion on whether the conversion from encrypted image to unencrypted ephemeral storage should be allowed
15:03:58 mhen we don't really like the idea of exposing the image data this way but the Cinder team suggested making this optional for the similarly natured volume use case
15:04:36 efried jaypipes: Because then the libvirt driver would have to use that (HPET=required) as its cue to turn HPET on in the guest. I.e. using a trait to effect configuration.
15:05:23 efried jaypipes: I'm writing up the alternatives with their respective cons; stay tuned.
15:05:56 cfriesen sean-k-mooney: if we ever wanted to support passthrough of host TPM, then there really would be a finite inventory
15:06:26 cfriesen sean-k-mooney: for emulated TPM we could make it a trait if the host supports it
15:08:44 cfriesen sean-k-mooney: if we ever wanted to support both emulated and passthrough TPM, what would the placement side look like? would that be two resource providers, one with the "emulated" trait and one with the "real" trait?
15:09:13 jaypipes mrch_: why would 5 hosts be spamming that same message? does that mean you have the same instance stuck in a migration to multiple hosts?
15:09:44 jaypipes cfriesen: and that's the problem with embedding key/value things into a trait string...
15:10:50 cfriesen jaypipes: maybe no traits are needed....in a sense this would be equivalent to VCPU vs PCPU
15:11:07 cfriesen so maybe it's just two separate resource providers
15:13:46 jaypipes cfriesen: ack
15:23:33 spatel Quick question, i am creating SR-IOV instance and in order to do that i need to create neutron port first. i have created bunch of port during testing but now i need to find out which neutron port is active and non-active how do i find that out?
15:24:07 spatel sean-k-mooney: morning
15:24:16 openstackgerrit Eric Fried proposed openstack/nova-specs master: WIP: High Precision Event Timer (HPET) on x86 guests https://review.openstack.org/607989
15:24:48 efried sean-k-mooney, cdent, jaypipes, cfriesen, dansmith, bauzas, gibi: ^
15:24:56 cdent noted
15:25:41 dansmith jaypipes: you around for a hangout in 35 minutes on this hpet thing?
15:32:50 cfriesen efried: got it. thanks for writing this up

Earlier   Later