Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 27/04/15 10:44 -0700, Joe Gordon wrote:



On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter  wrote:

   On 24/04/15 20:00, Joe Gordon wrote:
  
  


   On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote:

       Notification might be a good way to integrate with nova. Individual
       tenants might want to do things as vm's come up/down, etc. Right
       now, you need a privileged pipe into rabbit. Forwarding them to
       Zaqar, per tenant queue's could solve the problem.


   Right now you can poll the nova API. Or tenants can use any number of
   monitoring tools.  How does zaqar better then the alternatives?
  


   So, a couple of points about that:

    1) Polling sucks.
    2) If a bunch of things are going to get polled, at least collect them
   together so there is *one* thing to optimise for massive polling load.
   (Zaqar is this thing - you have to poll it too atm.)
    3) Long-polling and WebSockets suck a lot less than polling. If you
   already collected all the polling in one place, it's really easy to make
   the switch as soon as you implement them in that one place.
    4) If you don't have a common place to poll, then you can't use the events
   as triggers for other services in OpenStack (without writing custom polling
   code for every endpoint in every API - which is pretty much what Heat does
   now, but that work doesn't extend automatically to Mistral, Congress, &c.
   in the way that Zaqar notifications could.)

   Also, APIs tend to only return the current status. You could miss events if
   you just poll the API, whereas if the events are dispatched to a durable
   queue and you just poll the queue for events, that problem goes away. 

  


   FWIW, I think there are some really neat use cases for amazon SQS, that
   presumably Zaqar would fit as well. Cases such as
   https://aws.amazon.com/articles/1464


   Bingo, this is where it starts to get really interesting.


Instead of asking the community to come up with reasons to integrate with
Zaqar, I think it would be more effective if the Zaqar team came up with one or
two use cases they want to support that require integration with other projects
and go from there. Turn this abstract call for adoption into a more narrow but
concrete proposal for X and Y to integrate with Zaqar to support a specific use
case. 


The Zaqar team has done this several times in these last 2 years. The
latest info that was collected is written here [0] and here [1]. These
use cases were discussed in the Kilo summit [2] and we reached an
agreement with people from other teams. Unfortunately, some priorities
changed and the integration didn't happen in Kilo.

This thread is more a call for action rather than a beg for adoption.
The team knows what the use cases are but we cannot force them into
projects if they are not willing to adopt it. With the very limited
resources we have, we need to be *very* careful on where our time is
spent. Therefore, we need to know what projects are indeed willing to
consume Zaqar so that we can help them with such efforts.

[0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
[1] https://etherpad.openstack.org/p/zaqar-overcloud-use-cases
[2] https://etherpad.openstack.org/p/kilo-zaqar-summit-integration-with-services

--
@flaper87
Flavio Percoco


pgpcUovyZvBMG.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Clint Byrum]

Excerpts from Joe Gordon's message of 2015-04-27 10:36:57 -0700:
> On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter  wrote:
> 
> > On 24/04/15 19:02, Joe Gordon wrote:
> >
> >>
> >>
> >> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  >> > wrote:
> >>
> >> Greetings,
> >>
> >> I'd like my first action as Zaqar's PTL to be based on reflections and
> >> transparency with regards to what our past has been, to what our
> >> present is and to what our future could be as a project and community.
> >> Therefore, I'm sending this call for adoption and support before
> >> taking other actions (also mentioned below).
> >>
> >> The summit is very close and the Zaqar team is looking forward to it.
> >>
> >> The upcoming summit represents an important opportunity for Zaqar to
> >> integrate with other projects. In the previous summits - since
> >>
> >>
> >> I get integration with Horizon etc. But to use the SQS/SNS analogy how
> >> would say Nova integrate with Zaqar?
> >>
> >
> > Speaking very generally, anything where it makes sense for Nova to tell
> > the user - or, more importantly, the application - when something is
> > happening. The cloud can't afford to be making synchronous calls to the
> > client-side, and applications may not be able to afford missing the
> > notifications, so a reliable, asynchronous transport like Zaqar is a good
> > candidate.
> >
> > So examples might be:
> >  - Hey, your resize is done
> >  - Hey, your [re]build is done
> >  - Hey, your VM rebooted
> >  - Hey, your VM disappeared
> >
> > Now, this is not to presuppose that having Nova put messages directly into
> > Zaqar is the correct design. It may be that it's better to have some other
> > service (Ceilometer?) collect some or all of those notifications and handle
> > putting them into Zaqar (though the reliability would be a concern).
> > Certainly EC2 seems to funnel all this stuff to CloudWatch, although other
> > services like S3, CloudFormation & Auto Scaling deliver notifications to
> > SNS directly. There is some integration work either way though, to produce
> > the notification.
> >
> > Obviously there's less integration to do for a project like Nova that only
> > produces notifications than there would be for those that could actually
> > consume notifications. Heat would certainly like to use these notifications
> > to reduce the amount of polling we do of the APIs (and ditch it altogether
> > if reliability is guaranteed). But if we can get both ends integrated then
> > the *user* can start doing really interesting things like:
> >
> 
> This is one of the bigger questions for me, as a nova developer. What would
> integration look like from Nova's POV.  I am a little weary of adding yet
> another API when we have so much trouble with our existing ones.
> Especially the notification based API.
> 

It seems to me like there's no need for Nova to do anything except keep
sending notifications. The service that is needed is the one that
exposes appropriate notifications to end-users, and it would have an API
which would work something like


POST /subscriptions
Auth-Things: go-here

{ "topic": "compute",
  "subject": [{"id": "12346566789"}],
  "destination": {"driver": "zaqar", "args": {"queue-id": "id-of-zaqar-inbox"}} 
}

