<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p><br>
</p>
<br>
<br>
<div style="color: rgb(49, 55, 57);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> tbuskey@gmail.com <tbuskey@gmail.com> on behalf of Tom Buskey <tom@buskey.name><br>
<b>Sent:</b> Wednesday, June 22, 2016 11:18 AM<br>
<b>To:</b> Ivan Chavero<br>
<b>Cc:</b> Boris Derzhavets; alan pevec; rdo-list; Javier Pena<br>
<b>Subject:</b> Re: [rdo-list] Packstack refactor and future ideas</font>
<div> </div>
</div>
<div>
<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.<br>
<br>
In current thread there were 2 major arguments why packstack has to be dropped ( or at least less functional<br>
in regards of multinode support then currently in RDO Mitaka )<br>
<br>
1. Multinode functionality cannot pass CI ( creating this tests is out of scope , hence it should be dropped)<br>
If it is not tested , then it is not working BY DEFINITION ( I am quoting Alan word in word )<br>
Why Lars Kellogg-Stedman provided "RDO Havana Hangout" via YouTube and as slide-show,<br>
he was explaining packstack functionality which NEVER passed CI ?<br>
Something happened in Mitaka/Newton times - TripleO stabilized ( first of all on bare metal )<br>
<br>
2. Packstack is compromising RDO providing to customers wrong impression about <b> RDO Core features<br>
in reality and in meantime</b> . Hence, it is breaking correct focus on Triple0 Bare Betal/TripleO QuickStart
<br>
( now virtual but supposed to handle bare metal ASAP) .<br>
<br>
Regarding statement (2) <span>I would better hold my opinion with myself.</span><br>
Boris. <br>
</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>
</div>
</div>
</div>
</body>
</html>