during forced auto-enrolllment, service instance delete should be rejected

[cloudfoundry-community]

during forced auto-enrolllment, service instance delete should be rejected

[PadmaB]

Hi,

From the updated documentation, it is confirmed that the autosleep service instance shouldn't be able to be deleted if the auto-enrollment parameter is set to 'forced'.
If yes, who can delete such instances - will CF admin be able to delete the instances? Or, changing the parameter back to 'standard' is the only way to delete the service instance.

Can you please clarify?

Thanks!
Padma

[gberche-orange]

Thanks @PadmaB for your feedback.

1 The space developer is still able to unbind the application from the autosleep service instance

Actually, the space developer is able to transiently unbind the application, however the application will be autoenrolled at the end of the inactivity period, this being represented by having the app being bound to the autosleep service.

See associated acceptance test for a reference. I've started updating documentation in https://github.com/Orange-OpenSource/autosleep/tree/wording-169#lockauto-enrollment

2 The space developer is still able to delete the autosleep service instance

Thanks for catching this. We had planned to indeed reject deletes during forced enrollment mode, but this was missed in the implementation. Filled #173 as an acceptance test for this bug.

3 Upon checking the VCAP variables for the bound app, the credentials section doesn't seem to display the auto-enrollment variable. Is the behavior expected - that the variables are hidden from displaying to the end-user?

VCAP_SERVICES credentials are parameters provided to the app for programmatic access by the app. We felt the only relevant parameter is the idle-duration, that possibly an app could use (e.g. to keep alive by generating log activity before end of the idle-duration)

I'd be interested if you have other use-cases in mind that would deserve other fields in the credentials, such as enrollment mode you were mentionning.

Note that the enrollment status is available for human consumption (e.g. by app teams) in the autosleep service instance dashboard.

[PadmaB]

Thanks for clarifying!
Couple of more queries:

1. The current behavior of VCAP_SERVICES is fine - only relevant parameters are exposed. Since the functionality was not working, I was looking for details in the VCAP_SERVICES.
2. Do you plan to provide the implementation and make a release for the use-case - not allowing the user to delete the service instance during forced auto-enrollment mode?

The space developer is still able to unbind the application from the autosleep service instance
Actually, the space developer is able to transiently unbind the application, however the application will be autoenrolled at the end of the inactivity period, this being represented by having the app being bound to the autosleep service.

Any specific reason for waiting until the end of inactivity period to 're-bind' the app to the service? The inactivity period could be vary from few hours to few days as per the configuration. Wouldn't this mean that the apps will be in running state for a much longer duration even though their inactivity period has reached/exceeded?
Is the behavior same for new applications deployed to the space once the autosleep mode is enabled? If so, atleast for the first instance of stopping the inactive apps, there can be cases where the apps are stopped after a duration of 2x where x is the idle-duration defined for the autosleep service instance.
In this case the administrators will have to considered these boundary conditions before defining the 'ideal' idle-duration.

Kind Regards,
Padma

[PadmaB]

Hi,
I see some fixes submitted to address the auto-enrollment issue.
Quick question on the expected behavior here: Which users will not be able to delete the service instance during the forced auto-enrollment mode?
Or no user is allowed to delete the instance unless the auto-enrollment configuration is set to 'standard'.
Can you please clarify?

Thanks!
Kind Regards,
Padma

[gberche-orange]

Hi @PadmaB

Any specific reason for waiting until the end of inactivity period to 're-bind' the app to the service? The inactivity period could be vary from few hours to few days as per the configuration. Wouldn't this mean that the apps will be in running state for a much longer duration even though their inactivity period has reached/exceeded?

The rationale is that we need to provide a way for app teams to delete their apps: the autosleep forced enrollment should not get in their way to do their work. When the app team in unbinding the autosleep service configured in forced enrollment mode, this will have the effect of pausing the autosleep mechanism for idle-duration * 2 (one period to re-autoenroll + one period to autosleep). If space members do need to have their app up, it it fine for them either to cron/script a periodic unbind or regularly send traffic to the app.

The goal of th autosleep is just to reduce wasted RAM, and we try to avoid being in the way of the app teams.

Would you have other suggestions ?

Quick question on the expected behavior here:
1- Which users will not be able to delete the service instance during the forced auto-enrollment mode?
2- Or no user is allowed to delete the instance unless the auto-enrollment configuration is set to 'standard'.
Can you please clarify?

Option 2 is correct: ``no user is allowed to delete the instance unless the auto-enrollment configuration is set to 'standa

[arnaudruffin]

When the app team in unbinding the autosleep service configured in forced enrollment mode, this will have the effect of pausing the autosleep mechanism for idle-duration * 2 (one period to re-autoenroll + one period to autosleep).

That's not entirely true. The automatic enrollment is performed by our "SpaceEnroller" that run every idle-duration to check every app in space. So you have to wait for a maximum of idle-duration before being re-enrolled.
Once enrolled, autosleep will immediately check app logs and last events to compute when to check again for inactivity (last event + idle-duration). As the binding do not appears as an "event", if the app has already been inactive for idle-duration it will be stopped immediately.

So I would rather say

When the app team in unbinding the autosleep service configured in forced enrollment mode, this will have the effect of pausing the autosleep mechanism for a random duration that could reach idle-duration.

do you agree @gberche-orange ?

[PadmaB]

Once enrolled, autosleep will immediately check app logs and last events to compute when to check again for inactivity (last event + idle-duration). As the binding do not appears as an "event", if the app has already been inactive for idle-duration it will be stopped immediately.

If this is the behavior, then it should be fine.

Thanks for the detailed explanation and clarifying the queries!

[gberche-orange]

Thanks @PadmaB for your feedback.

Waiting for @arnaudruffin status on acceptance testing before cloding

[arnaudruffin]

Related feature and acceptance test are ok and merged in develop branch since commit a083277.
Closing the issue.