How much sense has magnum implementation on RDO Ocata via packstack ?

UPDATE
I still believe that creating storage.pp role been able to pass CI and responsible for separation Swift,Cinder,Glance services from Controller set up via packstack is not the task out of scope for RH Cloud team. Changes been done in Newton release of RDO will cause performance degradation on production system making containers (kubernetes,docker swarm) support on RDO Ocata almost impossible.
TripleO has serious issues with maintenance of production environment. Wrong allocation memory per CPU
causes heat update to crash even during attempt to add compute node to overcloud. Original deployment of
TripleO may be redone as many times as needed versus failure of redeploying ( heat update of overcloud stack )
overcloud as entity during maintenance either recovery HA Controller been crashed .
The question - is it worth of efforts to maintain packstack responsible for containers support via magnum
or no ?
END UPDATE

Just a sample - docker swarm VMs are using cinder volumes to spawn. But, cinder services due to known restriction (CI related) may run only on Controller.
Due to well known packstack limitation as of Newton Release ( not to split Storage Node anymore ) . Thus answer unfortunately appears to be "Just for fun" . Please, correct me If I am wrong about that. A bunch of people are still using packstack for RDO deployments. Might be it makes some
sense to create "Infra" ( vs it was stated by A.P. on rdo mailing list ).

Here I’d like to summarize our six-months long experience with the TripleO installer:

In our experience, the configuration of the OpenStack cluster using only the TripleO installer is not flexible enough. As a workaround, we ended up writing a bunch of Ansible scripts.
The overcloud update can take a very long time to complete and it can fail because of random errors. Also during the update operation all the overcloud nodes have to be reachable by the TripleO installer. For this reason, I personally cannot imagine using TripleO to manage a cluster with more than one hundred nodes.
As we experienced, the TripleO installer can easily break a working OpenStack cluster. This is a big no-no for a production system.
Overall, I think that the TripleO installer in the Mitaka version of OpenStack would need more work to become production ready. In the meantime, we’re continuing with patching of what we have.
In the future, there are other projects that could replace the TripleO installer. I found the kolla-ansible and kolla-kubernetes rather promising.

Quoting ends

I guess that major concern of any customer is safe production maintenance and abilty recover from disaster for sure with minimal downtime.
I am also very sorry about RH's policy regarding packstack development. Ales Nosek mentioned "Kolla" related projects and there is also well
known project running by Google && Intel && Mirantis "implementation Openstack on top Kubernetes containers"

Do you mean dependency of magnum deployed swarm cluster on cinder services. If yes, you can skip using cinder volume by specifying --docker-volume-size 0 while creating cluster-template if you have issue with cinder volumes.

But i don't understand: how running of cinder services on controller impacted your swarm cluster. Any link to known restriction that you mentioned?