| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-02-16 | |||
| 14:51:36 | sdague | so even mordred's issues don't seem very far from concensus | |
| 14:51:53 | cdent | sdague: Yes, but I'm not willing to do so while there's still some pretty hefty disagreement in the comments. I'm trying to be really agnostic about my own points of view and get the disagreements to a point of at least compromise if not aggreement, without imposing my own view. | |
| 14:52:14 | sdague | ok, what do you see as the major disagreements? | |
| 14:52:14 | cdent | I think steve isn't fully on board with everything yet, for example | |
| 14:53:23 | cdent | a) not a disagreement but something that needs to be cleared up is the unresolved questions section | |
| 14:54:15 | cdent | b) monty's comments about never changing even with a version is an important thing to resolve. it is the heart of the discussion and the main reason why the document now opens with "if you're gonna do this you must version" | |
| 14:54:49 | cdent | c) the role or meaning of discoverability with regard to capability needs to be clarified | |
| 14:55:24 | cdent | d) 5xx to 4xx == okay needs to change to 500 to anything == okay | |
| 14:55:56 | cdent | e) at least one person wants the examples back | |
| 14:56:24 | sdague | so I don't think c) needs to be resolved before this is updated, because that's an active and ongoing discussion | |
| 14:56:45 | sdague | and other things are held up by the asserting that the currently written api guidelines aren't valid any more | |
| 14:56:55 | cdent | sure, but that conversation is happening because we are doing this process | |
| 14:57:15 | cdent | so it would be good to have it play out on a field where it's already happening? | |
| 14:58:50 | sdague | only if there is a belief that all relevant inputs have the stamina for that, and won't give up and go other places. I'm much more a fan of "ok, we're all agreed on X, get that committed, so it's clear where we are still having discussion" | |
| 14:59:16 | sdague | because while the whole thing remains uncommitted people assume, correctly, that everything is up for reinterpretation | |
| 15:03:00 | cdent | I guess I'm pretty invested in allowing people to explore that reinterpretation because it is exactly that which leads to real, instead of artifical, agreement | |
| 15:04:11 | cdent | sdague: I'm not intending to draw this out forever or anything, and if I had a clear understanding of everything that was in the comments right now, I'd try to close it up pronto. but right now I don't. | |
| 15:06:08 | cdent | sdague: I'm especially hesitant to commit the pending conversation down when people who I know to have a lot of interest and opinion on this topic (like mordred) have only commented today | |
| 15:06:25 | cdent | he's provided some good input which will help the next version | |
| 15:07:42 | sdague | sure, there is just a lot of cognitive weight on the fact that the diff is the entire document. | |
| 15:08:47 | cdent | Yeah, that was intentional. Sometimes making good stuff takes work. | |
| 15:09:05 | cdent | I think think for you this feels like tuning something for which there was already some measure of agreement | |
| 15:09:39 | cdent | but based on the conversations I've had with other people, there are significant bits that were rules that people felt they didn't or couldn't agree with | |
| 15:10:24 | cdent | the lumbering and cumbersome process here is in place to try to expose those things that make people squirm and to be explicit about it and not paper over it | |
| 15:15:10 | mordred | cdent: yesterday I had some fun with usage from nova ... | |
| 15:15:19 | mordred | a project's usage contains some totals for the project and then a list of explicit server usages that enumerate each server's usage of resources | |
| 15:15:21 | mordred | in the top level usage, there are two datetimes - stop and start - which are the start and stop of the time period requested | |
| 15:15:23 | mordred | in the server_usages list - there are two datetimes - started_at and ended_at | |
| 15:15:25 | mordred | then in a server itself - there are four datetimes launched_at, terminated_at, created and updated | |
| 15:16:40 | mordred | cdent: isn't that magical? | |
| 15:18:44 | sdague | cdent: ok, I'm throwing on a few more comments there | |
| 15:19:00 | cdent | sdague: great, thank you | |
| 15:19:38 | sdague | my hope, one day I'll stop having to explain that adding a field in a multi deployment environment isn't a non breaking change | |
| 15:20:56 | cdent | sdague: I think we've almost reached buy in on that, but not quite yet on values | |
| 15:25:11 | dtroyer | values is nearly the came thing from a consumer standpoint, where we've hurt ourselves is where those are deployment-specific. and that's part of the discovery question that is ongoing. Values that are part of say a server's state should be API versioned as those are expressed in code not in config. | |
| 15:25:17 | dtroyer | s/came/same/ | |
| 15:25:38 | mordred | dtroyer: ++ | |
| 15:38:01 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient master: Gate broken test https://review.openstack.org/434818 | |
| 15:39:35 | dtroyer | stevemar: any idea on why that passed to get in but fails so regularly now? | |
| 15:40:05 | stevemar | dtroyer: i'm guessing something broke us? | |
| 15:40:17 | stevemar | dtroyer: maybe tempest or cliff or something more subtle | |
| 15:40:48 | dtroyer | cliff hasn't changed, I did wonder about the wisdom of pulling in tempest there, but figured utilities were safe | |
| 15:46:05 | stevemar | dtroyer: looking at the source it seems okay... | |
| 15:48:21 | stevemar | dtroyer: tempest looks OK, i'm quite confused :) | |
| 15:49:09 | stevemar | dtroyer: but i definitely don't see something that we merged that would have broken us | |
| 15:49:12 | dtroyer | its the unicode coercion that struck me… does tempest include unicode chars in the generated name, maybe only occasionally? | |
| 15:50:34 | stevemar | dtroyer: thats what i was wondering, why i put up the patch to use a straight uuid | |
| 15:50:52 | stevemar | dtroyer: but it doesn't seem like tempest does that https://github.com/openstack/tempest/blob/master/tempest/lib/common/utils/data_utils.py#L46-L62 | |
| 15:50:57 | dtroyer | which I think we should do anyway | |
| 15:51:56 | dtroyer | yeah, that's pretty simple | |
| 16:17:33 | mordred | cdent: what channel is the api meeting in again? | |
| 16:17:48 | cdent | mordred: #openstack-meeting-3 | |
| 16:34:18 | openstackgerrit | Michael Johnson proposed openstack/service-types-authority master: Add load-balancing service type https://review.openstack.org/434999 | |
| 16:38:06 | openstackgerrit | Merged openstack/api-wg master: Add guidelines for boolean names https://review.openstack.org/411529 | |
| 19:01:15 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add new parameter "is_default" to Network QoS policy. https://review.openstack.org/432260 | |
| 19:11:55 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Reorganize key_manager docs https://review.openstack.org/435069 | |
| 19:16:14 | ankur-gupta-f4 | dtroyer: finalize --<agent-name> for the network agent commands. Put the optional arg. Done-done. | |
| 19:16:43 | dtroyer | ok, cool, I'll chekc when I pass through the review queue again later | |
| 19:17:27 | sindhu | dtroyer: ping? | |
| 19:17:49 | dtroyer | sindhu: yes | |
| 19:18:08 | sindhu | dtroyer: hi, regarding https://review.openstack.org/#/c/382023/ | |
| 19:18:55 | sindhu | dtroyer: is it ok to have --network, --compute, --volume option like the list command? | |
| 19:19:17 | sindhu | dtroyer: right now this patch only handles network extension | |
| 19:19:53 | dtroyer | what other API still has extensions? They've been eradicated from the other core projects | |
| 19:19:59 | ankur-gupta-f4 | the others don't have extension show though do they? | |
| 19:20:01 | ankur-gupta-f4 | yea | |
| 19:20:10 | dtroyer | and I'd argue should go away in neutron too, but that's for a different audience | |
| 19:20:51 | ankur-gupta-f4 | hence my comment to take it out of common and make it a core networking command. so 'os network extension show' | |
| 19:20:54 | dtroyer | that said, I dislike making the resource name 'network extension' because it reinforces the notion that "all network commands must be namespaced with 'network'" which is exactly not the case | |
| 19:21:14 | reedip_1 | dtroyer : Neutron is pretty tightly coupled with extensions actually | |
| 19:21:45 | dtroyer | OSC is based around named resources, many of which are qualified with names that happen to match API service types, but some do not. and | |
| 19:21:55 | reedip_1 | I agree with ankur-gupta-f4 , remove this from common till we do not have more extensions to list :P | |
| 19:22:09 | dtroyer | reedip_: that doesn't make it a good idea or one that should be copied elsewhere. it isn't | |
| 19:23:38 | reedip_1 | dtroyer : I agree , if it has been removed from other projects, neutron can also look in the future to remove the same , if possible . But till it is not, we can use "openstack extension list --network " to list network extensions, couldnt we ? | |
| 19:23:41 | dtroyer | I would also argue that we prefixed some resources with 'network' out of habit that didn't need it, again due to the misconception that "that is the way it should be done" rather than to fully-qualify the resource | |
| 19:24:49 | dtroyer | reedip_: yes, that would work. also, since no other API has extensions (in the OSC repo anyway) —network can be optional. if others appear then no option simply lists them all | |
| 19:24:49 | ankur-gupta-f4 | reedip_1: note the the command is extension show. List is already in place. | |
| 19:25:22 | dtroyer | why does a show command need a type identifier? | |
| 19:25:47 | dtroyer | to show something you have to have a name or ID to begin with? | |
| 19:26:04 | reedip_1 | sorry ankur-gupta-f4 , misread the command | |
| 19:26:18 | ankur-gupta-f4 | because list extensions exists for all core resources. But extension show only is a network command | |
| 19:26:39 | ankur-gupta-f4 | volume and compute APIs don't support the 'show' which returns more details about a specific API extension | |
| 19:27:13 | dtroyer | so either throw an exception for them (not found?) or return an empty or minimal result set | |
| 19:27:49 | sindhu | so i'll still keep in common ? | |
| 19:27:55 | dtroyer | yes | |
| 19:28:05 | ankur-gupta-f4 | but update help text plz | |
| 19:28:12 | ankur-gupta-f4 | as per John Davidge's comments | |
| 19:28:33 | sindhu | okay will do | |
| 19:28:45 | reedip_1 | dtroyer : but is keeping this implementation in common correct ? | |
| 19:29:13 | reedip_1 | I mean that was your query , and I found it right. Wondering what changed your mind :) | |
| 19:30:28 | dtroyer | phase of moon? | |
| 19:30:41 | reedip_1 | wont change till tomorrow :P | |
| 19:30:53 | dtroyer | I don't recall exactly what was the rationaly, but the way I understand it today may be different | |
| 19:31:24 | reedip_1 | so should we take this with a pinch of salt ??? | |
| 19:32:30 | ankur-gupta-f4 | moving on though. I want to bring up these updated functional test stuff coming in | |
| 19:32:47 | dtroyer | am I not allowed to change my mind if my understanding changes? | |
| 19:33:10 | reedip_1 | dtroyer : no you are , for sure :) | |
| 19:33:25 | dtroyer | also, given that a number of other commands have dependencies on knowing if extensions are installed/enabled, this is one area I would support putting into a common network lib (network.v2.common) | |
| 19:33:36 | reedip_1 | and I think keeping it in the network section sounds logical | |
| 19:33:38 | dtroyer | excpet that particular module already has command classes in it | |