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

Earlier   Later