Re: [rdo-list] Packstack refactor and future ideas

On Jun 8, 2016 11:54 PM, "Ivan Chavero" < ichavero(a)redhat.com > wrote: > > > > ----- Original Message ----- > > From: "Hugh Brock" < hbrock(a)redhat.com > > > To: "Ivan Chavero" < ichavero(a)redhat.com > > > Cc: "Javier Pena" < javier.pena(a)redhat.com >, "David Moreau Simard" < > > dms(a)redhat.com >, "rdo-list" < rdo-list(a)redhat.com > > > Sent: Wednesday, June 8, 2016 5:40:39 PM > > Subject: Re: [rdo-list] Packstack refactor and future ideas > > > > On Jun 8, 2016 11:33 PM, "Ivan Chavero" < ichavero(a)redhat.com > wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > From: "David Moreau Simard" < dms(a)redhat.com > > > > > To: "Ivan Chavero" < ichavero(a)redhat.com > > > > > Cc: "Javier Pena" < javier.pena(a)redhat.com >, "rdo-list" < > > rdo-list(a)redhat.com > > > > > Sent: Wednesday, June 8, 2016 3:37:08 PM > > > > Subject: Re: [rdo-list] Packstack refactor and future ideas > > > > > > > > On Wed, Jun 8, 2016 at 3:27 PM, Ivan Chavero < ichavero(a)redhat.com > > > wrote: > > > > > I think it can be reduced to a single manifest per node. > > > > > Also, when a review is created it would be easier to check if you > > create > > > > > one > > > > > review for the python, puppet, tests and release notes. > > > > > > > > This would not pass CI and thus could not be merged. > > > > If there are separate commits, each must pass CI. > > > > > > well, make it just one big commit if there's no way around this > > > > > > > Otherwise, my opinion is that Packstack should focus on being a lean, > > > > simple and efficient single node installation tool that targets the > > > > same use case as DevStack but for the RHEL-derivatives and RDO/OSP > > > > population. > > > > A tool that is lightweight, simple (to an extent), easy to extend and > > > > add new projects in and focuses on developers and proof of concepts. > > > > > > > I don't believe Packstack should be able to handle multi-node by > > > > itself. > > > > I don't think I am being pessimistic by saying there is too few > > > > resources contributing to Packstack to make multi-node a good story. > > > > We're not testing Packstack multi-node right now and testing it > > > > properly is really hard, just ask the whole teams of people focused > > > > on > > > > just testing TripleO. > > > > > > So in your opinion we should drop features that packstack already has > > > because this are difficult to test. > > > I don't agree with this, we can set the untested features as > > "experimental" > > > or "unsupported" > > > > > > > > > > If Packstack is really good at installing things on one node, an > > > > advanced/experienced user could have Packstack install components on > > > > different servers if that is what he is looking for. > > > > > > > > Pseudo-code: > > > > - Server 1: packstack --install-rabbitmq=y --install-mariadb=y > > > > - Server 2: packstack --install-keystone=y --rabbitmq-server=server1 > > > > --database-server=server1 > > > > - Server 3: packstack --install-glance=y --keystone-server=server2 > > > > --database-server=server1 --rabbitmq-server=server1 > > > > - Server 4: packstack --install-nova=y --keystone-server=server2 > > > > --database-server=server1 --rabbitmq-server=server1 > > > > (etc) > > > > > > I can be wrong but right now Packstack can already do this stuff, > > > more command line options are needed or it might need little tweaks to > > > the > > > code but this is not far from current Packstack options. > > > > > > > So in my concept, Packstack is not able to do multi node by itself > > > > but > > > > provides the necessary mechanisms to allow to be installed across > > > > different nodes. > > > > If an orchestration or wrapper mechanism is required, Ansible is a > > > > obvious choice but not the only one. > > > > Using Ansible would, notably, make it easy to rip out all the python > > > > code that's around executing things on servers over SSH. > > > > > > > > > > > > > I think this refactor discussion should focus on a proper puppet usage > > > and > > > optimizations instead of retiring stuff that already works. > > > Actually Packstack used to be able to install all the components in > > different > > > nodes and this feature was modified to the current limited multinode > > features. > > > > > > We need a tool like Packstack so users can try RDO without the > > > complexity > > of > > > TripleO, imagine you're new to OpenStack and you want to test it in > > different > > > scenarios, not everybody has a spare machine with 16GB of ram just to > > test, not to > > > mention the fact of understanding the concept of undercloud before > > understanding > > > the key concepts of OpenStack. > > > > > > Cheers, > > > Ivan > > > > Here's a possibly stupid question, indulge me.... > > > > Seems like we're always going to need a simple (ish) tool that just > > installs the openstack services on a single machine, without any need for > > VMs. > > > > In fact, the tripleo installer - instack - is one such tool. Packstack is > > another, more flexible such tool. Should we consider merging or adapting > > them to be the same tool? > > I don't think this is supid at all, actually TripleO and Packstack are both > based on OpenStack Puppet Modules but i don't think you can make merge them > since the behaviour of both tools is very different, Packstack is not > focused on managing the hardware, it's just focused on installing OpenStack > and i'm not very familiar with TripleO inner workings but i think it would > be > very difficult to make it more like Packstack. > > Cheers, > Ivan No, sorry, I didn't mean merge packstack and tripleo, they are very different beasts. I meant merge the tripleo installer -- which is called "instack", and whose job it is to install an openstack undercloud on a single machine so that it can then install openstack -- with packstack, whose job it is to install openstack on a single machine, for whatever reason. Deployers who want a production install could then go on to deploy a full overcloud.

-Hugh