Domain/Tenant is implied from auth details, and off to the races,
a filter is added and some notification-bus-aware workers receive the
fanout of notifications, passing applicable messages into the configured
driver. Drivers could be zaqar, or logstash, or SMTP inboxes, or whatever.
Point being, Nova wouldn't care, as long as its notifications can be
transformed into the output of a driver that the cloud operator has made
available. This would solve Heat's use case, and would probably be useful
for infra's nodepool if it were on the clouds we use since we could wait
for messages instead of polling the server list.

I've heard tell this might be something that could be built on top of,
or split out from, ceilometer, since it already sort of has to do this
to facilitate billing. Anyway, bottom line, if there aren't any users
willing to put resources into building it, then this has probably just
been a fun exercise in crystal ball gazing for now.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter  wrote:

> On 24/04/15 20:00, Joe Gordon wrote:
>
>>
>>
>> On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M > <mailto:kevin@pnnl.gov>> wrote:
>>
>> Notification might be a good way to integrate with nova. Individual
>> tenants might want to do things as vm's come up/down, etc. Right
>> now, you need a privileged pipe into rabbit. Forwarding them to
>> Zaqar, per tenant queue's could solve the problem.
>>
>>
>> Right now you can poll the nova API. Or tenants can use any number of
>> monitoring tools.  How does zaqar better then the alternatives?
>>
>
> So, a couple of points about that:
>
>  1) Polling sucks.
>  2) If a bunch of things are going to get polled, at least collect them
> together so there is *one* thing to optimise for massive polling load.
> (Zaqar is this thing - you have to poll it too atm.)
>  3) Long-polling and WebSockets suck a lot less than polling. If you
> already collected all the polling in one place, it's really easy to make
> the switch as soon as you implement them in that one place.
>  4) If you don't have a common place to poll, then you can't use the
> events as triggers for other services in OpenStack (without writing custom
> polling code for every endpoint in every API - which is pretty much what
> Heat does now, but that work doesn't extend automatically to Mistral,
> Congress, &c. in the way that Zaqar notifications could.)
>
> Also, APIs tend to only return the current status. You could miss events
> if you just poll the API, whereas if the events are dispatched to a durable
> queue and you just poll the queue for events, that problem goes away.


>
>  FWIW, I think there are some really neat use cases for amazon SQS, that
>> presumably Zaqar would fit as well. Cases such as
>> https://aws.amazon.com/articles/1464
>>
>
> Bingo, this is where it starts to get really interesting.
>

Instead of asking the community to come up with reasons to integrate with
Zaqar, I think it would be more effective if the Zaqar team came up with
one or two use cases they want to support that require integration with
other projects and go from there. Turn this abstract call for adoption into
a more narrow but concrete proposal for X and Y to integrate with Zaqar to
support a specific use case.


>
> cheers,
> Zane.
>
>
>> Thanks,
>> Kevin
>>
>> ------------
>> *From:* Joe Gordon [joe.gord...@gmail.com
>> <mailto:joe.gord...@gmail.com>]
>> *Sent:* Friday, April 24, 2015 4:02 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or
>> exclusion?)
>>
>>
>>
>> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco > <mailto:fla...@redhat.com>> wrote:
>>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on
>> reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and
>> community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward
>> to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar
>> to
>> integrate with other projects. In the previous summits - since
>>
>>
>> I get integration with Horizon etc. But to use the SQS/SNS analogy
>> how would say Nova integrate with Zaqar?
>>
>> Icehouse's - we've been collecting feedback from the community.
>> We've
>> worked on addressing the many use-cases, we've worked on
>> addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had
>> successes, as
>> a project and as a team. Nevertheless, we've got to the point
>> where it
>> doesn't make much sense to keep pushing new features to the
>> project
>> until it gains adoption. Therefore, I'd like to take ad

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter  wrote:

> On 24/04/15 19:02, Joe Gordon wrote:
>
>>
>>
>> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco > > wrote:
>>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar to
>> integrate with other projects. In the previous summits - since
>>
>>
>> I get integration with Horizon etc. But to use the SQS/SNS analogy how
>> would say Nova integrate with Zaqar?
>>
>
> Speaking very generally, anything where it makes sense for Nova to tell
> the user - or, more importantly, the application - when something is
> happening. The cloud can't afford to be making synchronous calls to the
> client-side, and applications may not be able to afford missing the
> notifications, so a reliable, asynchronous transport like Zaqar is a good
> candidate.
>
> So examples might be:
>  - Hey, your resize is done
>  - Hey, your [re]build is done
>  - Hey, your VM rebooted
>  - Hey, your VM disappeared
>
> Now, this is not to presuppose that having Nova put messages directly into
> Zaqar is the correct design. It may be that it's better to have some other
> service (Ceilometer?) collect some or all of those notifications and handle
> putting them into Zaqar (though the reliability would be a concern).
> Certainly EC2 seems to funnel all this stuff to CloudWatch, although other
> services like S3, CloudFormation & Auto Scaling deliver notifications to
> SNS directly. There is some integration work either way though, to produce
> the notification.
>
> Obviously there's less integration to do for a project like Nova that only
> produces notifications than there would be for those that could actually
> consume notifications. Heat would certainly like to use these notifications
> to reduce the amount of polling we do of the APIs (and ditch it altogether
> if reliability is guaranteed). But if we can get both ends integrated then
> the *user* can start doing really interesting things like:
>

This is one of the bigger questions for me, as a nova developer. What would
integration look like from Nova's POV.  I am a little weary of adding yet
another API when we have so much trouble with our existing ones.
Especially the notification based API.


