including aerogear-dev On 13 December 2017 at 08:55, Craig Brookes <cbrookes(a)redhat.com&gt; 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. > >

1. Use secrets for things which are actually secret like API keys, credentials, etc 2. Use config map for not-secret configuration data So the proposed change is well aligned with this statement.

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/mas > ter/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(a)redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) _______________________________________________ feedhenry-dev mailing list feedhenry-dev(a)redhat.com https://www.redhat.com/mailman/listinfo/feedhenry-dev

Great. Lets use this is a discussion point for thurday's call On Wed, Dec 13, 2017 at 10:48 AM, Wei Li <weil(a)redhat.com&gt; wrote: > Please see my comments inline. > > On Wed, Dec 13, 2017 at 9:36 AM, David Martin <davmarti(a)redhat.com&gt; > wrote: > >> including aerogear-dev >> >> On 13 December 2017 at 08:55, Craig Brookes <cbrookes(a)redhat.com&gt; 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. >>> >>> > +1. This is a quote I found from the author of both secret & configmap: > > >> 1. Use secrets for things which are actually secret like API keys, >> credentials, etc >> 2. Use config map for not-secret configuration data >> >> So the proposed change is well aligned with this statement. > > >> 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/mas >>> ter/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 >>> ... >>> >> > +1 on creating a repo for the proposals. I also want to add sometimes > there are a few options on the 'How'. In that case, it's important to list > all the options and explain why one of them is being chosen. > > We probably also want to capture the status of the proposal - e.g. > accepted, rejected, work in progress or completed etc so that community > members can easily find out what have been done and what haven't. > > >> >>> 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(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev(a)redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile <https://www.redhat.com/> > > weil(a)redhat.com M: +353862393272 > <https://red.ht/sig> > -- Craig Brookes RHMAP @maleck13 Github _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev