App hosting lifecycle

[vxc]

This pull request is about discussing the changes to the hosting process 9df082a
Here are the main proposals:

1. A larger list of hosting lifecycle events: Register, Host, Update, Alert, Suspend, Deregister.

2. Applications are a way of thinking about experiments and labs uniformly as far as lifecycle events go.

3. An Owner registration process.

4. Workflows for each lifecycle event.

[raj-vlabs]

3.5.1 We should not be instrumenting analytics into their code. It should be the responsibility of the developer. Besides, when we are touching their code, we cannot say that we will not test it. Anything that breaks due to our changes has to be fixed by us.

3.9 Adding analytics and UI should not be the responsibility of the hosting team. The hosting team should provide the tools necessary for the developers to select and integrate with the comon services.

6.1 If an application is identified by its registration issue id then we cannot assign any ids to the already existing labs.

6.2 If we allow multiple owners, who is responsible for co-ordination among them?

6.4.1
- Action column: What does (Suspension) mean? If it means the issue is of type suspension then it is probably misplaced.
- Supporting info column: Should it be Hosting Request Parameters or Registration Request Parameters?
After the Registration request goes to Failed status, is the requester sopposed to fix it or raise a new request?

7.4.8 A Reopened issue must be acted on and changed status of by the hosting team. Otherwise how will the Owner know that his Reopened request has been acted on? After Owner moves a request to Reopened, the hosting team should either move it to Reverted or Hosted as per Owner's instructions. Then Owner should Close it.

9.1 and 9.2 are duplicate.

9.3.1
- Supporting Info Column: Should be Registration/Deregistration parameters instead of Hosting Request Parameters.

11.1.3 Why do we need the Owner id in the Suspension request? If we need it to tag the Owner then we need it on the Alert issue too.

11.2.1
- Action column: Issue type should be Suspension.

[vxc]

3.5.1 We should not be instrumenting analytics into their code. It should be the responsibility of the developer. Besides, when we are touching their code, we cannot say that we will not test it. Anything that breaks due to our changes has to be fixed by us.

Agree to you point. I'm wondering , though, how is the analytics is being done right now. Are we not instrumenting the lab code?

3.9 Adding analytics and UI should not be the responsibility of the hosting team. The hosting team should provide the tools necessary for the developers to select and integrate with the comon services.

I agree, assuming that we have given them a library and a process document. Do we have something like that ready?

6.1 If an application is identified by its registration issue id then we cannot assign any ids to the already existing labs.

The way to do that is to register all current labs as monolithic applications.

6.2 If we allow multiple owners, who is responsible for co-ordination among them?

Agreed. We should recommend that that owner should be a team. The problem is that owners may change entirely. E.g., another institute may want to own the lab after some time. Perhaps in that case, the lab should be first deregistered and registered again.

6.4.1

• Action column: What does (Suspension) mean? If it means the issue is of type suspension then it is probably misplaced.

A suspension issue is to temporarily bring the app down due to severe security or performance problems.

• Supporting info column: Should it be Hosting Request Parameters or Registration Request Parameters?

Thanks. Will fix this.

After the Registration request goes to Failed status, is the requester sopposed to fix it or raise a new request?

New request. Because the new request typically will have a different tag.

7.4.8 A Reopened issue must be acted on and changed status of by the hosting team. Otherwise how will the Owner know that his Reopened request has been acted on? After Owner moves a request to Reopened, the hosting team should either move it to Reverted or Hosted as per Owner's instructions. Then Owner should Close it.

Agreed. I think the workflow table specifies this. Let me check again.

9.1 and 9.2 are duplicate.

Thanks! Will fix it.

9.3.1

• Supporting Info Column: Should be Registration/Deregistration parameters instead of Hosting Request Parameters.

Thanks! Will fix it.

11.1.3 Why do we need the Owner id in the Suspension request? If we need it to tag the Owner then we need it on the Alert issue too.

Agreed. Owner id is not required. The id will be evident from the issue itself.

11.2.1

• Action column: Issue type should be Suspension.

Thanks! Will fix it.

[raj-vlabs]

3.5.1 We should not be instrumenting analytics into their code. It should be the responsibility of the developer. Besides, when we are touching their code, we cannot say that we will not test it. Anything that breaks due to our changes has to be fixed by us.

