| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-04-16 | |||
| 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 | efried | :P | |
| 18:33:14 | mordred | efried: you think I get email from gerrit? :) | |
| 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 | |
| 18:55:57 | dtroyer | mordred: nvm, nothing like pouring out your problems publicly to help in figuring it out… that said I am exploring the best way to approach making a derivative SDK for STX. | |
| 18:57:23 | mordred | dtroyer: cool - you may want to chat with gtema next time he's around - he's been working on that same thing for his cloud - they have some services that are non-openstack, so supporting that flow is important to him | |
| 18:58:41 | dtroyer | ok, will do. I saw his recent improvements in add_service() that explained the different behaviours. | |
| 19:00:07 | mordred | cool. also - I'm not opposed in principle to starlingx support in sdk ... but I also have spent exactly 0 seconds thinking about it, so maybe it's a bad idea for a reason I haven't thought of yet | |
| 19:00:28 | mordred | but we're all part of the same happy family, so it's not, you know, inconceivable | |
| 19:00:54 | mordred | but I'm also not going to say it _should_ be done that way if the other way seems better | |
| 19:01:10 | dtroyer | mordred: I think there is a service-types conversation to come first, that'll help decide. | |
| 19:01:16 | mordred | cool | |
| 21:43:09 | openstackgerrit | Merged openstack/openstacksdk master: Return None from get_server_by_id on 404 https://review.openstack.org/652995 | |
| 21:57:51 | Sundar | Are the connections in openstack-sdk low cost enough that we can create one at each call site? | |
| 22:01:18 | mordred | Sundar: well.... | |
| 22:01:55 | mordred | Sundar: they're _fairly_ low cost - but there's also a bunch of plumbing to deal with caching some various things, so I would avoid it in long-running services if you can | |
| 22:02:24 | mordred | Sundar: the Connection object itself should be thread safe - so sharing one should work properly | |
| 22:03:17 | mordred | Sundar: however - if, for whatever reason, you need to create one per call site - if you can share the Session and/or Auth objects, that will take care of most of the caching you'll care about | |
| 22:03:47 | mordred | (since service discovery gets cached on the Session) | |
| 22:40:39 | Sundar | mordred: Thanks for the detailed explanation | |
| 22:41:23 | openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Fix docs bug link to go to storyboard rather than launchpad https://review.openstack.org/653162 | |
| 22:42:25 | Sundar | mordred: Also, in my devstack setup, I see specific roles like devstack_admin in clouds.yaml. Can we expect more standard roles like 'admin' irl? | |
| 22:42:31 | Sundar | mordred: Also, is there a good way to avoid hardcoding the role like ``connection.Connection(cloud='devstack-admin')``? | |
| 23:16:03 | dtroyer | Sundar: that isn't an actual role, it is a cloud user configuration that points at the devstack cloud. The configurations you will find IRL could be anything, it is just a name. with a cloud configuration behind it, that needs to be set up for your target. | |
| 23:20:21 | mriedem | need some design help on fixing https://storyboard.openstack.org/#!/story/2005468 | |
| 23:20:37 | mriedem | trying to fix openstack server create --config-drive in a backward compatible way | |
| 23:20:45 | mriedem | it takes a string today which is dumb b/c it's a boolean, | |
| 23:21:03 | mriedem | it should just be that specifying --config-drive means yeah, add a config drive, and omitting the option means no config drive | |
| 23:21:26 | mriedem | but i'm not sure how to deal with that as a string if it's not provided | |
| 23:21:46 | dtroyer | mriedem: it is likely possible (I personally dislike nargs but this is where it is useful) I can take a close look tomorrow… | |
| 23:21:48 | mriedem | like i guess you can specify --config-drive None? | |
| 23:22:17 | dtroyer | we have done this in one or two other places, it is possible | |
| 23:22:59 | dtroyer | and if I did that existing implementation I owe you a $COLD_BEVERAGE in DEN :) | |
| 23:23:00 | mriedem | ok i'll post what i have and we can sort it out tomorrow | |
| 23:23:13 | mriedem | dtroyer: not your fault if so b/c it's copying the busted novaclient code | |