Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-01-24
20:35:51 dims stevemar : ^
20:36:01 dims briancurtin : i know you filed it :)
20:36:19 dims briancurtin : freeze starts thu (email just hit -dev)
20:40:18 briancurtin dims: is my response to Matthew Thode on that review sufficient to answer your question?
20:43:52 openstackgerrit Justin A Wilson proposed openstack/python-openstackclient: Add support for Cinder API 3.3 into OSC https://review.openstack.org/421585
20:50:03 dims y that helped briancurtin
20:58:51 briancurtin dims: thanks a lot!
22:07:59 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433
23:11:46 stevemar dtroyer: heads up for https://review.openstack.org/#/c/418190/ and https://review.openstack.org/#/c/424847/
23:12:51 dtroyer stevemar: I've got one coming too… standby one
23:31:05 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433
23:32:11 stevemar dtroyer: you may want to join -nova and talk to mriedem and andreyk about it
23:32:24 dtroyer stevemar: so do we need to get that novaclient review merged still? or do we need to work around that problem yet? I thought it was fixed?
23:32:34 stevemar dtroyer: currently the sdk requirements bump will break them
23:32:43 stevemar dtroyer: i have no effing clue and i'm too tired to think :)
23:32:58 dtroyer sure, because someone still hasn't fixed the real issue, which I'm not sure I know anymore what it is
23:33:21 stevemar all i know is i want the minimum sdk bumped, and nova is stopping us
23:33:25 stevemar i have no idea why
23:39:45 briancurtin how could that even occur?
23:42:35 dtroyer novaclient functional tests broke with 0.9.11, from something in the network refactor, we've apparenty still not got it fixed
23:43:24 dtroyer I don't know where the root bug is, I thought we'd worked around it in OSC, apparently not
23:45:54 openstackgerrit Dean Troyer proposed openstack/python-openstackclient: Add server test for image and flavor lookups https://review.openstack.org/424901
#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 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: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: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

Earlier   Later