Open Stack

On 21/04/15 14:08 +0000, Fox, Kevin M wrote:
>I think getting operators to adopt it is key to getting other openstack
>projects to also adopt it. There is something of a chicken and the egg problem
>with the integration. Some of the projects you will want to integrate the most
>with are already considered pretty stable and may not want to rewrite working
>bits to target a service thats hard for ops to deploy. It makes their service
>hard to deploy too.
>
>Getting into RDO and Ubuntu will go a long way there. Getting into Packstack
>and other deployment tools even further.

I don't fully agree with the above. The problem on waiting for
operators to adopt it is that they might actually not have a reason to
do it, which doesn't mean the project is useless. Each operator will
decide what services they want to provide.

Integrating with other projects will give a "good" reason for
operators to install it. It's actually kind of forcing them if the
projects end up depending on each other but I don't think that's wrong
if the integration is made for good reasons instead of simple
promotion.

These thread is mostly to ask those projects that we know have use
cases where zaqar would be a good fit to help us working on this
integration.

>One of the places that would be interesting to start trying and get integrated
>is Sahara to Sahara VM hooks. In my opinion, it currently has the wrong model
>of trying to contact the vm from the controller rather then have the vm contact
>a queue. This requires all sahara vms to be public (less secure, wastes ips) or
>only have one controller/network node to tunnel with(nonscalable). This would
>fix a problem ops are having with it, benifiting all parties.
>
>I mentioned oslo.messaging earlier since trove I think uses it for its
>controller/vm communication. If a very simple messaging driver could be
>written, it also could help you prove out your api with real use and trove
>could see why closer integration would be good? It wouldnt need all the
>messaging features. Just the features that make point to point controller to vm
>work?

Oslo.messaging has a different target that I currently don't think
Zaqar is good for. Therefore, the integration with services like
Trove, Sahara, etc. will have to be done manually. That is, using the
zaqarclient directly.

Cheers,
Flavio

>
>Thanks,
>Kevin
> 
>━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>From: Flavio Percoco
>Sent: Tuesday, April 21, 2015 12:56:27 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>
>On 20/04/15 13:39 -0700, Vipul Sabhaya wrote:
>>
>>
>>On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>>
>>    Another parallel is Manilla vs Swift. Both provides something like a share
>>    for users to store files.
>>
>>    The former is a multitenant api to provision non multitenant file shares.
>>    The latter is a multitenant api to provide file sharing.
>>
>>    Cue is a multitenant api to provision non multitenant queues.
>>    Zaqar is an api for a multitenant queueing system.
>>
>>    They are complimentary services.
>>
>>
>>
>>Agreed, it’s not an either/or, there is room for both.  While Cue could
>>provision Zaqar, it doesn’t make sense, since it is already multi-tenant.  As
>>has been said, Cue’s goal is to bring non-multi-tenant message brokers to the
>>cloud.
>>
>>On the question of adoption, what confuses me is why the measurement of
>success
>>of a project is whether other OpenStack services are integrating or not. 
>Zaqar
>>exposes an API that seems best fit for application workloads running on an
>>OpenStack cloud.  The question should be raised to operators as to what’s
>>preventing them from running Zaqar in their public cloud, distro, or whatever.
>>
>>Looking at other services that we consider to be successful, such as Trove, we
>>did not attempt to integrate with other OpenStack projects.  Rather, we solved
>>the concerns that operators had.
>
>FWIW, the team is not messuring the success of the project on whether
>it's integrated with other services or not. The adoption in all
>possible areas play key parts in every project's life. While it's
>amazing that RDO - and I believe Ubuntu is packaging too, Zigo,
>correct me, pls - has support for it, I don't think that's enough for
>the project to go anywhere.
>
>The use cases of this project, from a *provider* point of view are
>very specific - you either want to sell/use queues or you don't - and
>similar to SQS's. The fact that many folks miss is that SQS itself is
>being used *internally* in AWS for other things that I'm not going to
>get into. This is true not just for SQS, SNS but also for several
>other services they provide. Thankfully enough, we've folloed the same
>lead of using the things we've created. For instance, Trove uses nova
>for vms, Nova uses Cinder for block devices, etc, etc, etc.
>
>This needs to happen for Zaqar too. This will help the project mature
>with feedback from the "real world". This will give deployers enough
>confidence that the project is needed and it'll also drive some
>attention towards the project.
>
>Comparing Trove and Zaqar as services won't, ever, give a good result.
>They have different uses-cases, users base and types of APIs - data vs
>control. Not to mention they both went through different processes in
>very different periods of our community (Integrated/big tent, etc).
>
>Flavio
>
>
>>    Thanks,
>>    Kevin
>>    ________________________________________
>>    From: Ryan Brown [rybrown at redhat.com]
>>    Sent: Monday, April 20, 2015 11:38 AM
>>    To: openstack-dev at lists.openstack.org
>>    Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>>
>>    On 04/20/2015 02:22 PM, Michael Krotscheck wrote:
>>    > What's the difference between openstack/zaqar and stackforge/cue?
>>    > Looking at the projects, it seems like zaqar is a ground-up
>>    > implementation of a queueing system, while cue is a provisioning api for
>>    > queuing systems that could include zaqar, but could also include rabbit,
>>    > zmq, etc...
>>    >
>>    > If my understanding of the projects is correct, the latter is far more
>>    > versatile, and more in line with similar openstack approaches like
>>    > trove. Is there a use case nuance I'm not aware of that warrants
>>    > duplicating efforts? Because if not, one of the two should be retired
>>    > and development focused on the other.
>>    >
>>    > Note: I do not have a horse in this race. I just feel it's strange that
>>    > we're building a thing that can be provisioned by the other thing.
>>    >
>>
>>    Well, with Trove you can provision databases, but the MagnetoDB project
>>    still provides functionality that trove won't.
>>
>>
>>    The Trove : MagnetoDB and Cue : Zaqar comparison fits well.
>>
>>    Trove provisions one instance of X (some database) per tenant, where
>>    MagnetoDB is one "instance" (collection of hosts to do database things)
>>    that serves many tenants.
>>
>>    Cue's goal is "I have a not-very-multitenant message bus (rabbit, or
>>    whatever)" and makes that multitenant by provisioning one per tenant,
>>    while Zaqar has a single install (of as many machines as needed) to
>>    support messaging for all cloud tenants. This enables great stuff like
>>    cross-tenant messaging, better physical resource utilization in
>>    sparse-tenant cases, etc.
>>
>>    As someone who wants to adopt Zaqar, I'd really like to see it continue
>>    as a project because it provides things other message broker approaches
>>    don't.
>>
>>    --
>>    Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>>
>>    __________________________________________________________________________
>>    OpenStack Development Mailing List (not for usage questions)
>>    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>    __________________________________________________________________________
>>    OpenStack Development Mailing List (not for usage questions)
>>    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>--
>@flaper87
>Flavio Percoco

>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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