APB service provision using secrets and configmaps and proposals in general

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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:
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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:
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: APB service provision using secrets and configmaps and proposals in general

Wei Li
Please see my comments inline.

On Wed, Dec 13, 2017 at 9:36 AM, David Martin <[hidden email]> wrote:
including aerogear-dev

On 13 December 2017 at 08:55, Craig Brookes <[hidden email]> 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:
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
Please see my comments inline.

On Wed, Dec 13, 2017 at 9:36 AM, David Martin <[hidden email]> wrote:
including aerogear-dev

On 13 December 2017 at 08:55, Craig Brookes <[hidden email]> 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:
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    




--
Craig Brookes
RHMAP 
@maleck13 Github

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

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

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

On Wed, Dec 13, 2017 at 2:27 PM, Craig Brookes <[hidden email]> wrote:
Great. Lets use this is a discussion point for thurday's call

On Wed, Dec 13, 2017 at 10:48 AM, Wei Li <[hidden email]> wrote:
Please see my comments inline.

On Wed, Dec 13, 2017 at 9:36 AM, David Martin <[hidden email]> wrote:
including aerogear-dev

On 13 December 2017 at 08:55, Craig Brookes <[hidden email]> 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:
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    




--
Craig Brookes
RHMAP 
@maleck13 Github

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

github: https://github.com/matzew 
twitter: http://twitter.com/mwessendorf

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev