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

[Craig Brookes]

Great. Lets use this is a discussion point for thurday's call

On Wed, Dec 13, 2017 at 10:48 AM, Wei Li <weil at redhat.com> wrote:

> Please see my comments inline.
>
> On Wed, Dec 13, 2017 at 9:36 AM, David Martin <davmarti at redhat.com> wrote:
>
>> 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.
>>>
>>>
> +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 at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
>
> WEI LI
>
> SENIOR SOFTWARE ENGINEER
>
> Red Hat Mobile <https://www.redhat.com/>
>
> weil at redhat.com    M: +353862393272
> <https://red.ht/sig>
>



-- 
Craig Brookes
RHMAP
@maleck13 Github
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/80a56eb6/attachment-0001.html