settingsLogin | Registersettings

[openstack-dev] meeting with the zaqar team at summit; my notes

0 votes

I'm posting this to the mailing list to summarize my notes from a meeting at 5pm yesterday at Summit relative to Zaqar and lightweight multi-tenant messaging and how it may be applicable to a number of projects.

I'll begin by saying these are not 'minutes' of a meeting, merely my notes and observations after the meeting and how they relate specifically to Trove. I don't claim to speak for Trove, other contributors to Trove, other projects who were at the meeting, for zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what Zaqar is but I am still not entirely sure. As best as I can tell, it is a lightweight, keystone authenticated, multi-tenant messaging system. I am still a little troubled that of the many people in the room who were knowledgeable of zaqar, there appeared to be some disagreement on how best to describe or explain the project.

I learned that users of zaqar can authenticate with keystone and then interact with zaqar, and pass messages using it. I learned also that zaqar is spelt with a 'q' that is not followed by a 'u'. i.e. it isn't zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on an existing AMQP service, rather zaqar is a "from the ground up" implementation. This scares me (a lot).

I gather there is currently no oslo.messaging integration with zaqar; for Trove to use zaqar we would have to either (a) abandon oslo.messaging and use zaqar, or (b) build in smarts within Trove to determine at run time whether we are using zaqar or o.m and implement code in Trove to handle the differences between them if any.

It wasn't clear to me after the meeting what differences there may be with Trove; one which was alluded to was the inability to do a synchronous (call()) style message and the statement was that this was something that "could be built into a driver".

It wasn't clear to me what scale zaqar has been run at and whether anyone has in fact deployed and run zaqar at scale, and whether it has been battle hardened the way a service like RabbitMQ has. While I hear from many that RabbitMQ is a nightmare to scale and manage, I realize that it does in fact have a long history of deployments at scale.

We discussed some of the assumptions being made in the conversation relative to the security of the various parties to the communication on the existing rabbit message queue and at the conclusion of the meeting I believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging driver and an easier path to integration by client projects like Trove. The rip-and-replace option put a certain damper on the enthusiasm

(b)Even with an o.m integration, the incremental benefits that zaqar brought were diminished by the fact that one would still have to operate an AMQP (RabbitMQ) service for the rest of the infrastructure message passing needs unless and until all projects decide to abandon RabbitMQ in favor of zaqar

(c)At this time it is likely that there is no net benefit to a project like Trove in integrating with zaqar given that the upside is likely limited, the downside(s) that we know of are significant, and there is a significant unknown risk.

My thanks to the folks from zaqar for having the session, I certainly learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a 'minutes of the meeting', merely my notes from the meeting.

Thanks,

-amrith


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 22, 2015 in openstack-dev by Amrith_Kumar (10,500 points)   2 4 4

8 Responses

0 votes

On Fri, May 22, 2015 at 8:48 AM, Amrith Kumar amrith@tesora.com wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my notes
and observations after the meeting and how they relate specifically to
Trove. I don’t claim to speak for Trove, other contributors to Trove, other
projects who were at the meeting, for zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is a
lightweight, keystone authenticated, multi-tenant messaging system. I am
still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how best
to describe or explain the project.

If we cannot agree on how to explain zaqar, how can projects even think
about adopting it?

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that zaqar
is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t zaquar as
I had thought it was.

It became clear that the underlying transport in zaqar is not based on an
existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

I gather there is currently no oslo.messaging integration with zaqar; for
Trove to use zaqar we would have to either (a) abandon oslo.messaging and
use zaqar, or (b) build in smarts within Trove to determine at run time
whether we are using zaqar or o.m and implement code in Trove to handle the
differences between them if any.

It wasn’t clear to me after the meeting what differences there may be with
Trove; one which was alluded to was the inability to do a synchronous
(call()) style message and the statement was that this was something that
“could be built into a driver”.

It wasn’t clear to me what scale zaqar has been run at and whether anyone
has in fact deployed and run zaqar at scale, and whether it has been battle
hardened the way a service like RabbitMQ has. While I hear from many that
RabbitMQ is a nightmare to scale and manage, I realize that it does in fact
have a long history of deployments at scale.

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on the
existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging driver
and an easier path to integration by client projects like Trove. The
rip-and-replace option put a certain damper on the enthusiasm

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate an
AMQP (RabbitMQ) service for the rest of the infrastructure message passing
needs unless and until all projects decide to abandon RabbitMQ in favor of
zaqar

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 22, 2015 by Joe_Gordon (24,620 points)   2 5 8
0 votes

