Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources
Hi, I still think we need to look at lot more carefully at why using an isolated service tenant would not work. Sure, thats a bit rich coming from someone trying to limit the scope of Nova, but really I am just trying to work out what the problem is you are tying to solve, and specifically what problems you have using a separate tenant to the user. On 4 June 2015 at 20:44, Eichberger, German german.eichber...@hp.com wrote: Amrith, Thanks for spearheading that work. In the Octavia project we are interested in the shadow tenant to solve some of the scalability issues we have encountered with one service tenant: * There is probably a limit how many Vms a tenant can have -1 There is a quota that will need updating for that tenant, but thats fine. Also, the list instance API call will be pages, and you have to deal with that. But I don't think there is a hard limit on that. If we find one, lets try fix it. * We have been running out of ipsec rules in our tenant Do you mean run out of the default quota, or hit a hard technical limit? * There is a limit how many ports a tenant can have (somebody mentioned 200 to me) I would hope thats also an adjustable quota? Or does this relate to a specific technology choice you have made? A lot of that we still have to validate but I think for various reason sharding over multiple tenants and networks is interesting to us. Thats a nice twist, if we do hit a hard limit somewhere. Thanks, John On 6/4/15, 6:45 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +: John, Thanks for your note. I've updated the review at https://review.openstack.org/#/c/186357/ with answers to some of your questions (and I added you to that review). Trove's use-case like some of the other projects listed is different from Glance in that Trove has a guest agent. I've tried to explain that in more detail in patch set 5. I'd appreciate your comments. We solved this in Akanda by placing the service VMs in a special tenant, isolating them with security group rules, and then giving the agent running in the VM a REST API connected to a private management network owned by the same tenant that owns the VM. All communication with the agent starts from a service on the outside, through that management network. The VMs act as routers, so they are also attached to the cloud-user's networks, but the agent doesn't respond on those networks. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources
With my op hat on, we're really interested in Service VM's working like normal VM's when it comes to nova (quota's, flavor access), cinder, etc. its greatly simplifies billing if you don't have to treat these types of advanced services any differently. We also let users launch on dedicated hardware with flavors. If they can't launch their service vm on their own hardware that is a problem. So having some way to mark the VM as a Service VM and restricting API access via policy would be quite attractive to us. Thanks, Kevin From: Eichberger, German [german.eichber...@hp.com] Sent: Thursday, June 04, 2015 12:44 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources Amrith, Thanks for spearheading that work. In the Octavia project we are interested in the shadow tenant to solve some of the scalability issues we have encountered with one service tenant: * There is probably a limit how many Vms a tenant can have * We have been running out of ipsec rules in our tenant * There is a limit how many ports a tenant can have (somebody mentioned 200 to me) A lot of that we still have to validate but I think for various reason sharding over multiple tenants and networks is interesting to us. Thanks, German On 6/4/15, 6:45 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +: John, Thanks for your note. I've updated the review at https://review.openstack.org/#/c/186357/ with answers to some of your questions (and I added you to that review). Trove's use-case like some of the other projects listed is different from Glance in that Trove has a guest agent. I've tried to explain that in more detail in patch set 5. I'd appreciate your comments. We solved this in Akanda by placing the service VMs in a special tenant, isolating them with security group rules, and then giving the agent running in the VM a REST API connected to a private management network owned by the same tenant that owns the VM. All communication with the agent starts from a service on the outside, through that management network. The VMs act as routers, so they are also attached to the cloud-user's networks, but the agent doesn't respond on those networks. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources
Amrith, Thanks for spearheading that work. In the Octavia project we are interested in the shadow tenant to solve some of the scalability issues we have encountered with one service tenant: * There is probably a limit how many Vms a tenant can have * We have been running out of ipsec rules in our tenant * There is a limit how many ports a tenant can have (somebody mentioned 200 to me) A lot of that we still have to validate but I think for various reason sharding over multiple tenants and networks is interesting to us. Thanks, German On 6/4/15, 6:45 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +: John, Thanks for your note. I've updated the review at https://review.openstack.org/#/c/186357/ with answers to some of your questions (and I added you to that review). Trove's use-case like some of the other projects listed is different from Glance in that Trove has a guest agent. I've tried to explain that in more detail in patch set 5. I'd appreciate your comments. We solved this in Akanda by placing the service VMs in a special tenant, isolating them with security group rules, and then giving the agent running in the VM a REST API connected to a private management network owned by the same tenant that owns the VM. All communication with the agent starts from a service on the outside, through that management network. The VMs act as routers, so they are also attached to the cloud-user's networks, but the agent doesn't respond on those networks. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
