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

[Matthias Wessendorf]

can you record that - and share the recording ? I am traveling :-/

On Wed, Dec 13, 2017 at 2:27 PM, Craig Brookes <cbrookes at redhat.com> wrote:

> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/2c6ecc2e/attachment.html