Open Stack

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 at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev