<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Blaire,</div><div class=""><br class=""></div><div class="">To what extent is it possible to “lock” a tenant to an availability zone, to guarantee that nova scheduler doesn’t land an ITAR VM (and possibly the wrong glance/cinder) into a non-ITAR space (and vice versa)…</div><div class=""><br class=""></div><div class="">For just that concern, Mike Lowe was chatting with me off list about using Regions….but I should probably let Mike speak for himself if he wants. Having never used anything other than the default “RegionOne” I can’t speak to the capabilities.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 10:23 PM, Blair Bethwaite <<a href="mailto:blair.bethwaite@gmail.com" class="">blair.bethwaite@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Dims, it might be overkill to introduce multi-Keystone + federation (I just quickly skimmed the PDF so apologies if I have the wrong end of it)?<div class=""><br class=""></div><div class="">Jon, you could just have multiple cinder-volume services and backends. We do this in the Nectar cloud - each site has cinder AZs matching nova AZs. By default the API won't let you attach a volume to a host in a non-matching AZ, maybe that's enough for you(?), but you could probably take it further with other cinder scheduler filters.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 22 March 2017 at 12:03, Davanum Srinivas <span dir="ltr" class=""><<a href="mailto:davanum@gmail.com" target="_blank" class="">davanum@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oops, Hit send before i finished<br class="">
<br class="">
<a href="https://info.massopencloud.org/wp-content/uploads/2016/03/Workshop-Resource-Federation-in-a-Multi-Landlord-Cloud.pdf" rel="noreferrer" target="_blank" class="">https://info.massopencloud.<wbr class="">org/wp-content/uploads/2016/<wbr class="">03/Workshop-Resource-<wbr class="">Federation-in-a-Multi-<wbr class="">Landlord-Cloud.pdf</a><br class="">
<a href="https://git.openstack.org/cgit/openstack/mixmatch" rel="noreferrer" target="_blank" class="">https://git.openstack.org/<wbr class="">cgit/openstack/mixmatch</a><br class="">
<br class="">
Essentially you can do a single cinder proxy that can work with<br class="">
multiple cinder backends (one use case)<br class="">
<br class="">
Thanks,<br class="">
Dims<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
On Tue, Mar 21, 2017 at 8:59 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com" class="">davanum@gmail.com</a>> wrote:<br class="">
> Jonathan,<br class="">
><br class="">
> The folks from Boston University have done some work around this idea:<br class="">
><br class="">
> <a href="https://github.com/openstack/mixmatch/blob/master/doc/source/architecture.rst" rel="noreferrer" target="_blank" class="">https://github.com/openstack/<wbr class="">mixmatch/blob/master/doc/<wbr class="">source/architecture.rst</a><br class="">
><br class="">
><br class="">
> On Tue, Mar 21, 2017 at 7:33 PM, Jonathan Mills <<a href="mailto:jonmills@gmail.com" class="">jonmills@gmail.com</a>> wrote:<br class="">
>> Friends,<br class="">
>><br class="">
>> I’m reaching out for assistance from anyone who may have confronted the<br class="">
>> issue of dealing with ITAR data in an OpenStack cloud being used in some<br class="">
>> department of the Federal Gov.<br class="">
>><br class="">
>> ITAR (<a href="https://www.pmddtc.state.gov/regulations_laws/itar.html" rel="noreferrer" target="_blank" class="">https://www.pmddtc.state.gov/<wbr class="">regulations_laws/itar.html</a>) is a less<br class="">
>> restrictive level of security than classified data, but it has some thorny<br class="">
>> aspects to it, particularly where media is concerned:<br class="">
>><br class="">
>> * you cannot co-mingle ITAR and non-ITAR data on the same physical hard<br class="">
>> drives, and any drive, once it has been “tainted” with any ITAR data, is now<br class="">
>> an ITAR drive<br class="">
>><br class="">
>> * when ITAR data is destroyed, a DBAN is insufficient — instead, you<br class="">
>> physically shred the drive. No need to elaborate on how destructive this<br class="">
>> can get if you accidentally mingle ITAR with non-ITAR<br class="">
>><br class="">
>> Certainly the multi-tenant model of OpenStack holds great promise in Federal<br class="">
>> agencies for supporting both ITAR and non-ITAR worlds, but great care must<br class="">
>> be taken that *somehow* things like Glance and Cinder don’t get mixed up.<br class="">
>> One must ensure that the ITAR tenants can only access Glance/Cinder in ways<br class="">
>> such that their backend storage is physically separate from any non-ITAR<br class="">
>> tenants. Certainly I understand that Glance/Cinder can support multiple<br class="">
>> storage backend types, such as File & Ceph, and maybe that is an avenue to<br class="">
>> explore to achieving the physical separation. But what if you want to have<br class="">
>> multiple different File backends?<br class="">
>><br class="">
>> Do the ACLs exist to ensure that non-ITAR tenants can’t access ITAR<br class="">
>> Glance/Cinder backends, and vice versa?<br class="">
>><br class="">
>> Or…is it simpler to just build two OpenStack clouds….?<br class="">
>><br class="">
>> Your thoughts will be most appreciated,<br class="">
>><br class="">
>><br class="">
>> Jonathan Mills<br class="">
>><br class="">
>> NASA Goddard Space Flight Center<br class="">
>><br class="">
>><br class="">
>> ______________________________<wbr class="">_________________<br class="">
>> OpenStack-operators mailing list<br class="">
>> <a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.<wbr class="">openstack.org</a><br class="">
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack-operators</a><br class="">
>><br class="">
><br class="">
><br class="">
><br class="">
> --<br class="">
> Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank" class="">https://twitter.com/dims</a><br class="">
<br class="">
<br class="">
<br class="">
--<br class="">
Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank" class="">https://twitter.com/dims</a><br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
OpenStack-operators mailing list<br class="">
<a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.<wbr class="">openstack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack-operators</a><br class="">
</div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br class="">~Blairo</div>
</div>
</div></blockquote></div><br class=""></body></html>