| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-26 | |||
| 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 guidelines on Version Discovery https://review.openstack.org/459710 | |
| 17:49:00 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add document describing consuming discovery https://review.openstack.org/459405 | |
| 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 | |
| 19:40:12 | cdent | yeah, more intertwingliness would be good | |
| 19:40:18 | mordred | a good for instance is that I ran across a public cloud with two regions. each region had a separate auth_url (which is decently normal) - but both regions thought of themselves as "RegionOne" | |
| 19:41:07 | mordred | I poked the operator and pointed out how that's confusing for a user - and their response was that nobody had ever given any advice on how to structure regions | |
| 19:42:01 | cdent | fair cop | |
| 19:42:02 | mordred | so what they actually had was two compltely independent clouds that happened to share a brand | |
| 19:42:30 | mordred | and I'm pretty sure we couldhave served them better :) | |
| 19:52:33 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Port image v1 to resource2 https://review.openstack.org/460291 | |
| 22:07:22 | briancurtin | Qiming: what do you think about just removing message v1 instead of porting it to resource2? it was deprecated in 2014, and we have had proper v2 support for quite a while now | |
| 22:09:24 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix quota functional tests for nova-net https://review.openstack.org/460334 | |
| 22:46:21 | openstackgerrit | Eric Fried proposed openstack/keystoneauth master: WIP: Introduce keystoneauth1.loading.adapter https://review.openstack.org/460337 | |
| 23:23:01 | openstackgerrit | Merged openstack/python-openstackclient master: Functional test for subnet_pool https://review.openstack.org/440150 | |
| 23:40:25 | openstackgerrit | Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/460264 | |
| 23:50:11 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix server create with nova-net https://review.openstack.org/460352 | |
| 23:52:41 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix quota functional tests for nova-net https://review.openstack.org/460334 | |
| #openstack-sdks - 2017-04-27 | |||
| 00:05:22 | Qiming | briancurtin, imo, removing it sounds the right thing to do since it was deprecated two years ago | |
| 00:09:16 | mordred | briancurtin: I believe you're using keystoneauth.session for endpoint finding/filtering - but you might find https://review.openstack.org/459405 interesting/worth a read - it's an attempt to capture the total story around service version discovery ... I'd love to know if it's got any holes or issues from your POV | |
| 00:09:25 | mordred | (if you have time - no worry/rush) | |
| 00:09:53 | mordred | briancurtin: it's also hairy - so it's entirely fine to have the opinion "screw that, I'll just let ksa do its thing thanks" :) | |
| 00:28:53 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix more nova-net functional tests https://review.openstack.org/460356 | |
| 02:02:35 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient master: Fix more nova-net functional tests https://review.openstack.org/460356 | |
| 02:02:35 | RuiChen | I saw a project named "OSCLIENT (CLI)" in the project navigator page https://www.openstack.org/software/project-navigator , that means openstackclient or any other things? | |
| 03:03:08 | openstackgerrit | Merged openstack/python-openstackclient master: Fix quota functional tests for nova-net https://review.openstack.org/460334 | |
| 03:06:50 | openstackgerrit | Merged openstack/python-openstackclient master: Fix server create with nova-net https://review.openstack.org/460352 | |
| 10:28:18 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Start using 'cliff.sphinxext' https://review.openstack.org/452861 | |
| 10:28:18 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Convert 'server' commands to use autoprogram https://review.openstack.org/458452 | |
| 11:40:43 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient master: Fix more nova-net functional tests https://review.openstack.org/460356 | |
| 12:45:06 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guidelines on Version Discovery https://review.openstack.org/459710 | |
| 12:45:07 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| 12:45:07 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add document describing consuming discovery https://review.openstack.org/459405 | |
| 12:49:46 | mordred | dtroyer: thanks for the review - great feedback | |