>
>  - Hey Zaqar, give me a new queue/topic/whatever
>  - Hey Mistral, run this workflow when you see a message on this topic
>  - Hey Nova, send a message to this topic whenever my VM reboots
>
> Bam, user-defined workflow triggered on VM reboot. (Super easy to set up
> in a Heat template BTW ;)
>
> It gets even cooler when there are multiple producers and consumers:
> imagine that Ceilometer alarms and all other kinds of notifications in
> OpenStack are produced this way, and that SNS-style notifications, Heat
> autoscaling events and Mistral workflows can all be triggered by them. And
> of course if the logic available in the workflow isn't sufficient, the user
> can always insert their own conditioning logic running in a VM (future:
> container), since the flow is through a user-facing messaging system.
>
> I wrote a blog post earlier today about why all this is needed:
>
> http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack
>
> tl;dr: many applications being written now and even more in the future
> will expect to be able to interact with their own infrastructure and will
> go to proprietary clouds if we don't provide an open source alternative.
>
> cheers,
> Zane.
>
>  Icehouse's - we've been collecting feedback from the community. We've
>> worked on addressing the many use-cases, we've worked on addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had successes, as
>> a project and as a team. Nevertheless, we've got to the point where it
>> doesn't make much sense to keep pushing new features to the project
>> until it gains adoption. Therefore, I'd like to take advantage of the
>> workshop slots and invite people from other projects to help us/guide
>> us through a hacking session on their projects so we can help with the
>> adoption. The current adoption of Zaqar consist in:
>>
>> - 1 company reachingunning it in production
>> - 1 planning to do it soon
>> - RDO support
>>
>> Unfortunately, the above is certainly not enough for a project to
>> succeed and it makes the time a

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 24/04/15 09:32 +1200, Fei Long Wang wrote:



On 24/04/15 06:02, Richard Raseley wrote:

Flavio Percoco 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.


The needs of operators are a reflection of the needs of their users.

I don't want to use the word 'useless', because it has a clear
negative connotation - and I don't think Zaqar is 'useless'. Let's
instead discuss 'utility'.

The utility of any solution or product is completely subjective, and
solely based upon the underlying requirements. If real operators with
real requirements do not view a particular solution as having utility
for them - then it doesn't.

You are correct in that there is a bit of a bootstrapping problem, but
I strongly feel like the answer to that is continuing to listen to,
and test against, the market (the architects and operators).

Build a minimally viable product that (a) has clear messaging and use
cases (b) is easy to deploy and configure and (c) doesn't demand deep
integration into an existing cloud and operators will start deploying,
testing, and providing feedback. This will create the right feedback
cycle and help in validating (or completely demolishing) assumptions
on what users actually need.

With regard to '(b)' above, it doesn't appear that there any any
Puppet modules to assist with the installation and configuration of
Zaqar. If you're interested, let's chat in Vancouver to see if I can
help in get a basic set out there.


Awesome, thank you for the support. I believe the puppet work is one of
our goals in Liberty, so please pop in #openstack-zaqar and let's have a
talk.


I'm very interested in chatting in Vancouver. FWIW, we do have partial
support for puppet. It's partial because, well, it's not complete yet.
I started it with basically now knowledge of how puppet manifest's
work and Jason took it over and started contributing to it.
Unfortunately, it's not done yet.

https://github.com/jasontclark/puppet-zaqar

Thanks for the feedback,
Flavio


Regards,

Richard Raseley

SysOps Engineer
Puppet Labs

__

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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgpb4eZjytsQU.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Zane Bitter]

On 24/04/15 20:00, Joe Gordon wrote:



On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote:

Notification might be a good way to integrate with nova. Individual
tenants might want to do things as vm's come up/down, etc. Right
now, you need a privileged pipe into rabbit. Forwarding them to
Zaqar, per tenant queue's could solve the problem.


Right now you can poll the nova API. Or tenants can use any number of
monitoring tools.  How does zaqar better then the alternatives?


So, a couple of points about that:

 1) Polling sucks.
 2) If a bunch of things are going to get polled, at least collect them 
together so there is *one* thing to optimise for massive polling load. 
(Zaqar is this thing - you have to poll it too atm.)
 3) Long-polling and WebSockets suck a lot less than polling. If you 
already collected all the polling in one place, it's really easy to make 
the switch as soon as you implement them in that one place.
 4) If you don't have a common place to poll, then you can't use the 
events as triggers for other services in OpenStack (without writing 
custom polling code for every endpoint in every API - which is pretty 
much what Heat does now, but that work doesn't extend automatically to 
Mistral, Congress, &c. in the way that Zaqar notifications could.)


Also, APIs tend to only return the current status. You could miss events 
if you just poll the API, whereas if the events are dispatched to a 
durable queue and you just poll the queue for events, that problem goes 
away.



FWIW, I think there are some really neat use cases for amazon SQS, that
presumably Zaqar would fit as well. Cases such as
https://aws.amazon.com/articles/1464


Bingo, this is where it starts to get really interesting.

cheers,
Zane.



Thanks,
Kevin

*From:* Joe Gordon [joe.gord...@gmail.com
<mailto:joe.gord...@gmail.com>]
*Sent:* Friday, April 24, 2015 4:02 PM
*To:* OpenStack Development Mailing List (not for usage questions)
    *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco mailto:fla...@redhat.com>> wrote:

Greetings,

I'd like my first action as Zaqar's PTL to be based on
reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and
community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward
to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since


I get integration with Horizon etc. But to use the SQS/SNS analogy
how would say Nova integrate with Zaqar?

Icehouse's - we've been collecting feedback from the community.
We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had
successes, as
a project and as a team. Nevertheless, we've got to the point
where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage
of the
workshop slots and invite people from other projects to help
us/guide
us through a hacking session on their projects so we can help
with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the
project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises
of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thank

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Zane Bitter]

On 24/04/15 19:02, Joe Gordon wrote:



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco mailto:fla...@redhat.com>> wrote:

Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since


I get integration with Horizon etc. But to use the SQS/SNS analogy how
would say Nova integrate with Zaqar?


Speaking very generally, anything where it makes sense for Nova to tell 
the user - or, more importantly, the application - when something is 
happening. The cloud can't afford to be making synchronous calls to the 
client-side, and applications may not be able to afford missing the 
notifications, so a reliable, asynchronous transport like Zaqar is a 
good candidate.


