Open Stack

On 15/07/16 18:36 +0000, Fox, Kevin M wrote:
>Some specific things:
>
>Magnum trying to not use Barbican as it adds an addition dependency. See the discussion on the devel mailing list for details.
>
>Horizon discussions at the summit around wanting to use Zaqar for dynamic ui updates instead of polling, but couldn't depend on a non widely deployed subsystem.


Are the two points above a big tent issue?

We did have that problem before the big tent because distributions wouldn't
package projects that weren't integrated and OPs wouldn't deploy projects that
weren't integrated. I do not think that's true anymore.

In fact, projects like TripleO and Heat are already using Zaqar, despite the
fact it's not widely deployed. As Thomas mentioned in his reply to this email,
optional dependencies are the answer here. Re-inventing the wheel to avoid
adding a new dependency is the wrong approach but that's not an issue originated
by the big tent itself.



>Each Advanced OpenStack Service implementing a guest controller communication channel that are incompatible with each other and work around communications issues differently. This makes a lot more pain for Ops to debug or architect a viable solution. For example:
> * Sahara uses ssh from the controllers to the vms. This does not play well with tenant networks. They have tried to work around this several ways:
>    * require every vm to have a floating ip. (Unnecessary attack surface)
>    * require the controller to be on the one and only network node (Uses ip netns exec to tunnel. Doesn't work for large clouds)
>    * Double tunnel ssh via the controller vm's. so some vms have fips, some don't. Better then all, but still not good.
>  * Trove uses Rabbit for the guest agent to talk back to the controllers. This has traffic going the right direction to work well with tenant networks.
>    * But Rabbit is not multitenant so a security risk if any user can get into any one of the database vm's.
>Really, I believe the right solution is to use a multitenant aware message queue so that the guest agent can pull in the right direction for tenant networks, and not have the security risk. We have such a system already, Zaqar, but its not widely deployed and projects don't want to depend on other projects that aren't widely deployed.

I believe what you're describing above is not really related to how widely
deployed Zaqar is, but I might be being too naive here. Even if it were, though,
I still don't think that issue was caused by the big tent change. If anything,
the big tent change alleviated part of the issue.

>The lack of Instance Users has caused lots of projects to try and work around the lack thereof. I know for sure, Mangum, Heat, and Trove work around the lack. I'm positive others have too. As an operator, it makes me have to very carefully consider all the tradeoffs each project made, and decide if I can accept the same risk they assumed. Since each is different, thats much harder.
>

I'd really appreciate if you'd ellaborate on why this issue was caused by the
big tent.

>I'm sure there are more examples. but I hope you get I'm not just trying to troll.
>

I don't think you are but I'm lacking of some context that I get the feeling you
have. Hopefully I'm not being short-minded.

>The TC did apply inconsistant rules on letting projects in. That was for sure a negative before the big tent. But it also provided a way to apply pressure to projects to fix some of the issues that multiple projects face, and that plague user/operators and raise the whole community up, and that has fallen to the wayside since. Which is a big negative now. Maybe that could be bolted on top of the Big Tent I don't know.
>
>I could write a very long description about the state of being an OpenStack App developer too that touches on all the problems with getting a consistent target and all the cross project communication issues there of. But thats probably for some other time.

TBH, I'd be interested in such email but I'd beg you to keep it in a separate
thread as I don't think such email relates entirely to this one.

I believe the things you're describing are side-effects caused by the growth of
our community, which I consider a good thing. As Graham said in one of his
replies, we've not seen the end of the big tent yet and I believe there are
still good and bad things to come. How fast we'll adapt/react to those will
determine the success of the big tent.

I agree there are things that need to be changed or reflected on already and
your email, Graham's and Clynt's are a good example of the community
trying/willing to keep up with the changes.

Looking forward to your reply,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160718/aa55ef61/attachment.pgp>