On 22/05/15 11:48, Amrith Kumar wrote:
I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database
and the Trove agent as within its own security perimeter. (Whether
that's appropriate is another debate, but it's up to the Trove
contributors to decide.) In this case, the ability to authenticate to
the queue using Keystone provides no real value, so this isn't really a
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user. That's
the kind of thing that needs to be replaced by a multi-tenant service.
The session was organised because it was assumed that Trove is in the
same boat, but it appears that Trove developers don't consider that it is.

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of the
security boundary is reconsidered.

cheers,
Zane.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 22, 2015 by Zane_Bitter (21,640 points)   4 6 9
0 votes

I believe that trove still needs the multi tenant isolation of a multi tenant message queue due to the fact that the vm runs in the tenant, and the tenant can then force a reboot, go to the console, root it, and inject messages at queues destened for other tenants vm's. And there are other routes too.

This is a major problem, and I think our site is going to have to strongly consider uninstalling trove until fixed.

Thanks,
Kevin


From: Zane Bitter
Sent: Friday, May 22, 2015 12:34:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my notes

On 22/05/15 11:48, Amrith Kumar wrote:
I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database
and the Trove agent as within its own security perimeter. (Whether
that's appropriate is another debate, but it's up to the Trove
contributors to decide.) In this case, the ability to authenticate to
the queue using Keystone provides no real value, so this isn't really a
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user. That's
the kind of thing that needs to be replaced by a multi-tenant service.
The session was organised because it was assumed that Trove is in the
same boat, but it appears that Trove developers don't consider that it is.

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of the
security boundary is reconsidered.

cheers,
Zane.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 22, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On 22/05/15 19:01, Fox, Kevin M wrote:
I believe that trove still needs the multi tenant isolation of a multi
tenant message queue due to the fact that the vm runs in the tenant, and
the tenant can then force a reboot, go to the console, root it, and
inject messages at queues destened for other tenants vm's. And there are
other routes too.

So what I gathered is that according to the Trove folks you are Doing It
Wrong(TM), even though you installed it in the default configuration.
You should have modified the Trove code in undocumented ways to create
the VMs in a project that Trove itself owns, not the user's project.

This is a major problem, and I think our site is going to have to
strongly consider uninstalling trove until fixed.

I think if you made that change the configuration it would be a lot less
dangerous. Arguably even then it would be better to use something
multi-tenant capable and authenticated (if it's so safe why not use the
same RabbitMQ as all the other services?), but it would be less of an
'immediate uninstall' case.

cheers,
Zane.

Thanks,
Kevin *
*


From: Zane Bitter
Sent: Friday, May 22, 2015 12:34:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my
notes

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database
and the Trove agent as within its own security perimeter. (Whether
that's appropriate is another debate, but it's up to the Trove
contributors to decide.) In this case, the ability to authenticate to
the queue using Keystone provides no real value, so this isn't really a
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user. That's
the kind of thing that needs to be replaced by a multi-tenant service.
The session was organised because it was assumed that Trove is in the
same boat, but it appears that Trove developers don't consider that it is.

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of the
security boundary is reconsidered.

cheers,
Zane.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


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


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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 23, 2015 by Zane_Bitter (21,640 points)   4 6 9
0 votes

Thank you. Ill look for this right away.

Long term, we would prefer some way for the resources to be associated with the tenant so that it simplifies quotas/billing since there are just instances/volumes we already quota. This would need some kind of service vm flag in nova to prevent via policy non admins from messing with them.

In addition, this is still a case where some users had an opertunity to get into a vm they shouldnt, and a multitenant message queue would then have privided extra protection.

Thanks,
Kevin


From: Zane Bitter
Sent: Friday, May 22, 2015 10:07:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my notes

On 22/05/15 19:01, Fox, Kevin M wrote:
I believe that trove still needs the multi tenant isolation of a multi
tenant message queue due to the fact that the vm runs in the tenant, and
the tenant can then force a reboot, go to the console, root it, and
inject messages at queues destened for other tenants vm's. And there are
other routes too.

So what I gathered is that according to the Trove folks you are Doing It
Wrong(TM), even though you installed it in the default configuration.
You should have modified the Trove code in undocumented ways to create
the VMs in a project that Trove itself owns, not the user's project.

This is a major problem, and I think our site is going to have to
strongly consider uninstalling trove until fixed.

I think if you made that change the configuration it would be a lot less
dangerous. Arguably even then it would be better to use something
multi-tenant capable and authenticated (if it's so safe why not use the
same RabbitMQ as all the other services?), but it would be less of an
'immediate uninstall' case.

cheers,
Zane.

Thanks,
Kevin *
*