So examples might be:
 - Hey, your resize is done
 - Hey, your [re]build is done
 - Hey, your VM rebooted
 - Hey, your VM disappeared

Now, this is not to presuppose that having Nova put messages directly 
into Zaqar is the correct design. It may be that it's better to have 
some other service (Ceilometer?) collect some or all of those 
notifications and handle putting them into Zaqar (though the reliability 
would be a concern). Certainly EC2 seems to funnel all this stuff to 
CloudWatch, although other services like S3, CloudFormation & Auto 
Scaling deliver notifications to SNS directly. There is some integration 
work either way though, to produce the notification.


Obviously there's less integration to do for a project like Nova that 
only produces notifications than there would be for those that could 
actually consume notifications. Heat would certainly like to use these 
notifications to reduce the amount of polling we do of the APIs (and 
ditch it altogether if reliability is guaranteed). But if we can get 
both ends integrated then the *user* can start doing really interesting 
things like:


 - Hey Zaqar, give me a new queue/topic/whatever
 - Hey Mistral, run this workflow when you see a message on this topic
 - Hey Nova, send a message to this topic whenever my VM reboots

Bam, user-defined workflow triggered on VM reboot. (Super easy to set up 
in a Heat template BTW ;)


It gets even cooler when there are multiple producers and consumers: 
imagine that Ceilometer alarms and all other kinds of notifications in 
OpenStack are produced this way, and that SNS-style notifications, Heat 
autoscaling events and Mistral workflows can all be triggered by them. 
And of course if the logic available in the workflow isn't sufficient, 
the user can always insert their own conditioning logic running in a VM 
(future: container), since the flow is through a user-facing messaging 
system.


I wrote a blog post earlier today about why all this is needed:

http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack

tl;dr: many applications being written now and even more in the future 
will expect to be able to interact with their own infrastructure and 
will go to proprietary clouds if we don't provide an open source 
alternative.


cheers,
Zane.


Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
or

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M  wrote:

>  Notification might be a good way to integrate with nova. Individual
> tenants might want to do things as vm's come up/down, etc. Right now, you
> need a privileged pipe into rabbit. Forwarding them to Zaqar, per tenant
> queue's could solve the problem.
>
>
Right now you can poll the nova API. Or tenants can use any number of
monitoring tools.  How does zaqar better then the alternatives?


FWIW, I think there are some really neat use cases for amazon SQS, that
presumably Zaqar would fit as well. Cases such as
https://aws.amazon.com/articles/1464



> Thanks,
> Kevin
>  --
> *From:* Joe Gordon [joe.gord...@gmail.com]
> *Sent:* Friday, April 24, 2015 4:02 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>
>
>
> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  wrote:
>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar to
>> integrate with other projects. In the previous summits - since
>>
>
>  I get integration with Horizon etc. But to use the SQS/SNS analogy how
> would say Nova integrate with Zaqar?
>
>
>> Icehouse's - we've been collecting feedback from the community. We've
>> worked on addressing the many use-cases, we've worked on addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had successes, as
>> a project and as a team. Nevertheless, we've got to the point where it
>> doesn't make much sense to keep pushing new features to the project
>> until it gains adoption. Therefore, I'd like to take advantage of the
>> workshop slots and invite people from other projects to help us/guide
>> us through a hacking session on their projects so we can help with the
>> adoption. The current adoption of Zaqar consist in:
>>
>> - 1 company reachingunning it in production
>> - 1 planning to do it soon
>> - RDO support
>>
>> Unfortunately, the above is certainly not enough for a project to
>> succeed and it makes the time and effort spent on the project not
>> worth it. It's been more than 2 years since we kicked the project off
>> and it's time for it to show some results. The current problem seems
>> to be that many people want the project but no one wants to be the
>> first in adopting Zaqar (which kind of invalidates the premises of the
>> "Big tent").
>>
>> In summary, this is a call for adoption before we call it a nice
>> adventure and ask for the project to be excluded from the OpenStack
>> organization based on the lack of adoption and contributions.
>>
>> If you think it's worth it, speak up. Either way, thanks for the
>> support and for reading thus far.
>>
>> On behalf of the Zaqar team,
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

Notification might be a good way to integrate with nova. Individual tenants 
might want to do things as vm's come up/down, etc. Right now, you need a 
privileged pipe into rabbit. Forwarding them to Zaqar, per tenant queue's could 
solve the problem.

Thanks,
Kevin

From: Joe Gordon [joe.gord...@gmail.com]
Sent: Friday, April 24, 2015 4:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco 
mailto:fla...@redhat.com>> wrote:
Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since

I get integration with Horizon etc. But to use the SQS/SNS analogy how would 
say Nova integrate with Zaqar?

Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  wrote:

> Greetings,
>
> I'd like my first action as Zaqar's PTL to be based on reflections and
> transparency with regards to what our past has been, to what our
> present is and to what our future could be as a project and community.
> Therefore, I'm sending this call for adoption and support before
> taking other actions (also mentioned below).
>
> The summit is very close and the Zaqar team is looking forward to it.
>
> The upcoming summit represents an important opportunity for Zaqar to
> integrate with other projects. In the previous summits - since
>

I get integration with Horizon etc. But to use the SQS/SNS analogy how
would say Nova integrate with Zaqar?


