| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-26 | |||
| 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 | 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? | |
| 02:02:35 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient master: Fix more nova-net functional tests https://review.openstack.org/460356 | |
| 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: Convert 'server' commands to use autoprogram https://review.openstack.org/458452 | |
| 10:28:18 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Start using 'cliff.sphinxext' https://review.openstack.org/452861 | |
| 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 document describing consuming discovery https://review.openstack.org/459405 | |
| 12:45:07 | openstackgerrit | Monty Taylor proposed openstack/api-wg master: Add guideline describing a cloud profile document https://review.openstack.org/459869 | |
| 12:49:46 | mordred | dtroyer: thanks for the review - great feedback | |
| 12:49:59 | mordred | and *doh* - how did I mess mention of volumev2 | |
| 12:50:53 | mordred | edleafe: I'm starting to think that maybe there should be two documents where version discovery one is - one about version discovery, and one about what should go into the service catalog | |
| 13:02:23 | edleafe | mordred: Yeah, I'm not sure about the exact breakdown, but in general there should be a "here's how to set things up correctly as a provider", and a "here's to process things correctly as a consumer" | |
| 13:02:37 | edleafe | Most of the API-WG stuff focuses only on the former | |
| 13:12:26 | openstackgerrit | Monty Taylor proposed openstack/service-types-authority master: Add an attribute for aliases https://review.openstack.org/460539 | |
| 13:12:27 | openstackgerrit | Monty Taylor proposed openstack/service-types-authority master: Add explicit mention of versions https://review.openstack.org/460540 | |
| 13:13:19 | mordred | edleafe: yah - cdent and I chatted briefly about a similar breakdown yesterday - which is "this is how a service should write an API" and "this is an action a deployer should take that affects the API" | |
| 13:13:50 | mordred | edleafe: but I'm happy to be mixing things up and adding this new confusing "this is how to process things as a consumer" :) | |
| 13:15:04 | edleafe | The consumer angle is new to us. We've assumed that if you follow the guidelines, it'll be super-easy for the consumer. :) | |
| 13:15:36 | mordred | edleafe: I look forward to the day when this is true! | |
| 13:16:14 | mordred | edleafe: (I do agree quite strongly with that goal, btw - in some ways the "consuming-discovery" document is a bit of a cautionary tale explaining why the discovery guideline is important) | |
| 13:17:13 | edleafe | Ah, I like that POV. "While we strive to make things easy, we also need to handle some inherently complex stuff." | |
| 13:23:12 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Deprecated Message v1 https://review.openstack.org/460544 | |
| 13:23:24 | dtroyer | that is an uphill battle on the client dev side too, not just the API developers… it takes new contributors a bit to understand why OSC goes to extra lengths to make things simpler for the user. "But I'd have to make another API call, can't the user just do that?" | |
| 13:24:50 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Deprecate Message v1 https://review.openstack.org/460544 | |
| 13:26:16 | edleafe | dtroyer: heh, I feel your pain. Developing an intermediate layer, like an SDK or a client like OSC, requires both consuming and creating interfaces | |
| 13:28:29 | mordred | edleafe: yup. super fun | |
| 14:16:51 | openstackgerrit | Merged openstack/python-openstacksdk master: Port database v1 to resource2 https://review.openstack.org/460236 | |
| 14:17:01 | openstackgerrit | Merged openstack/python-openstacksdk master: Port image v1 to resource2 https://review.openstack.org/460291 | |
| 14:17:06 | openstackgerrit | Merged openstack/python-openstacksdk master: Port identity v2 to resource2 https://review.openstack.org/460288 | |
| 14:27:25 | openstackgerrit | Monty Taylor proposed openstack/service-types-authority master: Add aliases for historical well-used block-storage types https://review.openstack.org/460609 | |
| 14:29:32 | cdent | edleafe: that's a good point about next_min_version. I think when I added it there I just kind of assumed next_min_version would resolve (to most likely merging) before the interop stuff did | |
| 14:29:36 | cdent | it has not turned out that way | |
| 14:31:48 | amotoki | ankur-gupta-f4: ping | |
| 14:32:38 | edleafe | cdent: Let's bring that up at today's meeting | |
| 14:33:47 | dtroyer | #RgentL33 | |
| 14:34:15 | mordred | dtroyer: welp, so much for that one | |
| 14:34:50 | dtroyer | now if you only knoew what it actually was :) | |
| 14:35:33 | mordred | dtroyer: it's like the key I have on my keychain that I have no idea what lock it's for | |
| 14:36:18 | dtroyer | I have a box of those. it's the one marked "Bugatti" that I'm most interested in finding | |