Open Stack

So I think the thing to keep in mind here is that your overcloud nodes
are OpenStack _instances_ in TripleO.  Would you would expect to start a
VM in Nova, shut off all of the OpenStack services, and still be able to
reboot that VM successfully?  Maybe if you had static networking, but I
highly doubt this is a use case we intentionally support.  Running
instances should stay running and available, but until you have
OpenStack back up you won't be able to make changes to those instances.
 The same applies to TripleO overcloud nodes.

Also keep in mind that TripleO isn't simply a deployment tool - it's
also the thing you manage your cloud with.  No undercloud = no
management interface, which is why HA is so important.

Enabling the no undercloud use case might be possible, but it doesn't
scale and I think it would be a diversion from the ultimate goal of the
project.  Just my opinion, of course.

-Ben

On 08/28/2014 09:20 AM, Jyoti Ranjan wrote:
> It is not a big worry but it would have been better if overcloud nodes to
> be independent of undercloud except being a manager. Think the use case
> where:
> 
> 1. nova has three region, geographically apart
> 2. geographical area hosting undercloud gets doomed
> 3. all region of nova gets affected as they can not reboot
> 
> But, we can leave operator to ensure undercloud comes backend. Or, am I
> thinking too much?
> 
> 
> On Thu, Aug 28, 2014 at 10:47 AM, James Polley <jp at jamezpolley.com> wrote:
> 
>> That is correct, we intend that the undercloud should be designed with HA
>> in mind.
>>
>> In terms of the design of TripleO, the devtest.sh implementation aims to
>> have this available as a default (see
>> http://docs.openstack.org/developer/tripleo-incubator/README.html#stage-2-being-worked-on
>> for some dated and very brief notes about our aims). This is something
>> that's been receiving a lot of attention over the last cycle, but it's not
>> quite ready out-of-the-box yet.
>>
>> In terms of implementation, this will still require the implementor to
>> make sure that their implementation meets their needs for HA. For instance,
>> it doesn't matter how many redundant neutron nodes we run if they all hang
>> off the back of a single physical non-redundant switch...
>>
>> Are there particular concerns you have with this design?
>>
>>
>>
>> On Thu, Aug 28, 2014 at 2:20 PM, Jyoti Ranjan <jranjan at gmail.com> wrote:
>>
>>> I do agree but it create an extra requirement for Undercloud if we high
>>> availability is important criteria. Because of this, undercloud has to be
>>> there 24x7, 365 days and to make it available we need to have HA for this
>>> also. So, you indirectly mean that undercloud also should be designed
>>> keeping high availability in mind.
>>>
>>>
>>> On Wed, Aug 27, 2014 at 7:53 PM, Ben Nemec <openstack at nemebean.com>
>>> wrote:
>>>
>>>> We probably will at some point, but I don't know that it's a huge
>>>> priority right now.  The PXE booting method works fine, and as I
>>>> mentioned we don't intend you to reboot machines without using the
>>>> undercloud anyway, just like Nova doesn't expect you to reboot vms
>>>> directly via libvirt (or your driver of choice).
>>>>
>>>> It's likely there would be other issues booting a deployed machine if
>>>> the undercloud is down anyway (nothing to respond to DHCP requests, for
>>>> one), so I don't see that as something we want to encourage anyway.
>>>>
>>>> -Ben
>>>>
>>>> On 08/27/2014 04:11 AM, Jyoti Ranjan wrote:
>>>>> I believe that local boot option is available in Ironic. Will not be a
>>>> good
>>>>> idea to boot from local disk instead of relying on PXE boot always?
>>>> Curious
>>>>> to know why we are not going this path?
>>>>>
>>>>>
>>>>> On Wed, Aug 27, 2014 at 3:54 AM, 严超 <yanchao727 at gmail.com> wrote:
>>>>>
>>>>>> Thank you very much.
>>>>>> And sorry for the cross-posting.
>>>>>>
>>>>>> *Best Regards！*
>>>>>>
>>>>>>
>>>>>> *Chao Yan--------------**My twitter：Andy Yan @yanchao727
>>>>>> <https://twitter.com/yanchao727>*
>>>>>>
>>>>>>
>>>>>> *My Weibo：http://weibo.com/herewearenow
>>>>>> <http://weibo.com/herewearenow>--------------*
>>>>>>
>>>>>>
>>>>>> 2014-08-26 23:17 GMT+08:00 Ben Nemec <openstack at nemebean.com>:
>>>>>>
>>>>>> Oh, after writing my response below I realized this is cross-posted
>>>>>>> between openstack and openstack-dev.  Please don't do that.
>>>>>>>
>>>>>>> I suppose this probably belongs on the users list, but since I've
>>>>>>> already written the response I guess I'm not going to argue too
>>>> much. :-)
>>>>>>>
>>>>>>> On 08/26/2014 07:36 AM, 严超 wrote:
>>>>>>>> Hi, All:
>>>>>>>>         I've deployed undercloud and overcloud on some baremetals.
>>>> All
>>>>>>>> overcloud machines are deployed by undercloud.
>>>>>>>>         Then I tried to shutdown undercloud machines. After that,
>>>> if I
>>>>>>>> reboot one overcloud machine, it will never boot from net, AKA PXE
>>>> used
>>>>>>> by
>>>>>>>> undercloud.
>>>>>>>
>>>>>>> Yes, that's normal.  With the way our baremetal deployments work
>>>> today,
>>>>>>> the deployed systems always PXE boot.  After deployment they PXE
>>>> boot a
>>>>>>> kernel and ramdisk that use the deployed hard disk image, but it's
>>>> still
>>>>>>> a PXE boot.
>>>>>>>
>>>>>>>>         Is that what TripleO is designed to be ? We can never
>>>> shutdown
>>>>>>>> undercloud machines for maintainance of overcloud ?  Please help me
>>>>>>>> clearify that.
>>>>>>>
>>>>>>> Yes, that's working as intended at the moment.  I recall hearing that
>>>>>>> there were plans to eliminate the PXE requirement after deployment,
>>>> but
>>>>>>> you'd have to talk to the Ironic team about that.
>>>>>>>
>>>>>>> Also, I don't think it was ever the intent of TripleO that the
>>>>>>> undercloud would be shut down after deployment.  The idea is that you
>>>>>>> use the undercloud to manage the overcloud machines, so if you want
>>>> to
>>>>>>> reboot one you do it via the undercloud nova, not directly on the
>>>> system
>>>>>>> itself.
>>>>>>>
>>>>>>>>
>>>>>>>> *Best Regards！*
>>>>>>>>
>>>>>>>>
>>>>>>>> *Chao Yan--------------**My twitter：Andy Yan @yanchao727
>>>>>>>> <https://twitter.com/yanchao727>*
>>>>>>>>
>>>>>>>>
>>>>>>>> *My Weibo：http://weibo.com/herewearenow
>>>>>>>> <http://weibo.com/herewearenow>--------------*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>