LIBCLOUD-470: Add VPC Elastic IP Support#208
Conversation
There was a problem hiding this comment.
Please add a docstring which describes what only_allocated and all_properties arguments do.
…e passed in Added docstring for to_addresses method Only include the domain parameter if it equals vpc
|
I went ahead and added the raise condition into ex_associate_address_with_node so it gets thrown should the user use that method or the deprecated ex_associate_address method. |
There was a problem hiding this comment.
You should also throw here if both arguments are specified, right?
Please also add a test case for this.
There was a problem hiding this comment.
Right you are. I will take care of that later this morning.
On Dec 27, 2013 8:59 AM, "Tomaz Muraus" notifications@github.com wrote:
In libcloud/compute/drivers/ec2.py:
""" params = {'Action': 'DisassociateAddress'}
params.update({'PublicIp': elastic_ip_address})if elastic_ip_address:You should also throw here if both arguments are specified, right?
Please also add a test case for this.
—
Reply to this email directly or view it on GitHubhttps://github.com//pull/208/files#r8567553
.
Added tests for the raise conditions
|
My reading of this is that |
|
Also I wonder if allocation_id should be encapsulated within an ElasticIP class, so instead of passing elastic_ip_address AND allocation_id, you pass a single object. (This PR has caused me to look at the various elastic IP API's we have for other providers - bright box, cloudstack, openstack, haven't looked further yet - and i'm going to try and propose a 'standard' API for the feature. Hiding allocation_id would be needed to do that). |
|
Yes, only associated would likely be a better name for this and certainly comes with less ambiguity. |
|
Given that virtually all cloud vendors have some form of public/floating/elastic IP addresses I am all for creating a standard API for this with a class (eg: NodeAddress). I do wish Amazon wouldn't require the allocation ID for VPC related actions as it would certainly make this a bit easier. |
|
Just checking in to see what direction you guys would like to go to support this functionality. If @Jc2k is indeed going to propose promoting this to the base API then I'll go ahead and close this out. |
|
+1. Hope to look at core API soon, but having this merged suits me. |
|
@cderamus Also, I don't want to rush you, but the whole 0.14.0 release has already been taking longer than usual and I would like to start a voting thread for it soon and it would be great if we could include this change in it. |
|
@Kami I live for pressure! I'm planning on dedicating a few hours to the project this evening and will bump this to the top of my list. I should have no issues getting this shored up. |
|
@cderamus heh, great! :) |
…PC_Elastic_IP_Support Conflicts: libcloud/compute/drivers/ec2.py
|
Sorry about the bad commit message on this one guys. I went ahead and added a new ElasticIp class into the driver and put all VPC specific attributes into the extra dict. As I was making the change I couldn't help but think that the all_properties boolean is sort of silly now that we're using a class. |
|
I'll be submitting a follow-up with some additional changes momentarily. |
…class for both method arguments and return objects. This will make things much easier when promoting ElasticIp/FloatingIp to the base API in the future. All address tests were also updated to reflect this change.
|
@Jc2k I believe this is what you wanted. Leveraging the ElasticIp instance required a new keyword argument 'domain' which is only used for VPC actions. If anything other than vpc is passed in the class will throw. Thanks for the suggestions as this was definitely a better approach. |
There was a problem hiding this comment.
Second check won't work everywhere.
is compares identifies (e.g. if two variables point to the same objects) which means you should only use it for immutable types (True, False, None, ...) otherwise you might get an unexpected result.
When you are comparing values you should use == or != in this case.
This is also the reason why PyPy tests are currently failing.
There was a problem hiding this comment.
Aye, will make that change now. Thanks!
…he migration to the ElasticIp abstraction. Docstring information was added for the ElasticIp class and the unit tests were updated accordingly. The domain conditional test which checks to validate that the value is 'vpc' was also updated.
There was a problem hiding this comment.
Hm, I just checked the code and it seems like there is an even split between Ip and IP.
I prefer IP (ElasticIP) over Ip since it's an abbreviation for Internet Protocol. What do other ppl think?
kami /w/lc/libcloud/libcloud (git:trunk)$ grep -r IP . | grep class
./test/loadbalancer/test_rackspace.py:class RackspaceLBWithVIPMockHttp(MockHttpTestCase):
./common/gandi.py:class IPAddress(BaseObject):
./compute/drivers/cloudstack.py:class CloudStackIPForwardingRule(object):
kami /w/lc/libcloud/libcloud (git:trunk)$ grep -r Ip . | grep class
./common/gogrid.py:class GoGridIpAddress(object):
./compute/drivers/openstack.py:class OpenStack_1_0_SharedIpGroup(object):
./compute/drivers/openstack.py:class OpenStack_1_0_NodeIpAddresses(object):
./compute/drivers/openstack.py:class OpenStack_1_1_FloatingIpPool(object):
./compute/drivers/openstack.py:class OpenStack_1_1_FloatingIpAddress(object):3 participants
No description provided.