Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-16
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
23:49:53 dtroyer where 'that case' is from a long-running service
23:50:44 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: WIP: Fix openstack server create --config-drive value https://review.openstack.org/653176
23:51:21 mriedem Sundar: e.g. nova's config for talking to glance https://docs.openstack.org/nova/latest/configuration/config.html#glance
23:51:31 mriedem uses keystoneauth1 config options for building the ksa session adapter
23:51:56 mriedem efried is well versed in all of that code
23:53:25 Sundar mriedem: I am investigating the 'new' approach, newer than ksa adapter, which is to use openstack sdk with clouds.yaml.
23:53:55 Sundar mriedem: efried is advocating that new approach
23:56:19 Sundar mriedem: Along the lines of https://review.openstack.org/#/c/643664/
23:56:46 Sundar dtroyer: Got it. This should go into cyborg.conf
23:58:56 mriedem Sundar: ok i don't know why we're doing that,
23:59:03 mriedem we don't have a blueprint or anything for that in nova
#openstack-sdks - 2019-04-17
00:00:19 mriedem dtroyer: https://review.openstack.org/653176 is my wip for that --config-drive thing, problem noted within on nargs='?' which maybe you know...tomorrow
00:00:57 Sundar mriedem: One advantage, from what I see, is that it gives a uniform way for one project to talk to any other project, without having to have a separate entry in the conf file for every single callee.
03:24:51 openstackgerrit Erik Olof Gunnar Andersson proposed openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
06:53:31 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
06:57:58 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add image.stage methods https://review.openstack.org/652981
07:42:17 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
07:43:05 dtantsur gtema: morning, have a second for an easy approval? ^^^
07:43:49 gtema yeah, am on call now, in a few minutes
07:48:31 dtantsur thx
07:55:15 gtema wlcm
09:18:30 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update baremetal to use proxy logger https://review.openstack.org/652083
11:53:51 openstackgerrit Merged openstack/openstacksdk master: Actually pass on network_data when building configdrive https://review.openstack.org/653271
13:28:22 cdent elmiko, edleafe, dtantsur, mordred when you have a moment please look at https://storyboard.openstack.org/#!/story/2005474 at the concept of "openstack-shard" mooted in there and the command line client issues it might present. apologies for the haphazard text there, just trying to get things written up without losing ideas
13:28:38 mordred cdent: oh goodie!
13:28:44 edleafe cdent: ack
13:28:47 mordred cdent: it's open in my browser
13:29:14 mordred cdent: also - I haven't followed the rest of the email thread about placement and docker - but I definitely want to sit down with you at the PTG and show you what we've got and how it works
13:29:30 cdent mordred++
13:29:32 mordred cdent: corvus is going to be doing a keynote on the topic too - but as a keynote, it'll obviously be missing details :)
13:30:15 cdent I will probably need to coralled in order to remember. Do not feel bad about hassling me if it comes to that. I'm not good at remembering things at large gatherings.
13:30:21 mordred I figure placement is a popular enough kid that if we get you hooked up it might serve as a good blueprint for other people - or if that doesn't work it can serve as good feedback
13:30:38 mordred cdent: me either. but I think this is a good targetted opportunity, so I'll do my best to remember
13:30:53 cdent I will endeavor as well
13:31:19 cdent btw: the docker stuff got a story too: https://storyboard.openstack.org/#!/story/2005463
13:39:54 elmiko cdent: ack, will take a look
14:47:23 elmiko cdent: are the storyboard comments an appropriate place to leave my thoughts about your idea?
14:47:47 elmiko (sorry, don't have a ton of storyboard experience)
14:48:27 cdent elmiko: If you like, but I was thinking of it more as fodder for some api-sig noodling that would then be reflected back to either to the story or a guideline if everyone loved it
14:48:49 cdent elmiko: basically if you have comments on the goal (get sharding working in placement) the story would be the right place
14:49:10 cdent but if you have coments on the concept of an 'openstack-shard: header' somewhere else might be better
14:50:42 elmiko ack, thanks!
14:51:02 elmiko at this point i'm working more at the conceptual level, athough i did follow the email thread
14:52:17 elmiko i actually find the placement stuff to be kind of exciting/invigorating for the openstack community. it's nice to see that this community can still accept projects with the potential for high impact. ++ imo
15:00:17 efried mordred, dtroyer: I had another thing I wanted to bring up about consuming the SDK in projects like nova/cyborg...
15:00:59 efried We find ourselves having a tough time with testing at several levels because of the internal magic Connection does when you instantiate it
15:01:52 efried and could really use a fixture to mock out enough of those bits that we can use Connection mostly like it's supposed to be used, just mocking e.g. response payloads for certain methods
15:03:00 efried but writing those fixtures in the consuming project is going to be either really brittle because we patch out internals that could change; or too high-level because we patch out the whole Connection and essentially rewrite the SDK framework in our fixture.

Earlier   Later