<div dir="ltr">Having a tiny, multi-node, non-HA cloud has been extremely useful for developing anything that needs an Openstack cloud to talk to.<div><br></div><div>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.</div><div><br></div><div>We need to test > 1 compute node but not 5 compute nodes. Ex: migration can't be done on a single node!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>We don't need HA and the load on the controller is light enough that it can also handle compute.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 10:11 AM, Ivan Chavero <span dir="ltr"><<a href="mailto:ichavero@redhat.com" target="_blank">ichavero@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br> <br> ----- Original Message -----<br> > From: "Boris Derzhavets" <<a href="mailto:bderzhavets@hotmail.com">bderzhavets@hotmail.com</a>><br> > To: "Javier Pena" <<a href="mailto:javier.pena@redhat.com">javier.pena@redhat.com</a>><br> > Cc: "alan pevec" <<a href="mailto:alan.pevec@redhat.com">alan.pevec@redhat.com</a>>, "rdo-list" <<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a>><br> > Sent: Monday, June 20, 2016 8:35:52 AM<br> > Subject: Re: [rdo-list] Packstack refactor and future ideas<br> ><br> ><br> ><br> ><br> ><br> ><br> ><br> > From: Javier Pena <<a href="mailto:javier.pena@redhat.com">javier.pena@redhat.com</a>><br> > Sent: Monday, June 20, 2016 7:44 AM<br> > To: Boris Derzhavets<br> > Cc: rdo-list; alan pevec<br> > Subject: Re: [rdo-list] Packstack refactor and future ideas<br> > ----- Original Message -----<br> ><br> > > From: <a href="mailto:rdo-list-bounces@redhat.com">rdo-list-bounces@redhat.com</a> <<a href="mailto:rdo-list-bounces@redhat.com">rdo-list-bounces@redhat.com</a>> on behalf<br> > > of<br> > > Javier Pena <<a href="mailto:javier.pena@redhat.com">javier.pena@redhat.com</a>><br> > > Sent: Friday, June 17, 2016 10:45 AM<br> > > To: rdo-list<br> > > Cc: alan pevec<br> > > Subject: Re: [rdo-list] Packstack refactor and future ideas<br> ><br> > > ----- Original Message -----<br> > > > > We could take an easier way and assume we only have 3 roles, as in the<br> > > > > current refactored code: controller, network, compute. The logic would<br> > > > > then be:<br> > > > > - By default we install everything, so all in one<br> > > > > - If our host is not CONFIG_CONTROLLER_HOST but is part of<br> > > > > CONFIG_NETWORK_HOSTS, we apply the network manifest<br> > > > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS<br> > > > ><br> > > > > Of course, the last two options would assume a first server is<br> > > > > installed<br> > > > > as<br> > > > > controller.<br> > > > ><br> > > > > This would allow us to reuse the same answer file on all runs (one per<br> > > > > host<br> > > > > as you proposed), eliminate the ssh code as we are always running<br> > > > > locally,<br> > > > > and make some assumptions in the python code, like expecting OPM to be<br> > > > > deployed and such. A contributed ansible wrapper to automate the runs<br> > > > > would be straightforward to create.<br> > > > ><br> > > > > What do you think? Would it be worth the effort?<br> > > ><br> > > > +2 I like that proposal a lot! An ansible wrapper is then just an<br> > > > example playbook in docs but could be done w/o ansible as well,<br> > > > manually or using some other remote execution tooling of user's<br> > > > choice.<br> > > ><br> > > Now that the phase 1 refactor is under review and passing CI, I think it's<br> > > time to come to a conclusion on this.<br> > > This option looks like the best compromise between keeping it simple and<br> > > dropping the least possible amount of features. So unless someone has a<br> > > better idea, I'll work on that as soon as the current review is merged.<br> > ><br> > > Would it be possible :-<br> > ><br> > > - By default we install everything, so all in one<br> > > - If our host is not CONFIG_CONTROLLER_HOST but is part of<br> > > CONFIG_NETWORK_HOSTS, we apply the network manifest<br> > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS<br> > > - If our host is not CONFIG_CONTROLLER_HOST but is part of<br> > > CONFIG_STORAGE_HOSTS , we apply the storage manifest<br> > ><br> > > Just one more role. May we have 4 roles ?<br> ><br> > This is a tricky one. There used to be support for separate<br> > CONFIG_STORAGE_HOSTS, but I think it has been removed (or at least not<br> > tested for quite a long time).<br> <br> </div></div>This option is still there, is set as "unsupported" i think it might be<br> a good idea to keep it.<br> <br> what do you guys think?<br> <div class="HOEnZb"><div class="h5"><br> <br> > However, this feature currently works for RDO Mitaka ( as well it woks for<br> > Liberty)<br> > It's even possible to add Storage Node via packstack , taking care of glance<br> > and swift proxy<br> > keystone endpoints manually .<br> > For small prod deployments like several (5-10) Haswell Xeon boxes. ( no HA<br> > requirements from<br> > customer's side ). Ability to split Storage specifically Swift (AIO)<br> > instances or Cinder iSCSILVM<br> > back ends hosting Node from Controller is extremely critical feature.<br> > What I am writing is based on several projects committed in South America's<br> > countries.<br> > No complaints from site support stuff to myself for configurations deployed<br> > via Packstack.<br> > Dropping this feature ( unsupported , but stable working ) will for sure make<br> > Packstack<br> > almost useless toy .<br> > In situation when I am able only play with TripleO QuickStart due to Upstream<br> > docs<br> > ( Mitaka trunk instructions set) for instack-virt-setup don't allow to commit<br> > `openstack undercloud install` makes Howto :-<br> ><br> > <a href="https://remote-lab.net/rdo-manager-ha-openstack-deployment" rel="noreferrer" target="_blank">https://remote-lab.net/rdo-manager-ha-openstack-deployment</a><br> ><br> > non reproducible. I have nothing against TripleO turn, but absence of Red Hat<br> > high quality manuals for TripleO bare metal / TripleO Instak-virt-setup<br> > will affect RDO Community in wide spread way. I mean first all countries<br> > like Chile, Brazil, China and etc.<br> ><br> > Thank you.<br> > Boris.<br> ><br> > This would need to be a follow-up review, if it is finally decided to do so.<br> ><br> > Regards,<br> > Javier<br> ><br> > > Thanks<br> > > Boris.<br> ><br> > > Regards,<br> > > Javier<br> ><br> > > > Alan<br> > > ><br> ><br> > > _______________________________________________<br> > > rdo-list mailing list<br> > > <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br> > > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br> ><br> ><br> > rdo-list Info Page - Red Hat<br> > <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br> > The rdo-list mailing list provides a forum for discussions about installing,<br> > running, and using OpenStack on Red Hat based distributions. To see the<br> > collection of ...<br> ><br> ><br> > > rdo-list Info Page - Red Hat<br> > > <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br> > > The rdo-list mailing list provides a forum for discussions about<br> > > installing,<br> > > running, and using OpenStack on Red Hat based distributions. To see the<br> > > collection of ...<br> ><br> > > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br> ><br> > > _______________________________________________<br> > > rdo-list mailing list<br> > > <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br> > > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br> ><br> > > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br> ><br> > _______________________________________________<br> > rdo-list mailing list<br> > <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br> > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br> ><br> > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br> <br> _______________________________________________<br> rdo-list mailing list<br> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br> <br> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br> </div></div></blockquote></div><br></div>