From: Zane Bitter
Sent: Friday, May 22, 2015 12:34:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my
notes

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database
and the Trove agent as within its own security perimeter. (Whether
that's appropriate is another debate, but it's up to the Trove
contributors to decide.) In this case, the ability to authenticate to
the queue using Keystone provides no real value, so this isn't really a
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user. That's
the kind of thing that needs to be replaced by a multi-tenant service.
The session was organised because it was assumed that Trove is in the
same boat, but it appears that Trove developers don't consider that it is.

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of the
security boundary is reconsidered.

cheers,
Zane.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


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


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


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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 23, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

--

Best
Li Tianqing

At 2015-05-23 13:07:42, "Zane Bitter" zbitter@redhat.com wrote:
On 22/05/15 19:01, Fox, Kevin M wrote:

I believe that trove still needs the multi tenant isolation of a multi
tenant message queue due to the fact that the vm runs in the tenant, and
the tenant can then force a reboot, go to the console, root it, and
inject messages at queues destened for other tenants vm's. And there are
other routes too.

So what I gathered is that according to the Trove folks you are Doing It
Wrong(TM), even though you installed it in the default configuration.
You should have modified the Trove code in undocumented ways to create

the VMs in a project that Trove itself owns, not the user's project.
Yes

This is a major problem, and I think our site is going to have to
strongly consider uninstalling trove until fixed.

I think if you made that change the configuration it would be a lot less
dangerous. Arguably even then it would be better to use something
multi-tenant capable and authenticated (if it's so safe why not use the
same RabbitMQ as all the other services?), but it would be less of an

'immediate uninstall' case.
Can you explain how the vm send messages to rabbitmq in management network?

cheers,
Zane.

Thanks,
Kevin *
*


From: Zane Bitter
Sent: Friday, May 22, 2015 12:34:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my
notes

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database
and the Trove agent as within its own security perimeter. (Whether
that's appropriate is another debate, but it's up to the Trove
contributors to decide.) In this case, the ability to authenticate to
the queue using Keystone provides no real value, so this isn't really a
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user. That's
the kind of thing that needs to be replaced by a multi-tenant service.
The session was organised because it was assumed that Trove is in the
same boat, but it appears that Trove developers don't consider that it is.

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of the
security boundary is reconsidered.

cheers,
Zane.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


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


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


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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2015 by Li_Tianqing (2,140 points)   3 7
0 votes

On 22/05/15 15:34 -0400, Zane Bitter wrote:
On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a
la Amazon SQS.

This is the way we've been describing it.

I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it
to Rabbit, which is a completely different thing with completely
different use cases. IMHO part of the problem has been that folks have
been reluctant to name SQS specifically, and so we end up talking
elliptically.

+1

I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains
about this and it's getting a little boring. It's irrelevant because
Zaqar is not a replacement for AMQP, it's a replacement for SQS.

Again +1

I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in
Oslo messaging.

This is probably the main reason why there's no driver for Zaqar in
oslo.messaging. That is, to prevent people from actually using Zaqar
as a message bus in openstack.

(Although that could be an interesting idea, it's another discussion
altogether.)

for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated
by Keystone). IMHO the ideal scenario would be that messages from
Trove (or whatever) to the VM would go over Zaqar, and for messages in
the other direction would just go straight to the Trove (or whatever)
API. The problem is that Keystone's authorisation capabilities are not
sufficient to handle this at the moment. One thing that should be
possible in a shorter time-frame is a pre-signed URL for a Zaqar queue
as a return path.

++

It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

And Catalyst

We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the
database and the Trove agent as within its own security perimeter.
(Whether that's appropriate is another debate, but it's up to the
Trove contributors to decide.) In this case, the ability to
authenticate to the queue using Keystone provides no real value, so
this isn't really a use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara.
Whenever the agent is outside the security perimeter, we need an
authenticated, metered, multi-tenant access method.

Correct. When we started talking about integrating Trove and Zaqar was
under the assumption that Trove VMs to be out of Tove's security
perimeter. The Trove team seems to disagree with this assumption,
although there are some OPs that disagree with Trove's team.