Agree to you point. I'm wondering , though, how is the analytics is being done right now. Are we not instrumenting the lab code?

Yes we decided to instrument the lab code for analytics because of multiple reasons, primarily because we didn't know the owners and we were not sure how much time it would take if we decided to go find out the owners. We also ended up spending huge efforts in fixing their code. For a developer it is much easier to fix such issues because they understand and control their code.

3.9 Adding analytics and UI should not be the responsibility of the hosting team. The hosting team should provide the tools necessary for the developers to select and integrate with the comon services.

I agree, assuming that we have given them a library and a process document. Do we have something like that ready?

We do not have that ready but I think we can take some time and prepare them. Analytics especially is very straightforward.

6.2 If we allow multiple owners, who is responsible for co-ordination among them?

Agreed. We should recommend that that owner should be a team. The problem is that owners may change entirely. E.g., another institute may want to own the lab after some time. Perhaps in that case, the lab should be first deregistered and registered again.

We have update requests to take care of change in lab details. Owners can be changed if required. I don't think it requires deregistration. I think we should stay with the idea of one owner even if it is a group/team. That will be a single interface for us and resolving discrepancies will be their responsibility.

6.4.1

• Action column: What does (Suspension) mean? If it means the issue is of type suspension then it is probably misplaced.

A suspension issue is to temporarily bring the app down due to severe security or performance problems.

Yes but 6.4 is about Registration and not Suspension.

After the Registration request goes to Failed status, is the requester sopposed to fix it or raise a new request?

New request. Because the new request typically will have a different tag.

We should probably specify it.

[travula]

• Review Comments

1. General comment :: How about we write in present tense.

2. Section =How does one become part of the virtual labs
   community?= :: Probably the developers become part of the
   community by registering and adhering to the process
   maintained at IIT Bombay. And this community builds the
   applications by following the defined process.

3. The section =Approvals= seems ambiguous. Hosting does
   not obtain an quality check report, but will it be
   presented by the owner as part of the registration
   process.

4. Owner Registration :: A team of developers work on
   repository. Does our process restrict one github
   handle as the =Owner= to request hosting of built
   application from these sources? Or do we allow multiple
   handles to register as =Owners= for a single repo.
   Also, does it mean an owner is registered first before
   any application is registered. In similar vein, if the
   application is registered with the owner details, do we
   need a separate registration for owner.

5. In the table under the section - =Registration Workflow=,
   should the process not allow the owner to resubmit a
   failed registration request.

6. In the section =Identity of the application=, we should
   mention that the issue id becomes the application id. I
   added couple of lines to the file to make this explicit.

7. From point 9 of the section =Hosting Workflow=, looks
   like the hosting team re-hosts the same tag. Is the
   assumption that re-hosting will solve the problem? A
   scenario could be that the development team finds a bug
   in the sources for the unexpected behaviour of the
   application, and therefore could request a new tag to be
   hosted or meanwhile could ask for a revert to the last
   stable deployment. This could obviate the need for a new
   request as stated in point 10.

8. Is there a transition from failed state. Can the request
   be rectified and therefore change the state to Open
   rather then closed state as stated in step 5 of table.

9. I guess, steps 9 and 10 of the hosting workflow table
   should be rethought.

10. In the section =Making an Update request=, the update
    request could be made explicit by saying it is the update
    of the registration

11. Can the registration update request happen without
    reference to the prior registration? Is the application
    id reference to it?

12. The first step in the table describing the update
    workflow is not clear to me.

13. Similarly, the first step in the de-registration request
    workflow looks ambiguous. Why are hosting request
    parameters required. Probably, we want to state that a
    registration request has happened earlier.

14. Is it a cut paste error in the column =Action taken by
    Actor= of the table =Suspension Workflow= table where
    Registration is put in brackets.

[travula]

Some grammar and other such things are rectified and committed.

[travula]

1.Should we fold the owner registration into application registration? because the application update allows for an update of owners?
2. Also, should we introduce a new state - 'Rejected' - when a hosting request is malformed. This
state contrasts with the state 'Failed', which states, a hosting request has been taken up, but a failure
occurred while hosting.

[travula]

Conditions for Reversion and Re-hosting with the same tag

1. When the owner sees a clear bug in the application caused due to sources , a revert is requested.
2. It is not clear when the application is re-hosted with the same tag as mentioned in the hosting request.