> Icehouse's - we've been collecting feedback from the community. We've
> worked on addressing the many use-cases, we've worked on addressing
> the concerns raised by the community and we've also kept moving
> towards reaching the project's goals.
>
> As you all know, the project has gone through many ups and downs.
> We've had some "failures" in the past and we've also had successes, as
> a project and as a team. Nevertheless, we've got to the point where it
> doesn't make much sense to keep pushing new features to the project
> until it gains adoption. Therefore, I'd like to take advantage of the
> workshop slots and invite people from other projects to help us/guide
> us through a hacking session on their projects so we can help with the
> adoption. The current adoption of Zaqar consist in:
>
> - 1 company reachingunning it in production
> - 1 planning to do it soon
> - RDO support
>
> Unfortunately, the above is certainly not enough for a project to
> succeed and it makes the time and effort spent on the project not
> worth it. It's been more than 2 years since we kicked the project off
> and it's time for it to show some results. The current problem seems
> to be that many people want the project but no one wants to be the
> first in adopting Zaqar (which kind of invalidates the premises of the
> "Big tent").
>
> In summary, this is a call for adoption before we call it a nice
> adventure and ask for the project to be excluded from the OpenStack
> organization based on the lack of adoption and contributions.
>
> If you think it's worth it, speak up. Either way, thanks for the
> support and for reading thus far.
>
> On behalf of the Zaqar team,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fei Long Wang]

On 24/04/15 06:02, Richard Raseley wrote:
> Flavio Percoco 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.
>
> The needs of operators are a reflection of the needs of their users.
>
> I don't want to use the word 'useless', because it has a clear
> negative connotation - and I don't think Zaqar is 'useless'. Let's
> instead discuss 'utility'.
>
> The utility of any solution or product is completely subjective, and
> solely based upon the underlying requirements. If real operators with
> real requirements do not view a particular solution as having utility
> for them - then it doesn't.
>
> You are correct in that there is a bit of a bootstrapping problem, but
> I strongly feel like the answer to that is continuing to listen to,
> and test against, the market (the architects and operators).
>
> Build a minimally viable product that (a) has clear messaging and use
> cases (b) is easy to deploy and configure and (c) doesn't demand deep
> integration into an existing cloud and operators will start deploying,
> testing, and providing feedback. This will create the right feedback
> cycle and help in validating (or completely demolishing) assumptions
> on what users actually need.
>
> With regard to '(b)' above, it doesn't appear that there any any
> Puppet modules to assist with the installation and configuration of
> Zaqar. If you're interested, let's chat in Vancouver to see if I can
> help in get a basic set out there.
>
Awesome, thank you for the support. I believe the puppet work is one of
our goals in Liberty, so please pop in #openstack-zaqar and let's have a
talk.
> Regards,
>
> Richard Raseley
>
> SysOps Engineer
> Puppet Labs
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Richard Raseley]

Flavio Percoco 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.


The needs of operators are a reflection of the needs of their users.

I don't want to use the word 'useless', because it has a clear negative 
connotation - and I don't think Zaqar is 'useless'. Let's instead 
discuss 'utility'.


The utility of any solution or product is completely subjective, and 
solely based upon the underlying requirements. If real operators with 
real requirements do not view a particular solution as having utility 
for them - then it doesn't.


You are correct in that there is a bit of a bootstrapping problem, but I 
strongly feel like the answer to that is continuing to listen to, and 
test against, the market (the architects and operators).


Build a minimally viable product that (a) has clear messaging and use 
cases (b) is easy to deploy and configure and (c) doesn't demand deep 
integration into an existing cloud and operators will start deploying, 
testing, and providing feedback. This will create the right feedback 
cycle and help in validating (or completely demolishing) assumptions on 
what users actually need.


With regard to '(b)' above, it doesn't appear that there any any Puppet 
modules to assist with the installation and configuration of Zaqar. If 
you're interested, let's chat in Vancouver to see if I can help in get a 
basic set out there.


Regards,

Richard Raseley

SysOps Engineer
Puppet Labs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 21/04/15 14:08 +, 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  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 he

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Steve Baker]

On 22/04/15 06:58, Tim Bell wrote:

This touches on many of the aspects of the Ops tagging to be discussed in
Vancouver.

What are the criteria for

- An operator to consider a PoC for a new function ? We look for RDO
packaging, Puppet configuration and ops/end user documentation.
- An operator offering function to their end users in test (I.e. This
works well enough to see if there is an end user benefit to justify the
operations cost) ?
- An operator to offer this in production (I.e. The operator deploys the
code and makes it available to the end users) ? This implies scaling,
upgradability, etc. and commits to a sustainable roadmap (with the
community)

I really appreciate the reflections going on here since the worst case
scenario for us is that the end users of the cloud become dependent on a
component and finding that the community is not self sustaining.

Tagging allows the operator to make an informed decision given their user
community and assess the risk vs benefit.

Agreed, and I've just proposed a cross-project track session to discuss 
how user-facing projects like OpenStackClient, Horizon and Heat can 
define and assign tags for the services they support.





On 4/21/15, 2:51 PM, "Ryan Brown"  wrote:


On 04/20/2015 07:12 PM, Steve Baker wrote:

On 21/04/15 11:01, Angus Salkeld wrote:


On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote:

 As an Op, a few things that come to mind in that category are:
  * RDO packaging (stated earlier). If its not easy to install, its
 not going to be deployed as much. I haven't installed it yet,
 because I haven't had time to do much other then yum install it...
  * Horizon UI
  * Heat Resources. (Some basic stuff like create/delete queue to
 go along with the stack. also link #1 below)


Here you go:
https://github.com/openstack/heat/tree/master/contrib/heat_zaqar

One thing we need to do in Vancouver is come up with criteria for moving
resources from contrib into the main tree. Previously this was whether
the project was integrated. As a starter I would suggest something like:
1. project is in the openstack git namespace
2. the client library is synced with global-requirements.txt
3. the resources are complete enough to be useful in template authoring
We need to think about potential for integration testing in the gate
too.

I think scenario/functional tests should be table stakes to graduate a
resource from contrib/ .

  


 Horizon has a discovery aspect to it. If users don't know a
 service is available, its hard for them to use it. Even with the
 most simple UI of Create/Delete/List queues, discovery is handled.

Absolutely agreed. Especially in a service like Zaqar where the vast
majority of usage isn't by humans in a web interface, the horizon bit
becomes mostly a dashboard/auditing/testing destination instead of a
primary interface.


[snip]

--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Tim Bell]

