If not FUSE, what is the timeline/status for support of mounting persistent volumes in Diego natively(remember seeing a talk in cf summit on floating/fixed volumes)? Pramod On Wed, Jul 29, 2015 at 9:53 AM <cf-dev-request(a)lists.cloudfoundry.org> wrote: Send cf-dev mailing list submissions to cf-dev(a)lists.cloudfoundry.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.cloudfoundry.org/mailman/listinfo/cf-dev or, via email, send a message with subject or body 'help' to cf-dev-request(a)lists.cloudfoundry.org
You can reach the person managing the list at cf-dev-owner(a)lists.cloudfoundry.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of cf-dev digest..."
Today's Topics:
1. Re: Removing FUSE support from CF (Onsi Fakhouri) 2. Droplets and Stacks (Colin Humphreys) 3. Re: Notifications on ORG, SPACE and USER modifications (Matt Cowger)
----------------------------------------------------------------------
Message: 1 Date: Wed, 29 Jul 2015 09:50:00 -0700 From: Onsi Fakhouri <ofakhouri(a)pivotal.io> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] Removing FUSE support from CF Message-ID: <CAFwdB-zsTVY4-KUzUmUOiHZ7XrWhvSzc=rnOhmXmkfBq= YCFqQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hey all,
Based on the feedback we got and the relatively low cost to maintain privileged support we'd like to propose making running privileged containers on the platform configurable - we will recommend this be turned off when running untrusted workloads and it will likely default to off. We have longer term plans to support mounting persistent volumes in Diego at which point support for mounting FUSE in unprivileged containers can become a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
? Thoughts? Concerns?
Well, that?s bad news.
We, and I assume many others as well (like the folks from Stackato who do
it in the public), have used SSHFS + FUSE to implement a persistent file system for old-fashioned apps/apps that are not Cloud-native. I don?t want
to fight an ideological battle here, it?s just that these apps do still exist (in majority) and a file system service is an important service/feature for them.
So if you remove FUSE (which we thought is not going away/was added to stay), it?s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful for running apps that depend on a persistent FS, like Wordpress. Perhaps this use case of mounting a remote SSHFS could be supported in some other way?
Dan
*From: *Onsi Fakhouri *Reply-To: *"Discussions about Cloud Foundry projects and the system overall." *Date: *Saturday 11 July 2015 01:10 *To: *cf-dev *Subject: *[cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving Garden-Linux's security features. Garden-Linux now employs user
namespaces
and drops capabilities when creating unprivileged containers - we're excited to bring both of these features to the platform!
Diego currently runs applications in *privileged* containers. These lack the security features outlined above and we are planning on switching
to launch all CF applications in *unprivileged* containers.
Unfortunately, it has proved difficult to support mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are planning on removing support for FUSE in favor of better securing our containers.* If/when FUSE support in unprivileged containers becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/94321642/attachment-0001.html ------------------------------
Message: 2 Date: Wed, 29 Jul 2015 17:51:42 +0100 From: Colin Humphreys <colin(a)cloudcredo.com> To: cf-dev(a)lists.cloudfoundry.org Subject: [cf-dev] Droplets and Stacks Message-ID: <CACfkAi+54GWe8c1pO8uDxWs_Sa4JjBkTQ5Ed+Xd8bLZRJWvg= A(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi All,
I wrote a couple of articles about droplets and stacks.
http://www.cloudcredo.com/a-droplet-of-value/
http://www.cloudcredo.com/stacks-of-problems/
The droplet post is fairly self-explanatory, and enabling the choice of shipping droplets or source is well on the way in Cloud Foundry development.
I feel our story around stacks is far less complete. It seems to be an overloaded concept inherited from Heroku and the contract with the stack seems to cause issues for both app and buildpack developers.
I'd like to open the discussion on what the future should be for stacks, or if you think they're perfect as they are.
Cheers, Colin
CloudCredo Cheerleader -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/d774b045/attachment-0001.html ------------------------------
Message: 3 Date: Wed, 29 Jul 2015 09:52:53 -0700 From: Matt Cowger <matt(a)cowger.us> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] Notifications on ORG, SPACE and USER modifications Message-ID: < CAOuA4vytsHYam7YydbL+eiW1EGByXnoT+QPKD2NtoMQexzZmfQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
For me the primary use case to developing management tools on top of the CC API, and being able to intelligently cache information about the state of those resources. Without etags or serial numbers or similar, that means every refresh needs to query a TON of data from CC.
On Tue, Jul 28, 2015 at 10:26 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
Hi all interested in notifications on modification of resources,
It would be helpful for me in framing the "what" and the "why" of this feature if you could also describe your specific use cases and pain points
on why you would want notifications on modifications and also which resources you particularly care about. Is it for real time updates on a dashboard? For consumption for billing purposes? For triggering provisioning/deprovisioning of resources?
-Dieu
On Tue, Jul 28, 2015 at 11:05 AM, Jean-Sebastien Delfino < jsdelfino(a)gmail.com> wrote:
I?m going to need something like this too for the CF Abacus service metering project, as I?d like to track the lifecycle of orgs, users, etc to
match their history with the usage data reported for them.
Here?s a straw man description of what I had in mind:
- For Abacus, I?d need a Lossless API. Usage metering eventually translates to billing and money, you don?t want to lose that :)
- An extension or variant of the current CF /v2/events API supporting users, orgs, app usage etc, as even with a notification API I?ll still need
to do GETs sometimes.
- 304 responses with etags on these GETs (as suggested earlier in the thread [1]) would be good.
- A Webhook style notification API where I could register interest in a selection of events with a callback URL, and get these events POSTed back
to me at that URL, similar to what Github and many others do with Webhooks.
- On top of Webhooks, it?d be nice to have a form of streaming (either down to the client like the Firehose does or in the other direction up
to
the Webhook callback URL), but I'm not sure if we?ll need that in the project right away.
- We?d obviously need some form of security, maybe use my user token to register for events on entities that I have access to?
- I?m also curious about the group?s thoughts on queueing and back-pressure when events get generated faster that they can be consumed for example. There was a mention of some message queuing earlier [2]. That
would make sense to me (although IMO it?d be good if the underlying MQ didn?t shine through the API). What did you have in mind for this?
I guess there are quite a few things to figure out here! I?ll be happy to
collaborate with the community on these discussions.
Thoughts?
[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p842.html
[2]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p834.html
- Jean-Sebastien
On Fri, Jul 24, 2015 at 9:59 PM, Matt Cowger <matt(a)cowger.us> wrote:
I think ETags is reasonable thought as well.
On Thu, Jul 23, 2015 at 4:39 PM, Benjamin Black <bblack(a)pivotal.io> wrote:
ETags and a 304 response are specifically intended for that purpose. I'd recommend that over relying on Last-Modified.
b
On Thu, Jul 23, 2015 at 12:34 AM, Koper, Dies < diesk(a)fast.au.fujitsu.com> wrote:
Or setting the Last-Modified HTTP response header accordingly, and allow clients to use HTTP caching mechanisms (Last-Modified, etc.)
to get
quick empty responses with the current APIs if no changes have been
made?
(Or maybe this is already working so ? haven?t checked).
Regards,
Dies Koper
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto: cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Matt Cowger *Sent:* Thursday, July 23, 2015 4:45 PM *To:* Discussions about Cloud Foundry projects and the system
overall.
*Subject:* Re: [cf-dev] Notifications on ORG, SPACE and USER modifications
I've wanted something similar as well.
On a related note, having a CC API 'serial' number (for each object
in
CC - apps, spaces, etc) that increments on every change relevant to
that
object would be of value for detecting if something has changed.
On Thu, Jul 23, 2015 at 3:27 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
There are a few different approaches to this and different concerns that are possible.
The requests I've seen have been around wanting to be able to subscribe to and filter the various events that cc currently
generates so
that other behavior could be triggered.
We currently have events, app usage events, and service usage events.
Is it acceptable for the notifications to be lossy? Depends on the use case but If so, then the firehose may be an acceptable approach.
The CAPI team is currently focusing on other work in the near term, such as the v3 API and private brokers, but would be happy to
collaborate
on a proposal.
On Wed, Jul 22, 2015 at 2:05 PM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote:
My take:
CC should have callbacks on for each model create, update and delete methods. Those callbacks will send a message to an MQ, which you can subscribe to consume those messages.
This can be expanded to pretty much every event we need to track.
What do you think?
JP
2015-07-22 17:30 GMT-03:00 Matthias X Hub <matthias.hub(a)de.ibm.com>:
Hi,
we (=IBM) are also having the need and are currently investigating
how
to solve this. We plan to work on a proposal to discuss this further
with
the cf community. I'll keep you updated on that.
Regards, Matthias
From: Mike Youngstrom <youngm(a)gmail.com> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: 22.07.2015 20:57 Subject: Re: [cf-dev] Notifications on ORG, SPACE and USER modifications Sent by: cf-dev-bounces(a)lists.cloudfoundry.org ------------------------------
We have the same need. Today we are polling the CC.
It would be nice for us also if we could get CC event notifications via something like the firehose.
Mike
On Wed, Jul 22, 2015 at 10:23 AM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote: I mean, I know you can list those events thru the API, but I want something that will react on an event instead of having to be
constantly
polling for them.
2015-07-22 13:18 GMT-03:00 Juan Pablo Genovese < juanpgenovese(a)gmail.com>: Sree,
thanks! Any pointers on how can I hook up to these audit events?
Thank you!
2015-07-22 13:12 GMT-03:00 Sree Tummidi <stummidi(a)pivotal.io>: I believe there are audit events generated for all these actions
which
can be captured and forwarded to an SIEM solution like splunk
Thanks, Sree
Sent from my iPhone
On Jul 22, 2015, at 8:54 AM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote:
Guys,
I need to somehow hook up into the Cloud Controller (CC) to capture ORG, SPACE and USER deletion, insertion and update.
So far, I considered some approaches, such as forking the CC (the least favorite) and modifying the code with some hooks, tapping into
Nginx
to capture the requests, and using triggers in the database to
capture each
event and send the necessary info to a service.
What do you think? Any other idea you might have?
Thanks!
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------
http://www.jpgenovese.com _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------
http://www.jpgenovese.com
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- -- Matt
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Jean-Sebastien
Sent from my DynaTAC 8000x
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/7488b9a8/attachment.html ------------------------------
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
End of cf-dev Digest, Vol 4, Issue 126 **************************************
|
Onsi Fakhouri <ofakhouri@...>
Hi Pramod, Still TBD - we're driving hard for a Diego GA first and will then evaluate the various priorities and scope them out. Onsi On Wed, Jul 29, 2015 at 9:59 AM, Pramod Mandagere <nagapramod(a)gmail.com> wrote: If not FUSE, what is the timeline/status for support of mounting persistent volumes in Diego natively(remember seeing a talk in cf summit on floating/fixed volumes)? Pramod
On Wed, Jul 29, 2015 at 9:53 AM <cf-dev-request(a)lists.cloudfoundry.org> wrote:
Send cf-dev mailing list submissions to cf-dev(a)lists.cloudfoundry.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.cloudfoundry.org/mailman/listinfo/cf-dev or, via email, send a message with subject or body 'help' to cf-dev-request(a)lists.cloudfoundry.org
You can reach the person managing the list at cf-dev-owner(a)lists.cloudfoundry.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of cf-dev digest..."
Today's Topics:
1. Re: Removing FUSE support from CF (Onsi Fakhouri) 2. Droplets and Stacks (Colin Humphreys) 3. Re: Notifications on ORG, SPACE and USER modifications (Matt Cowger)
----------------------------------------------------------------------
Message: 1 Date: Wed, 29 Jul 2015 09:50:00 -0700 From: Onsi Fakhouri <ofakhouri(a)pivotal.io> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] Removing FUSE support from CF Message-ID: <CAFwdB-zsTVY4-KUzUmUOiHZ7XrWhvSzc=rnOhmXmkfBq= YCFqQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hey all,
Based on the feedback we got and the relatively low cost to maintain privileged support we'd like to propose making running privileged containers on the platform configurable - we will recommend this be turned off when running untrusted workloads and it will likely default to off. We have longer term plans to support mounting persistent volumes in Diego at which point support for mounting FUSE in unprivileged containers can become a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
? Thoughts? Concerns?
Well, that?s bad news.
We, and I assume many others as well (like the folks from Stackato who do
it in the public), have used SSHFS + FUSE to implement a persistent file
system for old-fashioned apps/apps that are not Cloud-native. I don?t want
to fight an ideological battle here, it?s just that these apps do still exist (in majority) and a file system service is an important service/feature for them.
So if you remove FUSE (which we thought is not going away/was added to stay), it?s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful
for running apps that depend on a persistent FS, like Wordpress. Perhaps
this use case of mounting a remote SSHFS could be supported in some other
way?
Dan
*From: *Onsi Fakhouri *Reply-To: *"Discussions about Cloud Foundry projects and the system overall." *Date: *Saturday 11 July 2015 01:10 *To: *cf-dev *Subject: *[cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving Garden-Linux's security features. Garden-Linux now employs user
namespaces
and drops capabilities when creating unprivileged containers - we're excited to bring both of these features to the platform!
Diego currently runs applications in *privileged* containers. These lack the security features outlined above and we are planning on switching
to launch all CF applications in *unprivileged* containers.
Unfortunately, it has proved difficult to support mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are planning on removing support for FUSE in favor of better securing our containers.* If/when FUSE support in unprivileged containers becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/94321642/attachment-0001.html ------------------------------
Message: 2 Date: Wed, 29 Jul 2015 17:51:42 +0100 From: Colin Humphreys <colin(a)cloudcredo.com> To: cf-dev(a)lists.cloudfoundry.org Subject: [cf-dev] Droplets and Stacks Message-ID: <CACfkAi+54GWe8c1pO8uDxWs_Sa4JjBkTQ5Ed+Xd8bLZRJWvg= A(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi All,
I wrote a couple of articles about droplets and stacks.
http://www.cloudcredo.com/a-droplet-of-value/
http://www.cloudcredo.com/stacks-of-problems/
The droplet post is fairly self-explanatory, and enabling the choice of shipping droplets or source is well on the way in Cloud Foundry development.
I feel our story around stacks is far less complete. It seems to be an overloaded concept inherited from Heroku and the contract with the stack seems to cause issues for both app and buildpack developers.
I'd like to open the discussion on what the future should be for stacks, or if you think they're perfect as they are.
Cheers, Colin
CloudCredo Cheerleader -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/d774b045/attachment-0001.html ------------------------------
Message: 3 Date: Wed, 29 Jul 2015 09:52:53 -0700 From: Matt Cowger <matt(a)cowger.us> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] Notifications on ORG, SPACE and USER modifications Message-ID: < CAOuA4vytsHYam7YydbL+eiW1EGByXnoT+QPKD2NtoMQexzZmfQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8"
For me the primary use case to developing management tools on top of the CC API, and being able to intelligently cache information about the state of those resources. Without etags or serial numbers or similar, that means every refresh needs to query a TON of data from CC.
On Tue, Jul 28, 2015 at 10:26 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
Hi all interested in notifications on modification of resources,
It would be helpful for me in framing the "what" and the "why" of this feature if you could also describe your specific use cases and pain points
on why you would want notifications on modifications and also which resources you particularly care about. Is it for real time updates on a dashboard? For consumption for billing purposes? For triggering provisioning/deprovisioning of resources?
-Dieu
On Tue, Jul 28, 2015 at 11:05 AM, Jean-Sebastien Delfino < jsdelfino(a)gmail.com> wrote:
I?m going to need something like this too for the CF Abacus service metering project, as I?d like to track the lifecycle of orgs, users, etc to
match their history with the usage data reported for them.
Here?s a straw man description of what I had in mind:
- For Abacus, I?d need a Lossless API. Usage metering eventually translates to billing and money, you don?t want to lose that :)
- An extension or variant of the current CF /v2/events API supporting users, orgs, app usage etc, as even with a notification API I?ll still need
to do GETs sometimes.
- 304 responses with etags on these GETs (as suggested earlier in the thread [1]) would be good.
- A Webhook style notification API where I could register interest in a selection of events with a callback URL, and get these events POSTed back
to me at that URL, similar to what Github and many others do with Webhooks.
- On top of Webhooks, it?d be nice to have a form of streaming (either down to the client like the Firehose does or in the other direction up
to
the Webhook callback URL), but I'm not sure if we?ll need that in the project right away.
- We?d obviously need some form of security, maybe use my user token to register for events on entities that I have access to?
- I?m also curious about the group?s thoughts on queueing and back-pressure when events get generated faster that they can be consumed
for example. There was a mention of some message queuing earlier [2]. That
would make sense to me (although IMO it?d be good if the underlying MQ didn?t shine through the API). What did you have in mind for this?
I guess there are quite a few things to figure out here! I?ll be happy to
collaborate with the community on these discussions.
Thoughts?
[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p842.html
[2]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p834.html
- Jean-Sebastien
On Fri, Jul 24, 2015 at 9:59 PM, Matt Cowger <matt(a)cowger.us> wrote:
I think ETags is reasonable thought as well.
On Thu, Jul 23, 2015 at 4:39 PM, Benjamin Black <bblack(a)pivotal.io> wrote:
ETags and a 304 response are specifically intended for that purpose. I'd recommend that over relying on Last-Modified.
b
On Thu, Jul 23, 2015 at 12:34 AM, Koper, Dies < diesk(a)fast.au.fujitsu.com> wrote:
Or setting the Last-Modified HTTP response header accordingly, and allow clients to use HTTP caching mechanisms (Last-Modified, etc.)
to get
quick empty responses with the current APIs if no changes have been
made?
(Or maybe this is already working so ? haven?t checked).
Regards,
Dies Koper
*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto: cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Matt Cowger *Sent:* Thursday, July 23, 2015 4:45 PM *To:* Discussions about Cloud Foundry projects and the system
overall.
*Subject:* Re: [cf-dev] Notifications on ORG, SPACE and USER modifications
I've wanted something similar as well.
On a related note, having a CC API 'serial' number (for each object
in
CC - apps, spaces, etc) that increments on every change relevant to
that
object would be of value for detecting if something has changed.
On Thu, Jul 23, 2015 at 3:27 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
There are a few different approaches to this and different concerns that are possible.
The requests I've seen have been around wanting to be able to subscribe to and filter the various events that cc currently
generates so
that other behavior could be triggered.
We currently have events, app usage events, and service usage
events.
Is it acceptable for the notifications to be lossy? Depends on the use case but If so, then the firehose may be an acceptable approach.
The CAPI team is currently focusing on other work in the near term, such as the v3 API and private brokers, but would be happy to
collaborate
on a proposal.
On Wed, Jul 22, 2015 at 2:05 PM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote:
My take:
CC should have callbacks on for each model create, update and delete methods. Those callbacks will send a message to an MQ, which you can subscribe to consume those messages.
This can be expanded to pretty much every event we need to track.
What do you think?
JP
2015-07-22 17:30 GMT-03:00 Matthias X Hub <matthias.hub(a)de.ibm.com
:
Hi,
we (=IBM) are also having the need and are currently investigating
how
to solve this. We plan to work on a proposal to discuss this
further with
the cf community. I'll keep you updated on that.
Regards, Matthias
From: Mike Youngstrom <youngm(a)gmail.com> To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: 22.07.2015 20:57 Subject: Re: [cf-dev] Notifications on ORG, SPACE and USER modifications Sent by: cf-dev-bounces(a)lists.cloudfoundry.org ------------------------------
We have the same need. Today we are polling the CC.
It would be nice for us also if we could get CC event notifications via something like the firehose.
Mike
On Wed, Jul 22, 2015 at 10:23 AM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote: I mean, I know you can list those events thru the API, but I want something that will react on an event instead of having to be
constantly
polling for them.
2015-07-22 13:18 GMT-03:00 Juan Pablo Genovese < juanpgenovese(a)gmail.com>: Sree,
thanks! Any pointers on how can I hook up to these audit events?
Thank you!
2015-07-22 13:12 GMT-03:00 Sree Tummidi <stummidi(a)pivotal.io>: I believe there are audit events generated for all these actions
which
can be captured and forwarded to an SIEM solution like splunk
Thanks, Sree
Sent from my iPhone
On Jul 22, 2015, at 8:54 AM, Juan Pablo Genovese < juanpgenovese(a)gmail.com> wrote:
Guys,
I need to somehow hook up into the Cloud Controller (CC) to capture ORG, SPACE and USER deletion, insertion and update.
So far, I considered some approaches, such as forking the CC (the least favorite) and modifying the code with some hooks, tapping
into Nginx
to capture the requests, and using triggers in the database to
capture each
event and send the necessary info to a service.
What do you think? Any other idea you might have?
Thanks!
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------
http://www.jpgenovese.com _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
-- Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------ http://www.jpgenovese.com
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Mis mejores deseos, Best wishes, Meilleurs v?ux,
Juan Pablo ------------------------------------------------------
http://www.jpgenovese.com
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- -- Matt
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Jean-Sebastien
Sent from my DynaTAC 8000x
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.cloudfoundry.org/pipermail/cf-dev/attachments/20150729/7488b9a8/attachment.html ------------------------------
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
End of cf-dev Digest, Vol 4, Issue 126 **************************************
_______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|