| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-25 | |||
| 16:25:35 | annegentle | cdent thanks! | |
| 16:25:47 | cdent | thank you | |
| 20:30:17 | openstackgerrit | Merged openstack/osc-lib master: Tell ClientManager when auth is required https://review.openstack.org/459660 | |
| 21:33:06 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: WIP Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| 21:33:48 | mordred | dtroyer: I responded to your comments from the occ version in there ^^ although I also did respond on the occ review too | |
| 21:34:24 | mordred | cdent, edleafe: that is the last and most crazy of the crazy documents for now - I promise, this one will hurt the most | |
| 21:34:48 | mordred | and is also the most raw / in need of refinement | |
| 21:36:56 | cdent | no contest this time | |
| 21:37:05 | cdent | i haven't had a chance to look at any of the other ones yet | |
| 21:37:05 | mordred | :) | |
| 21:37:27 | mordred | cdent: no worries at all -I've just been in writing-mode so am pouring all the things out | |
| 21:37:54 | mordred | I'mma go clean up the first two based on feedback so far | |
| 21:37:54 | cdent | and a very good thing it is too | |
| 21:38:00 | cdent | i hope to find that mode again soon | |
| 21:50:05 | dtroyer | mordred: how do you feel about an o-c-c release this week or next? I'm finally seeing a lot of green on the OSC -tips jobs everywhere now and things are working locally, not that I'm a heavy user or anything | |
| 21:51:22 | edleafe | mordred: okie dokie. Working on the consuming doc now | |
| 22:32:08 | cdent | dtroyer: pants is what you sit on and in when writing. they _have_ to be right | |
| 22:38:44 | mordred | dtroyer: I thnik that's a great plan! (especially since the tips job is green) | |
| 22:58:22 | openstackgerrit | Merged openstack/os-client-config master: Make _fix_argv() somewhat compatible with Argparse action='append' https://review.openstack.org/459115 | |
| 23:05:29 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add document describing consuming discovery https://review.openstack.org/459405 | |
| 23:05:29 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guidelines on Version Discovery https://review.openstack.org/459710 | |
| 23:05:54 | mordred | edleafe: thank you - updated from yours and morgans comments. I very much appreciate your time reading | |
| 23:09:42 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: WIP Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| #openstack-sdks - 2017-04-26 | |||
| 06:06:00 | openstackgerrit | Takashi NATSUME proposed openstack/python-openstackclient master: Add '--no-live' and '--force' option in 'server migrate' https://review.openstack.org/427565 | |
| 06:34:35 | openstackgerrit | Duan Jiong proposed openstack/python-openstacksdk master: fix typo https://review.openstack.org/459963 | |
| 06:40:27 | openstackgerrit | Rui Chen proposed openstack/python-openstackclient master: Live migration to choose host automatically https://review.openstack.org/459667 | |
| 07:17:04 | openstackgerrit | Takashi NATSUME proposed openstack/python-openstackclient master: List/show all server migration types https://review.openstack.org/450119 | |
| 08:31:16 | openstackgerrit | Carlos Goncalves proposed openstack/python-openstackclient master: Add 'data_plane_status' option to Port classes https://review.openstack.org/458626 | |
| 10:58:26 | openstackgerrit | Rui Chen proposed openstack/python-openstackclient master: WIP: Rework server migrate to support cold and live https://review.openstack.org/460059 | |
| 11:56:57 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Correct Network ports docstring for query parameters https://review.openstack.org/459963 | |
| 12:59:21 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Correct Network `ports` query parameters https://review.openstack.org/459963 | |
| 13:35:16 | openstackgerrit | Merged openstack/python-openstacksdk master: Correct Network `ports` query parameters https://review.openstack.org/459963 | |
| 16:08:21 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix NoneType error for volume snapshot create command https://review.openstack.org/440497 | |
| 16:33:58 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Develop api.versions for microversion discovery https://review.openstack.org/451618 | |
| 17:15:19 | mordred | cdent: fwiw, I'd argue that changes to the min_version are a de-facto new major version - but that might be better for a beer discussion in boston | |
| 17:16:12 | cdent | there's been a few statements like that at various different times, and one position is that every-single-microversion is in fact a major version | |
| 17:16:38 | cdent | and that the reason for being able to tweak min_version is to indicate something more major than major | |
| 17:16:42 | cdent | all of which is wordplay | |
| 17:16:55 | cdent | but seems to keep at least some contexts happy | |
| 17:25:42 | mordred | cdent: yah - I think for me it's different because the major version sets the floor- if you do nothing else, these things will be present. then each microversion is an opt-in change to that base contract that a user can request | |
| 17:26:06 | mordred | cdent: so the version discovery process allows a user to select which of the base palettes of API are available that they'd like to work with | |
| 17:26:26 | mordred | and then microversions allow for subsequent tweaking of that | |
| 17:27:07 | cdent | sure, but if you plan to only ever have one base palette, how's that work? | |
| 17:27:21 | mordred | bumping a min is similar to removing a major from the deployment- if you say "I'd like to work with glance v1" and the cloud doesn't have v1, then you know what's going on quickly | |
| 17:27:38 | cdent | yes | |
| 17:27:46 | mordred | cdent: i'd say if you plan to only ever have one base palette that you should never bump your min | |
| 17:27:51 | mordred | since the min is the default palette | |
| 17:28:07 | cdent | I agree. Am I supposed to be defending something? ;) | |
| 17:28:13 | mordred | but if you do want to e able to bump your min, then the mechanism for doing that is called "release a new major api version" | |
| 17:28:25 | cdent | ah, that | |
| 17:28:26 | mordred | cdent: I don;t think so -it's entirely possible we're in total agreement | |
| 17:29:18 | cdent | If I were to try to defend/posit something, it would be: dear god stop putting versions in urls, if you need versions, put them in discovery, but preserve urls | |
| 17:29:21 | mordred | but it's also possible this is entirely a place where I'm being unreasonable but we'd have more fun discovering that iwth beers :) | |
| 17:29:27 | cdent | (even in the face of major versions) | |
| 17:29:44 | mordred | cdent: yah - I'd totallybe on board with that - and with decoupling the two concepts | |
| 17:32:12 | cdent | mordred: so I've just changed my boston flights so that I'm not there saturday to the sunday 8 days later, so I should have plenty of time to noodle about these things over beverages of our choice, especially if there is a bull involved | |
| 17:33:54 | cdent | s/not/now/ | |
| 17:45:48 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Port database v1 to resource2 https://review.openstack.org/460236 | |
| 17:49:00 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add document describing consuming discovery https://review.openstack.org/459405 | |
| 17:49:00 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guidelines on Version Discovery https://review.openstack.org/459710 | |
| 17:50:08 | mordred | cdent: ^^ I have responded to yours and morgan's comments - which has resulted in the removal of the Versioned document as a recommendation (although it does suggest an amendment to existing ones should they exist) | |
| 17:50:31 | mordred | and the result is quite a bit nicer all around I believe (was able to streamline a portion of the consume process too) | |
| 17:51:03 | cdent | mordred: awesome, will look again tomorrow morning, assuming the sun rises once more | |
| 17:51:21 | mordred | cdent: here's hoping that's a good assumption | |
| 17:52:05 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Functional test for subnet_pool https://review.openstack.org/440150 | |
| 18:19:36 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/460264 | |
| 18:50:36 | openstackgerrit | Merged openstack/python-openstackclient master: SDK refactor: Set "is_admin_state_up" for network agent https://review.openstack.org/427998 | |
| 19:08:11 | openstackgerrit | Merged openstack/python-openstackclient master: Fix NoneType error for volume snapshot create command https://review.openstack.org/440497 | |
| 19:10:10 | cdent | mordred: just read your novel and it made me think of what I think is becoming a bit of a candard: why can't we just have a service catalog that is a static cacheable file? | |
| 19:13:18 | mordred | cdent: because of data that's different per-user | |
| 19:13:26 | mordred | cdent: BUT - that's sort of what this is :) | |
| 19:14:03 | cdent | that's essentially my question: if project id and tenant id are not part of urls (because they shouldn't be in the glorious future) what part is per-user? | |
| 19:14:15 | cdent | (and not just "what" but "why") | |
| 19:14:25 | mordred | cdent: the big use case is rolling out new services to subsets of users | |
| 19:15:03 | cdent | yeah, I think it was in vancouver there was some degree of support for "just don't do that, just tell those people about the special thing" | |
| 19:15:08 | cdent | but that's probably unrealistic | |
| 19:15:40 | mordred | yah. also, there is stil a chicken-and-egg with putting this info into a nice static cacheable catalog | |
| 19:15:58 | mordred | which is hat one of the things that's imposibleto discover is "what auth plugin does my cloud's keystone use" | |
| 19:17:59 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Add default-quota to subnet pool commands https://review.openstack.org/437367 | |
| 19:18:11 | mordred | cdent: I've got an update though that maybe addresses it a little... | |
| 19:19:02 | cdent | mordred: I'm not suggested _all_ of it go in the service catalog | |
| 19:19:10 | cdent | just the stuff that is actually about services | |
| 19:19:28 | cdent | the post auth stuff | |
| 19:20:46 | mordred | yah - I hear you | |
| 19:21:07 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: WIP Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| 19:21:30 | mordred | cdent: there's some updates that maybe touch on this some? (it's also probably a great topic for beverages) | |
| 19:22:49 | cdent | yah, mostly just making conversation at this point because my brain got tickled | |
| 19:23:12 | mordred | \o/ | |
| 19:23:24 | mordred | it's fun conversation | |
| 19:29:43 | openstackgerrit | Merged openstack/python-openstackclient master: Remove ipdb installation in tox debug section https://review.openstack.org/459180 | |
| 19:33:26 | mordred | cdent: it occurs to me from working on these specs, that there are two different type of advice happening (three, really, but one is an outlier so meh) | |
| 19:34:02 | mordred | a) this is how a service's API should work and b) these are things a deployer should do so that the service works as expected | |
| 19:34:22 | mordred | they're both in service of "this is how the APIs should work when people consume them" - but there's definitely two different audiences | |
| 19:34:57 | mordred | now I'm mostly just musing out loud | |
| 19:35:21 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Port identity v2 to resource2 https://review.openstack.org/460288 | |
| 19:35:26 | cdent | they are two different audiences, true, but I think we do ourselves a disservice when we keep that kind of information separated. the context is useful for the other audience | |
| 19:35:57 | mordred | totally agree | |
| 19:36:23 | mordred | I think one of the great things about the stuff in this repo is that is gives context and intended outcome and isn't just focused on impl details | |
| 19:37:50 | mordred | mostly just started musing about ways to leave breadcrumbs to things so that a deployer could consume the things they need to without getting overwhelmed - but maybe that's just making sure the deployer guide is up to date and has pointers - like "do this. for more information, see api-wg document ..." | |
| 19:38:28 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/460264 | |