This touches on many of the aspects of the Ops tagging to be discussed in
Vancouver.

What are the criteria for

- An operator to consider a PoC for a new function ? We look for RDO
packaging, Puppet configuration and ops/end user documentation.
- An operator offering function to their end users in test (I.e. This
works well enough to see if there is an end user benefit to justify the
operations cost) ?
- An operator to offer this in production (I.e. The operator deploys the
code and makes it available to the end users) ? This implies scaling,
upgradability, etc. and commits to a sustainable roadmap (with the
community)

I really appreciate the reflections going on here since the worst case
scenario for us is that the end users of the cloud become dependent on a
component and finding that the community is not self sustaining.

Tagging allows the operator to make an informed decision given their user
community and assess the risk vs benefit.

Tim


On 4/21/15, 2:51 PM, "Ryan Brown"  wrote:

>On 04/20/2015 07:12 PM, Steve Baker wrote:
>> On 21/04/15 11:01, Angus Salkeld wrote:
>>>
>>>
>>> On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M >> > wrote:
>>>
>>> As an Op, a few things that come to mind in that category are:
>>>  * RDO packaging (stated earlier). If its not easy to install, its
>>> not going to be deployed as much. I haven't installed it yet,
>>> because I haven't had time to do much other then yum install it...
>>>  * Horizon UI
>>>  * Heat Resources. (Some basic stuff like create/delete queue to
>>> go along with the stack. also link #1 below)
>>>
>>>
>>> Here you go:
>>> https://github.com/openstack/heat/tree/master/contrib/heat_zaqar
>> One thing we need to do in Vancouver is come up with criteria for moving
>> resources from contrib into the main tree. Previously this was whether
>> the project was integrated. As a starter I would suggest something like:
>> 1. project is in the openstack git namespace
>> 2. the client library is synced with global-requirements.txt
>> 3. the resources are complete enough to be useful in template authoring
>> We need to think about potential for integration testing in the gate
>>too.
>
>I think scenario/functional tests should be table stakes to graduate a
>resource from contrib/ .
>
>>>  
>>>
>>> Horizon has a discovery aspect to it. If users don't know a
>>> service is available, its hard for them to use it. Even with the
>>> most simple UI of Create/Delete/List queues, discovery is handled.
>
>Absolutely agreed. Especially in a service like Zaqar where the vast
>majority of usage isn't by humans in a web interface, the horizon bit
>becomes mostly a dashboard/auditing/testing destination instead of a
>primary interface.
>
>>> [snip]
>
>-- 
>Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

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.

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?

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  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 [rybr...@redhat.com]
>Sent: Monday, April 20, 2015 11:38 AM
>To: openstack-dev@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 open

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 21/04/15 08:51 -0400, Ryan Brown wrote:

On 04/20/2015 07:12 PM, Steve Baker wrote:
Absolutely agreed. Especially in a service like Zaqar where the vast
majority of usage isn't by humans in a web interface, the horizon bit
becomes mostly a dashboard/auditing/testing destination instead of a
primary interface.


The above sounds correct to me for most of the cases. However, I can
see horizon being used to configured notifications/subscriptions.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpotm7AjKs5M.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Ryan Brown]

On 04/20/2015 07:12 PM, Steve Baker wrote:
> On 21/04/15 11:01, Angus Salkeld wrote:
>>
>>
>> On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M > > wrote:
>>
>> As an Op, a few things that come to mind in that category are:
>>  * RDO packaging (stated earlier). If its not easy to install, its
>> not going to be deployed as much. I haven't installed it yet,
>> because I haven't had time to do much other then yum install it...
>>  * Horizon UI
>>  * Heat Resources. (Some basic stuff like create/delete queue to
>> go along with the stack. also link #1 below)
>>
>>
>> Here you go:
>> https://github.com/openstack/heat/tree/master/contrib/heat_zaqar
> One thing we need to do in Vancouver is come up with criteria for moving
> resources from contrib into the main tree. Previously this was whether
> the project was integrated. As a starter I would suggest something like:
> 1. project is in the openstack git namespace
> 2. the client library is synced with global-requirements.txt
> 3. the resources are complete enough to be useful in template authoring
> We need to think about potential for integration testing in the gate too.

I think scenario/functional tests should be table stakes to graduate a
resource from contrib/ .

>>  
>>
>> Horizon has a discovery aspect to it. If users don't know a
>> service is available, its hard for them to use it. Even with the
>> most simple UI of Create/Delete/List queues, discovery is handled.

Absolutely agreed. Especially in a service like Zaqar where the vast
majority of usage isn't by humans in a web interface, the horizon bit
becomes mostly a dashboard/auditing/testing destination instead of a
primary interface.

>> [snip]

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Thomas Goirand]

On 04/21/2015 09:56 AM, Flavio Percoco wrote:

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.


As per this:
http://packages.ubuntu.com/search?keywords=zaqar&searchon=names&suite=all§ion=all

Ubuntu doesn't have it. I haven't worked on it (yet), though if you are 
saying it's ready, I may give it a try.


Thomas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 20/04/15 13:39 -0700, Vipul Sabhaya wrote:



On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M  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 [rybr...@redhat.com]
   Sent: Monday, April 20, 2015 11:38 AM
   To: openstack-dev@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 Bro

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Steve Baker]

On 21/04/15 11:01, Angus Salkeld wrote:



On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M <mailto:kevin@pnnl.gov>> wrote:


As an Op, a few things that come to mind in that category are:
 * RDO packaging (stated earlier). If its not easy to install, its
