| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-04-16 | |||
| 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 | |
| 23:23:19 | mriedem | which also says it can be a non-boolean string | |
| 23:23:22 | mriedem | from 2012 | |
| 23:43:27 | Sundar | dtoyer: Thanks. So, how do we get the right 'cloud name' or user configuration name for ``connection.Connection(cloud='devstack-admin')``? | |
| 23:43:41 | Sundar | dtroyer: ^ | |
| 23:45:23 | dtroyer | I don't know the exact context you are in, but that depends totally on the cloud you are calling | |
| 23:47:53 | Sundar | dtroyer: let me put it this way. When one project (say Cyborg) calls another (say Glance), is it appropriate to embed names like 'devstack-admin' in the caller code? One would tjhink not. So, where do I get the right name for the caller? | |
| 23:49:37 | dtroyer | Sundar: from the point of view of the application, it comes from the app. Most OpenStack services have a configuration value for service accounts like that, along with their DB config, etc. In that case, you probably do not want to rely on clouds.yaml for that information but create your connection from the individual pieces in your config | |