Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-15
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 mordred samueldmq: yah
16:11:05 samueldmq otherwise we wouldn't keep backwards compatibility upon normalziaiotn
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 samueldmq kk sounds reasonable
16:12:36 mordred yah
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
16:37:11 samueldmq hmm yes that's the same concept
16:38:13 samueldmq if I do print(network) it gives me {"provider_physical_network": True}, but I can access with
16:38:42 samueldmq network['provider_physical_network'] == network['provider:physical_network'] == network.provider_physical_network
16:53:59 samueldmq mordred: yes you're right, https://github.com/openstack/openstacksdk/blob/master/openstack/object_store/v1/container.py#L42
16:54:19 samueldmq Resource can do that for us, with a single alias, but should be enoguh for now
17:54:41 mordred samueldmq: \o/
18:05:00 openstackgerrit Corey Bryant proposed openstack/keystoneauth master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610685
18:22:16 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff https://review.openstack.org/605508
18:22:17 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318
18:22:17 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy https://review.openstack.org/608317
18:22:18 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rearrange shade image code https://review.openstack.org/609683
18:22:18 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass https://review.openstack.org/609747
18:22:19 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP Use proxy layer in shade networks https://review.openstack.org/610624
18:38:52 openstackgerrit Maxime Guyot proposed openstack/openstacksdk master: Update Auro cloud profile https://review.openstack.org/610699
19:04:30 openstackgerrit Maxime Guyot proposed openstack/openstacksdk master: Update ElastX cloud profile https://review.openstack.org/610704
19:09:54 openstackgerrit Maxime Guyot proposed openstack/openstacksdk master: Update ElastX cloud profile https://review.openstack.org/610704
22:07:44 openstackgerrit Merged openstack/python-openstackclient master: Handle not having cinderclient.v1 available https://review.openstack.org/609473
22:15:38 mordred Shrews: if you're bored, the stack ending at https://review.openstack.org/#/c/609683 is green now
22:38:05 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: DNM Testing magnum gate fix https://review.openstack.org/610744
22:50:45 openstackgerrit Filippo Inzaghi proposed openstack/cliff master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610746
22:50:57 openstackgerrit Filippo Inzaghi proposed openstack/openstackclient master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610748
22:52:26 openstackgerrit Filippo Inzaghi proposed openstack/osc-lib master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610749
22:52:41 openstackgerrit Filippo Inzaghi proposed openstack/python-openstackclient master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610751
#openstack-sdks - 2018-10-16
03:17:27 openstackgerrit Merged openstack/openstacksdk master: Turn down stevedore and urllib logging https://review.openstack.org/604515
09:36:38 openstackgerrit Tobias Rydberg proposed openstack/openstacksdk master: Adding two new regions and dynamic auth_url based on region name. https://review.openstack.org/610919
09:49:41 openstackgerrit Tobias Rydberg proposed openstack/openstacksdk master: Adding two new regions and dynamic auth_url based on region name. https://review.openstack.org/610921
10:13:31 openstackgerrit Merged openstack/openstacksdk master: Update Auro cloud profile https://review.openstack.org/610699
10:17:55 openstackgerrit Merged openstack/openstacksdk master: Update ElastX cloud profile https://review.openstack.org/610704
11:44:23 dtantsur mordred: morning! when you have some time, I could use your opinion on https://review.openstack.org/603427
11:44:43 dtantsur note that it does not take the TaskManager into account yet, I'd wait for its implementation to settle
12:16:25 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Convert inspect_machine to use the baremetal proxy https://review.openstack.org/610941
12:47:53 mordred dtantsur: hrm. reading through 603427 - it makes me think more that maybe we really should push the fair-locking based task manager replacement down in to keystoneauth (I was waffling about it earlier)- since the retriable status code logic is down in the Session, if we want that to honor a rate limit setting, we'd need it to know about it
12:49:26 dtantsur mordred: well, keystoneauth could certainly benefit from (optional) rate limiting logic
12:51:24 Luzi I already talked about this on the ML: We want to propose Image encryption for OpenStack, which would also affect osc. And we are gathering thought on which library to use: https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
12:51:38 Luzi It would be nice, to have some input from your side :)
12:52:22 mordred dtantsur: https://review.openstack.org/#/c/605043/1 :)
12:53:36 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Move wait_for_baremetal_node_lock to the baremetal proxy https://review.openstack.org/610946
12:53:41 dtantsur w00t
12:53:57 dtantsur meanwhile, I continue polishing the bare metal stuff in OpenStackCloud ^^^
12:54:13 dtantsur mordred: do you expect another release before 1.0? I guess I'll end up with a lot of deprecations..
12:55:18 mordred dtantsur: yeah - I think we need to do at least one just to see what we might have missed/broken

Earlier   Later