| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-12 | |||
| 04:19:51 | openstackgerrit | OpenStack Proposal Bot proposed openstack/osc-lib master: Updated from global requirements https://review.openstack.org/455972 | |
| 04:21:53 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/456003 | |
| 04:21:56 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstacksdk master: Updated from global requirements https://review.openstack.org/456004 | |
| 06:51:07 | RuiChen | hi reedip: I add some comments in https://review.openstack.org/#/c/425515/ | |
| 06:58:43 | reedip | hi RuiChen | |
| 06:58:45 | reedip | checking | |
| 06:59:09 | reedip | ok , seem like relevant comments | |
| 07:16:09 | openstackgerrit | Reedip proposed openstack/osc-lib master: Add MultiKeyValueCommaAction to osc-lib https://review.openstack.org/425515 | |
| 07:21:44 | reedip | RuiChen: updated | |
| 07:22:04 | reedip | I understood where I was going wrong with the KeyError, handled it separately | |
| 07:40:09 | RuiChen | reedip: key1=val1,val2 key2=val 3 => {"key1": "val1", "val2"},{"key2": "val3"} the example is still wrong, should be key1=val1,val2,key2=val3 => {"key1": "val1,val2", "key2": "val3"} | |
| 07:40:50 | RuiChen | reedip: and please fix the release notes | |
| 07:47:34 | openstackgerrit | Reedip proposed openstack/osc-lib master: Add MultiKeyValueCommaAction to osc-lib https://review.openstack.org/425515 | |
| 07:47:39 | reedip | RuiChen : ^^ | |
| 09:16:38 | openstackgerrit | Merged openstack/api-wg master: Remove reference to nova on version discovery https://review.openstack.org/453744 | |
| 11:36:36 | openstackgerrit | Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/456003 | |
| 12:25:42 | mordred | jamielennox: if you have a sec, could you look at https://review.openstack.org/#/c/452550/ ? | |
| 12:26:55 | jamielennox | mordred: i had something for this... | |
| 12:27:34 | mordred | jamielennox: neat! if there is a better way that's awesome :) | |
| 12:30:12 | jamielennox | mordred: so the plan was that session supports app_name and app_version, and adapter supports client_name and client_version | |
| 12:30:33 | jamielennox | when nova_client creates the adapter it should pass client_name and client_version | |
| 12:31:01 | jamielennox | when heat (or whoever) creates the session it passes to novaclient it passes app_name and app_version | |
| 12:31:21 | jamielennox | so when it talked to multiple clients you would get the correct heat/X novaclient/Y keystoneauth/Z ... | |
| 12:31:55 | mordred | cool - did we do those? | |
| 12:32:04 | jamielennox | in a couple of places... | |
| 12:32:07 | jamielennox | but largely no | |
| 12:32:24 | mordred | oh - but session and adapter have them - so I can use them it seems perhaps | |
| 12:32:49 | jamielennox | there was then a session.additional_user_agent list that was for things like os-c-c that fit somewhere in the middle | |
| 12:33:13 | mordred | jamielennox: awesome. I will rework this patch to make use of that system | |
| 12:33:45 | mordred | so for example, occ willbe additional_user_agent - shade will be client and nodepool will be app | |
| 12:34:11 | mordred | (at least, once all the python-*clients are removed) | |
| 12:34:12 | jamielennox | mordred: yea, that was the intent but it was one of those things that the person who was pushing a lot to have it in lost interest once it was | |
| 12:34:18 | jamielennox | yep | |
| 12:35:03 | jamielennox | i feel like additional on session is going to be weird so let me know if you want that tweaked | |
| 12:35:43 | mordred | kk. | |
| 12:35:51 | openstackgerrit | Merged openstack/python-openstacksdk master: Updated from global requirements https://review.openstack.org/456004 | |
| 12:50:23 | openstackgerrit | Merged openstack/python-openstacksdk master: Add 'project_id' to Server query parameters https://review.openstack.org/454241 | |
| 13:45:53 | openstackgerrit | yuval shalev proposed openstack/python-openstacksdk master: Add support for volume attachments in compute v2 https://review.openstack.org/455335 | |
| 13:56:03 | openstackgerrit | yuval shalev proposed openstack/python-openstacksdk master: Add support for volume attachments in compute v2 https://review.openstack.org/455335 | |
| 13:57:46 | openstackgerrit | yuval shalev proposed openstack/python-openstacksdk master: Add support for volume attachments in compute v2 https://review.openstack.org/455335 | |
| 14:19:57 | openstackgerrit | yuval shalev proposed openstack/python-openstacksdk master: Add support for volume attachments in compute v2 https://review.openstack.org/455335 | |
| 14:46:49 | openstackgerrit | Monty Taylor proposed openstack/os-client-config master: Add ability to pass in user_agent https://review.openstack.org/452550 | |
| 14:47:04 | mordred | jamielennox: ^^ ok. I think that does things right using the app_name/client_name bits | |
| 14:57:59 | mordred | jamielennox: also - client_name,client_version are not getting added to the user-agent in keystoneauth | |
| 14:58:25 | mordred | so setting them on the adapter is possible, but it doesn't change anyting (setting additional_user_agent in the Session _does_ work) | |
| 15:01:57 | mordred | jamielennox: oh - I see - it happens at request time - so I'm breaking that in shade - I can fix that | |
| 15:33:18 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Shift additional_user_agent in the stack https://review.openstack.org/456259 | |
| 15:33:19 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Allow setting client name on the Session https://review.openstack.org/456260 | |
| 16:00:39 | reedip_ | o/ | |
| 21:21:22 | mordred | edleafe, cdent: https://review.openstack.org/456394 I just made a neutron API spec that I'd love API-WG thoughts on | |
| 21:22:25 | cdent | mordred: ah, cool, I look forward to reading that tomorrow. i have zero brains left for today | |
| 21:23:07 | mordred | cdent: braaaaaaains | |
| 21:23:17 | mordred | cdent: I'm fairly certain it's all wrong | |
| 21:23:25 | cdent | best way to get started | |
| 21:23:27 | mordred | cdent: I mean, except for the part where it's an essential feature | |
| 21:23:37 | mordred | that I am certain I am correct about | |
| 21:23:40 | mordred | but everythign else is wrong | |
| 21:39:33 | edleafe | mordred: from an API perspective it seems fine. Maybe split the key type from the "key" key | |
| 21:39:45 | edleafe | heh - a key named 'key' | |
| 21:40:17 | edleafe | so the 'keys' list would contain dicts of "comment", "type", and "key" | |
| 21:40:36 | edleafe | just to make it easier to filter client-side | |
| 21:41:10 | mordred | edleafe: that'sa great idea | |
| 23:24:21 | jamielennox | mordred: with the additional shift why do you want it there? | |
| 23:24:37 | jamielennox | mordred: not that anyone else uses this, but my thought would be you would want to see like | |
| 23:24:52 | jamielennox | nova/A os-c-c/B glanceclient/C | |
| 23:25:03 | jamielennox | because os-c-c is like creating the glanceclient | |
| 23:28:48 | jamielennox | mordred: yea, i'd like to have a bit more discussion on what you're trying to do there | |
| #openstack-sdks - 2017-04-13 | |||
| 00:00:36 | mordred | jamielennox: ah- I see what you mean - so I'll try to make this extra complex ... | |
| 00:01:40 | mordred | but first - I mostly have stopped caring about python-*client - but let's keep them for now because they make the discussion more interesting (harder) | |
| 00:02:57 | mordred | so - for the shade case, we have nodepool uses shade which uses os-client-config which uses keystoneauth which uses requests (at least that's how I think of it in my head) | |
| 00:04:11 | mordred | then for novaclient, it would be nodepool -> shade -> os-client-config -> novaclient -> keystoneauth ... or is it? | |
| 00:04:34 | mordred | maybe for the novaclient/glanceclient path the occ part is not meaningful | |
| 00:04:46 | jamielennox | sounds right | |
| 00:04:52 | mordred | in fact, I wonder if occ is important in the user agent at all? | |
| 00:05:14 | jamielennox | i think this is what dtroyer came to as well, telling people osc-lib version wasn't that important - but it's there if you want it | |
| 00:05:15 | mordred | it's setting up objects, but it's not really involved (atm) in making actual calls | |
| 00:05:20 | mordred | nod | |
| 00:09:05 | mordred | jamielennox: so maybe focusing on interior ordering isn't important - nodepool "the app" being first in the list seems important, and ksa/requests being at the end seems right | |
| 00:09:21 | mordred | other than that, I can make all sorts of arguments about why one sequence makes more sense than the other | |
| 00:09:28 | mordred | but I'm not sure any of them actually make sense :) | |
| 00:09:56 | jamielennox | mordred: yea, it took us a while to get to the layout we have because of these sorts of things - you can get really picky about it | |
| 00:10:10 | mordred | ++ | |
| 00:10:12 | jamielennox | realistically the best thing to do would be to have the python clients actually insert their name into the sequence | |
| 00:10:43 | mordred | yah. although hopefully 'soon' I won't be using them for anything anymore and that can be someone else's problem | |
| 00:12:17 | mordred | jamielennox: for the other patch - the main thing was that without adding client_name to session and only on adater, we lose it when ksa makes discovery calls on behalf of the user | |
| 00:12:38 | mordred | so I figured just setting it on session would be eaiser than plumbing client_name to wherever it needed to be for discovery calls | |
| 00:12:46 | mordred | but again, it's possible I'm making it too difficult :) | |
| 00:12:52 | jamielennox | oh, because discovery is internal to ksa? | |
| 00:13:30 | jamielennox | i mean we can plumb it through - but maybe it doesn't matter | |
| 00:13:36 | mordred | yah - and ksa doens't use an adapter for it | |
| 00:13:42 | jamielennox | things done internal to ksa don't care what invoked the request | |
| 00:13:57 | jamielennox | i mean it would be useful to know what client started the call | |
| 00:14:42 | mordred | right - but when I think of user-agents I think of ops looking at logs to figure out why a particuar traffic pattern came in - and if it was shade that asked ksa for something, I feel like I'd be missing part of the story? | |
| 00:14:42 | jamielennox | mordred: i don't mean to argue this too much, but it's two new params in an already complicated list for fairly small benefit | |
| 00:14:51 | mordred | _but_.... I don't have an actual use case | |
| 00:15:16 | mordred | jamielennox: totally understand - I appreciate you curating the library well :) | |
| 00:15:40 | jamielennox | mordred: is shade creating the session? | |
| 00:16:09 | jamielennox | oh right, this is why shade is out of order with the python-*client in additional | |
| 00:16:21 | mordred | yah | |
| 00:16:50 | mordred | actually - shade does not create the session - occ creates the session for it | |