h4. (/) - [MSS Operator] As a Developer, I want a Mobile Security Service Operator, such that the Mobile Security Service can be instantiated, used and maintained. - DONE - Accepted after the demo.
Trello Link: https://trello.com/c/oLKC7jRi/11-mss-operator-as-a-developer-i-want-a-mobile-security-service-operator-such-that-the-mobile-security-service-can-be-instantiated
* (/) - An GoLang Operator for the Mobile Security Service
* (/) - The MSS Operator should be a cluster level operator
* (/) - A Mobile Security Service installation Custom Resource is made available
* (/) - The information which will reside in the installation CR should be documented; whats mandatory and what's not and what each piece of info represents. - AEROGEAR-8988
* (/) - When the installation CR is instantiated, the MSS Operator should provision the MSS Service into the namespace where the Operator resides. Each managed Service should have its own managed namespace. - AEROGEAR-8963
* (/) - The operator should populate the Status field inside the installation CR, such that the user knows the progress of the (de)provisioning. - AEROGEAR-8984
* (/) -The resources provisioned from the instantiation of the CR should be watched by the MSS Operator, e.g. deployment configs etc so if a user manually removes a deployment config associated to the service, the operator will return the service to the correct state e.g. create the deployment config again. - NOT MANDATORY
* (/) - Operator should be capable of updating the MSS to a new version, when a new version of MSS is released. - AEROGEAR-8985
* (/) - The MSS dependency on PostgreSQL needs to be handled. Use of the existing PostGreSQL operator is preferable. - AEROGEAR-8957
h4. (flag) - [MSS Consumption CR] As a Developer, I want to be able to specify necessary info through a CR, such that I can associate my Mobile App with the MSS. - (AEROGEAR-8903) - Required changes after demo
Trelo Link: https://trello.com/c/ExZqTlJ6/12-mss-consumption-cr-as-a-developer-i-want-to-be-able-to-specify-necessary-info-through-a-cr-such-that-i-can-associate-my-mobile
* (/) - Be able to specify MSS required info (App Name, App Id) in a CR such that the MSS will track a Mobile App.
* (/) - An individual instance of this CR should only be used once (the Operator should not act on updates after the initial usage of the CR). After initial instantiation of the CR, the user should do all other changes via the MSS UI.
* (/) - MSS Consumption CR should be fully documented.
* (/) - The config (similar to the config currently in mobile-services.json) which is created as a result of processing the CR, should be made available in a Config Map in the Mobile Apps namespace, with relevant labels.
* (!) - if the CR is deleted, then the associating Mobile App info in MSS should be marked as disabled/unbound. (AEROGEAR-9088)
* (/) - if the CR is deleted, then the associating Config Map in the Mobile App namespace should be removed.
Following the task that needs to get done for we are able to demo it again.
* Remove the Unbind Type - AEROGEAR-9088
* Impl to get automatically clusterHost IP - AEROGEAR-8990
* Change operator to watch specific namespaces and or labels - AEROGEAR-9089
* Rename the BIND type for APP - AEROGEAR-8968
Following the tasks that should get done but are not required for the demo:
* AEROGEAR-8809 - Cover operator with tests
* AEROGEAR-8810 - Configure CI/CD for the Operator
* AEROGEAR-8987 - Impl config the ouath proxy to the service
* AEROGEAR-8968 - Review roles and if required impl roles for no-privileged users |
|
