settingsLogin | Registersettings

Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources

0 votes

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" doug@doughellmann.com wrote:

Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +0000:

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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 4, 2015 in openstack-dev by Eichberger,_German (2,880 points)   2 3

2 Responses

0 votes

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.eichberger@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" doug@doughellmann.com wrote:

Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +0000:
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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 4, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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.eichberger@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" doug@doughellmann.com wrote:

Excerpts from Amrith Kumar's message of 2015-06-04 12:46:37 +0000:

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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 5, 2015 by John_Garbutt (15,460 points)   3 4 5
...