Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-16
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
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: ^

Earlier   Later