[rdo-list] Packstack refactor and future ideas

Wed Jun 22 16:51:01 UTC 2016

________________________________
From: tbuskey at gmail.com <tbuskey at gmail.com> on behalf of Tom Buskey <tom at buskey.name>
Sent: Wednesday, June 22, 2016 11:18 AM
To: Ivan Chavero
Cc: Boris Derzhavets; alan pevec; rdo-list; Javier Pena
Subject: Re: [rdo-list] Packstack refactor and future ideas

Having a tiny, multi-node, non-HA cloud has been extremely useful for developing anything that needs an Openstack cloud to talk to.

We don't care if the cloud dies.  Our VM images and recipes are elsewhere.  We rebuild the clouds as needed.  We migrate to another working cloud while we rebuild if needed.

We need to test > 1 compute node but not 5 compute nodes.  Ex: migration can't be done on a single node!

packstack is ideal.  A 2 node cloud where both nodes need to do compute lets us run 20-30 VMs to test.  We also need multiple clouds.

   In current thread there were 2 major arguments why packstack has to be dropped ( or at least less functional
   in regards of multinode support then currently in RDO Mitaka )

          1. Multinode functionality cannot pass CI ( creating  this tests is out of scope , hence it should be dropped)
               If  it is not tested , then it is not working BY DEFINITION ( I am quoting Alan word in word )
               Why Lars Kellogg-Stedman provided "RDO Havana Hangout"   via YouTube and as slide-show,
               he was explaining packstack functionality which NEVER passed CI ?
               Something happened in Mitaka/Newton times  - TripleO stabilized ( first of all on bare metal )

          2. Packstack is compromising RDO providing to customers wrong impression about  RDO Core features
               in reality and in meantime . Hence, it is breaking correct  focus on Triple0 Bare Betal/TripleO QuickStart
               ( now virtual but supposed to handle bare metal ASAP) .

          Regarding statement (2) I would  better hold my opinion with myself.
          Boris.

We have "production" clouds and need a minimum of 3 nodes == 50% more costs and the controller is mostly idle.  Going from 1 to 5 (7?) for a "real production" cloud is a big leap.

We don't need HA and the load on the controller is light enough that it can also handle compute.

On Mon, Jun 20, 2016 at 10:11 AM, Ivan Chavero <ichavero at redhat.com<mailto:ichavero at redhat.com>> wrote:

----- Original Message -----
> From: "Boris Derzhavets" <bderzhavets at hotmail.com<mailto:bderzhavets at hotmail.com>>
> To: "Javier Pena" <javier.pena at redhat.com<mailto:javier.pena at redhat.com>>
> Cc: "alan pevec" <alan.pevec at redhat.com<mailto:alan.pevec at redhat.com>>, "rdo-list" <rdo-list at redhat.com<mailto:rdo-list at redhat.com>>
> Sent: Monday, June 20, 2016 8:35:52 AM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
>
>
>
>
>
>
>
> From: Javier Pena <javier.pena at redhat.com<mailto: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<mailto:rdo-list-bounces at redhat.com> <rdo-list-bounces at redhat.com<mailto:rdo-list-bounces at redhat.com>> on behalf
> > of
> > Javier Pena <javier.pena at redhat.com<mailto: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).

This option is still there, is set as "unsupported" i think it might be
a good idea to keep it.

what do you guys think?

> 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
>
> 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<mailto:rdo-list at redhat.com>
> > https://www.redhat.com/mailman/listinfo/rdo-list
>
>
> 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 ...
>
>
> > 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<mailto:rdo-list-unsubscribe at redhat.com>
>
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list at redhat.com<mailto:rdo-list at redhat.com>
> > https://www.redhat.com/mailman/listinfo/rdo-list
>
> > To unsubscribe: rdo-list-unsubscribe at redhat.com<mailto:rdo-list-unsubscribe at redhat.com>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com<mailto:rdo-list at redhat.com>
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com<mailto:rdo-list-unsubscribe at redhat.com>

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160622/692dec44/attachment.html>