(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (RabbitMQ) service for the rest of the infrastructure message
passing needs unless and until all projects decide to abandon RabbitMQ
in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to
its agent on machines that are very much controlled by the user.
That's the kind of thing that needs to be replaced by a multi-tenant
service. The session was organised because it was assumed that Trove
is in the same boat, but it appears that Trove developers don't
consider that it is.

++

(c)At this time it is likely that there is no net benefit to a project
like Trove in integrating with zaqar given that the upside is likely
limited, the downside(s) that we know of are significant, and there is a
significant unknown risk.

I agree that in that in the case of Trove specifically, there's no
reason to change unless and until the decision about the location of
the security boundary is reconsidered.

Thanks Amrith for your notes and to you, Zane, for replying with so
precise answers to Amrith's email. Unless the perception of what the
Trove VM's boundaries are changes, I agree there's no much point in
dedicating time to this integration.

My thanks to the folks from zaqar for having the session, I certainly
learnt a lot more about the project, and about openstack.

Thank you all for attending and sharing such detailed information,
Flavio

Let me conclude where I began, by saying the preceding is not a ‘minutes
of the meeting’, merely my notes from the meeting.

Thanks,

-amrith


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


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

--
@flaper87
Flavio Percoco


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

responded May 25, 2015 by Flavio_Percoco (36,960 points)   3 7 11
0 votes

Flavio,

Thanks for your response. I was waiting for your response before replying further.

In parallel with the conversation with the Zaqar team, we started some other conversations (as you know) at the summit. Bruno (of Catalyst) is in the process of formalizing a blueprint for the Nova team that would provide some interfaces that would be useful for projects like Trove, Sahara, and if I'm not mistaken, Designate, and other projects that launch Nova VM's. Bruno has the action item to follow up on this and we'll be working with him on that.

There is one proposals about working with the keystone team (I have the action item on this and will be following up with them) to investigate whether the project already has, or could easily provide some additional capabilities that would similarly be useful for Trove, Sahara and other projects that launch VM's.

The lack of documentation around how to configure Trove is well taken, we will be resolving that and making available additional documentation and code to address this.

Thanks!

-amrith

| -----Original Message-----
| From: Flavio Percoco [mailto:flavio@redhat.com]
| Sent: Monday, May 25, 2015 10:36 AM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my
| notes
|
| On 22/05/15 15:34 -0400, Zane Bitter wrote:
| >On 22/05/15 11:48, Amrith Kumar wrote:
| >>I’m posting this to the mailing list to summarize my notes from a
| >>meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
| >>multi-tenant messaging and how it may be applicable to a number of
| projects.
| >>
| >>I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
| >>notes and observations after the meeting and how they relate
| >>specifically to Trove. I don’t claim to speak for Trove, other
| >>contributors to Trove, other projects who were at the meeting, for
| >>zaqar, etc., etc.,
| >>
| >>After the meeting I think I have a slightly better understanding of
| >>what Zaqar is but I am still not entirely sure. As best as I can tell,
| >>it is a lightweight, keystone authenticated, multi-tenant messaging
| system.
| >
| >I'm not sure what 'lightweight' means in this context. I'd describe it
| >as a keystone-authenticated multi-tenant reliable messaging system a la
| >Amazon SQS.
|
| This is the way we've been describing it.
| >
| >>I
| >>am still a little troubled that of the many people in the room who
| >>were knowledgeable of zaqar, there appeared to be some disagreement on
| >>how best to describe or explain the project.
| >
| >I don't think there's any disagreement. It just seems to be hard to
| >explain to people, because everyone instinctively wants to compare it
| >to Rabbit, which is a completely different thing with completely
| >different use cases. IMHO part of the problem has been that folks have
| >been reluctant to name SQS specifically, and so we end up talking
| >elliptically.
|
| +1
|
| >
| >>I learned that users of zaqar can authenticate with keystone and then
| >>interact with zaqar, and pass messages using it. I learned also that
| >>zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
| >>zaquar as I had thought it was.
| >>
| >>It became clear that the underlying transport in zaqar is not based on
| >>an existing AMQP service, rather zaqar is a “from the ground up”
| >>implementation. This scares me (a lot).
| >
| >Yes, literally every person who has ever heard of Zaqar complains about
| >this and it's getting a little boring. It's irrelevant because Zaqar is
| >not a replacement for AMQP, it's a replacement for SQS.
|
| Again +1
|
| >
| >>I gather there is currently no oslo.messaging integration with zaqar;
| >
| >Right, Zaqar has never been intended as a replacement for Rabbit in
| >Oslo messaging.
|
| This is probably the main reason why there's no driver for Zaqar in
| oslo.messaging. That is, to prevent people from actually using Zaqar as a
| message bus in openstack.
|
| >
| >(Although that could be an interesting idea, it's another discussion
| >altogether.)
| >
| >>for Trove to use zaqar we would have to either (a) abandon
| >>oslo.messaging and use zaqar, or (b) build in smarts within Trove to
| >>determine at run time whether we are using zaqar or o.m and implement
| >>code in Trove to handle the differences between them if any.
| >>
| >>It wasn’t clear to me after the meeting what differences there may be
| >>with Trove; one which was alluded to was the inability to do a
| >>synchronous (call()) style message and the statement was that this was
| >>something that “could be built into a driver”.
| >
| >Where Zaqar really provides the biggest benefit is sending the message
| >from the cloud to the user/application (since it can be authenticated
| >by Keystone). IMHO the ideal scenario would be that messages from Trove
| >(or whatever) to the VM would go over Zaqar, and for messages in the
| >other direction would just go straight to the Trove (or whatever) API.
| >The problem is that Keystone's authorisation capabilities are not
| >sufficient to handle this at the moment. One thing that should be
| >possible in a shorter time-frame is a pre-signed URL for a Zaqar queue
| >as a return path.
|
| ++
|
| >
| >>It wasn’t clear to me what scale zaqar has been run at and whether
| >>anyone has in fact deployed and run zaqar at scale, and whether it has
| >>been battle hardened the way a service like RabbitMQ has. While I hear
| >>from many that RabbitMQ is a nightmare to scale and manage, I realize
| >>that it does in fact have a long history of deployments at scale.
| >
| >I believe that Rackspace deployed it?
|
| And Catalyst
|
| >
| >>We discussed some of the assumptions being made in the conversation
| >>relative to the security of the various parties to the communication
| >>on the existing rabbit message queue and at the conclusion of the
| >>meeting I believe we left things as below.
| >>
| >>(a)Zaqar would be more appealing if it had a simple oslo.messaging
| >>driver and an easier path to integration by client projects like Trove.
| >>The rip-and-replace option put a certain damper on the enthusiasm
| >
| >So the key point here is that Trove regards the VM running the database
| >and the Trove agent as within its own security perimeter.
| >(Whether that's appropriate is another debate, but it's up to the Trove
| >contributors to decide.) In this case, the ability to authenticate to
| >the queue using Keystone provides no real value, so this isn't really a
| >use case that requires Zaqar.
| >
| >The same is not true for other projects, like Heat, Murano and Sahara.
| >Whenever the agent is outside the security perimeter, we need an
| >authenticated, metered, multi-tenant access method.
|
| Correct. When we started talking about integrating Trove and Zaqar was
| under the assumption that Trove VMs to be out of Tove's security
| perimeter. The Trove team seems to disagree with this assumption, although
| there are some OPs that disagree with Trove's team.
|
| >
| >>(b)Even with an o.m integration, the incremental benefits that zaqar
| >>brought were diminished by the fact that one would still have to
| >>operate an AMQP (RabbitMQ) service for the rest of the infrastructure
| >>message passing needs unless and until all projects decide to abandon
| >>RabbitMQ in favor of zaqar
| >
| >This is not at all what was being suggested.
| >
| >Murano, for example, is running a separate RabbitMQ service to talk to
| >its agent on machines that are very much controlled by the user.
| >That's the kind of thing that needs to be replaced by a multi-tenant
| >service. The session was organised because it was assumed that Trove is
| >in the same boat, but it appears that Trove developers don't consider
| >that it is.
|
| ++
|
| >
| >>(c)At this time it is likely that there is no net benefit to a project
| >>like Trove in integrating with zaqar given that the upside is likely
| >>limited, the downside(s) that we know of are significant, and there is
| >>a significant unknown risk.
| >
| >I agree that in that in the case of Trove specifically, there's no
| >reason to change unless and until the decision about the location of
| >the security boundary is reconsidered.
|
| Thanks Amrith for your notes and to you, Zane, for replying with so
| precise answers to Amrith's email. Unless the perception of what the Trove
| VM's boundaries are changes, I agree there's no much point in dedicating
| time to this integration.
|
| >>My thanks to the folks from zaqar for having the session, I certainly
| >>learnt a lot more about the project, and about openstack.
|
| Thank you all for attending and sharing such detailed information, Flavio
|
| >>
| >>Let me conclude where I began, by saying the preceding is not a
| >>‘minutes of the meeting’, merely my notes from the meeting.
| >>
| >>Thanks,
| >>
| >>-amrith
| >>
| >>
| >>
| >>______________________________________________________________________
| >>____ OpenStack Development Mailing List (not for usage questions)
| >>Unsubscribe:
| >>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
| >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
| >>
| >
| >
| >_______________________________________________________________________
| >___ OpenStack Development Mailing List (not for usage questions)
| >Unsubscribe:
| >OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
| >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
|
| --
| @flaper87
| Flavio Percoco


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 25, 2015 by Amrith_Kumar (10,500 points)   2 4 4
...