Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-08-10
13:25:41 mordred dtantsur: yup
13:25:49 mordred dtantsur: that was one of the changes in image api v2
13:25:58 mordred dtantsur: it got rid of the "properties" attribute
13:26:08 dtantsur wownotwow
13:26:16 mordred and instead put user-defined key/value metadata into the main image object itself
13:26:18 mordred right?
13:26:46 mordred in shade we chose to ignore that design choice and continue to present it as properties even if the service is running v2
13:27:16 mordred which is what I expect to do to fix the brokenness around image in sdk currently
13:27:50 mordred dtantsur: what's even better is that operators can define top-level keys to be "reserved" in their config
13:28:23 dtantsur O.M.G.
13:28:34 mordred dtantsur: you can't un-know that
13:30:03 dtantsur unfortunately
13:30:12 dtantsur I'm looking into JSON patch support.. and it's a mess
13:31:07 dtantsur I'll throw a half-finished patch soon just to collect opinions
13:34:31 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Correct update operations for baremetal https://review.openstack.org/590770
13:34:32 dtantsur mordred: wdyt about the overall approach ^^^ ?
13:40:55 mordred dtantsur: I suppose we can't just assume jsonpatch should be used if commit_message = 'PATCH' can we?
13:42:46 usr2033 mordred: thanks for response. i had a problem with get_project function. Normally get_project function in cloud/openstackcloud.py accept domain_id but in use like in get_compute_quota i can't pass domain_id to function. I had patched for that file for myself. I opened story in https://storyboard.openstack.org/#!/story/2003285
13:43:58 mordred dtantsur: overall approach looks good
13:44:57 dtantsur mordred: I assumed HTTP PATCH can also be used with an incomplete resource representation
13:45:13 dtantsur though openstack services seem to use PUT for that
13:47:05 mordred yah - they do seem to - but I think you're right- better safe than sorry
13:49:38 mordred maybe we could default it to None, then have a little method like def _use_json_patch(self): if self.commit_method is None: return self.commit_method == 'PATCH' ; else return self.commit_method
13:49:52 mordred but maybe that'stoo much - dunno, just thinking out loud
14:30:08 openstackgerrit Alan Bishop proposed openstack/python-openstackclient master: Deprecate volume create --project and --user options https://review.openstack.org/575804
14:53:38 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix the heat template resource more cleaner https://review.openstack.org/590786
14:53:42 mordred Shrews: ^^
15:21:01 cdent mordred: I wish to register my informal +1 on dtantsur as sdk core
15:32:25 mordred cdent: so noted
15:32:41 cdent he's OK
15:32:52 cdent someday might even get a huzzah
15:39:27 mordred cdent: wow. that's pretty strong
15:39:36 cdent ikr
15:41:51 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add simple create/show/delete functional tests for all baremetal resources https://review.openstack.org/590806
15:42:00 openstackgerrit Tim Rozet proposed openstack/python-openstackclient master: Cinder: Add version checking https://review.openstack.org/590807
15:43:17 dtantsur wow, I real huzzah!
15:43:27 dtantsur I must be really cool!
15:44:00 dtantsur * a real huzzah
15:54:45 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add simple create/show/delete functional tests for all baremetal resources https://review.openstack.org/590806
16:10:48 openstackgerrit Merged openstack/openstacksdk master: Remove special handling of stacks https://review.openstack.org/589195
16:12:47 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Correct update operations for baremetal https://review.openstack.org/590770
16:18:58 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Correct update operations for baremetal https://review.openstack.org/590770
16:19:10 dtantsur mordred: I found an inconsistency while working on ^^^
16:19:41 dtantsur when for a field the server name does not match our name (e.g. instance_uuid vs instance_id for nodes), we use the former when accessing it but the latter when updating
16:19:59 dtantsur e.g. node.instance_id but self.conn.node_update(node, instance_uuid='...')
16:25:42 mordred dtantsur: oh awesome
16:30:58 openstackgerrit Merged openstack/openstacksdk master: Make resource a dict subclass usable by shade layer https://review.openstack.org/530835
16:34:43 mordred zomg
16:34:45 mordred that happened
16:34:50 mordred MIND BLOWN
16:36:49 dtantsur lol
16:39:17 Shrews mordred: my mind will be blown if nothing breaks because of it :)
16:40:21 mordred Shrews: that'll totally be true for at least some definition of "nothing"
16:40:48 mordred see - now I just have to finish wiring in the discovery code ...
16:41:50 dtantsur "just"
16:46:10 mordred dtantsur: it should be "easy" - I "just" need to make a new descriptor to handle attaching proxy objects to the connection that can handle instantiating and connecting the correct versioned proxy. and then I "just" need to write another one to stick onto the attached proxy that will add a proxy object for each version of the service found in the cloud
16:46:26 mordred piece of cake
16:47:57 mordred dtantsur: my thinking so far has been make conn.image be the version of the service that's found via discovery (taking config overrides in to account) - but also have conn.image.v1 and conn.image.v2 be explicit instance of openstack.image.v1._proxy.Proxy and openstack.image.v2._proxy.Proxy
16:48:11 mordred does that make sense and/or sound like a somewhat unterrible idea?
16:51:32 dtantsur mordred: are you going to provide a common subset of v1 and v2 via conn.image?
16:51:51 dtantsur and #2: are we going to do it even for services with only one major version?
16:52:19 mordred dtantsur: for #2 - I think so - although I doubt it'll ever get used
16:53:07 dtantsur yeah, so for e.g. baremetal, conn.baremetal and conn.v1.baremetal is the same. what about image?
16:53:19 dtantsur conn.image - is it latest or a common subset?
16:53:19 mordred dtantsur: for #1 - it's a really great question - I had been thinking of just making what shows up in conn.image be different based on whats found- which is what happens today if you just set the config variable differently
16:53:46 dtantsur this is probably the realistic option, even though it's not great from interoperability PoV
16:53:57 mordred BUT - the shade layer is designed as an abstraction layer - maybe it would be worth making an 'unversioned' proxy that is what gets attached in those cases
16:54:26 mordred and if you wanted a specific version's semantics you can always just do conn.image.v2.create_image
16:54:58 dtantsur okay, so conn.image.create_image can behave differently, but conn.image.v2.create_image is the same?
16:55:17 mordred yah. that would be the easier path
16:55:40 dtantsur the easiest, but also quite confusing for consumers..
16:55:42 mordred and a user can always do conn.image.get_endpoint_info() to find out what version it is
16:55:44 mordred yah
16:55:52 mordred yah
16:56:08 mordred maybe I'll take a stab at it for image, since we already have all of the logic to handle it in the shade code
16:56:19 dtantsur in rust-openstack I only support one major version per service, it's so much easier :D
16:56:24 mordred basically - move the shademethods into an 'unversioned' proxy that calls the other ones
16:56:38 mordred and see how terrible that is
16:56:43 dtantsur I'd be curious to see that
16:56:51 mordred in fact, maybe I'll just do it with create_image
16:56:58 mordred keep it SUPER small so we can see what it looks like
16:57:03 dtantsur yup
16:57:28 dtantsur how many volume service versions do we have, 3? :)
16:58:26 dtantsur mordred: what's openstacksdk's official commitment wrt supporting deprecated major versions?
16:58:48 mordred support all of them until the end of time
16:58:59 dtantsur that's tough
16:59:01 mordred yah
16:59:15 mordred BUT - it's one of the reasons I'm pleased that we have requests-mock based unittests now
16:59:28 dtantsur I wonder how we're going to maintain them when there are no clouds supporting them
16:59:45 dtantsur unit tests are nice, but they only confirm existing assumptions
17:00:57 dtantsur on this positive note I'll call it a day :)
17:04:11 samueldmq mordred: Shrews: does 'tox -e functional --end-user' make sense to you at all?
17:05:04 samueldmq I wanted to run functional against public clouds. operator tests don't make sense in that context
17:06:00 mordred dtantsur|afk: I think the main idea is - keep the unittests for existing assumptions - and if someone reports a bug ask them to provide us with an http trace
17:06:02 mordred :)
17:06:34 mordred samueldmq: yes. although in a perfect world I think having each thing be able to detect whether or not the user is allowed to do a thing would be great ...
17:06:49 mordred buit that's not really feasible - so I thik your idea is more achievable
17:07:41 samueldmq mordred: seems like if we had a manner for the user to define what they expect to be able to do and test those things would be nice
17:08:45 samueldmq I agree that idea is not really feasible, since there needs to be a distinction between 403 because I'm not operator vs 403 ohh I should be allowed to do that
17:10:14 mordred yah

Earlier   Later