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 <[email protected]> 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" <[email protected]> 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: [email protected]?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
