Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-03-21
08:09:07 reedip RuiChen : new patch , just for you :) ^^
08:12:27 openstackgerrit Reedip proposed openstack/python-openstackclient master: TrivialFix : Introduce FindFloatingIP() without ip_Cache https://review.openstack.org/447938
08:15:37 openstackgerrit Reedip proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
08:26:10 openstackgerrit wangzhenyu proposed openstack/python-openstackclient master: Remove log translations https://review.openstack.org/447838
08:29:28 openstackgerrit Merged openstack/python-openstackclient master: Fix Trivial Changes in [1] https://review.openstack.org/447764
09:23:27 openstackgerrit yfzhao proposed openstack/python-openstackclient master: Remove log translations https://review.openstack.org/447888
10:08:16 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: Don't duplicate commands https://review.openstack.org/447592
13:39:31 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Add designateclient to constructors list https://review.openstack.org/448100
14:19:36 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
14:21:17 sindhu reedip: hey, u pinged yday?
14:21:48 reedip sindhu : I dont remember ...
14:22:00 reedip too many things were happening
14:22:06 reedip OSC, neutron etc etc etc :F
14:22:07 reedip :D
14:22:18 sindhu lol :D
14:43:51 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: OSC Extension Show https://review.openstack.org/382023
14:46:28 reedip sindhu : why is the Blueprint named extension-show ?? when it tackles almost everything for extension ^^
14:46:33 openstackgerrit Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907
14:50:25 sindhu reedip: It handles only show
14:50:49 sindhu reedip: everything?
14:50:51 reedip aah.... 2 meetings and code review dont work well !
14:50:58 reedip I thought it handled list as well
14:51:25 sindhu reedip: :)
15:19:11 openstackgerrit Merged openstack/python-openstacksdk master: Avoid imports in openstack/__init__.py https://review.openstack.org/446823
15:19:27 openstackgerrit Merged openstack/python-openstacksdk master: Expose ha_state property from HA enabled L3 Agents. https://review.openstack.org/447050
15:23:43 openstackgerrit Merged openstack/python-openstacksdk master: Add StackFiles resource to orchestration v1 https://review.openstack.org/446904
17:20:48 openstackgerrit Merged openstack/python-openstackclient master: Support to add/remove multi users for "group add/remove user" https://review.openstack.org/446848
17:30:04 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
21:00:02 sindhu dtroyer: stevemar : https://review.openstack.org/#/c/382023/ is ready for review :)
23:47:02 openstackgerrit Merged openstack/osc-lib master: Fix find_resource exception handling on numeric names with kwargs https://review.openstack.org/445679
23:53:51 openstackgerrit Merged openstack/osc-lib master: Updated from global requirements https://review.openstack.org/440084
23:56:50 reedip stevemar , sindhu : u there
23:57:09 reedip ankur-gupta-f4 : u too
#openstack-sdks - 2017-03-22
00:00:48 reedip stevemar, sindhu, ankur-gupta-f4 , RuiChen : need ur reviews on https://review.openstack.org/#/c/447938/2
00:01:57 ankur-gupta-f4 reedip: I agree with Sindhu adding that patchset within the FIP/port patch
00:02:12 reedip I brought it out of the Floating IP associate/disassociate patch bcz the change here is not related with that patch
00:02:39 reedip Its a separate piece of code which would also impact other locations where the code is used.
00:02:57 ankur-gupta-f4 okay makes sense
00:03:04 reedip If it would have been directly related to the floating ip associate/disassociate, I would have been the first one to put it there :)
00:07:41 sindhu reedip: hey, I still feel it can be added in the fip patch, then there is no need of any dependency and even fip patch can get merged soon rather than wait for this one. anyway this method is currently not being used anywhere else in the code
00:08:15 reedip sindhu : no not the new method, but there is a good amount of code which uses ip_cache but ignores it
00:08:32 reedip sindhu : like show floating ip, delete floating ip etc
00:08:53 reedip sindhu : the code you are working on is dependent on this change but this change also spawns other code changes
00:09:06 reedip sindhu :thats why I avoided mixing the 2
00:09:50 reedip the old method has some issues, and if you do a find, you will see that there are code sections which use the old function, get the ip_Cache, but then do not use it
00:10:45 sindhu reedip: are u planning to make changes to show and delete in the same patch?
00:11:52 reedip sindhu : I think I can do it in this patch or in a follow up patch . I wanted to get this patch on road so that the floating IP patch can move forward. But if you think its corret then I can make the changes in Show and Delete as well
00:12:50 reedip thats not a big issue, I guess. The point which dtroyer and stevemar had was that this function was not actually pretty good, but it can still be used where ip_cache is actually required
00:13:32 reedip therefore I spun up a new function so that old code isnt hampered, the ip_Cache function still exists and we can just move on
00:13:43 sindhu reedip: I feel, it makes sense to have a new patch only if ur changing the rest of the code base (show and delete). it its just defining the new method, then might as well do it in the fip patch so it gets merged together
00:14:19 reedip sindhu : okay, got your point. Wait, lemme spin the new version
00:15:33 sindhu reedip: gtg. will look at it again tom
00:15:44 reedip Okay ... have a great day :)
00:17:03 openstackgerrit Reedip proposed openstack/python-openstackclient master: TrivialFix : Introduce FindFloatingIP() without ip_Cache https://review.openstack.org/447938
00:17:10 reedip sindhu : jfyi , done :P
01:22:47 openstackgerrit Merged openstack/os-client-config master: Add support for bailing on invalid service versions https://review.openstack.org/439119
02:28:07 openstackgerrit qtlu proposed openstack/osc-lib master: Using assertIsNone() instead of assertEqual(None) https://review.openstack.org/448346
03:52:53 openstackgerrit Reedip proposed openstack/python-openstackclient master: TrivialFix : Introduce FindFloatingIP() without ip_Cache https://review.openstack.org/447938
05:55:54 reedip o/
10:07:38 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce FindFloatingIP() without ip_Cache https://review.openstack.org/447938
12:32:17 reedip__ o/
13:24:02 cdent elmiko, edleafe: some work in progress we might be able to halt sooner than later: https://bugs.launchpad.net/openstack-api-wg/+bug/1674192
13:24:02 openstack Launchpad bug 1674192 in openstack-api-wg "Mention max length limit of tags in api-wg" [Undecided,New]
13:52:57 elmiko cdent: added a comment agreeing with you and Sergey on the review
13:53:17 cdent thans elmiko
13:58:16 elmiko i'm curious though, why 60 char limit. why not 255?
14:00:58 cdent elmiko: 60 is what nova is using, so I think it was just a matter of codifying what's there
14:07:07 edleafe cdent: elmiko: added my two cents
14:07:37 edleafe I think it was my discussion with lbragstad that started this ball rolling
14:08:57 lbragstad edleafe cdent elmiko interesting - we actually just talked about that in yesterday's keystone meeting http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-03-21-18.00.log.html#l-228
14:09:59 lbragstad the overall reaction of the group was to be strict about validation individual tags - http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-03-21-18.00.log.html#l-249
14:10:09 lbragstad but we'd greatly appreciate any guidance on that
14:11:13 cdent I think there's been plenty of guidance already on the form of the tags (in the docs that's being changed) but not on length
14:11:28 cdent as in "make sure they are URL safe"
14:12:06 lbragstad fwiw - most of the discussion consisted of what policy we should use to enforce tags (which we kind of tabled and agreed to document for now), but the bits specific to "should we validate individual tags" is interesting
14:12:51 lbragstad the policy/rbac usecase we discussed in the meeting is related to other policy problems we have and isn't specific to tags
14:35:19 dstanek i added my 2 cents to that
14:35:29 dstanek yes, you are correct about the channel
14:35:54 dstanek lbragstad: lol....and i magically switched channels!
14:41:30 reedip stevemar, ankur-gupta-f4, sindhu, RuiChen : https://review.openstack.org/#/c/447938/
16:39:24 openstackgerrit Steve Martinelli proposed openstack/python-openstackclient master: OSC Extension Show https://review.openstack.org/382023
16:43:05 openstackgerrit Merged openstack/osc-lib master: Using assertIsNone() instead of assertEqual(None) https://review.openstack.org/448346
16:48:05 openstackgerrit Ed Leafe proposed openstack/api-wg master: Define pagination guidelines https://review.openstack.org/446716
16:53:36 openstackgerrit Ankur proposed openstack/python-openstackclient master: [WIP] Add support for Octavia Plugin https://review.openstack.org/447068
16:57:15 openstackgerrit Chris Dent proposed openstack/api-wg master: Create a new set of api stability guidelines https://review.openstack.org/421846
16:57:44 cdent edleafe, elmiko, anyone else: new version ^. I hope we're nearly done.
16:58:23 elmiko cdent: ack, added to the queue
17:09:04 edleafe cdent: yeah, saw that as I was commenting on the previous version :)
17:09:25 cdent *more tiny fist shaking*
18:14:30 openstackgerrit Ankur proposed openstack/python-openstackclient master: Network L3 Router Commands for OSC https://review.openstack.org/385729
18:15:24 cdent sdague, elmiko: I agree with you guys that the alternatives secion is a bit sparse, but it is in there to effectively say "yeah, we heard you, but it's not good enough for the needs delineated here"
18:15:40 cdent I'm happy to remove it though, if that's the consensus
18:24:02 elmiko lol
18:24:28 elmiko cdent: can we add a DONT DO THIS! to that section ;)
18:25:03 cdent elmiko: is the last paragraph to circumspect in that regard?
18:25:05 cdent too
18:58:23 elmiko cdent: i think so
18:58:28 elmiko it leaves too much wiggle room
18:59:18 cdent elmiko: have you read the followups from graham and chris? I'm probably gonna let it stew until tomorrow morning as I've lost steam in that direction
19:06:59 elmiko cdent: i'll look again, last reply i saw was from Sean

Earlier   Later