[rdo-list] Packstack refactor and future ideas

[Boris Derzhavets]

________________________________
From: Javier Pena <javier.pena at redhat.com>
Sent: Monday, June 20, 2016 7:44 AM
To: Boris Derzhavets
Cc: rdo-list; alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas

----- Original Message -----

> From: rdo-list-bounces at redhat.com <rdo-list-bounces at redhat.com> on behalf of
> Javier Pena <javier.pena at redhat.com>
> Sent: Friday, June 17, 2016 10:45 AM
> To: rdo-list
> Cc: alan pevec
> Subject: Re: [rdo-list] Packstack refactor and future ideas

> ----- Original Message -----
> > > We could take an easier way and assume we only have 3 roles, as in the
> > > current refactored code: controller, network, compute. The logic would
> > > then be:
> > > - By default we install everything, so all in one
> > > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> > >
> > > Of course, the last two options would assume a first server is installed
> > > as
> > > controller.
> > >
> > > This would allow us to reuse the same answer file on all runs (one per
> > > host
> > > as you proposed), eliminate the ssh code as we are always running
> > > locally,
> > > and make some assumptions in the python code, like expecting OPM to be
> > > deployed and such. A contributed ansible wrapper to automate the runs
> > > would be straightforward to create.
> > >
> > > What do you think? Would it be worth the effort?
> >
> > +2 I like that proposal a lot! An ansible wrapper is then just an
> > example playbook in docs but could be done w/o ansible as well,
> > manually or using some other remote execution tooling of user's
> > choice.
> >
> Now that the phase 1 refactor is under review and passing CI, I think it's
> time to come to a conclusion on this.
> This option looks like the best compromise between keeping it simple and
> dropping the least possible amount of features. So unless someone has a
> better idea, I'll work on that as soon as the current review is merged.
>
> Would it be possible :-
>
> - By default we install everything, so all in one
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_NETWORK_HOSTS, we apply the network manifest
> - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_STORAGE_HOSTS , we apply the storage manifest
>
> Just one more role. May we have 4 roles ?

This is a tricky one. There used to be support for separate CONFIG_STORAGE_HOSTS, but I think it has been removed (or at least not tested for quite a long time).

    However, this feature currently works for RDO Mitaka ( as well it woks for Liberty)
    It's even possible to add Storage Node via packstack , taking care of glance and swift proxy
    keystone endpoints manually .
        For small prod deployments like several (5-10) Haswell Xeon boxes. ( no HA requirements from
   customer's side ).  Ability to split Storage specifically Swift (AIO) instances or Cinder iSCSILVM
   back ends hosting Node from Controller is extremely critical feature.
   What I am writing is based on several projects committed in South America's countries.
   No complaints from site support stuff to myself for configurations deployed via Packstack.
   Dropping this feature ( unsupported , but stable working ) will for sure make Packstack
   almost useless toy .
       In situation when I am able only play with TripleO QuickStart  due to Upstream docs
( Mitaka trunk instructions set) for instack-virt-setup don't allow to commit
`openstack undercloud install` makes Howto :-

       https://remote-lab.net/rdo-manager-ha-openstack-deployment

<https://remote-lab.net/rdo-manager-ha-openstack-deployment>   non reproducible. I have nothing against TripleO turn, but absence of Red Hat
   high quality manuals  for TripleO bare metal / TripleO Instak-virt-setup
   will affect RDO Community in wide spread way.  I mean first all countries
   like Chile, Brazil, China and etc.

   Thank you.
   Boris.

This would need to be a follow-up review, if it is finally decided to do so.

Regards,
Javier

> Thanks
> Boris.

> Regards,
> Javier

> > Alan
> >

> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
rdo-list Info Page - Red Hat<https://www.redhat.com/mailman/listinfo/rdo-list>
www.redhat.com
The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ...



> rdo-list Info Page - Red Hat
> www.redhat.com<http://www.redhat.com>
> The rdo-list mailing list provides a forum for discussions about installing,
> running, and using OpenStack on Red Hat based distributions. To see the
> collection of ...

> To unsubscribe: rdo-list-unsubscribe at redhat.com

> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list

> To unsubscribe: rdo-list-unsubscribe at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160620/d62ba9cf/attachment.html>