| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-06-28 | |||
| 18:39:45 | mordred | yah - I'm just now starting to use the server side discovery ksa is doing in sdk - that patch above is the first consumption patch | |
| 18:40:36 | mordred | I think we might want to add some comparison methods to either the EndpointData object or directly to the Adapter | |
| 18:41:44 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Only send force parameter to live migration if supported https://review.openstack.org/578960 | |
| 18:41:47 | mordred | whoops. typo | |
| 18:42:36 | mriedem | oh god | |
| 18:43:34 | mriedem | 2.30 :) | |
| 18:46:50 | mriedem | mordred: would you like me to add the mega warnings to live migrate sdk if using host and force? | |
| 18:46:51 | mriedem | https://docs.openstack.org/openstacksdk/latest/user/proxies/compute.html#openstack.compute.v2._proxy.Proxy.live_migrate_server | |
| 18:46:57 | mriedem | people shouldn't use those, and really shouldn't use force | |
| 18:48:43 | mordred | mriedem: well - that's a good question | |
| 18:48:52 | mordred | by "should't use force" - do you mean force is going to go away? | |
| 18:49:07 | mriedem | no | |
| 18:49:09 | mordred | or it's a conceptually bad idea and humans shouldn't use it even though it's an exisitng feature | |
| 18:49:13 | mriedem | the latter | |
| 18:49:27 | mriedem | if you specify a host before 2.30, it's the same as specifying a host + force with 2.30 | |
| 18:49:36 | mriedem | both mean "send to this host regardless of the scheduler" | |
| 18:49:46 | mriedem | aka "please oversubscribe me and shoot myself and users in the foot" | |
| 18:50:03 | mordred | what is the behavior if you set host but not force with 2.30? | |
| 18:50:05 | mriedem | move your instance from az1 to az8 w/o knowing it, etc | |
| 18:50:13 | mriedem | we run that host through the scheduler | |
| 18:50:18 | mriedem | so if it checks out, great | |
| 18:50:31 | mriedem | "Prior to microversion 2.30, specifying a host will bypass validation by the scheduler, which could result in failures to actually migrate the instance to the specified host, or over-subscription of the host. It is recommended to either not specify a host so that the scheduler will pick one, or specify a host with microversion >= 2.30 and without force=True set." | |
| 18:51:28 | mordred | gotcha. this is fun | |
| 18:51:33 | mriedem | starting in pike we still check with placement to make sure you can allocate resources on the forced host and if placement says 'nope' then we fail | |
| 18:51:43 | mriedem | so it's not as terrible anymore, but you can still f things up like azs | |
| 18:52:19 | mriedem | any of the other qualitative filters - tenant isolation, image isolation, etc | |
| 18:52:49 | mordred | mriedem: lemme take a stab at updating that patch and tell me if I'm getting it right | |
| 18:54:19 | mordred | mriedem: does force have any meaning without host? | |
| 18:56:02 | mriedem | nope | |
| 18:56:09 | mordred | k. cool | |
| 18:57:08 | openstackgerrit | Toure Dunnon proposed openstack-infra/shade master: python-shade expose MTU setting. https://review.openstack.org/578861 | |
| 18:58:18 | nicolas_o | mriedem: mordred: I am afraid it's still broken with the patch. The API is not happy unless I pass block_migration: False, disk_over_commit: False. | |
| 18:58:51 | nicolas_o | This is how I got it to work with 2.1 api: https://github.com/nicolasochem/openstacksdk/commit/4a912a026a218e3b146fe1408c460608873ecfd4 | |
| 18:59:49 | mriedem | nicolas_o: that's for different reasons https://developer.openstack.org/api-ref/compute/#live-migrate-server-os-migratelive-action | |
| 19:00:10 | mriedem | the block_migration parameter was removed from the api in 2.24 | |
| 19:00:22 | mriedem | oh sorry, it was re-typed | |
| 19:00:30 | mordred | wow. this is fun | |
| 19:00:46 | mriedem | 2.25 allows you to send block_migration=auto | |
| 19:00:52 | mriedem | meaning, "you figure out if i'm using shared disk or not" | |
| 19:01:18 | mriedem | disk_over_commit was removed in 2.25 | |
| 19:01:32 | mriedem | https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-mitaka | |
| 19:01:54 | mriedem | i'm kind of worried that no one is reading our microversion history or api reference docs... | |
| 19:02:18 | mordred | mriedem: there's a lot of it - and I'm literally just now adding the very first use of a microversion :) | |
| 19:02:26 | mriedem | heh yeah i know | |
| 19:02:31 | mordred | so - I promise I'll read it more | |
| 19:02:33 | mriedem | i started https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc | |
| 19:03:17 | nicolas_o | Thanks for that. I just want to use the sdk to do something like: self.cloud.compute.live_migrate_server(id, host=host_id) | |
| 19:03:43 | mordred | yup. hopefully we'll get you there :) | |
| 19:03:58 | openstackgerrit | Alessandro Nesta proposed openstack/osc-lib master: Add release note link in README https://review.openstack.org/578459 | |
| 19:04:10 | mriedem | i'm not sure what the best default logic there is then, i'd say if you're specifying >= 2.25 and block_migration isn't specified, use 'auto'; | |
| 19:04:20 | mriedem | if < 2.25 and host isn't specified, default to True? | |
| 19:04:42 | mriedem | if you're specifying a host, then we might want to require block_migration since you should know if that host is on shared storage and < 2.25 | |
| 19:04:50 | mriedem | it's a complicated matrix | |
| 19:05:01 | openstackgerrit | Alessandro Nesta proposed openstack/osc-lib master: Add release note link in README https://review.openstack.org/578459 | |
| 19:23:16 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Only send force parameter to live migration if supported https://review.openstack.org/578960 | |
| 19:23:40 | mordred | mriedem: how does that look logically ... (ignore the fact that the code is overly repetitive - we can write cleverer code later) | |
| 19:26:14 | mriedem | oh wait we passed a law on nit picking didn't we? | |
| 19:38:29 | mriedem | mordred: supports_microversion is <= right? | |
| 19:44:35 | mriedem | mordred: comments inline | |
| 19:45:30 | mordred | mriedem: yes - <= ... and thanks! | |
| 19:48:48 | mriedem | and a late comment | |
| 19:48:55 | mriedem | 'host' is required in the body always, even if host=None | |
| 19:48:56 | mriedem | it's dumb | |
| 19:49:06 | mriedem | "The host to which to migrate the server. If this parameter is None, the scheduler chooses a host." | |
| 19:56:16 | rm_work | dtroyer: thanks for pushing that tag change through :) | |
| 19:59:21 | rm_work | mordred: was it you i was talking to about fixing some of the neutron version discovery issues that were introduced in 0.10? | |
| 19:59:36 | rm_work | I don't remember where we left that | |
| 20:01:16 | rm_work | looks like it's still not working in 0.14.x for me, though the message is a bit clearer :P | |
| 20:23:15 | rm_work | Failed to contact the endpoint at https://openstack:9696 for discovery. Fallback to using that endpoint as the base url. | |
| 20:23:21 | rm_work | NotFoundException: 404: Client Error for url: https://openstack:9696/networks, Not Found | |
| 20:23:29 | rm_work | ^^ on Liberty | |
| 20:56:01 | mordred | rm_work: I *think* we have a fix for that in master and I'm a bad person who has not cut a release for you yet | |
| 20:56:12 | rm_work | lol np, i can test it | |
| 20:56:22 | rm_work | you have a CR? | |
| 20:56:24 | rm_work | or, SHA | |
| 20:56:29 | rm_work | i can apply | |
| 20:56:36 | rm_work | or i guess i could just checkout master | |
| 20:56:46 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Only send force parameter to live migration if supported https://review.openstack.org/578960 | |
| 20:56:57 | mordred | mriedem: ^^ updates. thanks for the feedback btw - super helpful! | |
| 20:56:59 | mordred | rm_work: looking | |
| 20:57:00 | rm_work | yeah sec i'll just switch to master | |
| 20:57:03 | rm_work | don't worry about it | |
| 20:57:04 | mordred | ok. cool | |
| 20:57:31 | rm_work | hmmmmmmm | |
| 20:57:48 | mordred | it's also possible that we looked at this, I said "oh, I see the issue and will write a patch" and then didn't | |
| 20:57:56 | rm_work | yeah i think it's the latter | |
| 20:58:03 | rm_work | master seems to be the same | |
| 20:58:26 | mordred | yes! | |
| 20:58:30 | mordred | I remember the thing now | |
| 20:58:54 | rm_work | yeah everyone using this cloud is stuck on 0.9.x which is just sad T_T | |
| 20:58:59 | mordred | kmalloc: ^^ on older clouds, neutron's version discovery document is auth protected (because of course it is) | |
| 20:59:06 | rm_work | lolol yes | |
| 20:59:26 | mordred | kmalloc: I kind of think we should just update ksa to send a token if it has one when doing discovery | |
| 20:59:42 | mordred | kmalloc: (but not to get a token if it doesn't already have one perhaps) | |
| 21:00:05 | mordred | kmalloc: or else I can probably work around it in SDK - but it's definitely a weird gotcha for folks | |
| 21:00:08 | rm_work | wouldn't that just make the error inconsistent then? :( | |
| 21:00:39 | kmalloc | Hmm | |
| 21:00:44 | mordred | rm_work: hrm. good point | |
| 21:01:05 | kmalloc | Yeah it is weird | |
| 21:01:53 | rm_work | can you assume that if it is auth protected, that it's one of the old versions pre-discovery? and that tells you what the endpoint is? :P or is it still variable? | |