not going to be deployed as much. I haven't installed it yet,
because I haven't had time to do much other then yum install it...
 * Horizon UI
 * Heat Resources. (Some basic stuff like create/delete queue to
go along with the stack. also link #1 below)


Here you go:
https://github.com/openstack/heat/tree/master/contrib/heat_zaqar
One thing we need to do in Vancouver is come up with criteria for moving 
resources from contrib into the main tree. Previously this was whether 
the project was integrated. As a starter I would suggest something like:

1. project is in the openstack git namespace
2. the client library is synced with global-requirements.txt
3. the resources are complete enough to be useful in template authoring

We need to think about potential for integration testing in the gate too.


Horizon has a discovery aspect to it. If users don't know a
service is available, its hard for them to use it. Even with the
most simple UI of Create/Delete/List queues, discovery is handled.
The user knows it exists, and can look for documentation on how to
make it work, can ask an admin how to use it, or start poking at
the cli for advanced features.

Thanks,
Kevin

1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar

*From:* Vipul Sabhaya [vip...@gmail.com <mailto:vip...@gmail.com>]
*Sent:* Monday, April 20, 2015 1:39 PM
*To:* OpenStack Development Mailing List (not for usage questions)

    *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or
exclusion?)



On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M mailto:kevin@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.

Thanks,
Kevin

From: Ryan Brown [rybr...@redhat.com <mailto:rybr...@redhat.com>]
Sent: Monday, April 20, 2015 11:38 AM
To: openstack-dev@lists.openstack.org
<mailto:openstack-dev@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 : 

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Angus Salkeld]

On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M  wrote:

>  As an Op, a few things that come to mind in that category are:
>  * RDO packaging (stated earlier). If its not easy to install, its not
> going to be deployed as much. I haven't installed it yet, because I haven't
> had time to do much other then yum install it...
>  * Horizon UI
>  * Heat Resources. (Some basic stuff like create/delete queue to go along
> with the stack. also link #1 below)
>
>
Here you go:
https://github.com/openstack/heat/tree/master/contrib/heat_zaqar



> Horizon has a discovery aspect to it. If users don't know a service is
> available, its hard for them to use it. Even with the most simple UI of
> Create/Delete/List queues, discovery is handled. The user knows it exists,
> and can look for documentation on how to make it work, can ask an admin how
> to use it, or start poking at the cli for advanced features.
>
> Thanks,
> Kevin
>
> 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar
>  --
> *From:* Vipul Sabhaya [vip...@gmail.com]
> *Sent:* Monday, April 20, 2015 1:39 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>
>
>
> On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M  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.
>
>
>
>> Thanks,
>> Kevin
>> 
>> From: Ryan Brown [rybr...@redhat.com]
>> Sent: Monday, April 20, 2015 11:38 AM
>> To: openstack-dev@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 

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fei Long Wang]

Thanks Kevin, all good suggestions. Re Horizon UI, yes, we even have a
blueprint to track that, but seems the owner didn't complete it. FWIW, I
would suggest to put it on the todo list of L.

[1] https://blueprints.launchpad.net/zaqar/+spec/marconi-horizon-integration

On 21/04/15 10:38, Fox, Kevin M wrote:
> As an Op, a few things that come to mind in that category are:
>  * RDO packaging (stated earlier). If its not easy to install, its not
> going to be deployed as much. I haven't installed it yet, because I
> haven't had time to do much other then yum install it...
>  * Horizon UI
>  * Heat Resources. (Some basic stuff like create/delete queue to go
> along with the stack. also link #1 below)
>
> Horizon has a discovery aspect to it. If users don't know a service is
> available, its hard for them to use it. Even with the most simple UI
> of Create/Delete/List queues, discovery is handled. The user knows it
> exists, and can look for documentation on how to make it work, can ask
> an admin how to use it, or start poking at the cli for advanced features.
>
> Thanks,
> Kevin
>
> 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar
> 
> *From:* Vipul Sabhaya [vip...@gmail.com]
> *Sent:* Monday, April 20, 2015 1:39 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>
>
>
> On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M  <mailto:kevin@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.
>
>  
>
> Thanks,
> Kevin
> 
> From: Ryan Brown [rybr...@redhat.com <mailto:rybr...@redhat.com>]
> Sent: Monday, April 20, 2015 11:38 AM
> To: openstack-dev@lists.openstack.org
> <mailto:openstack-dev@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&#

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

As an Op, a few things that come to mind in that category are:
 * RDO packaging (stated earlier). If its not easy to install, its not going to 
be deployed as much. I haven't installed it yet, because I haven't had time to 
do much other then yum install it...
 * Horizon UI
 * Heat Resources. (Some basic stuff like create/delete queue to go along with 
the stack. also link #1 below)

Horizon has a discovery aspect to it. If users don't know a service is 
available, its hard for them to use it. Even with the most simple UI of 
Create/Delete/List queues, discovery is handled. The user knows it exists, and 
can look for documentation on how to make it work, can ask an admin how to use 
it, or start poking at the cli for advanced features.

Thanks,
Kevin

1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar

From: Vipul Sabhaya [vip...@gmail.com]
Sent: Monday, April 20, 2015 1:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)



On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M 
mailto:kevin@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.


Thanks,
Kevin

From: Ryan Brown [rybr...@redhat.com<mailto:rybr...@redhat.com>]
Sent: Monday, April 20, 2015 11:38 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Vipul Sabhaya]

On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M  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.



> Thanks,
> Kevin
> 
> From: Ryan Brown [rybr...@redhat.com]
> Sent: Monday, April 20, 2015 11:38 AM
> To: openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Michael Krotscheck]

That's what I needed to know, thanks :)

Michael

On Mon, Apr 20, 2015 at 12:11 PM Fox, Kevin M  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.
>
> Thanks,
> Kevin
> 
> From: Ryan Brown [rybr...@redhat.com]
> Sent: Monday, April 20, 2015 11:38 AM
> To: openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

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.

Thanks,
Kevin

From: Ryan Brown [rybr...@redhat.com]
Sent: Monday, April 20, 2015 11:38 AM
To: openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Ryan Brown]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Michael Krotscheck]

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.

Michael

On Mon, Apr 20, 2015 at 6:00 AM Flavio Percoco  wrote:

