| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-08-10 | |||
| 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 | |
| 13:26:56 | TheJulia | dtantsur: thanks! Added to my review queue :) | |
| 14:03:18 | openstackgerrit | Merged openstack/python-openstackclient master: Fix inconsistency (nit) https://review.openstack.org/572771 | |
| 14:29:37 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: add support for VIF attach/detach API https://review.openstack.org/591324 | |
| 14:33:46 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: add support for VIF attach/detach API https://review.openstack.org/591324 | |