Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-15
09:41:04 dtantsur mordred: impressive!
10:13:07 samueldmq morning
10:13:56 samueldmq does recall if there was ever a version 1 of keystone, nova and neutron?
10:14:10 samueldmq I suspect there was but only in the first days of openstack. I don't remember why we chose to jump to 2.0 on all those..
10:14:58 samueldmq mordred: ^ I know you were here since the first days ... so you might know somehting about thsi
10:22:10 frickler samueldmq: this has a bit of history for keystone https://docs.openstack.org/keystone/pike/contributor/http-api.html#history . I'm also pretty sure neutron only ever implemented v2, but I can only guess that that happened in order to match nova when it was split out
10:24:12 frickler samueldmq: and this makes me assume that nova v1 was also the legacy rackspace api https://blueprints.launchpad.net/openstack-sdk-php/+spec/nova-api-v1
10:37:35 samueldmq Hmm. Awesome
10:37:54 samueldmq Thanks frickler
11:10:13 dtantsur frickler++ this is interesting
13:18:40 mordred frickler: yes - nova v1 was the legacy rackspace api ... keystone v1 was, iirc, the legacy rackspace auth
13:18:55 mordred ah - yes, that link above says much the same about keystone
13:18:57 mordred samueldmq: ^^
13:32:35 samueldmq mordred: awesome, thanks for confirming
13:32:54 samueldmq that helps answering the question "why does sdk not support those API versions?"
13:32:55 mordred dtantsur: so - in a very slow answer to your question - yes, you should be worried about http methods ignoring error_message ... error_message is a parameter to _adapter._json_response - so that means we missed an update to a callsite
13:32:59 mordred samueldmq: ++
13:33:13 samueldmq mordred: it would probably be useful to have that somewhere in our docs
13:33:19 dtantsur mordred: that's what I suspected
14:15:46 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use network proxy in openstack.cloud https://review.openstack.org/604645
14:15:47 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff https://review.openstack.org/605508
14:15:47 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy https://review.openstack.org/608317
14:15:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318
14:15:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass https://review.openstack.org/609747
14:15:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rearrange shade image code https://review.openstack.org/609683
14:16:03 mordred dtantsur: ok. I think 604645 is good now
14:20:04 dtantsur great :)
14:20:22 dtantsur mordred: re _normalize_* stuffs: what is its role?
14:20:36 dtantsur I thought as a bare minimum we should remove "links", etc?
14:53:56 mordred dtantsur: well - long term I think _normalize_* should go away and the data model contract should just be expressed in the Resource objects ...
14:54:22 mordred but that's a little handwavey
14:54:41 dtantsur the Resource objects do have a bit technical things like "links". do we want to keep them in the output?
15:05:13 mordred dtantsur: it's a good question. I'm less opposed to them than I was in years past because we have the underlying structure to do something with them now (it use to be you got a link in a novaclient object, but didn't have any configured rest client that could actually make a request from that link)
15:05:47 mordred so maybe they're ok to keep around now? or maybe they're a terrible idea ...
15:07:17 dtantsur I'm fine with either way, but we need it consistent
15:07:29 dtantsur currently we're quite inconsistent, at least in the baremetal world
15:08:12 mordred yah. I agre - consistency is the most important
15:09:07 mordred dtantsur: to me I think it's more important that we get to a place where you get the same return object whether you use shade layer or proxy layer - because that way you can write nicer programs that sometimes use a higher-level helper method and sometimes lower-level methods
15:09:43 dtantsur okay, then hiding links probably does not make much sense..
15:09:47 mordred yah
15:10:15 dtantsur okay, so I'll probably drop _normalize_machine and won't introduce _normalize_nic
15:23:39 mordred ++
15:47:34 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP Use proxy layer in shade networks https://review.openstack.org/610624
15:47:57 mordred samueldmq: there's a half-written stab at using self.network.networks() for list_networks ...
15:50:06 mordred samueldmq: which I think may get us further than doing new normalize methods like https://review.openstack.org/#/c/602218
15:50:46 dtantsur heh, openstackcloud.py is so big, it even makes vim slow :D
15:50:58 mordred dtantsur: hehe
15:51:26 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Switch bare metal NIC actions in OpenStackCloud to baremetal Proxy calls https://review.openstack.org/610024
16:06:53 samueldmq mordred: kk, I'll take a look at that today
16:07:11 samueldmq mordred: it'd be awesome to have that and the rest of the patches approved soon
16:07:19 samueldmq they're all ready for review, passing tests
16:08:42 mordred yah
16:09:39 mordred samueldmq: it's also possible that what we should do is start by landing your normalize patches (possibly making sure that they normalize things into a form that also looks like the fields in the Resource classes)
16:09:48 samueldmq except for a _metadata test that insists on failing intermitently
16:10:03 samueldmq mordred: have you seen some gates breaking with taht?
16:10:21 mordred and then a second set of patches to shift to using Resource- so that we can see the test updates along with the normalize (I think we're likely going to need to change some of the tests to be better)
16:10:30 samueldmq mordred: ++
16:10:34 mordred I haven't?
16:10:56 mordred samueldmq: although - my network patch from above (https://review.openstack.org/604645) is totally gonna merge-conflict yours
16:10:59 samueldmq mordred: because for the specific esources that we don't normalize yet we need to include all the known attributes anyway
16:11:05 samueldmq otherwise we wouldn't keep backwards compatibility upon normalziaiotn
16:11:05 mordred samueldmq: yah
16:11:58 mordred samueldmq: well - althugh - within reason I'm ok with some skew here as we haven't ever defined a contract, and neutron objects are very variable depending on deployer plugins and stuff
16:12:31 samueldmq mordred: so it's really free in the wild
16:12:32 mordred so - I don't think we should go crazy, but I also don't think our tests of that api surface are particularly great, so I think we can make a best effort
16:12:36 mordred yah
16:12:36 samueldmq kk sounds reasonable
16:13:37 mordred for instance - we're letting values like provider:physical_network through as keys directly - while the sdk resource is normalizing that to provider_physical_network
16:14:03 mordred we might have to get clever at some point ...
16:14:14 samueldmq mordred: you want to nomalize that? or should we keep both?[
16:14:35 samueldmq mordred: yes. I think we all understand we need to improve things at some point
16:15:01 mordred :)
16:15:06 samueldmq but we don't liek to talk about not being backwards compatible. perhaps a deprecation approach that is very solid could be adopted
16:15:48 mordred yeah. or - maybe resource gives us enough tools to define 'provider:physical_network' as an alias for provider_physical_network
16:16:12 samueldmq mordred: but then we keep including both formats forever?
16:16:14 mordred so that if a user does network['provider:physical_network'] it'll still return a value - but the api docs will show network.provider_physical_network
16:16:38 samueldmq hmm, we would need to support that while reading the munch
16:16:58 mordred samueldmq: yeah - I think it's more generally thinking about how we provide a good and consistent interface but also letting people use the names from the service api docs?
16:17:01 samueldmq even though it's not in the munch if you only do print(my_resource)
16:17:12 mordred yeah. I *think* resource can already handle that
16:17:27 samueldmq mordred: maybe. I don't like to think about the services at all
16:17:47 samueldmq I like to think as a newcomer that just wants things done in a cloud
16:18:23 samueldmq I don't care about being too clever, just use the basic things (get a server up)
16:18:32 samueldmq and that's all shade is about right
16:22:26 samueldmq mordred: I don't think we have a clear picture of what goes in abstraction layer and what doesn't in terms of depth in the resources
16:23:21 samueldmq I get confused whether we want to have a one handle'em all abstraction layer, or really the most important/common
16:23:24 samueldmq "Clouds can do many many many things - but there are probably only about 10 of them that most people care about with any regularity."
16:24:15 mordred samueldmq: yah. I agree - it's definitely unclear
16:25:17 mordred samueldmq: how I've been thinking about it recently is to try to make the Resource layer be similar to the _normalize_* methods from shade - so that we can have objects that are returned with consistent field names no matter which api you're using
16:26:00 samueldmq mordred: sure for that part yes, I agree 100%
16:26:01 mordred and then have shade have the "10 things more people care about" methods - and the sdk/proxy layer have the more service-oriented specific methods
16:27:03 mordred so - like with that image patch as an example - there are methods in the proxy layer for image.v1.upload_image and image.v2.upload_image and block_storage.v2.create_image_from_volume - but in the shade layer there's still just 'create_image' that just works
16:28:50 samueldmq mordred: that makes total sense
16:29:38 samueldmq what I was saying is that we should watch for how deep we go in representing resources. we might be normalizing to attributes that require not basic usage, let's keep abstraction layer simple
16:30:22 samueldmq mordred: what if the user could define what their resources look like by defining their own aliases. does that make sense at all?
16:31:39 samueldmq my rationale is that simple may vary from user to user,
16:33:56 samueldmq maybe that's not the best api design. can be crazy to maintain
16:35:41 mordred samueldmq: hrm. it's an interesting thought ... but I think maybe what I'm thinking is somewhere in the middle
16:36:31 mordred like, since Resource does magic with __getattribute__ anyway - we should be able to make any attribute of the original json from the service accessible?
16:36:44 samueldmq what if I inherit Munch in MunchWithAliases

Earlier   Later