| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 06:57:07 | satyar | Thanks alex_xu | |
| 06:57:28 | alex_xu | satyar: np | |
| 06:59:32 | satyar | Hi dansmith | |
| 07:00:51 | openstackgerrit | Béla Vancsics proposed openstack/nova: Reduce code duplication https://review.openstack.org/342187 | |
| 07:08:28 | openstackgerrit | Zhenyu Zheng proposed openstack/nova: Add new policy for server list/detail with all_tenants https://review.openstack.org/415330 | |
| 07:13:04 | moshele | alex_xu: hi can you review https://review.openstack.org/#/c/423608/ ? | |
| 07:46:10 | alex_xu | moshele: just add it to my list | |
| 07:46:34 | moshele | alex_xu: thanks :) | |
| 07:47:35 | alex_xu | moshele: np | |
| 08:26:44 | alex_xu | gmann: just prepare to send a mail about the device tag | |
| 08:28:40 | gmann | alex_xu: nice, thanks. | |
| 08:29:10 | gmann | alex_xu: looks like some issue in functional tests also. debugging that | |
| 08:31:04 | alex_xu | gmann: let us put all the info in the mail and discuss at here | |
| 08:31:08 | alex_xu | s/here/there/ | |
| 08:32:07 | gmann | alex_xu: +1 | |
| 08:54:44 | snikitin | alex_xu: Hi, Alex! I changed a file name in diagnostics patch and lost your +2 :( Can you look again please? Also I left a comment about your proposal for docs https://review.openstack.org/#/c/355540/ | |
| 08:55:13 | alex_xu | snikitin: ok, I will check that | |
| 08:55:58 | snikitin | thanks! | |
| 09:13:41 | openstackgerrit | Ildiko Vancsa proposed openstack/nova: Implement new attach/detach Cinder flow https://review.openstack.org/330285 | |
| 09:14:34 | openstackgerrit | Ildiko Vancsa proposed openstack/nova: Implement new attach/detach Cinder flow https://review.openstack.org/330285 | |
| 09:14:36 | openstackgerrit | Ildiko Vancsa proposed openstack/nova: Remove check_attach https://review.openstack.org/335358 | |
| 09:31:10 | moshele | sfinucan: hi can you review this https://review.openstack.org/#/c/423608/ | |
| 09:31:33 | sfinucan | moshele: Sure | |
| 09:32:01 | openstackgerrit | Hironori Shiina proposed openstack/nova: Ironic: Add soft power off support to Ironic driver. https://review.openstack.org/407977 | |
| 09:42:58 | sfinucan | moshele: Done | |
| 09:45:35 | moshele | sfinucan: thanks | |
| 09:47:11 | sfinucan | bauzas: Could you take a look at https://review.openstack.org/#/c/419479 when you have a moment? | |
| 09:47:34 | bauzas | sfinucan: currently under the water because of the scheduler upcall, but I'll try | |
| 09:47:55 | sfinucan | bauzas: No panic at all. Priorities :) | |
| 09:50:35 | bauzas | sfinucan: I'm just investigating a grenade issue, hopefully to sort it out soonish | |
| 09:58:42 | johnthetubaguy | bauzas: I have added a few ideas on that call placement from scheduler thing: https://review.openstack.org/#/c/417961 | |
| 09:59:09 | johnthetubaguy | bauzas: FWIW, the caching scheduler looks correct to me | |
| 10:00:35 | bauzas | johnthetubaguy: lemme look at | |
| 10:09:07 | johnthetubaguy | mdbooth: was reading your comment on here: https://review.openstack.org/#/c/408002 | |
| 10:09:13 | johnthetubaguy | mdbooth: very, very valid | |
| 10:09:45 | bauzas | johnthetubaguy: got a few mins for discussing about https://review.openstack.org/#/c/417961 ? | |
| 10:09:48 | johnthetubaguy | mdbooth: I thought of a slight alternative, we could update the config option docs to very clearly state there are 10 steps | |
| 10:10:22 | mdbooth | johnthetubaguy: I wonder if anybody has ever tuned this, tbh. | |
| 10:10:44 | johnthetubaguy | mdbooth: most people just tune the 500 total timeout, AFAIK | |
| 10:11:00 | johnthetubaguy | mdbooth: kill it all might be a better solution (i.e. just hard code it) | |
| 10:11:16 | johnthetubaguy | bauzas: sure thing | |
| 10:11:45 | bauzas | johnthetubaguy: so, AFAICU we're discussing on how to have a right interface | |
| 10:12:27 | mdbooth | We could add a new config variable which is a total, and immediately deprecate the old 2. The new value will default to the product of the deprecated values if not set explicitly. We hardcode 10 steps. | |
| 10:13:45 | bauzas | johnthetubaguy: so, you'd prefer to have https://review.openstack.org/#/c/417961/19/nova/scheduler/host_manager.py@635 in the scheduler report client ? | |
| 10:14:05 | mdbooth | johnthetubaguy: If this is up against the wire I can probably write that today myself, btw. Is this on anybody's radar? | |
| 10:14:18 | johnthetubaguy | mdbooth: we already have the total as a config setting I think, thats the delay between steps, not the size of the steps | |
| 10:14:37 | johnthetubaguy | mdbooth: pkoniszewski is usually responsive if he is around | |
| 10:14:42 | mdbooth | I don't think there's a total time, it's calculated. | |
| 10:15:08 | pkoniszewski | I'm around | |
| 10:15:16 | pkoniszewski | yeah, I also agree with mdbooth comment, very good point | |
| 10:15:41 | johnthetubaguy | bauzas: I think I would like to see the scheduler directly call the placement client, then pass the return value into the host_state to get back the list of objects | |
| 10:15:56 | johnthetubaguy | bauzas: it could go into the scheduler or the placement client I think | |
| 10:16:09 | johnthetubaguy | mdbooth: I think live_migration_downtime is the config I mean | |
| 10:16:15 | bauzas | johnthetubaguy: you mean the scheduler driver, not the host manager ? | |
| 10:16:27 | bauzas | johnthetubaguy: so we could just drill down a list of hosts to the host manager? | |
| 10:16:31 | johnthetubaguy | mdbooth: there is the total timeout, and the time to reach the total timeout in the steps | |
| 10:16:54 | bauzas | johnthetubaguy: I need to consider that if so | |
| 10:16:58 | johnthetubaguy | mdbooth: given we also define a time after which the live-migrate is considered failed and we give up, we could use that to define the steps | |
| 10:17:13 | bauzas | johnthetubaguy: I actually made that split because of the CachingScheduler, but lemme think about that loud | |
| 10:17:19 | pkoniszewski | johnthetubaguy: live migration timeout can be set to 0 to disable it | |
| 10:17:22 | johnthetubaguy | bauzas: I think we would pass resource providers into the host manager | |
| 10:17:30 | pkoniszewski | johnthetubaguy: however, nova still needs to increase downtime over time | |
| 10:17:33 | bauzas | johnthetubaguy: I'm not sure I like that | |
| 10:17:33 | johnthetubaguy | bauzas: it shouldn't affect the caching scheduler | |
| 10:17:43 | bauzas | johnthetubaguy: I would pass hosts, not RPs to the Hostmanager | |
| 10:17:45 | gmann | alex_xu: seems like we just broke the validation part, feature still should work | |
| 10:17:53 | johnthetubaguy | pkoniszewski: yeah, we would need a default if that timeout is zero | |
| 10:17:54 | pkoniszewski | we would need some kind of a magic number | |
| 10:18:03 | bauzas | johnthetubaguy: I mean, lemme clarify | |
| 10:18:25 | bauzas | johnthetubaguy: I think having the filter scheduler directly calling the reportclient to get the list of RPs is a good idea | |
| 10:18:29 | alex_xu | gmann: is there still a way to set tag to the bdm or network device? | |
| 10:18:45 | johnthetubaguy | pkoniszewski: it could be some multiple of the 500 seconds setting, if overall timeout is 0 | |
| 10:18:47 | bauzas | johnthetubaguy: what I'm saying is that the translation from RP to compute nodes should still be filter scheduler thing | |
| 10:18:59 | johnthetubaguy | bauzas: agreed | |
| 10:19:14 | johnthetubaguy | bauzas: I think the filter scheduler method stays the same, its just whats in there that changes | |
| 10:19:15 | bauzas | johnthetubaguy: from an interface PoV, that's actually an excellent point | |
| 10:19:27 | bauzas | I mean, the filter scheduler returns compute nodes | |
| 10:19:34 | bauzas | the host manager returns host states | |
| 10:19:34 | johnthetubaguy | bauzas: I kinda like passing the spec_obj into the placement client | |
| 10:19:43 | bauzas | that, I'm not sure | |
| 10:20:06 | johnthetubaguy | ah, OK, you want that to be resource providers? | |
| 10:20:07 | johnthetubaguy | thats fair enough | |
| 10:20:15 | bauzas | johnthetubaguy: because I'd like to see the "spec to RC usage" logic be still a scheduler thing | |
| 10:20:38 | bauzas | the placement client shouldn't expect anything about how the scheduler works | |
| 10:21:03 | mdbooth | johnthetubaguy pkoniszewski: Sorry, even though I only read it yesterday, I still had to refresh it :) | |
| 10:21:05 | gmann | alex_xu: for bdm yes as there is no additionalProperties=False there but yes for network it is not allowed as additionalProperties=False :( | |
| 10:21:15 | bauzas | johnthetubaguy: in particular given I'm now very opiniated on having the resource query being optional depending on the filters | |
| 10:21:30 | gmann | alex_xu: i am modifying tempest device tag tests with all combination and with all version mentioned by you | |
| 10:21:39 | mdbooth | So there's live_migration_downtime, which is the maximum permitted downtime of an instance during live migration | |
| 10:21:41 | gmann | alex_xu: let's see how bdm tag behave on those | |
| 10:21:42 | bauzas | johnthetubaguy: the last 3 days convinced me we need to opt-in the filters | |
| 10:22:10 | johnthetubaguy | mdbooth: totally with you on need to refresh, I guess thats the problem the operators are having too | |
| 10:22:16 | mdbooth | Then there live_migration_downtime_steps, which is the number of steps to take towards that maximum, and live_migration_downtime_delay, which is the delay between each step. | |
| 10:22:17 | bauzas | johnthetubaguy: either way, thanks for reviewing, that's very good insight, and I can do a new iteration this morning | |
| 10:22:35 | bauzas | johnthetubaguy: FWIW, I'm stuck with grenade not liking the placement service in newton | |
| 10:22:49 | johnthetubaguy | bauzas: I was thinking it would ideally be an object we pass into the placement client (that could be empty) | |
| 10:22:51 | mdbooth | So the total time until we go with the maximum is live_migration_downtime_steps * live_migration_downtime_delay | |
| 10:22:58 | mdbooth | pkoniszewski: Am I reading that right? ^^^ | |
| 10:22:59 | johnthetubaguy | bauzas: ah yeah, that... :( | |
| 10:22:59 | alex_xu | gmann: initial I also think there is no addtionalProperties, but I found it copy that from bdm v1 schema https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/block_device_mapping.py#L61 | |