| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-02 | |||
| 22:56:37 | mgagne | mriedem: cool stuff! are there multiple cells in the test? | |
| 22:57:03 | mriedem | yes, except that doesn't currently work b/c there is a bug in our fixtures, i need to test it with https://review.openstack.org/#/c/524264/ or https://review.openstack.org/#/c/558160/ underneath | |
| 22:57:14 | mriedem | but, in-laws are here and i'm going to get yelled at soon | |
| 22:58:45 | mgagne | mriedem: there is no rush, have a good one ;) | |
| 23:11:22 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Use revision_number on adding/removing security group https://review.openstack.org/535510 | |
| 23:15:51 | melwitt | guh, all that hacking on CellDatabases that I was trying to fix with https://review.openstack.org/508432 makes me sad | |
| 23:21:01 | arvindn05 | melwitt: thanks for the reply on the rebuild thread....wanted to get your thoughts on whether the approach is easy to maintain going forward | |
| 23:21:58 | arvindn05 | melwitt: my main concern is if we decide to support forbidden/granular traits etc for images at some point, this part of the logic will need to be updated | |
| 23:22:02 | melwitt | well, rejecting a valid request doesn't seem correct and would likely require later maintenance too | |
| 23:22:08 | arvindn05 | aand maintained going forward... | |
| 23:22:36 | melwitt | meaning, the placement queries would have to be updated? | |
| 23:24:56 | arvindn05 | not just that....the current approach is to get allocations for current instance and then match them in the conductor | |
| 23:25:46 | arvindn05 | the matching happens in the conductor for required traits for now...but if we need to handle granular/forbidden traits etc this matching logic will need to be updated | |
| 23:27:00 | melwitt | can you point me to the code you're referring to? | |
| 23:27:19 | arvindn05 | my point is that since required traits are qualitative requirements, if they change its better to ask the scheduler rather than try to duplicate logic in placement and in conductor | |
| 23:27:52 | arvindn05 | there is not code yet....but eric summarized in this post http://lists.openstack.org/pipermail/openstack-dev/2018-April/129740.html | |
| 23:28:27 | melwitt | okay. well, I'm just saying verifying the traits in placement seems like the only correct thing to do | |
| 23:30:38 | arvindn05 | ideally yes, but a rebuild request never gets to placement api with any of the options described in the thread i think | |
| 23:31:34 | arvindn05 | is there an different alternative where verifying the traits can happen in placement code in case of rebuild? | |
| 23:32:49 | melwitt | what? some of the options involve calling placement | |
| 23:35:01 | arvindn05 | sorry if its unclear...i meant if there is way to utilize the matching logic of placement instead of trying to duplicate that in the conductor/schedulers | |
| 23:39:15 | melwitt | if there's a way to ask placement "do these providers have these traits?" then that's what we need right? we need to ask if the providers hosting our current allocations have the traits requested in the image | |
| 23:40:11 | melwitt | if we could ask it that way, placement would do the matching. but I don't have deep knowledge the placement APIs | |
| 23:41:10 | melwitt | that is, I don't know if there's an available API like that | |
| 23:41:24 | arvindn05 | As i understand it its not just "do these providers have these traits?"...its also "do we have allocations from these providers for those traits?" | |
| 23:42:07 | arvindn05 | since we cannot do allocations during rebuild...we need to make sure our existing allocations satisfy all the trait requirements | |
| 23:42:15 | melwitt | it is, and that's what I tried to say. we have to 1) know our allocations 2) know what providers are hosting our allocations 3) know what traits the providers in 2) have | |
| 23:44:22 | melwitt | so I guess it would be 1) query for own allocations by consumer == our instance 2) use the providers returned by that to ask 2) do these providers have these traits. again, I'm making up the second query, I don't know if one like that exists | |
| 23:44:54 | melwitt | maybe I made up the first one too, but you get the idea | |
| 23:45:45 | arvindn05 | yea...that was what efried had... | |
| 23:47:36 | arvindn05 | 2. we need to need to account for handling preferred traits or granular resource traits if we decide to implement them for images at some point... | |
| 23:47:36 | arvindn05 | 1.the rebuild may or may not succeed, depending on how well the original allocations match up with the new requirements. | |
| 23:47:36 | arvindn05 | the only 2 cons for this approach | |
| 23:47:39 | arvindn05 | see http://lists.openstack.org/pipermail/openstack-dev/2018-May/130087.html | |
| 23:48:12 | arvindn05 | to see why 1 may occur.... | |
| 23:51:35 | melwitt | are traits the same as properties? do they replace properties or? | |
| 23:51:42 | melwitt | *image properties | |
| 23:53:13 | arvindn05 | they are an addition to image properties... | |
| 23:53:34 | arvindn05 | maybe long term they can start to replace some of the image properties.... | |
| 23:53:58 | melwitt | okay. was just thinking about whether 1. would be a regression on how it behaves today. you can rebuild with a new image with new image properties if they pass scheduler filtering | |
| 23:54:41 | melwitt | if image property == image trait then if you reject any rebuild with new traits, then that's a step backward from what's possible today | |
| 23:56:23 | arvindn05 | nope traits are independent of image properties...they use the same key:value and are expressed as such in the image properties...but not the same | |
| #openstack-nova - 2018-05-03 | |||
| 00:01:23 | arvindn05 | i think either of the 2 options we boiled down to work for me....i put this in open dicussion for tommorow's meeting...hopefully we get concensus then :) | |
| 00:25:06 | openstackgerrit | Jake Yip proposed openstack/nova master: Add --before to nova-manage db archive_deleted_rows https://review.openstack.org/556751 | |
| 00:46:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886 | |
| 01:13:36 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP new migration threads control https://review.openstack.org/563505 | |
| 01:23:28 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies https://review.openstack.org/546925 | |
| 02:52:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix the request context in ServiceFixture https://review.openstack.org/558160 | |
| 02:52:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886 | |
| 02:54:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add multi-cell negative test for cold migration with target host https://review.openstack.org/524027 | |
| 03:14:27 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658 | |
| 03:14:28 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 03:14:29 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 03:14:30 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 04:55:34 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 04:55:35 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 05:55:26 | openstackgerrit | Vishakha Agarwal proposed openstack/nova master: Re-using the code of os brick cinder https://review.openstack.org/565703 | |
| 06:08:02 | openstackgerrit | Vishakha Agarwal proposed openstack/nova master: Re-using the code of os brick cinder https://review.openstack.org/565703 | |
| 07:16:24 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP new migration threads control https://review.openstack.org/563505 | |
| 07:43:45 | sahid | stephenfin: if you can have a look to the serie https://review.openstack.org/#/c/561912/ | |
| 08:00:00 | bauzas | morning stackers | |
| 08:02:21 | gibi | good morning nova | |
| 08:08:52 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Consider nested RPs in get_all_with_shared https://review.openstack.org/556450 | |
| 08:08:53 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Support shared and nested allocation candidates https://review.openstack.org/556514 | |
| 08:08:54 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Support nested alloc cands without shared RPs https://review.openstack.org/561842 | |
| 08:08:55 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Return all resources in provider_summaries https://review.openstack.org/558045 | |
| 08:08:56 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Return all nested providers in tree https://review.openstack.org/559480 | |
| 08:08:57 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Return resource providers without inventories https://review.openstack.org/559554 | |
| 08:08:58 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Support nested allocation candidates in placement https://review.openstack.org/565487 | |
| 08:23:49 | gibi | bauzas: could you look at a small spec template update that already has +2 from mriedem? https://review.openstack.org/#/c/562265/ | |
| 08:24:11 | bauzas | sure | |
| 08:24:50 | gibi | bauzas: thanks | |
| 08:25:41 | bauzas | done | |
| 08:25:47 | bauzas | with a comment but +Wd | |
| 08:27:37 | gibi | bauzas: I can quickfix your nit then you can fastapprove it | |
| 08:28:23 | bauzas | gibi: nah, no worries | |
| 08:28:29 | bauzas | I understand what's an API entity | |
| 08:28:34 | bauzas | no need for a followup | |
| 08:28:41 | bauzas | and I'm not a API SIG expert ;) | |
| 08:28:54 | bauzas | but I use a vocabulary | |
| 08:29:05 | bauzas | REST verbs : GET, PUT, etc. | |
| 08:29:12 | gibi | bauzas: OK then let's merge it as is :) | |
| 08:29:15 | bauzas | REST resource : /servers, etc. | |
| 08:29:46 | gibi | bauzas: I think your vocabulary is the correct one | |
| 08:29:55 | bauzas | actions are not RESTful | |
| 08:30:12 | bauzas | but let's call it a subcollection | |
| 08:30:28 | kashyap | Those who can +2 backports, can you put this through please: https://review.openstack.org/#/c/565668/ | |
| 08:30:33 | kashyap | (It already has a +2.) | |
| 08:31:11 | bauzas | kashyap: just did | |
| 08:31:25 | kashyap | bauzas: Fantastic. I've got two more, mind looking there too? | |
| 08:31:39 | bauzas | kashyap: see matt's comment | |
| 08:32:03 | bauzas | kashyap: https://review.openstack.org/#/c/565670/1 | |
| 08:32:30 | openstackgerrit | Merged openstack/nova-specs master: Suggest when to propose notification changes https://review.openstack.org/562265 | |
| 08:32:44 | kashyap | bauzas: Actually, that's what I did | |
| 08:32:48 | kashyap | But let me double-check | |
| 08:33:07 | gibi | bauzas: subcollection sound weird. as PUT and GET is called verb, the 'action' term for our unRESTful actions makes more sense to me | |
| 08:36:42 | kashyap | bauzas++ | |
| 08:38:24 | bauzas | gibi: fair enoguh | |
| 08:38:34 | bauzas | gibi: let's call it an API action | |
| 08:38:47 | gibi | bauzas: action on an API resource :) | |