Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140828/58dcc39f/attachment.html>