> Greetings,
>
> I'd like my first action as Zaqar's PTL to be based on reflections and
> transparency with regards to what our past has been, to what our
> present is and to what our future could be as a project and community.
> Therefore, I'm sending this call for adoption and support before
> taking other actions (also mentioned below).
>
> The summit is very close and the Zaqar team is looking forward to it.
>
> The upcoming summit represents an important opportunity for Zaqar to
> integrate with other projects. In the previous summits - since
> Icehouse's - we've been collecting feedback from the community. We've
> worked on addressing the many use-cases, we've worked on addressing
> the concerns raised by the community and we've also kept moving
> towards reaching the project's goals.
>
> As you all know, the project has gone through many ups and downs.
> We've had some "failures" in the past and we've also had successes, as
> a project and as a team. Nevertheless, we've got to the point where it
> doesn't make much sense to keep pushing new features to the project
> until it gains adoption. Therefore, I'd like to take advantage of the
> workshop slots and invite people from other projects to help us/guide
> us through a hacking session on their projects so we can help with the
> adoption. The current adoption of Zaqar consist in:
>
> - 1 company reachingunning it in production
> - 1 planning to do it soon
> - RDO support
>
> Unfortunately, the above is certainly not enough for a project to
> succeed and it makes the time and effort spent on the project not
> worth it. It's been more than 2 years since we kicked the project off
> and it's time for it to show some results. The current problem seems
> to be that many people want the project but no one wants to be the
> first in adopting Zaqar (which kind of invalidates the premises of the
> "Big tent").
>
> In summary, this is a call for adoption before we call it a nice
> adventure and ask for the project to be excluded from the OpenStack
> organization based on the lack of adoption and contributions.
>
> If you think it's worth it, speak up. Either way, thanks for the
> support and for reading thus far.
>
> On behalf of the Zaqar team,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 20/04/15 14:08 +, Fox, Kevin M wrote:

RDO packaging would go a long way for us.

Also what about oslo support? We have a second rabbit for sahara/trove/
designate for reasons I wont get into here on one cloud that could just be made
to use Zaqar instead?


This is exactly the kind of adoption we're looking forward to. I
don't think there'll be support for Zaqar in oslo.messaging - they simply have
different goals - but Zaqar would be a good fit for the use-cases that
sahara, trove and designate have (I believe we're talking about agents
communication).

This call, however, belongs to the project's owners and maintainers.
Since I believe Zaqar is a good project for OpenStack and I know there
are folks - like yourself - that believe so too, I'm raising this warn
so that people know what might happen to the project if it doesn't get
some help from "the inner-outside world"


I do believe Zaqar is very important. Its been a long bumpy road, but you folks
are doing a great job. Dont loose heart.


Thanks :)
Flavio



Thanks,
Kevin

━━━
From: Flavio Percoco
Sent: Monday, April 20, 2015 5:54:54 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since
Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


pgpX5xn_xP3JP.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Anita Kuno]

On 04/20/2015 08:54 AM, Flavio Percoco wrote:
> Greetings,
> 
> I'd like my first action as Zaqar's PTL to be based on reflections
> and transparency with regards to what our past has been, to what
> our present is and to what our future could be as a project and
> community. Therefore, I'm sending this call for adoption and
> support before taking other actions (also mentioned below).
> 
> The summit is very close and the Zaqar team is looking forward to
> it.
> 
> The upcoming summit represents an important opportunity for Zaqar
> to integrate with other projects. In the previous summits - since 
> Icehouse's - we've been collecting feedback from the community.
> We've worked on addressing the many use-cases, we've worked on
> addressing the concerns raised by the community and we've also kept
> moving towards reaching the project's goals.
> 
> As you all know, the project has gone through many ups and downs. 
> We've had some "failures" in the past and we've also had successes,
> as a project and as a team. Nevertheless, we've got to the point
> where it doesn't make much sense to keep pushing new features to
> the project until it gains adoption. Therefore, I'd like to take
> advantage of the workshop slots and invite people from other
> projects to help us/guide us through a hacking session on their
> projects so we can help with the adoption. The current adoption of
> Zaqar consist in:
> 
> - 1 company reachingunning it in production - 1 planning to do it
> soon - RDO support
> 
> Unfortunately, the above is certainly not enough for a project to 
> succeed and it makes the time and effort spent on the project not 
> worth it. It's been more than 2 years since we kicked the project
> off and it's time for it to show some results. The current problem
> seems to be that many people want the project but no one wants to
> be the first in adopting Zaqar (which kind of invalidates the
> premises of the "Big tent").
> 
> In summary, this is a call for adoption before we call it a nice 
> adventure and ask for the project to be excluded from the
> OpenStack organization based on the lack of adoption and
> contributions.
> 
> If you think it's worth it, speak up. Either way, thanks for the 
> support and for reading thus far.
> 
> On behalf of the Zaqar team, Flavio
> 
> 
> 
> __
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Thank you for the honesty, here Flavio, I certainly appreciate it.

One of the challenges we all currently face is relevance to our
mission. I think many developers continue to work diligently in that
regard on Zaqar but results need a combination of things, hard work
and dedication are only part of that.

I am heartened by your courage in taking an honest look at the status
of your project and asking for support in understanding its place in
the overall picture. Regardless of the outcome I hope you and your
fellow developers recognize how much that speaks of your character.

I hope you get some honest answers to your question, in turn.

Thanks Flavio,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

RDO packaging would go a long way for us.

Also what about oslo support? We have a second rabbit for 
sahara/trove/designate for reasons I wont get into here on one cloud that could 
just be made to use Zaqar instead?

I do believe Zaqar is very important. Its been a long bumpy road, but you folks 
are doing a great job. Dont loose heart.

Thanks,
Kevin


From: Flavio Percoco
Sent: Monday, April 20, 2015 5:54:54 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since
Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since
Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco


pgpYJfTYIMlv6.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev