<div style="white-space:pre-wrap">Hi Jay,<br><br>Thank you for your comments.</div><br class="gmail_msg">
<br class="gmail_msg">
2016-11-14 2:19 GMT+09:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com" class="gmail_msg" target="_blank">jaypipes@gmail.com</a>>:<br class="gmail_msg">
> On 11/13/2016 01:52 AM, Akira Yoshiyama wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hi Jay,<br class="gmail_msg">
>><br class="gmail_msg">
>> 2016-11-13 3:12 GMT+09:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com" class="gmail_msg" target="_blank">jaypipes@gmail.com</a>>:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> On 11/12/2016 09:31 AM, Akira Yoshiyama wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> Hi Stackers,<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> In TripleO, Ironic provides physical servers for an OpenStack<br class="gmail_msg">
>>>> deployment but we have to configure physical storages manually, or<br class="gmail_msg">
>>>> with any tool, if required. It's better that an OpenStack service<br class="gmail_msg">
>>>> manages physical storages as same as Ironic for servers.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> IMO, there are 2 plans to manage physical storages:<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> When you say "manage physical storage" are you referring to configuring<br class="gmail_msg">
>>> something like Ceph or GlusterFS or even NFS on a bunch of baremetal<br class="gmail_msg">
>>> servers?<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> No. "physical storages" means storage products like EMC VNX, NetApp<br class="gmail_msg">
>> Data ONTAP, HPE Lefthand and so on.<br class="gmail_msg">
>> Say there is a new service named X to manage them. A user, he/she will<br class="gmail_msg">
>> be a new IaaS admin, requests many baremetal servers to Ironic and<br class="gmail_msg">
>> some baremetal storages to X. After they are provided, he/she will<br class="gmail_msg">
>> start to build a new OpenStack deployment with them. Nova in the new<br class="gmail_msg">
>> one will provide VMs on the servers and Cinder will manage logical<br class="gmail_msg">
>> volumes on the storages. X doesn't manage each logical volume but<br class="gmail_msg">
>> pools, user accounts and network connections of the storages.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Yeah, I personally believe that is the domain of configuration management<br class="gmail_msg">
> systems not OpenStack HTTP API services. What you are describing is not a<br class="gmail_msg">
> multi-tenant HTTP API service, it's an IT/storage admin automation tool.<br class="gmail_msg">
><br class="gmail_msg">
> Incidentally, Ironic isn't multi-tenant either. It lives in the weird land<br class="gmail_msg">
> in OpenStack of being an HTTP API service that isn't meant for "normal<br class="gmail_msg">
> users" so in order to provider a cloud service (BareMetal-as-a-Service),<br class="gmail_msg">
> Ironic *requires* Nova to provide the multi-tenancy aspects of the<br class="gmail_msg">
> "as-a-Service" part of the software.<br class="gmail_msg">
<br class="gmail_msg"><div style="white-space:pre-wrap">Hmm... so, if I built a (multi-tenant) baremetal IaaS service like SoftLayer<br>with OpenStack Newton release, tenant users can deploy an OpenStack<br>environment with cinder using SDS on it. No physical storages.</div><br class="gmail_msg">
<br class="gmail_msg">
> Ironic is great, of course, but it ain't a cloud service without help from<br class="gmail_msg">
> Nova.<br class="gmail_msg">
><br class="gmail_msg">
> Best,<br class="gmail_msg">
> -jay<br class="gmail_msg">
<br class="gmail_msg"><div style="white-space:pre-wrap">BR,<br>Akira<br></div>