Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App hosting lifecycle #19

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

App hosting lifecycle #19

wants to merge 16 commits into from

Conversation

vxc
Copy link
Collaborator

@vxc vxc commented Apr 19, 2020

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.

Venkatesh Choppella and others added 5 commits April 15, 2020 23:03
The life cycle now has the following events

Registration, hosting, updates, deregistration, suspension,
and alert.

Hosting Unit -> Application.
@travula travula closed this Apr 20, 2020
@travula travula reopened this Apr 20, 2020
@raj-vlabs
Copy link

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
Copy link
Collaborator Author

vxc commented Apr 21, 2020

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
Copy link

raj-vlabs commented Apr 21, 2020

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
Copy link
Member

travula commented Apr 21, 2020

  • 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
Copy link
Member

travula commented Apr 21, 2020

Some grammar and other such things are rectified and committed.

@travula
Copy link
Member

travula commented Apr 23, 2020

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
Copy link
Member

travula commented Apr 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants