Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
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
10:23:13 pkoniszewski johnthetubaguy: but im still considering a new config option, i see a case where operator might want to get to target downtime in a couple of seconds but still such live migration might need 10+ minutes to complete
10:23:16 bauzas johnthetubaguy: for the moment, I was seeing a dict
10:23:22 pkoniszewski mdbooth: right, that's the current state
10:23:27 bauzas johnthetubaguy: but longer term, why not an object, agreed
10:23:53 johnthetubaguy bauzas: honestly, a TODO in there saying this argument sucks might be all I need on that bit, lol
10:23:57 bauzas I'm just thinking it shouldn't be the Spec object
10:24:11 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient: [CLI] Fix token auth type https://review.openstack.org/424256
10:24:12 johnthetubaguy bauzas: yeah, thats cool, I just re-read that file, it has to be resource providers
10:24:18 bauzas yup zactly
10:24:24 gmann alex_xu: ahh, yea, thanks for pointing that

Earlier   Later