Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-05-17
16:56:18 dtantsur oh, I"m going to miss an epic battle :)
16:57:07 edleafe Will we all have little flags to show our allegiances?
16:57:27 mugsie that is a great idea :)
17:00:04 dtantsur I have love-hate relationships with microversions
17:08:32 cdent I have no idea what flag to fly.
17:22:44 elmiko cdent edleafe, ok, i'm good for wednesday too now =)
17:23:20 cdent like I said:
17:23:50 elmiko hahaha
17:25:13 edleafe how does that even work?
17:25:26 edleafe I change a flight, and it's several hundred $$
17:25:50 elmiko they let me change for free, maybe status on delta?
17:32:29 cdent didn't you buy your flight late? In which case it would be changeable anyway?
17:32:44 elmiko good point, i was still in some sort of grace period
18:16:50 mordred dtantsur|afk: I'm all for bumping min microversions - I'm just arguing that doing so already has a name and a well-understood and supported system. it's called "bumping the major version" and we support it everywhere with no additional effort :)
18:53:46 elmiko mordred: i'm kinda curious about the effects on maintenance of keeping around old versions, like what if a team wants to move away from keeping the old code (assuming there is some rational reasoning behind it)
18:54:36 elmiko or am i misunderstanding this issue?
19:01:06 cdent elmiko: that's one of the main points of this discussion: making it possible to drop old versions
19:01:25 cdent but doing it in concert
19:05:09 elmiko yeah
19:05:30 elmiko i just really appreciate mordred's take on the idea of bump max keep min, i'm curious to hear more about his thoughts
19:05:44 elmiko i'm also trying to confirm that i understood this XD
19:06:32 elmiko from a compatability standpoint i totally get it, i'm just concerned about the developer response to keeping old stuff
21:06:52 openstackgerrit Merged openstack/keystoneauth master: Collect timing information for API calls https://review.openstack.org/568877
21:06:53 openstackgerrit Merged openstack/keystoneauth master: Add oslo.config option for split-loggers https://review.openstack.org/568878
21:06:55 openstackgerrit Merged openstack/keystoneauth master: Expose version_between as a real function https://review.openstack.org/568640
22:39:14 dmsimard|off mordred, Shrews: does that ring you a bell ? http://paste.openstack.org/show/721195/
22:39:29 dmsimard|off when trying to use the openstack dynamic inventory
22:39:39 dmsimard|off fresh install, afaict shade, os_client_config are installed etc
22:41:10 dmsimard|off looks like https://github.com/openstack/os-client-config/commit/5c2eae8f8242332aff59d18b45a7d17f01524aaa
23:28:23 openstackgerrit Alexander D. proposed openstack/os-client-config master: fix saltstack breakage introduced in v1.31.0 https://review.openstack.org/569291
#openstack-sdks - 2018-05-18
02:06:40 openstackgerrit Chen proposed openstack/python-openstackclient master: Compute: Add description support for server https://review.openstack.org/568549
02:12:59 openstackgerrit Chen proposed openstack/python-openstackclient master: Compute: Add description support for server https://review.openstack.org/568549
02:31:48 openstackgerrit Chen proposed openstack/python-openstackclient master: Compute: Add description support for server Part 1 https://review.openstack.org/568549
09:21:29 dtantsur mordred: well, I'd argue with the "no additional effort" bit.. at least for me as rust-openstack developer supporting major versions is a bit of a pain
10:12:24 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: refuse to inspect associated machines https://review.openstack.org/569375
11:00:35 openstackgerrit Chen proposed openstack/python-openstackclient master: Compute: Add description support for server Part 2 https://review.openstack.org/569385
11:00:37 openstackgerrit tianhui proposed openstack/python-openstackclient master: Compute: Add tags support for server https://review.openstack.org/569386
11:15:12 frickler dmsimard|off: do you use the default contrib/inventory/openstack.py from the ansible repo or do you have a modified version? I had a similar issue with the former that was resolved in https://github.com/openstack/os-client-config/commit/e65033910714d6f7d198d8eff6997fdaec102474
11:57:49 mordred dtantsur: that's fair. I guess what I should have said is that since major versions already exist, clients that want to support the existing openstack installations have to have major version discovery / handling code today anyway - and we have documentation about how to handle all of the cases of it
11:58:36 mordred dmsimard|off, frickler: I think in this case it's an issue with executing the openstack dynamic inventory from a directory containing the inventory with the inventory script still named 'openstack.py'
11:58:54 mordred since it causes os-client-config's import of 'openstack.config' to fail by finding the inventory script as "openstack" instead
11:59:22 mordred dmsimard|off, frickler the solutions for now are either to rename the inventory script before running it, or to switch to the new inventory plugin
12:11:14 dmsimard|off mordred: oh yeah that makes sense
12:11:31 dmsimard|off mordred: I've had something similar happen with a json.py file at some point..
12:11:32 frickler mordred: hah, good catch, that explains why I couldn't reproduce this. mine is called 10-openstack.py for $reasons
12:12:21 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Update command test for volume.v3 https://review.openstack.org/569398
12:12:58 mordred dmsimard|off, frickler: I think it just goes to show that the new inventory plugin feature is a much better idea than the old inventory script model :)
12:14:36 mordred dtroyer, dhellmann, amotoki: ^^ the above osc patch is needed to fix osc gate jobs now that the cinder-v3-by-default patch landed
12:15:38 mordred dtroyer, dhellmann, amotoki: I'd love it if y'all could land it - that job not working also breaks occ's gate, and we just got a patch from a saltstack person fixing a regression they're having in production that I'd love to get landed and out the door
12:15:54 amotoki mordred: looking
12:16:00 mordred amotoki: thanks
12:23:25 dtantsur jroll: good catch re unit testing! I suspect that for some reason the test is not running at all...
12:23:42 jroll dtantsur: yeah, it's strange :)
12:24:08 dtantsur SKIPPED: Ironic operations not supported yet
12:24:21 dtantsur yay, mordred is it expected for all ironic unit tests to be skipped with ^^^?
12:24:24 jroll O_o
12:26:59 jroll mordred: totally agree that bumping the major version is the right thing to do - though seems like lots of effort to drop e.g. 1.11 and below, when the max is 1.48. 1.12 would become 2.1, 1.13, would become 2.2, etc, besides the code work it feels like lots of mental/docs overhead
12:29:45 mordred jroll: yes, I agree - I was actually thinking cut the new major at the latest max of the current - and keep the old major around for at least the normal deprecation cycle to give people a chance to catch up - so instead of cutting a v2 at 1.11 - just go ahead and cut a new major at 1.48 - but it's possible that's a bad idea for other reasons I haven't realized yet
12:30:23 jroll mordred: yeah, it just feels heavy
12:30:31 jroll most of this is about getting rid of bad apis or tech debt, right
12:30:50 mordred well - except that getting rid of bad apis is an illusion
12:31:02 jroll so either you do that in small pieces (and have many major versions in the end), or you have to do it all at once to keep it in a single major version bump
12:31:40 jroll ok, ignore "bad apis" for now, we can discuss that bit later :)
12:31:47 mordred I think it should be more about making progress towards a place where the 'default' api people see is nicer than it is about removing things
12:32:26 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: refuse to inspect associated machines https://review.openstack.org/569375
12:32:38 mordred the reason I've come to like microversions so much is that I can completely and totally ignore them - and for the most part that's what I do
12:33:23 mordred the problem I have with bumping a min is that it makes caring about microversions cease to be optional - and now microversions become the new major versions and there are 48 of them
12:34:15 mordred I'd rather us add things / change things over a few cycles using microversions until we like where we've got ... and then do a legit new major version based on where we got by iterating over time with the microversions
12:34:51 mordred that way consumers can continue to ignore microversions if they don't care about a specific feature and just program to the current major api version - and when a new major api version comes out then they can start caring about it
12:35:09 mordred but if we did new majors too often, it would also cause undue burden on people
12:35:31 mordred so it's certainly a balancing act that would take thought and likely can't be codified in a policy about 'when' a major is cut
12:35:40 jroll why are you making so much sense, I want to argue
12:35:42 jroll :)
12:36:02 dtantsur :D
12:36:05 jroll lol
12:36:14 jroll I think I'm good with that proposal, though probably needs more thought
12:37:16 mordred jroll: yes. much more thought - and discussion and whatnot
12:38:15 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Enable bare metal unit tests https://review.openstack.org/569401
12:38:16 dtantsur mordred: this is quite urgent IMO ^^^
12:39:19 mordred dtantsur: I agree - +A
12:40:21 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: refuse to inspect associated machines https://review.openstack.org/569375
12:51:34 mordred dtantsur: there's gonna me a small rabbit hole here - we need to land an osc patch that I pushed up this morning to fix the osc gate so that those patches will be green. but I have confidence we can get it done soon
13:00:16 dtantsur I see
13:08:40 mordred dtantsur: much text is needed in many places :)
13:09:05 dtantsur yep :) since I'm doing some work with openstacksdk now, I may be able to write a few paragraphs there
13:09:25 dtantsur (probably not today though)
13:46:42 openstackgerrit Pavlo Shchelokovskyy proposed openstack/python-openstackclient master: Add --name-lookup option to server list https://review.openstack.org/568345
14:02:11 gtema mordred: in my cloud router enable_snat is False by default. But in both openstacksdk and shade it is assumed to be True and therefore can be only switched off.
14:02:23 gtema mordred: Nice comment in the code "
14:02:24 gtema Sending it can cause a policy violation error
14:02:26 gtema # on some clouds.
14:02:54 gtema mordred: " makes me wonder how to fix the situation
14:14:19 mordred gtema: it looks to me like it defaults to None... ah
14:16:28 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Allow explicitly setting enable_snat to either value https://review.openstack.org/569422
14:16:34 mordred gtema: how about that ^^ ?
14:18:01 gtema great. Was also thinking about that, but was confused by this comment. shade will also need the same, since ansible is having same problem
14:19:38 gtema mordred: what is the plan to switch ansible from shade to sdk?
14:20:03 mordred gtema: yes - we'll need the same patch for shade
14:22:09 mordred gtema: there's two parts to the plane. one is to make shade a thin wrapper around openstacksdk like we just did with os-client-config. the other is to update the ansible modules... I think we could start that transition in the modules before the thin-shim layer is done for ansible 2.6 - as shade for ansible 2.5 already has a dependency on openstacksdk, so people should already have it installed
14:23:34 openstackgerrit Monty Taylor proposed openstack-infra/shade master: Allow explicitly setting enable_snat to either value https://review.openstack.org/569425

Earlier   Later