[aerogear-dev] [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general

[David Martin]

including aerogear-dev

On 13 December 2017 at 08:55, Craig Brookes <cbrookes at redhat.com> wrote:

> Hey guys,
>
> *tldr*
> *- Use a combination of configmaps and secrets to store public (ie client
> config) vs secret (ie credentials) when provisioning services via an APB*
> *- Use proposals for these kind of changes (ie where they are larger
> changes, breaking changes or changes in technical direction that have cross
> cutting concerns.)*
> *- As we have many pieces, setup aerogear/proposals repo.*
>
> I would like to suggest that we  make use of a mixture of configmap and
> secrets during the provision of a mobile "aware" service.
> Currently when we provision a service we must also create a secret with a
> label: mobile:enabled and at least two pieces of information:
> - uri
> - name
> but it often contains more (such as username and password etc)
> This secret is used by the UI to represent that the service is present in
> the namespace and to display the credential information that allows the
> developer to sign into the service.
> During the PoC this secret was also used to populate the mobile client
> config. This meant filtering out fields that we did not want the mobile
> client to have access to.
> My suggestion is that we move to using an additional configmap labeled
> "mobile:enabled" that contains the public information that can be exposed
> to the mobile client as configuration and a secret still labeled
> "mobile:enabled" to capture other information such as the credentials for
> logging into the service.
>
>  This really amounts to a proposal. Which brings me to the second
> question. Where to keep proposals? I would like us to standardise on have a
> public record of technical changes. These proposals should capture the
> following:
> 1) What
> 2) Why
> 3) How
> As an example here is a proposal that I put together for the ansible
> service broker:
> https://github.com/openshift/ansible-service-broker/blob/
> master/docs/proposals/last-operation-description.md
> This shows the kind of level of detail that I believe we should be
> capturing.
> When is a proposal necessary? In my experience they are often used for
> larger changes, breaking changes or changes in technical direction that
> have cross cutting concerns. So in the case of my change outlined above, it
> is a breaking change that both the CLI and UI need to be aware of along
> with the developers of service APBs and so it should be a proposal.
> In the ansible service broker case the proposal is kept in the docs dir of
> the repo, however for something larger like Kubernetes they have a separate
> repo https://github.com/kubernetes/community.
> We could do something similar: aerogear/proposals with directories for
> each area
> - core
>    - ui
>    - cli
>    - ide-extenstions
> - services
>   - apbs
>   - push
>   - sync
> ...
>
> I think this would allow the owner or gatekeeper of the proposal to be
> clearly identified.
>
> Interested in hearing thoughts and opinions
>
>
>
> --
> Craig Brookes
> RHMAP
> @maleck13 Github
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>


-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/eea4d6e6/attachment.html