| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-02-16 | |||
| 01:50:30 | ankur-gupta-f4 | Or it should if functional hits bug, which if its a complete functional test it should hit | |
| 01:53:11 | RuiChen | the current functional test don't cover the port set/unset --secuerty-group logic, so it don't catch the bug | |
| 01:54:04 | RuiChen | the related cases should be added in your patch, it's good, I just want to avoid the merge conflict | |
| 01:54:30 | ankur-gupta-f4 | Okay. Fair enough | |
| 01:54:42 | ankur-gupta-f4 | Im good with whichever decision you make | |
| 01:54:55 | ankur-gupta-f4 | As long as it gets done im happy :) | |
| 01:56:50 | RuiChen | thank you :) | |
| 02:55:01 | openstackgerrit | Merged openstack/python-openstacksdk master: Reorganize image docs https://review.openstack.org/434539 | |
| 02:56:27 | openstackgerrit | Merged openstack/python-openstacksdk master: Reorganize compute docs https://review.openstack.org/434475 | |
| 02:56:32 | openstackgerrit | Merged openstack/python-openstacksdk master: Reorganize database docs https://review.openstack.org/434500 | |
| 02:58:07 | openstackgerrit | Merged openstack/python-openstacksdk master: Reorganize bare_metal docs https://review.openstack.org/434460 | |
| 02:58:13 | openstackgerrit | Merged openstack/python-openstacksdk master: Privatize session instance on Proxy subclasses https://review.openstack.org/434457 | |
| 03:05:10 | openstackgerrit | Merged openstack/python-openstacksdk master: Remove unnecessary coding format in the head of files https://review.openstack.org/416500 | |
| 03:15:22 | openstackgerrit | jiahui.qiang proposed openstack/python-openstackclient master: Fix can not set is_default in network https://review.openstack.org/434602 | |
| 04:07:25 | RuiChen | anyone face the issue ? I have no idea about it | |
| 04:07:33 | RuiChen | ft1.1: openstackclient.tests.functional.compute.v2.test_server.ServerTests.test_server_attach_detach_floating_ip_StringException: Traceback (most recent call last): | |
| 04:07:33 | RuiChen | File "openstackclient/tests/functional/compute/v2/test_server.py", line 94, in setUp | |
| 04:07:33 | RuiChen | self.server_create(self.NAME) | |
| 04:07:33 | RuiChen | File "openstackclient/tests/functional/compute/v2/test_server.py", line 68, in server_create | |
| 04:07:33 | RuiChen | name + opts) | |
| 04:07:34 | RuiChen | TypeError: coercing to Unicode: need string or buffer, NoneType found | |
| 04:08:23 | RuiChen | in functional tests, block current jenkin jobs gate-osc-dsvm-functional-ubuntu-xenial | |
| 04:21:51 | sindhu | RuiChen: https://review.openstack.org/#/c/383025/ | |
| 04:22:15 | sindhu | RuiChen: yes, even I m getting the same error | |
| 04:50:25 | reedip | o/ | |
| 05:42:18 | openstackgerrit | zhiyong.dai proposed openstack/python-openstackclient master: Fix the output of quota show https://review.openstack.org/431366 | |
| 05:43:56 | openstackgerrit | zhiyong.dai proposed openstack/python-openstackclient master: Support --no-property in "volume set" command https://review.openstack.org/434094 | |
| 05:52:49 | openstackgerrit | jiahui.qiang proposed openstack/python-openstackclient master: Fix can not set is_default in network https://review.openstack.org/434602 | |
| 06:00:30 | openstackgerrit | jiahui.qiang proposed openstack/python-openstackclient master: Fix can not set is_default in network https://review.openstack.org/434602 | |
| 06:13:37 | RuiChen | sindhu, reedip looks like all patch are blocked by the issue, so we have some workaround tips? | |
| 06:25:47 | reedip | which issue ? | |
| 06:26:17 | reedip | RuiChen : nm | |
| 06:27:32 | reedip | RuiChen, restacking devstack, will look into it as soon as it is up. | |
| 06:29:52 | reedip | RuiChen : https://review.openstack.org/#/c/432993/ ?? | |
| 06:32:04 | RuiChen | reedip: yes, I found the current osc patches face the same issue in job gate-osc-dsvm-functional-ubuntu-xenial | |
| 06:32:17 | RuiChen | TypeError: coercing to Unicode: need string or buffer, NoneType found | |
| 06:32:40 | RuiChen | raise TypeError in setup() of functional tests | |
| 06:33:35 | RuiChen | the same cases pass in my local devstack env | |
| 09:28:26 | openstackgerrit | Huanxuan Ao proposed openstack/osc-lib master: Avoid 'NoneType' error when format conversion https://review.openstack.org/434768 | |
| 10:33:39 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add new parameter "is_default" to Network QoS policy. https://review.openstack.org/432260 | |
| 11:18:49 | openstackgerrit | Huanxuan Ao proposed openstack/python-openstackclient master: Gate broken test https://review.openstack.org/434818 | |
| 13:06:14 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Reorganize identity docs https://review.openstack.org/434534 | |
| 14:35:36 | cdent | mordred: thanks for adding your words to the api stability guideline thing. I think we'll get there in the end, but if nothing else it has done a good job of showing what I thought: that there isn't yet a solid consensus. So all in all a good exercise I guess. | |
| 14:35:49 | mordred | cdent: ++ | |
| 14:36:38 | cdent | I was hoping to write a new version today, but I don't think we're there yet | |
| 14:36:56 | mordred | cdent: if I had a billion dollars, I'd buy a large billboard in the bay area and put on it "using semver is not an excuse to break your users" | |
| 14:37:34 | mordred | of course, if I actually had a billion dollars, Id likely stop caring about semver really quickly | |
| 14:37:40 | cdent | I would hope so | |
| 14:38:07 | cdent | I tried to address that concept at the top a bit where I say that if you do use versioning it shouldn't mean that you're removing the old version. | |
| 14:38:10 | dtroyer | mordred: you might be able to pay me to care as your proxy though... | |
| 14:38:14 | cdent | But that's in the "should" side. | |
| 14:39:30 | cdent | yup. dtroyer you're input is eagerly awaited here: https://review.openstack.org/#/c/421846/ | |
| 14:39:42 | cdent | oh for heaven's sake | |
| 14:39:43 | cdent | your | |
| 14:50:23 | sdague | cdent: that's looking quite good, it would be nice to move that into merge state | |
| 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 | cdent | I think steve isn't fully on board with everything yet, for example | |
| 14:52:14 | sdague | ok, what do you see as the major disagreements? | |
| 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 | |