| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-05 | |||
| 14:06:40 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Add get_stack_* methods to documentation https://review.openstack.org/453646 | |
| 14:25:25 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Clean up some errant doc warnings/errors https://review.openstack.org/453661 | |
| 14:30:15 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add "qos-policy" option to "port create" & "port set" https://review.openstack.org/419236 | |
| 14:44:25 | reedip | ZZelle_ yes hello | |
| 14:48:00 | openstackgerrit | David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924 | |
| 14:49:13 | reedip | rabel_b1 : hi | |
| 14:49:56 | rabel_b1 | reedip: hi. arg, i just made it worse... :D | |
| 14:50:55 | reedip | rabel_b1 : I saw ZZelle_ 's comments. I agree, lets discuss this in detail here or on the bug . dtroyer 's input would alsio be great here :) | |
| 14:51:08 | reedip | s/bug/patch/ | |
| 14:51:32 | openstackgerrit | David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924 | |
| 14:52:06 | openstackgerrit | Merged openstack/python-openstacksdk master: Add get_stack_* methods to documentation https://review.openstack.org/453646 | |
| 14:53:50 | rabel_b1 | i would prefer not to discuss that in the change. here is fine, launchpad also. but on the change there is already enough, if it's only about the implementation. so i would like to keep the "what to implement?" question separate | |
| 14:55:13 | rabel_b1 | also in the launchpad bug we already started talking about that. | |
| 14:55:38 | ZZelle_ | rabel_b1, reedip, it's a mess to jump between launchpad and review.o.o ... let's discuss in one place | |
| 14:55:49 | reedip | agreed ZZelle_ | |
| 14:56:17 | reedip | but where ?? :) | |
| 14:56:48 | ZZelle_ | reedip, review.o.o :) | |
| 14:57:03 | ZZelle_ | reedip, the code won't go in launchpad :) | |
| 14:57:08 | reedip | rabel_b1 : is that ok with u ?? | |
| 14:57:15 | reedip | ZZelle_ hehe.. yeah | |
| 14:58:19 | rabel_b1 | ZZelle_, reedip: ok, review then. | |
| 14:58:31 | openstackgerrit | Monty Taylor proposed openstack/os-client-config master: Add ability to pass in user_agent https://review.openstack.org/452550 | |
| 14:58:48 | rabel_b1 | but maybe we can also talk about it here first | |
| 14:59:39 | rabel_b1 | since we three are here right now and we can post the outcome as comment on the review? | |
| 15:00:33 | ankur-gupta-f4 | Which patchset are you discussing | |
| 15:00:53 | reedip | ankur-gupta-f4 : I was waiting for you to chime in :) | |
| 15:01:03 | reedip | https://review.openstack.org/444924 | |
| 15:01:38 | ankur-gupta-f4 | Oh yea. Fun | |
| 15:01:51 | reedip | :D | |
| 15:03:12 | reedip | I will be Back ... ( in a jiffy ) | |
| 15:03:16 | ZZelle_ | rabel_b1, reedip, dtroyer, the main point to agree is the format | |
| 15:03:48 | ZZelle_ | rabel_b1, reedip, dtroyer, imo, there is no reason to have 3 options --nic, --network, --port which supports complex values | |
| 15:04:34 | ZZelle_ | rabel_b1, reedip, let's use --network --port for simplex cases: --network $network or --port $port | |
| 15:05:15 | ZZelle_ | rabel_b1, reedip, if you need a finer interface description then use --nic $key=$value,... | |
| 15:07:48 | rabel_b1 | ZZelle_, reedip, ankur-gupta-f4, dtroyer: sounds reasonable to me. i think i first had in mind that --nic could be deprecated in the future in favour of --network and --port. but since those are not going to implement the --nic auto and --nic none functionality either, we will probably stay with having three parameters. | |
| 15:08:19 | reedip | ZZelle_ ok, so you mean with --network and --port we do not need to specify nic | |
| 15:08:21 | rabel_b1 | so, since --nic will not be deprecated, i think you are right, ZZelle_. | |
| 15:08:30 | ZZelle_ | rabel_b1, what means --nic none or --nic auto? | |
| 15:08:54 | reedip | if that is so ZZelle_ , rabel_b1 , we need to be pretty thorough in the Help Message | |
| 15:09:16 | rabel_b1 | ZZelle_: afaiu --nic none means having a nic without a port connected to it and --nic auto means looking for a network that fits it needs. but i'm not sure here. | |
| 15:09:29 | ZZelle_ | reedip, yes, --network $network enables to specify a nic on a specific network, --port port a nic using a specific port and --nic is for other cases | |
| 15:09:40 | ZZelle_ | rabel_b1, ok | |
| 15:10:38 | ankur-gupta-f4 | If --nic will be deprecated then --network and --port need to fulfill all the options that --nic supports | |
| 15:10:42 | ankur-gupta-f4 | Imho | |
| 15:11:05 | rabel_b1 | ankur-gupta-f4: yes, but it very probably won't | |
| 15:11:17 | reedip | rabel_b1 : IIUC currently --nic should have default none if nothing is specified, you might need to handle that with --network and --port as well ( i.e. if no option is specified, treat --nic as none in the body ) | |
| 15:11:31 | reedip | auto option should be with --nic only , not with --network/--port | |
| 15:11:55 | reedip | ankur-gupta-f4 ; it would be difficult to replacte the auto behavior with --network/--port | |
| 15:12:58 | ankur-gupta-f4 | It shouldn't be that complicated if both nic and network options are handled in similar ways | |
| 15:13:07 | rabel_b1 | yes, dtroyer said something similar: none and auto should only be available for --nic, not for --network/--port | |
| 15:14:11 | reedip | ankur-gupta-f4 : it shouldnt be, but ideally it need not be required if we have --nic :) anyways, I think rabel_b1 has reached a satisfying conclusion , thanks to ZZelle_ :) | |
| 15:15:44 | ankur-gupta-f4 | Okay | |
| 15:16:18 | ankur-gupta-f4 | Will review it later. Still seems like it is would be confusing for end user. | |
| 15:16:27 | ankur-gupta-f4 | Lets see how it turnsout | |
| 15:17:11 | rabel_b1 | ankur-gupta-f4, reedip, ZZelle_: so, everyone seems to be fine with that solution. i will implement that in a new patch set. | |
| 15:17:39 | rabel_b1 | reedip: i am not quite sure yet how to do the help message the best way. | |
| 15:18:51 | openstackgerrit | Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025 | |
| 15:19:22 | reedip | rabel_b1 : hmm ... for help message, you can simply mention like what we have mentioned here | |
| 15:19:27 | rabel_b1 | ZZelle_: i use network= instead of net-id= in that place to distinguish between --nic and --network later for the error message. see line 610+ | |
| 15:20:26 | rabel_b1 | ZZelle_: maybe it is better to change the error message to something more generic? | |
| 15:20:26 | ZZelle_ | rabel_b1, i will wait for the next PS as it's not really meaningful to review the current one more | |
| 15:21:20 | rabel_b1 | ok, i will first create a new patch set now, then we can discuss on that. :) | |
| 15:21:24 | sindhu | dtroyer: hi, https://review.openstack.org/#/c/383025/ is ready. Have added a detail commit message | |
| 15:24:05 | dtroyer | I don't mind having multiple ways to do things when they fit particular use cases, I think —port and —network do as long as they are simple options. in PS9 they are nearly aliases to —nic which I do not think adds much here. | |
| 15:28:05 | openstackgerrit | Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025 | |
| 15:28:58 | reedip | dtroyer : missing your opinion on this : ^^ ( I am going to bug you a bit for this , hope you dont mind :) ) | |
| 15:31:11 | dtroyer | reedip: you mean 383025? | |
| 15:31:20 | reedip | dtroyer : YES :) | |
| 15:31:33 | dtroyer | what specifically? | |
| 15:31:46 | reedip | well, its ready .. | |
| 15:32:14 | dtroyer | not quite: https://review.openstack.org/#/c/383025/74/doc/source/command-objects/floating-ip.rst@156 | |
| 15:32:40 | reedip | ohh ... | |
| 15:32:56 | reedip | 3rd April , will look into it.. thanks | |
| 15:33:16 | dtroyer | also, what I was looking for with regard to the SDK is when that dependent review gets released. | |
| 15:33:32 | dtroyer | ie, it's merged, what is the next release expected to be? | |
| 15:33:42 | dtroyer | but that's just a bit of leg owrk to track down | |
| 15:34:53 | reedip | dtroyer: thats what sindhu has mentioned in the commit message and in the file | |
| 15:35:28 | ankur-gupta-f4 | reedip make note in commit saying 0.9.15 SDK release needed | |
| 15:35:40 | dtroyer | it only points to a (now merged) review. it is more helpful to say "is expected to be relased in 0.9.xx", but that's just a bit of research to figure out if that has happened | |
| 15:35:43 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Enable warnings_as_errors in doc enforcer https://review.openstack.org/453676 | |
| 15:36:01 | dtroyer | you don't always know, that's fine | |
| 15:36:08 | reedip | dtroyer : ankur-gupta-f4 : ok... | |
| 15:37:04 | reedip | dtroyer: I think I and sindhu agree that that type of work could be tracked down by us... but yes mentioning a ToDO with the approporate SDK release is imp | |
| 15:37:43 | briancurtin | if you guys need an SDK release, we’re probably close to one. should probably wait on a couple of these load_balancer ones since they’re close to being done and they’re all related | |
| 15:38:31 | sindhu | reedip: for some reason I thought u addressed https://review.openstack.org/#/c/383025/74/doc/source/command-objects/floating-ip.rst@156, are u doing it or shall I do it | |
| 15:39:00 | reedip | sindhu : be my guest if you want to .. I was searching for the patch that merged on 3rd april :) | |
| 15:39:06 | dtroyer | thanks briancurtin. I think there are a couple of things in OSC that go with new/fixed SDK bits. We're cutting a release today or tomorrow for OSC and osc-lib so we're not really blocked on the SDK | |
| 15:40:14 | sindhu | reedip: oh ok | |
| 15:40:25 | dtroyer | sindhu, reedip: actually, it isn't just released, but that version of the SDK needs to be in the minimum in global requirements (requirements.txt) before we can assume it will be present | |
| 15:40:57 | reedip | dtroyer : yeah, thats what is bliocking us and is our requirement ( the SDK needs to be in ou requirements ) | |
| 15:41:52 | sindhu | dtroyer: Oh ok ... but we don't have to be blocked by that now right? | |
| 15:41:58 | ankur-gupta-f4 | briancurtin: for the load balancer ones we are concerned over the functional tests not being run. And we haven't yet been able to verify whether the calls/functionally are working correctly yet. I don't know if you want to wait upon those to release. Else, we can push those all though and deal with fixing them later | |
| 15:42:44 | briancurtin | ankur-gupta-f4: yeah, actually it does look like the functional tests might take a bit so we could be waiting a while. i’ll take a look in about an hour and see if we have anything else necessary to get a release out | |
| 15:44:08 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstacksdk master: [WIP] Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488 | |
| 15:44:30 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488 | |
| 15:44:31 | ankur-gupta-f4 | that seems best. I would prefer to hold off on merging the LBs till I/we can verify its working as expected locally before merging. | |
| 15:44:54 | dtroyer | sindhu: if an OSC review requires an SDK review to be present to work, yes, you must either handle both cases (with and without the SDK review present) or you must wait until the SDK release that includes that dependent review is in global-requirements. | |
| 15:45:10 | reedip | ankur-gupta-f4 : feel free to let me know if something needs to be done for octaviaclient | |
| 15:45:32 | ankur-gupta-f4 | yea review the initial. Figure out how to deal with that function that just "pass"es | |
| 15:45:59 | reedip | link ? | |