Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-08-10
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 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:19 dtantsur conn.image - is it latest or a common subset?
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
17:10:39 mordred also - if clouds have disabled something by policy because they are evil evil people, that can show up as 404 not found not 403 unauthorized
17:10:47 mordred which is one of the reasons I hate the policy system
17:13:24 samueldmq mordred: yes policy is hard. splitting operator vs non-operator for now would be a good first step
17:13:59 mordred ++
17:14:03 samueldmq you okay if that reflects on really splitting tests into separate files/directories? or should I add a decorator or somehting on the top of the tests?
17:14:23 samueldmq like @operator to indicate that's an operator test
17:14:49 samueldmq s/test/testcase
17:17:37 mordred samueldmq: either thing works for me - I don't have a strong opinion - so whichever seems to work best as you work on it
17:18:00 mordred directories is probably easier
17:18:16 samueldmq nice, I like that. let's just get the thing done
17:18:34 mordred samueldmq: in fact, we could get a little fancy ...
17:19:17 samueldmq also, I found we allow tests to run against other clouds... but we call it so many different things: OS_CLOUD, OS_TEST_CLOUD, OS_DEMO_CLOUD, OS_OPERATOR_CLOUD. so having that consolidated into a single envvar is a must.
17:19:19 mordred we have self.demo_cloud and self.operator_cloud
17:19:25 mordred samueldmq: ++
17:19:47 mordred samueldmq: if we make an OperatorFunctionalTest base class that is where self.operator_cloud comes from
17:20:10 mordred it could help us make sure we're testing features even in devstack with the correct user vs. operator context
17:20:14 mordred or something
17:20:37 samueldmq base.py for each one of enduser/ operator/ dirs then?
17:20:40 mordred probably still need self.operator_cloud in setUp/tearDown methods though ...
17:21:03 mordred samueldmq: but yeah - start with the directories - and we can figure out if we can do fancier things later :)
17:21:53 samueldmq mordred: nice. I will follow what we had as operator cloud in shade previously
17:22:01 samueldmq to define what's operator and what's not
17:24:58 mordred sounds great to me
17:25:59 Shrews mordred: my wrist is quite sore today so i'm going to stop keyboarding for a while. i'll check in on things later
17:30:11 mordred Shrews: ++
17:30:23 mordred Shrews: don't push through - gotta let that wrist heal
17:35:17 openstackgerrit Merged openstack/openstacksdk master: Fix the heat template resource more cleaner https://review.openstack.org/590786
17:37:05 abishop dtroyer: I need to ask you re-review https://review.openstack.org/575804 (I had to rebase to resolve merge conflict)
17:59:20 openstackgerrit Samuel de Medeiros Queiroz proposed openstack/openstacksdk master: Make require_service use conn.has_service in tests https://review.openstack.org/591029
18:09:38 openstackgerrit Samuel de Medeiros Queiroz proposed openstack/openstacksdk master: Consolidate cloud/base.py into functional/base.py https://review.openstack.org/591031
18:20:16 samueldmq mordred: what is the difference between tests in functional/ vs functional/cloud ?
18:20:48 samueldmq all those in /cloud came from shade? are there known intersections?
19:50:57 mordred samueldmq: yes - that's the only difference
#openstack-sdks - 2018-08-11
12:25:29 openstackgerrit Merged openstack/openstacksdk master: Add more options to enable ansible testing feature https://review.openstack.org/590078
22:03:21 openstackgerrit Merged openstack/openstacksdk master: Fix wait for futures append 'result' error https://review.openstack.org/559523
#openstack-sdks - 2018-08-13
07:27:15 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: add pool member operating status https://review.openstack.org/591281
07:38:37 usr2033 hi, how can i get services available resource amount that can be allocated to projects
09:07:24 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Correct update operations for baremetal https://review.openstack.org/590770
09:12:27 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Use the base Resource's JSON patch support in Image https://review.openstack.org/591314
09:51:31 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] VIF API for baremetal https://review.openstack.org/591324
10:01:39 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Add VIF API for baremetal https://review.openstack.org/591324
10:26:53 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] Add VIF API for baremetal https://review.openstack.org/591324
11:40:40 openstackgerrit Merged openstack/osc-lib master: Replaced a few references to LP bugs with storyboard https://review.openstack.org/586453
12:27:59 dtantsur TheJulia: early comments welcome: https://review.openstack.org/591324
12:48:42 openstackgerrit Merged openstack/openstacksdk master: Add simple create/show/delete functional tests for all baremetal resources https://review.openstack.org/590806
12:55:28 openstackgerrit Merged openstack/openstacksdk master: fix 2 typos in documentation https://review.openstack.org/587624

Earlier   Later