Re: [openstack-dev] Chalenges with highly available service VMs

2013-07-18 Thread Ian Wells 
On 18 July 2013 19:48, Aaron Rosen aro...@nicira.com wrote:
 Is there something this is missing that could be added to cover your use
 case? I'd be curious to hear where this doesn't work for your case.  One
 would need to implement the port_security extension if they want to
 completely allow all ips/macs to pass and they could state which ones are
 explicitly allowed with the allowed-address-pair extension (at least that is
 my current thought).

Yes - have you got docs on the port security extension?  All I've
found so far are
http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html
and the fact that it's only the Nicira plugin that implements it.  I
could implement it for something else, but not without a few hints...
-- 
Ian.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack][neutron] Reserved fixed IPs

2013-07-17 Thread Ian Wells 
It's already possible to port-create with an IP address-and-subnet
specified, which seems like an effective way of allocating an address
and setting it aside for later.  Doesn't this satisfy your needs?

-- 
Ian.

On 16 July 2013 19:42, Mark McClain mark.mccl...@dreamhost.com wrote:
 Have you considered altering the allocation range of a subnet?  You can still 
 create ports with IPs that are within the subnet, but outside of the 
 allocation range.  You can then control which instances get the reserved 
 IPs from the block that is outside of the allocation range.  If this does not 
 work, I'd hold off making changes to the IPAM setup as this will be changing 
 in early H3.

 mark

 On Jul 15, 2013, at 7:50 AM, Cristian Tomoiaga ctomoi...@gmail.com wrote:

 Hello everyone,

 I am working on implementing fixed IP reservation for tenants. My goal is to 
 be able to reserve fixed IPs for a tenant and avoid as much as possible the 
 ephemeral state of an IP.

 A basic workflow would be like this:

 Tenant or admin reserves one or more fixed IPs. He will than be able to use 
 one or more of those reserved IPs on his instances (assign them to ports, 
 support multiple IPs per port).
 If no/not enough fixed IPs are reserved, use the current IPAM implementation 
 otherwise allow the tenant to select from his reserved IPs and then go 
 through the current IPAM.

 I am using fixed routable and non-routable IPs for public and private 
 networks (provider network , no NAT and no tagging). I will also use 
 floating IPs for LB, DNS a.s.o.

 I have a few questions regarding the development of this since the 
 documentation is still being worked on and I have to dig through the code a 
 lot to understand a few things:

 1. nova reserve-fixed-ip, this belongs to nova-network now obsolete right ?
 2. I though of creating a new model (mainly a db table) to hold the IPs and 
 the tenant IDs in order to keep the association. I've done this for the 
 openvswitch plugin in ovs_models_v2 by adding a new model. I can probably do 
 this globally in /db directly right (especially if I plan on supporting 
 multiple plugins) ?
 3. I was planning on adding to Neutron the api calls nova has for fixed IPs 
 (ex: fixed-ip-get, reserve, unreserve) Does this seem right ? I am asking 
 because I believe there is some work towards a new IPAM implementation and I 
 would like to get some thoughts. I am also asking because to me it seems a 
 little bit confusing that nova can also manage IPs and I am not sure if/what 
 functions are
 obsolete there.
 4. This should go as an extension first (as far as I understand for the 
 docs). Add the extension to extend the Neutron API and modify the current 
 IPAM right ?


 --
 Regards,
 Cristian Tomoiaga
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Chalenges with highly available service VMs

2013-07-04 Thread Ian Wells 
On 4 July 2013 23:42, Robert Collins robe...@robertcollins.net wrote:
 Seems like a tweak would be to identify virtual IPs as separate to the
 primary IP on a port:
  you don't need to permit spoofing of the actual host IP for each host in
 the HA cluster; you just need to permit spoofing of the virtual IP. This
 would be safer than disabling the spoofing rules, and avoid configuration
 errors such as setting the primary IP of one node in the cluster to be a
 virtual IP on another node - neutron would reject that as the primary IP
 would be known as that.

With apologies for diverting the topic somewhat, but for the use cases
I have, I would actually like to be able to disable the antispoofing
in its entirety.

It used to be essential back when we had nova-network and all tenants
ended up on one network.  It became less useful when tenants could
create their own networks and could use them as they saw fit.

It's still got its uses - for instance, it's nice that the metadata
server can be sure that a request is really coming from where it
claims - but I would very much like it to be possible to, as an
option, explicitly disable antispoof - perhaps on a per-network basis
at network creation time - and I think we could do this without
breaking the security model beyond all hope of usefulness.
-- 
Ian.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<    1   2   3