Open Stack

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 at 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 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