| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-10 | |||
| 16:14:54 | efried | oh, core in requirements are we? Even better. | |
| 16:26:57 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Add 'openstack server migrate [--resize|--confirm]' flags https://review.opendev.org/664393 | |
| 17:41:30 | mnaser | ok, i'm not the only one ever to deal with this but | |
| 17:41:41 | mnaser | is there any reason why we couldnt add a cascade delete option to openstackclient | |
| 17:55:55 | dtroyer | stephenfin: I didn't do that because I didn't think about it. set/unset is a natural opposite pair, revert by itself might be too generic but we certainly could have a two word verb just as much as we have multi-word resources | |
| 17:56:28 | dtroyer | modulo if I was the one who originally mapped that command, I honestly don't remember, so if its wrong I prolly did :) | |
| 17:57:15 | dtroyer | mnaser: is that different from the purge command? I assume so but am not sure exactly how… | |
| 17:57:55 | mnaser | dtroyer: i think purge is meant to kill an entire project, where as this.. the idea is that i can give it a network and it can list all subnets, then list all ports a ttached tos ubnets, and delete from ports up to make the network deletable | |
| 17:58:00 | mnaser | unless purge exists and does just that.. | |
| 17:58:48 | dtroyer | I have not used nor worked on purge, but yeah I do think it is for a whole project. so do we need to come up with a way to specify subsets of project-owned resources? | |
| 17:59:19 | mnaser | dtroyer: yeah well the idea is i'm adding a --cascade command and i guess it'll naively gather the resources we know about at least | |
| 18:00:41 | dtroyer | you are tying that to a network? would it make sense to also have subsets of that? I don't have enough Neutron in my head for it to be obvious where else to use that idea | |
| 18:01:22 | mnaser | dtroyer: correct, you would ask for a cascading network delete, and it would go, list all subnets, then list all ports attached to each subnet, delete all ports, and then now we'll be able to delete all subnets, then we'll be able to delete the network | |
| 18:01:41 | mnaser | and i'm adding a --force which will do it regardless, and a confirmation of what resource will be deleted before | |
| 18:02:24 | dtroyer | we'll need to think about output on a delete command, they don't do that now other than warnings and errors… | |
| 18:02:36 | mnaser | yeah i noticed that too.. | |
| 18:03:02 | mnaser | i mean i can drop the --force thing too | |
| 18:03:08 | mnaser | it was mostly for my development too | |
| 18:03:43 | mnaser | its probably eaiser to do it without it for now | |
| 18:04:13 | dtroyer | —force seems useful if the API implements something for it. so would —dry-run but I think a way to see what would be deleted is necessary for —dry-run to actually be useful... | |
| 18:40:21 | openstackgerrit | Mohammed Naser proposed openstack/python-openstackclient master: port: drop host-id and device-id https://review.opendev.org/664421 | |
| 19:02:55 | openstackgerrit | Mohammed Naser proposed openstack/python-openstackclient master: port: drop host-id and device-id https://review.opendev.org/664421 | |
| 19:03:12 | openstackgerrit | Mohammed Naser proposed openstack/python-openstackclient master: port: drop host-id and device-id https://review.opendev.org/664421 | |
| 19:05:35 | openstackgerrit | Mohammed Naser proposed openstack/python-openstackclient master: port: drop host-id and device-id https://review.opendev.org/664421 | |
| 19:05:36 | openstackgerrit | Mohammed Naser proposed openstack/python-openstackclient master: network: add cascade delete https://review.opendev.org/664422 | |
| 19:06:17 | mnaser | dtroyer: ^ first run without --dry-run | |
| 19:06:26 | mnaser | adding --dry-run should be fairly straightforward | |
| #openstack-sdks - 2019-06-11 | |||
| 09:29:53 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.opendev.org/650903 | |
| 09:35:28 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer for network SecurityGroups https://review.opendev.org/662724 | |
| 11:27:06 | mordred | gtema: morning! we ran in to https://storyboard.openstack.org/#!/story/2005851 with nodepool and had to pin to a previous version | |
| 11:27:26 | gtema | morning mordred | |
| 11:27:37 | mordred | ah - I see you commented on it ... yeah, that header is present | |
| 11:27:40 | gtema | Is it possible to see a real query going there? | |
| 11:27:47 | mordred | I'm working on running some ... yeah - one sec | |
| 11:28:06 | mordred | http://paste.openstack.org/raw/752708/ | |
| 11:28:30 | mordred | I'm working on doing the same upload again with 0.27 to get a comparable chunk of logging | |
| 11:28:38 | gtema | hmm, looks good. Exactly | |
| 11:28:42 | mordred | because I don't see anything wrong there - yeah | |
| 11:32:15 | mordred | the awesome part is that because rax uses the image-task method, I have to upload a full actually valid image :) | |
| 11:32:27 | gtema | :D | |
| 11:38:34 | gtema | what I see could be different - presence of "Accept: " | |
| 11:43:58 | mordred | yes. although I did try a run hacking it to not send the accept header - and that sent the same 400 | |
| 11:44:12 | gtema | really? hm | |
| 11:44:25 | gtema | that's the only thing I might think of | |
| 11:45:58 | mordred | yeah. same here | |
| 11:51:41 | gtema | btw, to which version you downgraded? | |
| 11:54:24 | mordred | gtema: 0.27.0 | |
| 11:54:38 | mordred | gtema: which is what nodepool had been running before this recent restart that picked up latest sdk | |
| 11:54:44 | gtema | ok | |
| 11:54:46 | mordred | ok - so - I have confirmed the upload works under 0.27.0 | |
| 11:55:10 | gtema | and the request looks like ...? | |
| 11:55:32 | mordred | the main difference I can see in the REST calls is that in 0.27.0 that request is not made after the task import is complete - I THINK | |
| 11:55:47 | mordred | (I really should have logged this to a file - scrollback is a bit hard to scane because of the list calls) | |
| 11:56:29 | mordred | you know what? I'm going to do it again and log to a file - then I can upload the whole file somewhere | |
| 11:56:38 | gtema | cool | |
| 11:57:30 | mordred | have I mentioned how happy I am that image uploading is so complicated? :) | |
| 11:57:47 | gtema | nope, but I totally agree with you | |
| 11:58:09 | gtema | server normalization (with respect to network addresses) is not much better | |
| 11:58:14 | mordred | yeah | |
| 11:59:01 | gtema | but btw have found why nodepool was not happy with flavors - dogpile.cache is not happy with Resource, since it is returned from a function from a generator from a .... | |
| 11:59:13 | mordred | I mean - ultimately a large percentage of the crazy logic in the shade layer is related to rackspace being weird (the one example in the other direction is how hard it is to boot a server with an ip address) | |
| 11:59:16 | mordred | AH - joy | |
| 11:59:29 | mordred | well - I think we should rework how the caching works anyway ... | |
| 11:59:42 | gtema | it's basically pickle.dumps(list(self.compute.flavors())) does not work | |
| 11:59:54 | gtema | yeah, would need to | |
| 12:00:55 | mordred | you know what - maybe I should write a quick spec with the thoughts that were in my head WRT caching and we can talk it through and come up with an actual plan | |
| 12:01:29 | gtema | btw, racks support creating server with block_device_mapping2. Currently we use os-volumes_boot if bdm_v2 is present in params | |
| 12:01:39 | gtema | for caching - cool | |
| 12:01:42 | gtema | let's do this | |
| 12:01:50 | mordred | \o/ | |
| 12:02:24 | mordred | so - I'm also thinking - the support you added for having a cloud/vendor-specific driver that overrides some of the proxies ... | |
| 12:02:39 | gtema | :D | |
| 12:02:46 | mordred | maybe it would be cleaner to extract the rackspace-specific logic we have into a rackspace driver | |
| 12:03:46 | gtema | the ones "originated" all OpenStack are now a separate incompatible driver ??? | |
| 12:04:00 | mordred | yeah. it's "funny" | |
| 12:04:14 | mordred | but we carry a lot of logic that's just for them | |
| 12:04:24 | gtema | but yes, we can start really packing all of that into "drivers" | |
| 12:04:32 | mordred | like - the task import stuff - it's technically in upstream glance, but it's untestable in devstack | |
| 12:06:18 | gtema | I'm back in 10-20 min | |
| 12:18:11 | gtema | am back | |
| 12:19:20 | mordred | just added the call from 0.27.0 | |
| 12:20:11 | gtema | so it's really just "Accept:" | |
| 12:21:29 | gtema | well and then the order of "path" and "value" for each item | |
| 12:22:59 | mordred | I'm thinking maybe it's something to do with call sequencing | |
| 12:23:09 | mordred | I'm going to re-run latest logging to a file | |
| 12:23:17 | gtema | if you quickly remove line 284 in image/v2/image.py (setting Accept) to be also sure | |
| 12:23:30 | mordred | yeah - I did that yesterday | |
| 12:23:34 | gtema | ok | |
| 12:23:37 | mordred | but I can do it again and do the log if we want | |
| 12:24:27 | gtema | would be nice, but if you say it didn't help - not prio | |
| 12:25:09 | gtema | let's then really compare order or calls. However unittest tests this also. And here we had no change | |
| 12:25:36 | mordred | yeah. I was pretty confident in the changes because we have this covered in unittests | |
| 12:29:16 | gtema | latest trace is broken - incomplete | |
| 12:29:45 | mordred | oh yeah? poo - maybe there was a length limit here | |
| 12:29:47 | mordred | hit | |
| 12:30:02 | mordred | http://paste.openstack.org/show/752725/ <-- there's a trimmed version with just the request sequence | |
| 12:31:49 | gtema | the order is same as in tests | |
| 12:32:04 | mordred | yeah | |
| 12:32:44 | mordred | running 0.31.0 now - we'll see how it goes | |
| 12:32:49 | mordred | takes about 20 minutes | |