This option is still there, is set as "unsupported" i think it might be
----- Original Message -----
> From: "Boris Derzhavets" <bderzhavets@hotmail.com>
> To: "Javier Pena" <javier.pena@redhat.com>
> Cc: "alan pevec" <alan.pevec@redhat.com>, "rdo-list" <rdo-list@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@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@redhat.com <rdo-list-bounces@redhat.com> on behalf
> > of
> > Javier Pena <javier.pena@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).
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@redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
>
>
> rdo-list Info Page - Red Hat
> 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
> > 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@redhat.com
>
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
>
> > To unsubscribe: rdo-list-unsubscribe@redhat.com
>
> _______________________________________________
> rdo-list mailing list
> rdo-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe@redhat.com
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe@redhat.com