Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-01-25
00:12:36 openstackgerrit Merged openstack/python-openstackclient: Use image client for images instead of compute https://review.openstack.org/424688
00:55:55 openstackgerrit OpenStack Proposal Bot proposed openstack/python-openstackclient: Updated from global requirements https://review.openstack.org/423277
02:34:31 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: Add server test for image and flavor lookups https://review.openstack.org/424901
03:57:35 openstackgerrit Merged openstack/python-openstacksdk: Remove discover from test-requirements https://review.openstack.org/416118
04:01:55 reedip amotoki : ping
04:03:33 amotoki reedip: pong
04:03:38 reedip stevemar : everything fine , or is there a fire with the release of 0.9.13
04:03:53 reedip amotoki: I had a question regarding your comment in https://review.openstack.org/#/c/356263/
04:04:04 stevemar reedip: getting it fixed :)
04:04:11 reedip >> The possible way is to change --dhcp-options to take two parameters (nargs=2): --dhcp-option <opt-name> <opt-value>.
04:04:19 reedip stevemar : lemme know if I can help
04:05:14 amotoki reedip: ?
04:05:45 reedip amotoki : I am not sure about how you wanted the dhcp options to be handled
04:06:08 reedip amotoki : you stated --dhcp options can take 2 parameters (nargs = 2 )
04:06:55 amotoki reedip: in the case of dhcp option, a value can vary and it can contain even a comma.
04:07:06 reedip amotoki : ok
04:07:52 reedip amotoki : so the value needs to be handled specially
04:08:00 amotoki reedip: parsing strdict now depends on a comma, and the current value format forces a special parsing.
04:08:06 reedip i mean the value parameter of dhcp-options
04:08:28 amotoki reedip: if the option takes two parameters (name and value), such parsing is no longer needed.
04:09:00 amotoki reedip: yes. the format of the value of dhcp-option is NOW opt_name=XXX,opt_value=YYY
04:09:10 amotoki reedip: this format needs parsing.
04:09:34 amotoki reedip: if we have two option, parsing is no longer needed. does it make sense?
04:10:25 reedip amotoki : oh , so that means --dhcp-options can have [name] , [opt-name,opt-value], [ip-version]
04:10:30 reedip amotoki : is that correct?
04:11:12 amotoki reedip: ah... I totally forget ip-version....
04:12:10 amotoki reedip: if we always have two parameters, it can be simple, but ip-version is optional, so it would be complicated.
04:12:16 reedip amotoki : then is it opt_name,opt_value,ip_version ?
04:12:19 amotoki reedip: my idea does not seem to work
04:12:43 amotoki reedip: yeah. that looks better
04:12:54 amotoki that means 'opt_name,opt_value,ip_version'
04:13:27 reedip amotoki : yes, but the classless route would have a comma separated value in the opt_value
04:13:47 reedip amotoki : so we cannot use the default strdict option, and need to create one for ourselves
04:14:05 amotoki reedip: yes. so we need more handling for a value with comma(s)
04:14:14 reedip amotoki : okay, got it
04:14:26 reedip let me work on it, thanks a lot for your time :)
04:14:40 amotoki reedip: np.
04:14:52 amotoki reedip: did you see neutronclient patch which tackles this problem?
04:15:56 reedip amotoki : not completely. But I need to relook at it because I think the changes would be applicable for the Library level of NeutronClient
04:17:28 amotoki reedip: the proposed code in neutronclient is not beautiful but works.
04:17:48 reedip amotoki : :) I guess you stated it correctly
04:17:54 amotoki reedip: one more thing.
04:18:06 reedip amotoki : yes
04:18:16 amotoki reedip: in https://review.openstack.org/#/c/356263/, you changes the original author in the commit message.
04:18:41 amotoki reedip: if there is no special reason like you wrote it from scratch, the original author should be kept.
04:19:01 amotoki and you can add youself as Co-Authored-By.
04:19:35 reedip amotoki : understood, will do that . I wanted to release the patch so did not see the commit message changed
04:20:14 amotoki reedip: you can check more details of commit messages by 'git show --format=fuller'
04:20:36 reedip amotoki : ok, will try with this command :)
04:26:49 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433
04:55:06 reedip amotoki : ping, one query
04:55:27 amotoki reedip: hey
04:56:18 reedip amotoki : just asking , is it necessary to have the separator for classless route as ',' or can we use ';'? Example : value="169.254.169.254/32;40.40.40.5"
04:56:37 reedip amotoki : just a query
05:02:04 amotoki reedip: not sure
05:03:24 reedip amotoki : hmm, maybe I would ask it once ,but anyways, let me fix the current issue. Actually , we can use ";" as a separator, but needs to be confirmed with openstackclient members
05:04:14 reedip RuiChen, dtroyer, stevemar, ankur-gupta-f1 : suggestions requested to use ";" as a separator in https://review.openstack.org/#/c/356263/
05:04:34 reedip in the value of dhcp-options
05:05:27 amotoki reedip: The specified value is passed down to neutron underlying dhcp server (like dnsmasq) and I think a string with comma like 169.254.169.254/32,20.20.20.1 is what we actually set.
05:05:51 amotoki reedip: so the bug author of https://bugs.launchpad.net/python-neutronclient/+bug/1605421 just wants to pass it as opt-value.
05:05:51 openstack Launchpad bug 1605421 in python-neutronclient "Unable to add classless-static-route in extra_dhcp_opt extension" [Medium,In progress] - Assigned to Shih-Hao Li (shihli)
05:06:00 amotoki reedip: it depends on a situation.
05:06:02 reedip amotoki : we can change it later after parsing
05:06:28 amotoki reedip: but it depends on a situation and IMHO OSC should not assume such backend behavior
05:06:50 amotoki reedip: some other use cases may want to use a semi-colon.
05:06:53 reedip amotoki : hmm
05:08:20 reedip amotoki: okay, makes sense . The RFC which handles classless static routes doesnt state any descriptor to separate the routes, that depends on the implementation. Neutron has implemeneted it in a specific way. OSC can handle it, but yes there may be a use case for ;
05:08:31 amotoki reedip: what we need to address is to allow users to pass (opt_name = classless-static-route, opt_value = 169.254.169.254/32,20.20.20.1)
05:08:53 amotoki reedip: what kind of formatting is used is up to OSC side.
05:09:41 amotoki double-quote escaping is okay. special parsing for comma is okay. it is up to OSC.
05:11:16 reedip amotoki : ok, lets see what others have to say. I will however go forward the fix for MultiKeyValue pair for now.
05:11:34 reedip amotoki: thanks for your help :)
05:28:12 openstackgerrit Merged openstack/python-openstackclient: Updated from global requirements https://review.openstack.org/423277
06:24:05 openstackgerrit Reedip proposed openstack/python-openstackclient: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
06:25:30 openstackgerrit Reedip proposed openstack/python-openstackclient: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
06:57:57 openstackgerrit Reedip proposed openstack/python-openstackclient: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
06:58:41 openstackgerrit Rui Chen proposed openstack/python-openstackclient: Rework port functional tests on json output format https://review.openstack.org/423970
07:00:27 openstackgerrit Reedip proposed openstack/python-openstackclient: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
07:22:58 openstackgerrit harishchandra proposed openstack/python-openstackclient: Correctly format the empty fields of "openstack network show" o/p. https://review.openstack.org/424733
07:53:58 openstackgerrit harishchandra proposed openstack/python-openstackclient: Correctly format the empty fields of "openstack network show" o/p. https://review.openstack.org/424733
08:59:19 reedip RuiChen : have a great vacation :)
09:11:40 openstackgerrit Reedip proposed openstack/python-openstackclient: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
10:01:59 openstackgerrit harishchandra proposed openstack/python-openstackclient: Correctly format the empty fields of "openstack network show" o/p. https://review.openstack.org/424733
10:12:17 openstackgerrit harishchandra proposed openstack/python-openstackclient: Correctly format the empty fields of "openstack network show" o/p. https://review.openstack.org/424733
10:18:40 openstackgerrit harishchandra proposed openstack/python-openstackclient: Correctly format the empty fields of "openstack network show" o/p. https://review.openstack.org/424733
12:13:33 stevemar dtroyer: looks like we're short rui and huanxuan -- chinese new year :)
12:37:06 dtroyer stevemar: timing!
12:38:34 stevemar :)
12:45:36 reedip_ :)
12:45:52 reedip_ Yeah, RuiChen seemed pretty happy in the afternoon
12:53:28 stevemar reedip_: its been a busy week, i don't blame him :P
12:53:38 stevemar reedip_: i'll be very happy in about 48 hours
12:53:49 reedip_ heheheh :)
12:56:12 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433
13:55:10 Cagelin ping
13:56:28 Cagelin Can anyone shine some light on the availability of OpenAPI spec files for (at least) keystone and maybe nova, glance and neutron? I'm wondering if there's an ETA available for when we could use this to generate client API's to use in our company.
13:56:53 Cagelin (I just stumbled across this: https://www.openstack.org/videos/video/openapi-as-a-standard-a-new-way-forward-for-api-documentation-design-and-tool)
13:58:51 openstackgerrit Merged openstack/js-openstack-lib: Add flavorList to Openstack wrapper https://review.openstack.org/406612
15:39:17 dtroyer stevemar: https://review.openstack.org/#/c/424847/ should be ready to go now, andrey has removed his -1 and novalcient seems to be good
15:56:32 dtroyer stevemar: also, do you want https://review.openstack.org/#/c/424433/ for stable?

Earlier   Later