Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-05-17
16:48:46 cdent elmiko: ^
16:48:58 edleafe cdent: you should add wording to that effect then
16:49:15 cdent i'm not sure how to say it. thus bouncing the idea here
16:49:21 elmiko i changed it a little, see if that works
16:50:17 dtantsur "clarify what it means when we bump the minimum microversion" ambitiously :)
16:50:46 dtantsur otherwise LGTM
16:51:06 elmiko i like the reference point cdent
16:51:23 elmiko dtantsur: haha, totally
16:51:55 elmiko ooh, even more ambitious edleafe
16:52:03 edleafe asbestos jackets are required
16:52:10 elmiko hahaha, indeed!
16:52:30 edleafe I changed my color. Blue is cdent
16:52:36 elmiko oh, whoops
16:52:40 elmiko then good show cdent
16:52:40 edleafe our colors were too close
16:53:05 cdent I just took what I added from the session description. I'm done.
16:53:09 elmiko can we add (abestos jackets recommended) at the end?
16:53:45 elmiko thanks for the help all, gonna publish
16:53:51 cdent rumor has it all the firefighting will happen over beer beforehand
16:53:58 elmiko +1
16:53:59 edleafe nah, let 'em figure it out themselves!
16:54:04 cdent so I phoned ahead to the vancouver breweries to prepare them for mordred and mugsie
16:54:08 elmiko edleafe: haha
16:54:16 cdent dtantsur: it was mordred's idea
16:54:23 cdent (partly)
16:54:50 dtantsur that's a plan: collect all people who want to bump the minimum version in one room aaaaand <invent your even ending>
16:55:01 dtantsur s/even/evil/
16:55:07 elmiko sent
16:55:29 mugsie well, there is one person who wants to `rm -rf microversions` going to be in that room :P
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

Earlier   Later