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

[Craig Brookes]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/825faaf9/attachment.htm>