| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-04-16 | |||
| 13:41:03 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Return None from get_server_by_id on 404 https://review.openstack.org/652995 | |
| 13:45:10 | openstackgerrit | Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682 | |
| 13:45:35 | openstackgerrit | Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682 | |
| 14:49:06 | mordred | gtema: left a review on the image patches - I think they're close | |
| 14:49:59 | gtema | yes, thanks. Few issues: | |
| 14:50:35 | gtema | auto_disk_config - I think it would be better to drop this attr from image resource and rely on the "properties" interpretation of it | |
| 14:51:03 | gtema | drop compute for list - ok, will do | |
| 14:52:02 | gtema | switch to wait_for_task - it's this fallback for _IMAGE_ERROR_396 which makes it not easy | |
| 14:52:39 | mordred | gtema: auto_disk_config - yeah | |
| 14:52:51 | mordred | gtema: or else we should add ALL of the driver-specific properties | |
| 14:53:19 | gtema | which we do not want to | |
| 14:53:53 | mordred | gtema: yeah. and unfortunately _IMAGE_ERROR_396 is a wonderful thing that rackspace does throw. like - that chunk of logic exists because of issues production nodepool sees without it | |
| 14:54:09 | mordred | gtema: totally. there's too many of them - it would make the image objects absurd | |
| 14:54:43 | gtema | morderd: so should I then drop all hw*, vmware*? | |
| 14:56:27 | mordred | gtema: ugh. we do have a lot of these already don't we | |
| 14:56:33 | gtema | yupp | |
| 14:56:46 | mordred | gtema: maybe it's better that we just add the rest of them? I wish they were documented somewhere that isn't a wiki page | |
| 14:56:50 | mordred | like, you know - in the API docs | |
| 14:57:00 | mordred | lemme ask rosmaita | |
| 14:57:04 | gtema | ok | |
| 15:02:21 | mordred | gtema: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html | |
| 15:02:51 | gtema | morder: ack, will go through | |
| 15:03:22 | mordred | wow. trait:trait_name is fantastic | |
| 15:03:51 | gtema | however, if on Rackspace auto_disk_config returns you "disabled" - we have a problem and need to treat all those as strings only | |
| 15:04:03 | gtema | since it should be true or false | |
| 15:09:00 | mordred | gtema: mriedem tells me that auto_disk_config is string in the nova schema, so even the true and false values are actually "true" and "false" | |
| 15:09:39 | gtema | ok, that is the problem, that in Image it was casted to bool and therefore I had problem | |
| 15:10:32 | mordred | aha! | |
| 15:10:36 | mordred | https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L233 | |
| 15:10:48 | mordred | gtema: this is apparently where we can look to find out actual thing | |
| 15:11:00 | gtema | yeah, looks interesting | |
| 15:11:27 | gtema | but is also interesting "architecture" vs "hw_architecture" | |
| 15:11:41 | gtema | hw_auto_disk_config | |
| 15:11:47 | mordred | there's a legacy property map at the bottom | |
| 15:11:58 | gtema | oh, thks | |
| 15:12:25 | mordred | I wonder how hard it would be to write a gate job (or maybe a functional test that works only on devstack installs) | |
| 15:12:33 | gtema | it's huge. Do we really want all of that? | |
| 15:12:40 | mordred | that would import that nova file and do a cross-check to make sure the property lists match | |
| 15:12:46 | mordred | gtema: I don't know | |
| 15:12:53 | mordred | it's an excellent questions | |
| 15:13:21 | gtema | we will anyway put everything what we get under properties and even allow to set anything | |
| 15:14:39 | gtema | and those traits - we can't define such things as of now | |
| 15:15:34 | mordred | yeah ... so - in #openstack-nova I just said : | |
| 15:16:39 | mordred | oh - screw it - copy/paste not worth it... basically - since the various base properties can have varied data types, we might really want to do the whole list so we can make sure everything in properties is just a string type and is a user-defined property | |
| 15:16:42 | mordred | BUT | |
| 15:16:50 | mordred | maybe we can wait a bit and do that later | |
| 15:17:01 | mordred | I think what's there now is fine for now until someone gets upset | |
| 15:17:24 | gtema | so simply let it stay how it is now? | |
| 15:17:41 | gtema | auto_disk_config - will remove type=bool | |
| 15:18:58 | mordred | OH GOD. THERE ARE ENUMS | |
| 15:19:21 | mordred | gtema: yeah. let's do that for now - I think dealing with the whole thing is ... large ... and requires some real thought | |
| 15:19:38 | mordred | like - if we wanted to actually tackle it - I'd want to figure out how to keep thigns liek enum lists in sync | |
| 15:20:15 | mordred | gtema: you know - there's also the schema field you added support for | |
| 15:20:33 | gtema | yes, I know | |
| 15:20:47 | mordred | gtema: I wonder if it would be easier/better to just write something that grabs the schema and figures out which properties are base and which are user based on that schema | |
| 15:20:50 | gtema | you want us to make use of it? | |
| 15:20:59 | mordred | maybe? I don't know how useful it is | |
| 15:21:23 | gtema | well, I am not sure it is usefull as of now. Maybe later | |
| 15:22:07 | gtema | this would not be very efficient by default, since nearly always we would need to invoke it and/or cache schema data | |
| 15:22:14 | mordred | ++ | |
| 15:22:26 | mordred | yeah - we'd definitely have to cache schema data I think | |
| 15:22:38 | mordred | but for single-use processes like osc it woudl still be inefficient | |
| 15:22:48 | gtema | definitely | |
| 15:22:59 | mordred | so it's PROBABLY better to think about a test job that validates against the nova source code | |
| 15:23:13 | mordred | but HOLY CRAP that'll be a lot of work too due to the use of custom enum classes | |
| 15:23:28 | gtema | agree | |
| 15:29:33 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534 | |
| 15:43:32 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Add image.stage methods https://review.openstack.org/652981 | |
| 18:23:48 | efried | mordred: This openstacksdk business is ready for primetime, yah? So like, new projects like cyborg that don't yet have a legacy commitment to python-*client and/or oslo.config for ksa can and should bootstrap their talking-to-other-services business with a clouds.yaml and production Connection constructor-ness? | |
| 18:30:13 | mordred | efried: yes | |
| 18:30:39 | mordred | efried: it would be very welcome for them to add support for their service into sdk directly | |
| 18:30:56 | efried | mordred: I was talking about cyborg wanting to communicate *at* other services, like placement and glance. | |
| 18:31:02 | mordred | ah. yes. that too | |
| 18:31:20 | Shrews | mordred: very very small nit on https://review.openstack.org/652995 but happy to merge as is too if you'd rather say "meh" | |
| 18:31:23 | efried | Sundar: ^ Given that you've just succeeded in connecting using a ksa adapter, it should be fairly trivial to translate your oslo.config-based values into a clouds.yaml. | |
| 18:31:25 | mordred | so - both things are true | |
| 18:32:02 | mordred | efried: yah. although if they _want_ to use the oslo.config stuff, we've got that helper method we put in for nova | |
| 18:32:12 | efried | mordred: Well, yeah, it's still in flight. | |
| 18:32:28 | efried | mordred: And I'm not sure there's a reason to use oslo.config stuff, is there? | |
| 18:32:33 | mordred | efried: god, have we not landed that yet? I should really finish writing tests | |
| 18:32:47 | efried | mordred: I did leave a poke there a week or two ago :) | |
| 18:32:48 | mordred | efried: not really - other than consistency with other services for operators | |
| 18:33:04 | efried | I mean, how much gerrit mail could you possibly get? | |
| 18:33:14 | mordred | efried: you think I get email from gerrit? :) | |
| 18:33:14 | efried | :P | |
| 18:33:41 | efried | I've got a guy coming up to speed and working on the ironicclient swapout for nova | |
| 18:33:55 | efried | We're getting close-ish to a point where we'll want that dep merged & released. | |
| 18:34:10 | efried | dustinc: ^ | |
| 18:34:46 | mordred | efried: cool. we'll get it merged for you then | |
| 18:35:01 | efried | mordred: Let me know if you need anything from me on that. | |
| 18:35:29 | mordred | don't think so - I think the nova depends-on patches provide good integration testing that it works - we just need to add some sdk-side testing and it should be good to go | |
| 18:35:54 | mordred | Shrews: oh piddle. can you tell I copy-pastad that? | |
| 18:36:21 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Return None from get_server_by_id on 404 https://review.openstack.org/652995 | |
| 18:36:28 | mordred | Shrews: ^^ fixed | |
| 18:36:31 | mordred | thanks | |
| 18:36:52 | dtroyer | mordred: is there a known problem with Connection.add_service() currently? I am attempting some manner of support of StarlingX APIs without adding them directly (just starting with direct REST for now) and I get different failures with latest release and master… | |
| 18:37:12 | dtroyer | I need to work up a small test case, you don't want to try what I have at the moment… | |
| 18:37:24 | openstackgerrit | Jeremy Houser proposed openstack/python-openstackclient master: Exploratory Fix for Common in Compute v2 Common https://review.openstack.org/653077 | |
| 18:37:29 | dustinc | efried, mordred: 👍 | |
| 18:42:05 | Shrews | mordred: +3'd | |