Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-02-16
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
19:33:44 reedip_1 ok
19:33:50 dtroyer err, network.common
19:33:59 dtroyer similar to what is in identity.common
19:34:25 dtroyer I'm talking about the actual access methods (calling REST) not the command classes
19:34:41 dtroyer so another command can easily check if an extension is enabled and act appropriately
19:35:34 dtroyer that doesn't need to be done immediately, but I wanted to mention it as an example of places I do think factoring out stuff is beneficial since I rant against that so much in the command classes
19:37:19 ankur-gupta-f4 makes sense.

Earlier   Later