Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-02-28
15:45:18 reedip sindhu : ok ...
15:45:39 reedip floatin_ip doesnt have a name , so I guess we are searching based on IP or ID
15:46:22 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Reorganize workflow docs https://review.openstack.org/439028
15:46:55 sindhu reedip: https://github.com/openstack/python-openstacksdk/blob/master/openstack/network/v2/_proxy.py#L513, but the find_floating_ip defined in the openstackclient/network/v2/floating_ip is capable of doing the search based on IP as well. If I understand correctly
15:47:57 reedip sindhu : the _proxy file does the job smoothly on the SDK side
15:54:21 sindhu reedip: let me know if u think there is something wrong
15:54:47 reedip sindhu : I will, in some time though
15:54:57 sindhu reedip: sure
15:55:03 reedip if there is something wrong . but I doubt there is something
16:15:47 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
16:21:47 dtroyer briancurtin: got a question on how SDK handles resource attribute updates. Specifically I am looking at port security_groups, and find that adding one fails in this case: a) port has at least one existing security group; b) add a new security group ID at the end of the list of existing groups. No PUT is executed. If I add the new ID to the beginning of the list the PUT is sent.
16:22:08 dtroyer I've started looking for where this update detection happens in SDK and have not traced it down yet...
16:23:02 reedip dtroyer : really ????
16:23:35 reedip dtroyer : so you are appending the data ?
16:23:53 dtroyer yes, appending new ID to the list fo exsting IDs
16:25:18 reedip dtroyer : ohk, lemme try the same ...
16:28:08 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Simplify logic around option lists in port set https://review.openstack.org/439048
16:28:44 dtroyer reedip: ^^^^ is what I am doing.
16:28:54 briancurtin dtroyer: looking
16:29:01 reedip dtroyer: yeah saw that and reviewing the same
16:29:06 dtroyer we've gotten a bit complicated in option handling and its hard to follow
16:30:23 briancurtin dtroyer: ah, i’ll have to look up my special methods again, but i bet it’s that we’re not catching the += in setting the dirty. we currently set it based on __setitem__
16:30:47 dtroyer ah, ok. .append() then maybe?
16:32:41 briancurtin what you’re doing should work (fixing and releasing that in a coordinated way is another matter)—what should work no matter what would be to get the value, do the append (or even a += to a local value), and then do the fixed_ips=my_new_thing instead of doing it in-place
16:33:37 reedip dtroyer : Line #740 in https://review.openstack.org/#/c/439048/1/openstackclient/network/v2/port.py
16:33:50 dtroyer ok, that may be cleaner anyway too. I'm re-doing this because I couldn't follow the logic without a lot of caffiene… :)
16:33:54 briancurtin i think that’s what we’re missing. the value itself is being appended to fine, but it’s not flagging the dirty setting because the in-place operation (i think, looking up something right now)
16:34:26 dtroyer I think that is what I see too briancurtin, I finally found _ComponentManager :)
16:39:15 reedip dtroyer : One thing I cannot understand is why the attrs object is not able to update the info on the neutron server side
16:40:25 dtroyer reedip: SDK Resource tracks attributes that have been changed (dirty) and only sends back the ones actually changed for update(). Setting the dirty flag is not happening in some cases
16:42:42 reedip dtroyer : I remember having this discussion with stevemar , I guess
16:43:20 reedip but cant see why the dirty flag isnt set ( being the original writer of this patch, I would need the feedback for future reference :) )
16:46:03 dtroyer reedip: briancurtin thought it might be because using += modifies the attribute in place and doens't pass through __setitem__(), which is where the dirty flag is set.
16:46:16 dtroyer Without tracing it I think I agree
16:47:02 reedip dtroyer : so , we shouldnt use += in Set attributes ( sounds like a doc update :P )
16:47:08 reedip ??
16:47:08 dtroyer I'm trying to make the handling of these arguments clearer, it took me a while to understand what was happening before
16:47:20 dtroyer maybe not in this case, no
16:47:35 reedip dtroyer : so this is a case by case basis ?
16:47:44 dtroyer at least when operating on an attribute obtained from an SDK object
16:48:20 dtroyer I think that is the distinction; if we used a copy of an object attribute it might have worked
16:53:39 reedip dtroyer : ok ...
16:54:50 dtroyer hmmmm, of the 3 options pairs I am looking at, security groups was the only one to not iterate over the existing list
16:57:34 reedip the only difference which I found was that we are using the client.find_xxx function for SG
16:57:58 reedip dtroyer: for fixed-ip and allowed-address-pair , we didnt execute the find function
16:58:21 reedip can that be of some impact , dtroyer ?
16:58:24 dtroyer I don' tthink that is involved, that is looping over the 'new' values
16:59:46 dtroyer actually, I think using [].extend() rather than += will be enough of a change
16:59:51 reedip dtroyer : ok, because += was used with fixed-ips as well, and if it was updated successfully, then maybe something else is wrong
17:00:18 dtroyer fixed_ips never directly re-used the list from the resource object, it iterated over it
17:00:29 reedip dtroyer : ok
17:00:30 dtroyer that forced __setitem__() to be called
17:00:38 reedip yeah , makes sense
17:01:03 dtroyer so I think we'll do both, it seems clearer to me
17:03:32 reedip dtroyer : ok :)
17:03:56 reedip sindhu :still causes an issue . Did you run tox -v -e functional openstackclient.tests.functional.network.v2.test_floating_ip.FloatingIpTests.test_floating_ip_set_and_unset_port
17:04:08 reedip sindhu : can you tell me the output of ^^ ?
17:17:16 sindhu reedip: y, what's wrong?
17:18:27 reedip sindhu : I am still getting a failure, thats why asking you if it is passing in your system
17:19:37 reedip sindhu : can u just run and check if it giving a positive result in your setup ?
17:21:41 sindhu reedip: something is wrong with my local it fails in the setup itself. Let me get a new env n check again. Thanks for looking :)
17:22:05 sindhu reedip: what error are u getting?
17:22:08 reedip sindhu : NP , I am just trying to close the NeutronClient CLI migration for now :)
17:22:58 sindhu reedip: I m not sure if cleanup is working the way it should
17:23:42 reedip sindhu : It isnt , I brought the router delete line to Line #234
17:28:52 sindhu reedip: and it is working now?
17:29:14 reedip No, a different error is occurring, thats what I a trying to resolve
17:29:27 sindhu reedip: what's that ?
17:29:53 reedip unicode is not callable, str is not callable :)
17:30:03 reedip I have been trying to fix this since this evening :)
17:30:10 reedip my brain is not working with me !
17:30:16 sindhu yup, that's the same failure even in gate
17:30:56 wklm hey guys, i'm having troubles installing python sdk on centos. I'm getting the following error: Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-gyuzq2sj/cliff/ How can I deal with that?
17:31:06 sindhu reedip: Ohhhh I think I got it !!!!!
17:31:21 briancurtin wklm: how are you installing it?
17:31:35 reedip sindhu : whats that ?
17:32:05 sindhu reedip: so in all the cleanup, I have missed self.openstack
17:32:13 sindhu reedip: will fix it now
17:32:25 reedip sindhu : thats not necessary , is it?
17:32:26 wklm briancurtin: simply: pip install python-openstackclient
17:32:35 wklm being root
17:33:23 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
17:33:48 sindhu reedip: it is, I have updated
17:33:58 reedip sindhu : testing the same
17:34:03 reedip I have made some other changes as well
17:34:05 sindhu reedip: can u check now with the latest patch
17:34:23 reedip sindhu : sure, gimme a minute. My changes are just running right now
17:34:31 sindhu reedip: sure
17:34:32 briancurtin wklm: someone else will have to take a look, i thought you were installing the sdk
17:35:09 wklm briancurtin: is there a more proper channel for it, or am i right here? :)
17:35:16 briancurtin fine here
17:35:26 briancurtin i just don’t know about that
17:39:04 reedip sindhu : my patch failed :P Now trying yours
17:39:23 wklm here more specific error stack trace:
17:39:24 wklm Traceback (most recent call last): File "/tmp/pip-build-mgg6jby7/cliff/.eggs/pbr-1.10.0-py3.4.egg/pbr/core.py", line 111, in pbr attrs = util.cfg_to_args(path, dist.script_args) File "/tmp/pip-build-mgg6jby7/cliff/.eggs/pbr-1.10.0-py3.4.egg/pbr/util.py", line 248, in cfg_to_args kwargs = setup_cfg_to_setup_kwargs(config, script_args) File "/tmp/pip-build-mgg6jby7/cliff/.eggs/pbr-1.10.0-py3.4.
17:39:30 sindhu reedip: ok, thanks :)
17:45:20 reedip sindhu : okay , your patch also didnt work on my system
17:45:25 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Reorganize network docs https://review.openstack.org/439074
17:45:40 sindhu reedip: Ah really?? what does it say now?
17:46:05 reedip Just a min

Earlier   Later