From kboumedh at redhat.com Thu Feb 1 08:39:57 2018 From: kboumedh at redhat.com (Karim Boumedhel) Date: Thu, 1 Feb 2018 09:39:57 +0100 Subject: [Ansible-service-broker] cluster-role escalation In-Reply-To: References: Message-ID: so, for what it's worth, i ve overcome my issue pretty much logging in as an admin user within my apb. the credentials are defined as required parameters so while not perfect, i believe it makes it an acceptable first iteration of this kind of apb. regards, On Wed, Jan 31, 2018 at 9:57 PM, John Matthews wrote: > > > On Wed, Jan 31, 2018 at 2:30 PM, Mo Khan wrote: > >> Just to be clear, I am extremely uncomfortable in giving the ASB any more >> powers. If you want a broker that can manipulate cluster resources, it >> needs to be completely separated from the standard ASB broker that handles >> user requests. A better approach will likely involve the user giving the >> ASB a token that it then uses to perform actions (i.e. the user must have >> the powers needed to perform those actions but the ASB itself does not). >> > > Totally agree, no objections. > Think of the work happening now is R&D effort focused on APB development > for future of how cluster infrastructure APBs can be developed. > > The larger problem of proper permissions for cluster infrastructure has > not been researched yet. > That is future work we have yet to begin. > > > > >> >> Ryan is correct on the scoping of bindings and the escalation checks. >> >> On Wed, Jan 31, 2018 at 1:44 PM, Ryan Hallisey >> wrote: >> >>> Following up on my original post. I found the reason the rolebinding >>> was failing to create the cluster-admin role. My broker service >>> account was not a cluster-admin. This makes sense since you shouldn't >>> be able to elevate to higher permissions that you are. However, >>> adding the cluster-admin role to apb does not provide cluster level >>> access. Since we're creating a role binding, the apb is granted >>> cluster-admin permissions within it's namespace. In order to access >>> cluster level resources (anything outside it's namespace), we need to >>> create a clusterrolebinding. >>> >>> Here's a writeup for adding a feature that will allow developers to >>> have full access to the cluster: >>> https://github.com/openshift/ansible-service-broker/issues/715 >>> >>> -Ryan >>> >>> On Wed, Jan 31, 2018 at 11:20 AM, Ryan Hallisey >>> wrote: >>> > Thanks David, that's really good to know. >>> > >>> > >>> > On Wed, Jan 31, 2018 at 9:13 AM, David Zager >>> wrote: >>> >> Ryan, >>> >> >>> >> My understanding of wanting to run APBs with extra privileges from our >>> >> broker is that this is a feature we would like to support down the >>> line. As >>> >> an aside, it seems worth pointing out that you can workaround this >>> issue by >>> >> using docker run like: >>> >> >>> >> docker run --rm --net=host \ >>> >> -v $HOME/.kube:/opt/apb/.kube:z \ >>> >> -u $UID \ >>> >> ${APB_NAME} ${APB_ACTION:-'provision'} \ >>> >> --extra-vars "namespace=mycoolnamespace" \ >>> >> --extra-vars "etc=etc" >>> >> >>> >> >>> >> Notes on this command: >>> >> >>> >> You need to be using your host's network stack (--net=host) >>> >> Passing your kube config allows the APB to run at your permission >>> level (ie. >>> >> if you are an cluster-admin you can do what you want). >>> >> APB_NAME in this case would be kubevirt-apb >>> >> You may or may not need the namespace argument, I just know that a >>> lot of >>> >> our existing APBs assume that the namespace already exists >>> >> >>> >> I am a huge fan of the idea of using APBs to manage a cluster outside >>> the >>> >> service-catalog/service-broker context. However, I am also excited >>> about >>> >> pursuing the extra privileged APBs in our broker and how we will meet >>> that >>> >> use case, so this is not meant to take away from that discussion. >>> >> >>> >> Thanks, >>> >> David >>> >> >>> >> On Wed, Jan 31, 2018 at 6:13 AM John Matthews >>> wrote: >>> >>> >>> >>> Mo, >>> >>> >>> >>> Do you have any thoughts on the issue Ryan mentions below on being >>> unable >>> >>> to create a rolebinding that is cluster-admin? >>> >>> For background, this is for enabling the Broker to deploy APBs that >>> will >>> >>> modify cluster infrastructure...not a typical application/service but >>> >>> special APBs that require extra privileges. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Jan 30, 2018 at 9:56 PM, Ryan Hallisey >>> >>> wrote: >>> >>>> >>> >>>> Karim, >>> >>>> >>> >>>> I think I have a workaround patch that will get provision working >>> for >>> >>>> the kubevirt-apb. Instructions for how to test it are in the commit >>> >>>> message. >>> >>>> >>> >>>> >>> >>>> https://github.com/rthallisey/ansible-service-broker/commit/ >>> f27e0538959c43d47d2ff80bba1e894f2249ad62 >>> >>>> >>> >>>> To summarize for folks what I think is happening. We need the apb to >>> >>>> have the cluster-admin role so it can create cluster-roles. To do >>> >>>> this, set sandbox_role: cluster-admin, auto_escalate: true, and make >>> >>>> the asb user cluster-admin. Then when you provision, you'll hit >>> this >>> >>>> issue: https://github.com/openshift/ansible-service-broker/issues/7 >>> 11. >>> >>>> The rolebinding fails to create with the error: >>> >>>> rolebindings.rbac.authorization.k8s.io >>> >>>> "apb-9c21c424-7091-4bc1-b5c5-0caa08aeec39" is forbidden: attempt to >>> >>>> grant extra privileges. >>> >>>> It seems that we can't create a rolebinding that is cluster-admin. >>> >>>> I'm still exploring for the reason why it fails, but my theory is >>> that >>> >>>> the cluster-admin role gives access outside the scope of a role so >>> it >>> >>>> requires a clusterrolebinding. With the clusterrolebinding created >>> >>>> with cluster-admin permissions, I was able to create >>> cluster-resources >>> >>>> from the apb. >>> >>>> >>> >>>> Thanks, >>> >>>> -Ryan >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Ansible-service-broker mailing list >>> >>>> Ansible-service-broker at redhat.com >>> >>>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Ansible-service-broker mailing list >>> >>> Ansible-service-broker at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >> >>> >> >>> >> _______________________________________________ >>> >> Ansible-service-broker mailing list >>> >> Ansible-service-broker at redhat.com >>> >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >> >>> >> >> > -- KARIM BOUMEDHEL SENIOR SOFTWARE ENGINEER, RHCA Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzager at redhat.com Thu Feb 1 18:15:20 2018 From: dzager at redhat.com (David Zager) Date: Thu, 01 Feb 2018 18:15:20 +0000 Subject: [Ansible-service-broker] Sprint 141 - Sprint 143 Release Notes Message-ID: Bugs - Bug 1525817 - remove duplicate help output and return 0 exit code. (#594) - Bug 1512042 - Allowing error messages to make it from apb to user. (#607) - Bug 1526887 - Handle case when whitelist/blacklist set to "" (#609) - Bug 1472226 - Add additional field validations for JSON Schema. (#615) - Bug 1533208 - Re adding registry auth as secrets and files (#629) - Bug 1526949 - Set registry user/pass if auth_type is not defined (#635) - Bug 1534715 - unbind checks for existence of binding before trying to delete it (#642) - Bug 1534467 - apiserver was not told how to output error response (#647) - Bug 1534715 - Moves BindInstance retrieval and error handling to handler.go (#648) - Bug 1535652 - return 200 to bind PUT when a binding already exists (#650) - Bug 1506978 - Apply proxy settings to running APBs (#654) - Bug 1535182 - adding ability to retrieve an array of subconfigs (#655) - Bug 1534957 - Fix secret parameters regression (#659) - Bug 1536088 - fixes panic when bind can't find ServiceInstance (#653) - Bug 1536629 - send job state and credentials from job (#610) - Bug 1536659 - bind PUT returns http code 202 when operation runs async (#669) - Bug 1506978 - Include lowercase proxy vars (#683) - Bug 1537367 - missing last_operation for bindings (#677) - Bug 1536629 - Send job msg immediately as job starts. To set initial JobState (#671) - Bug 1537367 - fix the test for last_operation (#688) - Bug 1539757 - async unbind returns http 202 (#704) - Bug 1534957 - Add namespace to broker config docs (#712) Other Enhancements - Remove logging from function and structs. (#582) - Initial proposal for dealing with network isolation SDNs (#572) - stop multiple update apb containers from launching (#595) - Simple template to support my blog post (#597) - Execute into a pod with API for runtime V1 (#596) - allows parameter types to be case-insensitive (#599) - Adding local openshift adapter (#601) - fixing issue with versioning the rbac API. (#618) - Fixes labels on asb Endpoint in local dev template (#598) - remove the different job msg types to avoid duplication of code (#603) - Remove WorkMsg interface to avoid unneeded marshalling and unmarshalling.(#604) - The config should only use type as a key when name does not exist. (#606) - fix incorrect check in if statement (#611) - fix potential nil pointer panic (#613) - Use the router prefix for apb tool endpoints (#616) - Add 3.8/3.9 releasers to tito (#620) - fixes typo in a log statement (#622) - uses "exec" so bash process gets replaced instead of retained (#624) - fixing handler tests in master branch (#630) - Update config doc to document storing creds in a secret (#628) - Add minishift documentation (#627) - Run latest build with a default public ip. (#626) - Fix debug statement for ISV registry to be more verbose (#633) - Async bind feature (#625) - Openshift Multi-tenant Sandbox Hooks (#600) - quiet errors related to docker0 address (#641) - vendor bump to k8s 1.9.1 (#645) - Print information on any pod failures (#646) - Add some missing networking permissions to the k8s template (#657) - make build-image isn't retrying (#656) - Fix linting on ProxyConfig (#662) - Remove ancient comment with app startup (#664) - Remove old comment re: platform version header (#661) - Fail faster with travis (#658) - Update test bash scripts (#668) - Add a second job that runs the broker on k8s (#643) - fixes #665 - remove many of the TODOs (#673) - Skip running the travis job if we're only changing docs (#678) - add ASB debugging guide (#676) - One CI fix and a few improvements (#679) - Continue to load specs even when a spec fails to load (#682) - Add proxy docs (#634) - add a 3.10 releaser (#690) - Remove unecessary dao ref from DeproJob (#691) - Adding ability for Subject Rules Review to do the correct check. (#693) - Make the k8s CI scripts consumable with curl (#695) - update copyright date to 2018 (#699) - Add fall through case to deprovision handler (#700) - Ignore IDE extras (#703) - Check that all the containers in a pod are running (#706) - Proposes solutions for tracking state of BindInstance creation (#680) - revert image back to match blog post in simple broker template. (#714) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Mon Feb 5 21:12:01 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Mon, 5 Feb 2018 16:12:01 -0500 Subject: [Ansible-service-broker] Creating Tests for your APBs Message-ID: Hey folks, There have been some new APBs that have been popping up in the community, which I'm excited to see :). I wanted to make everyone aware that there are multiple paths you to can take to add testing to your apb. First, there's the command `apb test`, which will run a test.yaml playbook to test if your apb is in a working condition. Second, you can add CI to your apb that will run per pull request to your apb's git repo. I published a video today demonstrating how to add CI: https://youtu.be/b-yYZuQllVo. It can test multiple apbs together on top of both openshift and kuberentes using the service-catalog and broker. The more tests the better!! Thanks, - Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Fri Feb 9 14:07:01 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Fri, 9 Feb 2018 09:07:01 -0500 Subject: [Ansible-service-broker] published apb tags Message-ID: Hey folks, Lately I've been trying to fix the ci job on the release-1.0 branch and I was having a hard time locating the APB tag that's correlated with this branch. This was an issue because the release-1.0 branch was cut before we changed the extract credentials method so I need a specific APB. Since we tag APBs based on sprint, I had to look back at the sprint dates in order to narrow my search to a few APB tags. Fortunately for me, I know where to go to find the sprint dates, but that may not be the case for everyone. I think it's worth tagging APBs based on sprints, but I think we should also have a tag per broker release. What do folks think? Thanks, -Ryan From jmatthew at redhat.com Fri Feb 9 14:44:43 2018 From: jmatthew at redhat.com (John Matthews) Date: Fri, 9 Feb 2018 09:44:43 -0500 Subject: [Ansible-service-broker] published apb tags In-Reply-To: References: Message-ID: On Fri, Feb 9, 2018 at 9:07 AM, Ryan Hallisey wrote: > Hey folks, > > Lately I've been trying to fix the ci job on the release-1.0 branch > and I was having a hard time locating the APB tag that's correlated > with this branch. This was an issue because the release-1.0 branch > was cut before we changed the extract credentials method so I need a > specific APB. Since we tag APBs based on sprint, I had to look back > at the sprint dates in order to narrow my search to a few APB tags. > Fortunately for me, I know where to go to find the sprint dates, but > that may not be the case for everyone. > > I think it's worth tagging APBs based on sprints, but I think we > should also have a tag per broker release. What do folks think? > > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Fri Feb 9 14:48:09 2018 From: ernelson at redhat.com (Erik Nelson) Date: Fri, 9 Feb 2018 09:48:09 -0500 Subject: [Ansible-service-broker] published apb tags In-Reply-To: References: Message-ID: +1 , I faced this recently as well. On Fri, Feb 9, 2018 at 9:44 AM, John Matthews wrote: > > On Fri, Feb 9, 2018 at 9:07 AM, Ryan Hallisey wrote: >> >> Hey folks, >> >> Lately I've been trying to fix the ci job on the release-1.0 branch >> and I was having a hard time locating the APB tag that's correlated >> with this branch. This was an issue because the release-1.0 branch >> was cut before we changed the extract credentials method so I need a >> specific APB. Since we tag APBs based on sprint, I had to look back >> at the sprint dates in order to narrow my search to a few APB tags. >> Fortunately for me, I know where to go to find the sprint dates, but >> that may not be the case for everyone. >> >> I think it's worth tagging APBs based on sprints, but I think we >> should also have a tag per broker release. What do folks think? >> > > +1 > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > From jmontleo at redhat.com Fri Feb 9 19:35:37 2018 From: jmontleo at redhat.com (Jason Montleon) Date: Fri, 9 Feb 2018 14:35:37 -0500 Subject: [Ansible-service-broker] published apb tags In-Reply-To: References: Message-ID: If you know the sprint tag there is a retag task in jenkins you can use to create a release-1.0 tag from it for all the existing apb's. Agree we should do that with future releases as well. I forked the copr repo, so if we need to create something we should be able to without too much trouble as well. On 02/09/2018 09:44 AM, John Matthews wrote: > > On Fri, Feb 9, 2018 at 9:07 AM, Ryan Hallisey > wrote: > > Hey folks, > > Lately I've been trying to fix the ci job on the release-1.0 branch > and I was having a hard time locating the APB tag that's correlated > with this branch.? This was an issue because the release-1.0 branch > was cut before we changed the extract credentials method so I need a > specific APB.? Since we tag APBs based on sprint, I had to look back > at the sprint dates in order to narrow my search to a few APB tags. > Fortunately for me, I know where to go to find the sprint dates, but > that may not be the case for everyone. > > I think it's worth tagging APBs based on sprints, but I think we > should also have a tag per broker release.? What do folks think? > > > +1 > > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -- Jason Montleon | email: jmontleo at redhat.com Software Engineer | gpg key: 0x069E3022 Red Hat, Inc. | irc: jmontleo desk: 978-392-3930 | cell: 508-496-0663 From pgough at redhat.com Mon Feb 12 21:30:16 2018 From: pgough at redhat.com (Philip Gough) Date: Mon, 12 Feb 2018 21:30:16 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour Message-ID: Hi all, I have had some over and back discussion with the owners of the service broker over IRC and on this pull request in relation to issue #666 . Ryan suggested I open up this thread for discussion on how we will handle failed deprovisions, whilst remaining compliant to the spec. To summarise the conversation, the spec states that "When a Service Broker receives a deprovision request from a Platform, it MUST delete any resources it created during the provision." , my question to Ryan was what happens in the case of a deprovision when the playbook is broken and it fails early. This leaves potentially many kubernetes resources orphaned within a namespace. Since we don't track this particular resources, we then have no way to delete them later. The linked pr sets a flag to overwrite the current behaviour, which is spec compliant with regards to return codes as is. We are wondering what people think the default behaviour should be and what could be done with these untracked resources when a playbook fails. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Tue Feb 13 19:51:41 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 13 Feb 2018 14:51:41 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: Message-ID: Thanks for starting the thread Philip. Shawn and John brought to my attention that there were some issues created in the service-catalog recently around this topic. I posted our idea of using a broker config option for "force_delete" in the issue: https://github.com/kubernetes-incubator/service-catalog/issues/1723 to gather some feedback. -Ryan On Mon, Feb 12, 2018 at 4:30 PM, Philip Gough wrote: > Hi all, > > I have had some over and back discussion with the owners of the service > broker over IRC and on this pull request > in > relation to issue #666 > . Ryan > suggested I open up this thread for discussion on how we will handle failed > deprovisions, whilst remaining compliant to the spec. > > To summarise the conversation, the spec states that "When a Service > Broker receives a deprovision request from a Platform, it MUST delete any > resources it created during the provision." , my question to Ryan was > what happens in the case of a deprovision when the playbook is broken and > it fails early. > > This leaves potentially many kubernetes resources orphaned within a > namespace. Since we don't track this particular resources, we then have no > way to delete them later. > > The linked pr sets a flag to overwrite the current behaviour, which is > spec compliant with regards to return codes as is. We are wondering what > people think the default behaviour should be and what could be done with > these untracked resources when a playbook fails. > > Regards > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravijo at gmail.com Tue Feb 13 21:59:58 2018 From: ravijo at gmail.com (Ravi Jonnadula) Date: Tue, 13 Feb 2018 13:59:58 -0800 Subject: [Ansible-service-broker] Use case for Broker module Message-ID: Hello, I 'm trying to use Ansible Service Broker module in the following scenario. Basically, the Broker services are invoked by the controller to perform some actions on the remote system. The remote system can be a VM or Kubernetes cluster. In the former case, the ansible commands are executed on the VM. In the later case, the ansible commands will interface with Kube-Scheduler. The typical services the Broker shall provide are: 1) Provision some software on the remote system. 2) Push a given file by the controller to a specific remote VM / POD 3) Execute a specific command given by the controller on the remote system. [image: Inline image 4] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 46991 bytes Desc: not available URL: From shurley at redhat.com Tue Feb 13 22:29:13 2018 From: shurley at redhat.com (Shawn Hurley) Date: Tue, 13 Feb 2018 17:29:13 -0500 Subject: [Ansible-service-broker] Release 1.0 CI Fix Message-ID: Hello All, I have a small PR up that should fix the CI for release 1.0. @Ryan I borrowed some stuff from your WIP PR as well, it seems that the combo of the changes has fixed the problem. Also I noticed that we no longer need the dist upgrade on each run of CI. I think that we should also change this for master and release 1.1. I don?t think that we should need a bug for this fix and will post a PR tomorrow unless someone wants to take this issue up. Thanks, Shawn Hurley From shurley at redhat.com Tue Feb 13 22:29:41 2018 From: shurley at redhat.com (Shawn Hurley) Date: Tue, 13 Feb 2018 17:29:41 -0500 Subject: [Ansible-service-broker] Release 1.0 CI Fix In-Reply-To: References: Message-ID: Forgot the PR link: https://github.com/openshift/ansible-service-broker/pull/760 Sorry - Shawn > On Feb 13, 2018, at 5:29 PM, Shawn Hurley wrote: > > Hello All, > > I have a small PR up that should fix the CI for release 1.0. > > @Ryan I borrowed some stuff from your WIP PR as well, it seems that the combo of the changes has fixed the problem. > > Also I noticed that we no longer need the dist upgrade on each run of CI. I think that we should also change this for master and release 1.1. I don?t think that we should need a bug for this fix and will post a PR tomorrow unless someone wants to take this issue up. > > Thanks, > > Shawn Hurley -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Wed Feb 14 00:19:18 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 13 Feb 2018 19:19:18 -0500 Subject: [Ansible-service-broker] Release 1.0 CI Fix In-Reply-To: References: Message-ID: Thanks Shawn! I'm glad we got that working again. > Also I noticed that we no longer need the dist upgrade on each run of CI. > The kubernetes job we have didn't need the dist upgrade. Something must've changed upstream, but I wasn't sure if it propagated to the latest openshift release. Looks like it did. I'll post PRs dropping the dist upgrade. Thanks, -Ryan On Tue, Feb 13, 2018 at 5:29 PM, Shawn Hurley wrote: > Forgot the PR link: https://github.com/openshift/ansible-service- > broker/pull/760 > > Sorry > > - Shawn > > On Feb 13, 2018, at 5:29 PM, Shawn Hurley wrote: > > Hello All, > > I have a small PR up that should fix the CI for release 1.0. > > @Ryan I borrowed some stuff from your WIP PR as well, it seems that the > combo of the changes has fixed the problem. > > Also I noticed that we no longer need the dist upgrade on each run of CI. > I think that we should also change this for master and release 1.1. I don?t > think that we should need a bug for this fix and will post a PR tomorrow > unless someone wants to take this issue up. > > Thanks, > > Shawn Hurley > > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Wed Feb 14 00:24:28 2018 From: ernelson at redhat.com (Erik Nelson) Date: Tue, 13 Feb 2018 19:24:28 -0500 Subject: [Ansible-service-broker] Release 1.0 CI Fix In-Reply-To: References: Message-ID: @Ryan, I merged Shawn's PR. You have another PR that looked like a WIP for release-1.0? Is your PR required anymore now that Shawns is merged, or is it doing something else? On Tue, Feb 13, 2018 at 7:19 PM, Ryan Hallisey wrote: > Thanks Shawn! I'm glad we got that working again. > >> Also I noticed that we no longer need the dist upgrade on each run of CI. >> > The kubernetes job we have didn't need the dist upgrade. Something must've > changed upstream, but I wasn't sure if it propagated to the latest openshift > release. Looks like it did. I'll post PRs dropping the dist upgrade. > > Thanks, > -Ryan > > On Tue, Feb 13, 2018 at 5:29 PM, Shawn Hurley wrote: >> >> Forgot the PR link: >> https://github.com/openshift/ansible-service-broker/pull/760 >> >> Sorry >> >> - Shawn >> >> On Feb 13, 2018, at 5:29 PM, Shawn Hurley wrote: >> >> Hello All, >> >> I have a small PR up that should fix the CI for release 1.0. >> >> @Ryan I borrowed some stuff from your WIP PR as well, it seems that the >> combo of the changes has fixed the problem. >> >> Also I noticed that we no longer need the dist upgrade on each run of CI. >> I think that we should also change this for master and release 1.1. I don?t >> think that we should need a bug for this fix and will post a PR tomorrow >> unless someone wants to take this issue up. >> >> Thanks, >> >> Shawn Hurley >> >> >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > From rhallise at redhat.com Wed Feb 14 00:25:54 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 13 Feb 2018 19:25:54 -0500 Subject: [Ansible-service-broker] Release 1.0 CI Fix In-Reply-To: References: Message-ID: It's no longer required. Closing it now. -Ryan On Tue, Feb 13, 2018 at 7:24 PM, Erik Nelson wrote: > @Ryan, I merged Shawn's PR. You have another PR that looked like a WIP > for release-1.0? Is your PR required anymore now that Shawns is > merged, or is it doing something else? > > On Tue, Feb 13, 2018 at 7:19 PM, Ryan Hallisey > wrote: > > Thanks Shawn! I'm glad we got that working again. > > > >> Also I noticed that we no longer need the dist upgrade on each run of > CI. > >> > > The kubernetes job we have didn't need the dist upgrade. Something > must've > > changed upstream, but I wasn't sure if it propagated to the latest > openshift > > release. Looks like it did. I'll post PRs dropping the dist upgrade. > > > > Thanks, > > -Ryan > > > > On Tue, Feb 13, 2018 at 5:29 PM, Shawn Hurley > wrote: > >> > >> Forgot the PR link: > >> https://github.com/openshift/ansible-service-broker/pull/760 > >> > >> Sorry > >> > >> - Shawn > >> > >> On Feb 13, 2018, at 5:29 PM, Shawn Hurley wrote: > >> > >> Hello All, > >> > >> I have a small PR up that should fix the CI for release 1.0. > >> > >> @Ryan I borrowed some stuff from your WIP PR as well, it seems that the > >> combo of the changes has fixed the problem. > >> > >> Also I noticed that we no longer need the dist upgrade on each run of > CI. > >> I think that we should also change this for master and release 1.1. I > don?t > >> think that we should need a bug for this fix and will post a PR tomorrow > >> unless someone wants to take this issue up. > >> > >> Thanks, > >> > >> Shawn Hurley > >> > >> > >> > >> _______________________________________________ > >> Ansible-service-broker mailing list > >> Ansible-service-broker at redhat.com > >> https://www.redhat.com/mailman/listinfo/ansible-service-broker > >> > > > > > > _______________________________________________ > > Ansible-service-broker mailing list > > Ansible-service-broker at redhat.com > > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgough at redhat.com Mon Feb 12 11:44:09 2018 From: pgough at redhat.com (Philip Gough) Date: Mon, 12 Feb 2018 11:44:09 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour Message-ID: Hi all, I have had some over and back discussion with the owners of the service broker over IRC and on this pull request in relation to issue #666 . Ryan suggested I open up this thread for discussion on how we will handle failed deprovisions, whilst remaining compliant to the spec. To summarise the conversation, the spec states that "When a Service Broker receives a deprovision request from a Platform, it MUST delete any resources it created during the provision." , my question to Ryan was what happens in the case of a deprovision when the playbook is broken and it fails early. This leaves potentially many kubernetes resources orphaned within a namespace. Since we don't track this particular resources, we then have no way to delete them later. The linked pr sets a flag to overwrite the current behaviour, which is spec compliant with regards to return codes as is. We are wondering what people think the default behaviour should be and what could be done with these untracked resources when a playbook fails. Regards Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmatthew at redhat.com Wed Feb 14 14:52:41 2018 From: jmatthew at redhat.com (John Matthews) Date: Wed, 14 Feb 2018 09:52:41 -0500 Subject: [Ansible-service-broker] Use case for Broker module In-Reply-To: References: Message-ID: Hi Ravi, Thank you for sharing your use case and the helpful diagram. We haven't explored running ansible playbooks directly on a remote system through a launched APB yet. I imagine some work will be required to setup the inventory/ssh credentials and pass into the APB, Use Case sounds like a future capability that would be interesting to have. Our current workflow is to run the ansible playbooks on localhost of the launched Pod, then the ansible modules interact with remote hosts through API calls (i.e. AWS APBs are a good example of interacting with a remote API, https://github.com/search?q=org%3Aawslabs+servicebroker). On Tue, Feb 13, 2018 at 4:59 PM, Ravi Jonnadula wrote: > Hello, > > I 'm trying to use Ansible Service Broker module in the following scenario. > > Basically, the Broker services are invoked by the controller to perform > some actions on the remote system. The remote system can be a VM or > Kubernetes cluster. In the former case, the ansible commands are executed > on the VM. In the later case, the ansible commands will interface with > Kube-Scheduler. > > The typical services the Broker shall provide are: > 1) Provision some software on the remote system. > 2) Push a given file by the controller to a specific remote VM / POD > 3) Execute a specific command given by the controller on the remote system. > > > > [image: Inline image 4] > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 46991 bytes Desc: not available URL: From shurley at redhat.com Wed Feb 14 15:09:49 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 14 Feb 2018 10:09:49 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: Message-ID: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Hey everyone, Thanks for the idea Philip. I do agree that the problem described is something that the broker team needs to fix for the APB developers and we should fix it sooner rather than later. I don?t know if I feel comfortable with adding this logic to the primary code path for deprovision. This is mostly me being conservative with adding configuration values that can allow things to get deleted from our storage. With that said, I don?t have a well thought out alternative. Off the cuff I would suggest that we add an API surface to delete this instance, that would only be available if you have a configuration value set something similar to dev_broker config. I would also like to mention that with the CRD changes that are on the roadmap, this is doable just by granting the correct permissions and knowing the correct resource to delete with the oc command. This is something that we may also want to keep in mind. Thanks, Shawn > On Feb 13, 2018, at 2:51 PM, Ryan Hallisey wrote: > > Thanks for starting the thread Philip. > > Shawn and John brought to my attention that there were some issues created in the service-catalog recently around this topic. I posted our idea of using a broker config option for "force_delete" in the issue: https://github.com/kubernetes-incubator/service-catalog/issues/1723 to gather some feedback. > > -Ryan > > > On Mon, Feb 12, 2018 at 4:30 PM, Philip Gough > wrote: > Hi all, > > I have had some over and back discussion with the owners of the service broker over IRC and on this pull request in relation to issue #666 . Ryan suggested I open up this thread for discussion on how we will handle failed deprovisions, whilst remaining compliant to the spec. > > To summarise the conversation, the spec states that "When a Service Broker receives a deprovision request from a Platform, it MUST delete any resources it created during the provision." , my question to Ryan was what happens in the case of a deprovision when the playbook is broken and it fails early. > > This leaves potentially many kubernetes resources orphaned within a namespace. Since we don't track this particular resources, we then have no way to delete them later. > > The linked pr sets a flag to overwrite the current behaviour, which is spec compliant with regards to return codes as is. We are wondering what people think the default behaviour should be and what could be done with these untracked resources when a playbook fails. > > Regards > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Wed Feb 14 15:32:21 2018 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 14 Feb 2018 10:32:21 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Message-ID: > I don?t know if I feel comfortable with adding this logic to the primary > code path for deprovision. This is mostly me being conservative with adding > configuration values that can allow things to get deleted from our storage. The developer experience is not acceptable right now, but I have to agree with Shawn. > With that said, I don?t have a well thought out alternative. Off the cuff I > would suggest that we add an API surface to delete this instance, that would > only be available if you have a configuration value set something similar to > dev_broker config. Unless I missed it, let's backup and describe the high-level problem in a proposal and submit solutions there. That's been our approach thus far and I think it applies here well. > I would also like to mention that with the CRD changes that are on the > roadmap, this is doable just by granting the correct permissions and knowing > the correct resource to delete with the oc command. This is something that > we may also want to keep in mind. This should be called on on the proposal. From rhallise at redhat.com Wed Feb 14 16:29:19 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Wed, 14 Feb 2018 11:29:19 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Message-ID: >> I don?t know if I feel comfortable with adding this logic to the primary >> code path for deprovision. This is mostly me being conservative with adding >> configuration values that can allow things to get deleted from our storage. >> > The developer experience is not acceptable right now, but I have to > agree with Shawn. > Agreed, the dev experience is really rough with deprovision. For instance, if you are testing your provision playbook with the broker and your deprovision playbook fails, then you can't test provision again without some manually steps. But, I think Phillip's patch is a good way to provide significant improvement to the dev experience with minimal code changes. The meat of his code is 4 lines: ```go if a.brokerConfig.ForceDelete { log.Infof("Deprovision failed. Attempting to clean up related resources. User should ensure clean up is successful") cleanupDeprovision(&instance, a.dao) // Return a 200 to the service-catlog } ``` > Unless I missed it, let's backup and describe the high-level problem > in a proposal and > submit solutions there. That's been our approach thus far and I think > it applies here well. To make this the default behaviour, I agree needs a proposal. -Ryan On Wed, Feb 14, 2018 at 10:32 AM, Erik Nelson wrote: > > I don?t know if I feel comfortable with adding this logic to the primary > > code path for deprovision. This is mostly me being conservative with > adding > > configuration values that can allow things to get deleted from our > storage. > > The developer experience is not acceptable right now, but I have to > agree with Shawn. > > > With that said, I don?t have a well thought out alternative. Off the > cuff I > > would suggest that we add an API surface to delete this instance, that > would > > only be available if you have a configuration value set something > similar to > > dev_broker config. > > Unless I missed it, let's backup and describe the high-level problem > in a proposal and > submit solutions there. That's been our approach thus far and I think > it applies here well. > > > I would also like to mention that with the CRD changes that are on the > > roadmap, this is doable just by granting the correct permissions and > knowing > > the correct resource to delete with the oc command. This is something > that > > we may also want to keep in mind. > > This should be called on on the proposal. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhrivnak at redhat.com Wed Feb 14 16:45:42 2018 From: mhrivnak at redhat.com (Michael Hrivnak) Date: Wed, 14 Feb 2018 11:45:42 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Message-ID: If an async unbind fails, it creates a similar situation to a failed deprovision. This bug for example is a result of the broker deleting its own records of a binding before the cluster-based resources have been deleted: https://github.com/openshift/ansible-service-broker/issues/709 I suspect whatever approach we take to deal with this dilemma will work for both cases, but it's worth keeping them both in mind. On Wed, Feb 14, 2018 at 11:29 AM, Ryan Hallisey wrote: > >> I don?t know if I feel comfortable with adding this logic to the primary > >> code path for deprovision. This is mostly me being conservative with > adding > >> configuration values that can allow things to get deleted from our > storage. > >> > > The developer experience is not acceptable right now, but I have to > > agree with Shawn. > > > Agreed, the dev experience is really rough with deprovision. For instance, > if you are testing your provision playbook with the broker and your > deprovision playbook fails, then you can't test provision again without > some manually steps. But, I think Phillip's patch is a good way to provide > significant improvement to the dev experience with minimal code changes. > The meat of his code is 4 lines: > > ```go > if a.brokerConfig.ForceDelete { > log.Infof("Deprovision failed. Attempting to clean up related > resources. User should ensure clean up is successful") > cleanupDeprovision(&instance, a.dao) // Return a 200 to the > service-catlog > } > ``` > > > Unless I missed it, let's backup and describe the high-level problem > > in a proposal and > > submit solutions there. That's been our approach thus far and I think > > it applies here well. > To make this the default behaviour, I agree needs a proposal. > > -Ryan > > > On Wed, Feb 14, 2018 at 10:32 AM, Erik Nelson wrote: > >> > I don?t know if I feel comfortable with adding this logic to the primary >> > code path for deprovision. This is mostly me being conservative with >> adding >> > configuration values that can allow things to get deleted from our >> storage. >> >> The developer experience is not acceptable right now, but I have to >> agree with Shawn. >> >> > With that said, I don?t have a well thought out alternative. Off the >> cuff I >> > would suggest that we add an API surface to delete this instance, that >> would >> > only be available if you have a configuration value set something >> similar to >> > dev_broker config. >> >> Unless I missed it, let's backup and describe the high-level problem >> in a proposal and >> submit solutions there. That's been our approach thus far and I think >> it applies here well. >> >> > I would also like to mention that with the CRD changes that are on the >> > roadmap, this is doable just by granting the correct permissions and >> knowing >> > the correct resource to delete with the oc command. This is something >> that >> > we may also want to keep in mind. >> >> This should be called on on the proposal. >> > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesusr at redhat.com Wed Feb 14 16:49:10 2018 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 14 Feb 2018 11:49:10 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Message-ID: <1518626950.11898.23.camel@redhat.com> On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote: > > > I don?t know if I feel comfortable with adding this logic to the > > > primary > > > code path for deprovision. This is mostly me being conservative > > > with > > adding > > > configuration values that can allow things to get deleted from > > > our > > storage. > > > > > > > The developer experience is not acceptable right now, but I have to > > agree with Shawn. > > > > Agreed, the dev experience is really rough with deprovision. For > instance, > if you are testing your provision playbook with the broker and your > deprovision playbook fails, then you can't test provision again > without > some manually steps. But, I think Phillip's patch is a good way to > provide > significant improvement to the dev experience with minimal code > changes. > The meat of his code is 4 lines: > > ```go > if a.brokerConfig.ForceDelete { > log.Infof("Deprovision failed. Attempting to clean up related > resources. > User should ensure clean up is successful") > cleanupDeprovision(&instance, a.dao) // Return a 200 to the > service-catlog > } > ``` I think the problem is not necessarily that it is a seemingly small patch. But that there is an overall bigger issue that the dev experience isn't completely thought out yet. So while sure adding this flag seems to fix one aspect of it, albeit a key aspect, it would be better to see a proposal on dev experience from a developer perspective. And try to address the issues outlined and discussed. That discussion might lead to this exact patch, but it will be seen in the broader picture of how to fix the dev experience. My hesitation with applying this right now is I'd rather see what the broader list of dev experience problems are. How we can address them? Do we have a single flag that enables a bunch of things? Do we have a set of dev flags that can be flipped for individual things? Etc. We already have a dev_broker flag. Now this patch is adding a force_delete flag. While it is to fix a dev experience problem, how do I know that flag is just for dev? What are the implications of enabling said flag in a production environment? It's the list of subtleties that I'd like to at least see or anticipate before addressing just one aspect of a problem. > > > Unless I missed it, let's backup and describe the high-level > > problem > > in a proposal and > > submit solutions there. That's been our approach thus far and I > > think > > it applies here well. > > To make this the default behaviour, I agree needs a proposal. I would rather have a proposal to discuss the dev experience and needs. Then have a series of PRs to address the needs that come from that proposal. Again this patch fixes only one aspect of the dev experience. jesus From jesusr at redhat.com Wed Feb 14 16:51:30 2018 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 14 Feb 2018 11:51:30 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> Message-ID: <1518627090.11898.25.camel@redhat.com> On Wed, 2018-02-14 at 11:45 -0500, Michael Hrivnak wrote: > If an async unbind fails, it creates a similar situation to a failed > deprovision. This bug for example is a result of the broker deleting > its > own records of a binding before the cluster-based resources have been > deleted: > > https://github.com/openshift/ansible-service-broker/issues/709 > > I suspect whatever approach we take to deal with this dilemma will > work for > both cases, but it's worth keeping them both in mind. This is a great example of what I'm talking about. Let's step back to look at the issue to see if it lends itself to any broader things in the broker. As Michael points out here, there is a situation that isn't necessarily dev experience related that could use a means to remove resources. jesus From cbrookes at redhat.com Wed Feb 14 16:59:49 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 14 Feb 2018 16:59:49 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: <1518627090.11898.25.camel@redhat.com> References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> <1518627090.11898.25.camel@redhat.com> Message-ID: I like the idea of a proposal around this, to me though dev experience might be a bit broad. Perhaps concretely defining and agreeing what actions the broker takes in the situation of a failed APB for each of the APB actions would be a good starting place? I have a feeling we will likely find that if we do that, we wont need different behavior between dev and prod? On Wed, Feb 14, 2018 at 4:51 PM, jesus m. rodriguez wrote: > On Wed, 2018-02-14 at 11:45 -0500, Michael Hrivnak wrote: > > If an async unbind fails, it creates a similar situation to a failed > > deprovision. This bug for example is a result of the broker deleting > > its > > own records of a binding before the cluster-based resources have been > > deleted: > > > > https://github.com/openshift/ansible-service-broker/issues/709 > > > > I suspect whatever approach we take to deal with this dilemma will > > work for > > both cases, but it's worth keeping them both in mind. > > This is a great example of what I'm talking about. Let's step back to > look at the issue to see if it lends itself to any broader things in > the broker. As Michael points out here, there is a situation that isn't > necessarily dev experience related that could use a means to remove > resources. > > jesus > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Wed Feb 14 17:09:18 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Wed, 14 Feb 2018 12:09:18 -0500 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: <1518626950.11898.23.camel@redhat.com> References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> <1518626950.11898.23.camel@redhat.com> Message-ID: > So while sure adding this flag seems to fix one aspect of it, albeit a > key aspect, it would be better to see a proposal on dev experience from > a developer perspective. And try to address the issues outlined and > discussed. That discussion might lead to this exact patch, but it will > be seen in the broader picture of how to fix the dev experience. > Sounds good, let's go with a broader dev proposal. Philip, is that something you would be wiling to start? Here's a link to the template https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/proposal-template.md -Ryan On Wed, Feb 14, 2018 at 11:49 AM, jesus m. rodriguez wrote: > On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote: > > > > I don?t know if I feel comfortable with adding this logic to the > > > > primary > > > > code path for deprovision. This is mostly me being conservative > > > > with > > > > adding > > > > configuration values that can allow things to get deleted from > > > > our > > > > storage. > > > > > > > > > > The developer experience is not acceptable right now, but I have to > > > agree with Shawn. > > > > > > > Agreed, the dev experience is really rough with deprovision. For > > instance, > > if you are testing your provision playbook with the broker and your > > deprovision playbook fails, then you can't test provision again > > without > > some manually steps. But, I think Phillip's patch is a good way to > > provide > > significant improvement to the dev experience with minimal code > > changes. > > The meat of his code is 4 lines: > > > > ```go > > if a.brokerConfig.ForceDelete { > > log.Infof("Deprovision failed. Attempting to clean up related > > resources. > > User should ensure clean up is successful") > > cleanupDeprovision(&instance, a.dao) // Return a 200 to the > > service-catlog > > } > > ``` > > I think the problem is not necessarily that it is a seemingly small > patch. But that there is an overall bigger issue that the dev > experience isn't completely thought out yet. > > So while sure adding this flag seems to fix one aspect of it, albeit a > key aspect, it would be better to see a proposal on dev experience from > a developer perspective. And try to address the issues outlined and > discussed. That discussion might lead to this exact patch, but it will > be seen in the broader picture of how to fix the dev experience. > > My hesitation with applying this right now is I'd rather see what the > broader list of dev experience problems are. How we can address them? > Do we have a single flag that enables a bunch of things? Do we have a > set of dev flags that can be flipped for individual things? Etc. > > We already have a dev_broker flag. Now this patch is adding a > force_delete flag. While it is to fix a dev experience problem, how do > I know that flag is just for dev? What are the implications of enabling > said flag in a production environment? It's the list of subtleties that > I'd like to at least see or anticipate before addressing just one > aspect of a problem. > > > > > > Unless I missed it, let's backup and describe the high-level > > > problem > > > in a proposal and > > > submit solutions there. That's been our approach thus far and I > > > think > > > it applies here well. > > > > To make this the default behaviour, I agree needs a proposal. > > I would rather have a proposal to discuss the dev experience and needs. > Then have a series of PRs to address the needs that come from that > proposal. Again this patch fixes only one aspect of the dev experience. > > jesus > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgough at redhat.com Wed Feb 14 17:14:19 2018 From: pgough at redhat.com (Philip Gough) Date: Wed, 14 Feb 2018 17:14:19 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> <1518626950.11898.23.camel@redhat.com> Message-ID: Sure, I'll get something going asap. Philip On Wed, Feb 14, 2018 at 5:09 PM, Ryan Hallisey wrote: > > So while sure adding this flag seems to fix one aspect of it, albeit a > > key aspect, it would be better to see a proposal on dev experience from > > a developer perspective. And try to address the issues outlined and > > discussed. That discussion might lead to this exact patch, but it will > > be seen in the broader picture of how to fix the dev experience. > > > Sounds good, let's go with a broader dev proposal. Philip, is that > something you would be wiling to start? Here's a link to the template > https://github.com/openshift/ansible-service-broker/blob/ > master/docs/proposals/proposal-template.md > > -Ryan > > On Wed, Feb 14, 2018 at 11:49 AM, jesus m. rodriguez > wrote: > >> On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote: >> > > > I don?t know if I feel comfortable with adding this logic to the >> > > > primary >> > > > code path for deprovision. This is mostly me being conservative >> > > > with >> > >> > adding >> > > > configuration values that can allow things to get deleted from >> > > > our >> > >> > storage. >> > > > >> > > >> > > The developer experience is not acceptable right now, but I have to >> > > agree with Shawn. >> > > >> > >> > Agreed, the dev experience is really rough with deprovision. For >> > instance, >> > if you are testing your provision playbook with the broker and your >> > deprovision playbook fails, then you can't test provision again >> > without >> > some manually steps. But, I think Phillip's patch is a good way to >> > provide >> > significant improvement to the dev experience with minimal code >> > changes. >> > The meat of his code is 4 lines: >> > >> > ```go >> > if a.brokerConfig.ForceDelete { >> > log.Infof("Deprovision failed. Attempting to clean up related >> > resources. >> > User should ensure clean up is successful") >> > cleanupDeprovision(&instance, a.dao) // Return a 200 to the >> > service-catlog >> > } >> > ``` >> >> I think the problem is not necessarily that it is a seemingly small >> patch. But that there is an overall bigger issue that the dev >> experience isn't completely thought out yet. >> >> So while sure adding this flag seems to fix one aspect of it, albeit a >> key aspect, it would be better to see a proposal on dev experience from >> a developer perspective. And try to address the issues outlined and >> discussed. That discussion might lead to this exact patch, but it will >> be seen in the broader picture of how to fix the dev experience. >> >> My hesitation with applying this right now is I'd rather see what the >> broader list of dev experience problems are. How we can address them? >> Do we have a single flag that enables a bunch of things? Do we have a >> set of dev flags that can be flipped for individual things? Etc. >> >> We already have a dev_broker flag. Now this patch is adding a >> force_delete flag. While it is to fix a dev experience problem, how do >> I know that flag is just for dev? What are the implications of enabling >> said flag in a production environment? It's the list of subtleties that >> I'd like to at least see or anticipate before addressing just one >> aspect of a problem. >> >> > >> > > Unless I missed it, let's backup and describe the high-level >> > > problem >> > > in a proposal and >> > > submit solutions there. That's been our approach thus far and I >> > > think >> > > it applies here well. >> > >> > To make this the default behaviour, I agree needs a proposal. >> >> I would rather have a proposal to discuss the dev experience and needs. >> Then have a series of PRs to address the needs that come from that >> proposal. Again this patch fixes only one aspect of the dev experience. >> >> jesus >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravijo at gmail.com Wed Feb 14 18:21:50 2018 From: ravijo at gmail.com (Ravi Jonnadula) Date: Wed, 14 Feb 2018 18:21:50 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> <1518626950.11898.23.camel@redhat.com> Message-ID: One suggestion I would like to make is to let APB automatically build deprovision-playbook based on the provision-playbook, instead of letting it to the user to define. That IMO will minimize the possibility of deprovision failure as long as provision succeeds. Of course, this deprovision-playbook need to be maintained by APB internally corresponding to each provisioned module and maintain association between them. Ravi On Wed, Feb 14, 2018 at 9:16 AM Philip Gough wrote: > Sure, I'll get something going asap. > > Philip > > On Wed, Feb 14, 2018 at 5:09 PM, Ryan Hallisey > wrote: > >> > So while sure adding this flag seems to fix one aspect of it, albeit a >> > key aspect, it would be better to see a proposal on dev experience from >> > a developer perspective. And try to address the issues outlined and >> > discussed. That discussion might lead to this exact patch, but it will >> > be seen in the broader picture of how to fix the dev experience. >> > >> Sounds good, let's go with a broader dev proposal. Philip, is that >> something you would be wiling to start? Here's a link to the template >> https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/proposal-template.md >> >> -Ryan >> >> On Wed, Feb 14, 2018 at 11:49 AM, jesus m. rodriguez >> wrote: >> >>> On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote: >>> > > > I don?t know if I feel comfortable with adding this logic to the >>> > > > primary >>> > > > code path for deprovision. This is mostly me being conservative >>> > > > with >>> > >>> > adding >>> > > > configuration values that can allow things to get deleted from >>> > > > our >>> > >>> > storage. >>> > > > >>> > > >>> > > The developer experience is not acceptable right now, but I have to >>> > > agree with Shawn. >>> > > >>> > >>> > Agreed, the dev experience is really rough with deprovision. For >>> > instance, >>> > if you are testing your provision playbook with the broker and your >>> > deprovision playbook fails, then you can't test provision again >>> > without >>> > some manually steps. But, I think Phillip's patch is a good way to >>> > provide >>> > significant improvement to the dev experience with minimal code >>> > changes. >>> > The meat of his code is 4 lines: >>> > >>> > ```go >>> > if a.brokerConfig.ForceDelete { >>> > log.Infof("Deprovision failed. Attempting to clean up related >>> > resources. >>> > User should ensure clean up is successful") >>> > cleanupDeprovision(&instance, a.dao) // Return a 200 to the >>> > service-catlog >>> > } >>> > ``` >>> >>> I think the problem is not necessarily that it is a seemingly small >>> patch. But that there is an overall bigger issue that the dev >>> experience isn't completely thought out yet. >>> >>> So while sure adding this flag seems to fix one aspect of it, albeit a >>> key aspect, it would be better to see a proposal on dev experience from >>> a developer perspective. And try to address the issues outlined and >>> discussed. That discussion might lead to this exact patch, but it will >>> be seen in the broader picture of how to fix the dev experience. >>> >>> My hesitation with applying this right now is I'd rather see what the >>> broader list of dev experience problems are. How we can address them? >>> Do we have a single flag that enables a bunch of things? Do we have a >>> set of dev flags that can be flipped for individual things? Etc. >>> >>> We already have a dev_broker flag. Now this patch is adding a >>> force_delete flag. While it is to fix a dev experience problem, how do >>> I know that flag is just for dev? What are the implications of enabling >>> said flag in a production environment? It's the list of subtleties that >>> I'd like to at least see or anticipate before addressing just one >>> aspect of a problem. >>> >>> > >>> > > Unless I missed it, let's backup and describe the high-level >>> > > problem >>> > > in a proposal and >>> > > submit solutions there. That's been our approach thus far and I >>> > > think >>> > > it applies here well. >>> > >>> > To make this the default behaviour, I agree needs a proposal. >>> >>> I would rather have a proposal to discuss the dev experience and needs. >>> Then have a series of PRs to address the needs that come from that >>> proposal. Again this patch fixes only one aspect of the dev experience. >>> >>> jesus >>> >>> _______________________________________________ >>> Ansible-service-broker mailing list >>> Ansible-service-broker at redhat.com >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >> >> > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Wed Feb 14 19:37:58 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 14 Feb 2018 14:37:58 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility Message-ID: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> Hello All, As I start to move down the path to CRDs. I am worried about the impact of the deployment templates. Anytime something has changed to this in the past it has created a lot of issues. I am wondering how we can separate these different deployments. We have tags and GitHub branches and the like that I think this might be doable, but wanted to open up the discussion to get feedback on how people see this working. I think that we should: 1. Tag every deployment template to use a specific version of the broker. 2. Give Catasb the ability change which template it uses based on the release branch. i.e latest uses master, 1.1 uses release-1.1. 3. run_latest_build.sh will continue to only work with the latest code. (master branch deployment template and bleeding edge oc). 4. Need help to understand what mini shift should do, @erik would the combination of branch and image tag be enough? 5. any other deployment templates that will need to be separated? Thanks for your guys help, I want this to be a smoother transition than it has in the past. Regards, Shawn Hurley From jesusr at redhat.com Wed Feb 14 19:48:47 2018 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 14 Feb 2018 14:48:47 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> Message-ID: <1518637727.11898.49.camel@redhat.com> On Wed, 2018-02-14 at 14:37 -0500, Shawn Hurley wrote: > Hello All, > > As I start to move down the path to CRDs. I am worried about the > impact of the deployment templates. Anytime something has changed to > this in the past it has created a lot of issues. > > I am wondering how we can separate these different deployments. We > have tags and GitHub branches and the like that I think this might be > doable, but wanted to open up the discussion to get feedback on how > people see this working. > > I think that we should: > > 1. Tag every deployment template to use a specific version of the > broker. tag how? git? naming convention? > 2. Give Catasb the ability change which template it uses based on the > release branch. i.e latest uses master, 1.1 uses release-1.1. That would be very useful, I tend to override the asb_template_url value in my my_vars.yaml config to use my local template since it's the one I'm modifying as I work on the broker. So I think this would be pretty easy to do. > 3. run_latest_build.sh will continue to only work with the latest > code. (master branch deployment template and bleeding edge oc). +1 > 4. Need help to understand what mini shift should do, @erik would the > combination of branch and image tag be enough? > 5. any other deployment templates that will need to be separated? We do have the simple-broker-template.yaml that is referenced from the "Up and Running with the Ansible Broker" blog post. jesus From shurley at redhat.com Wed Feb 14 20:02:17 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 14 Feb 2018 15:02:17 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <1518637727.11898.49.camel@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <1518637727.11898.49.camel@redhat.com> Message-ID: <36254AED-4D41-47CF-BEC2-43948A8CBAC4@redhat.com> > On Feb 14, 2018, at 2:48 PM, jesus m. rodriguez wrote: > > On Wed, 2018-02-14 at 14:37 -0500, Shawn Hurley wrote: >> Hello All, >> >> As I start to move down the path to CRDs. I am worried about the >> impact of the deployment templates. Anytime something has changed to >> this in the past it has created a lot of issues. >> >> I am wondering how we can separate these different deployments. We >> have tags and GitHub branches and the like that I think this might be >> doable, but wanted to open up the discussion to get feedback on how >> people see this working. >> >> I think that we should: >> >> 1. Tag every deployment template to use a specific version of the >> broker. > > tag how? git? naming convention? We should set the version for the broker image in the template. right now each template defaults to latest. > >> 2. Give Catasb the ability change which template it uses based on the >> release branch. i.e latest uses master, 1.1 uses release-1.1. > > That would be very useful, I tend to override the asb_template_url > value in my my_vars.yaml config to use my local template since it's the > one I'm modifying as I work on the broker. So I think this would be > pretty easy to do. > >> 3. run_latest_build.sh will continue to only work with the latest >> code. (master branch deployment template and bleeding edge oc). > > +1 > >> 4. Need help to understand what mini shift should do, @erik would the >> combination of branch and image tag be enough? >> 5. any other deployment templates that will need to be separated? > > We do have the simple-broker-template.yaml that is referenced from the > "Up and Running with the Ansible Broker" blog post. > > jesus > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Wed Feb 14 20:27:22 2018 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 14 Feb 2018 15:27:22 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> Message-ID: > 1. Tag every deployment template to use a specific version of the broker. Do we have an official support list? I'm concerned with one and only template, and I don't think we should be supporting much else: https://github.com/openshift/ansible-service-broker/blob/master/templates/deploy-ansible-service-broker.template.yaml > 4. Need help to understand what mini shift should do, @erik would the combination of branch and image tag be enough? I have the minishift addon to pull this from github, pegged to a tag. It's hard set to our latest release, and requires manual updates. It's an explicit desire to have this pegged, but easy to update as we move. From dzager at redhat.com Wed Feb 14 20:32:24 2018 From: dzager at redhat.com (David Zager) Date: Wed, 14 Feb 2018 20:32:24 +0000 Subject: [Ansible-service-broker] Deprovision default behaviour In-Reply-To: References: <83A1DEEC-5DBD-479D-98EB-6280AAC26803@redhat.com> <1518626950.11898.23.camel@redhat.com> Message-ID: Ravi, I know that some of the example APBs and apb init, have separate roles for provision and deprovision that make provision/deprovision cumbersome. We have been toying with a single role approach in the form of an example ( https://github.com/ansibleplaybookbundle/hello-world-apb/pull/3/files). My understanding is that this would simplify the development of an APB with the introduction of the 'state_map' and having the objects we want either 'present' or 'absent' based on the 'state' . Would love your feedback (and anyone who wants to chime in) on that reference example. This is still being actively discussed, but I do believe that a single role approach simplifies the provision/deprovision scenarios of an APB. Regards, David On Wed, Feb 14, 2018 at 1:23 PM Ravi Jonnadula wrote: > One suggestion I would like to make is to let APB automatically build > deprovision-playbook based on the provision-playbook, instead of letting it > to the user to define. That IMO will minimize the possibility of > deprovision failure as long as provision succeeds. > > Of course, this deprovision-playbook need to be maintained by APB > internally corresponding to each provisioned module and maintain > association between them. > > Ravi > > On Wed, Feb 14, 2018 at 9:16 AM Philip Gough wrote: > >> Sure, I'll get something going asap. >> >> Philip >> >> On Wed, Feb 14, 2018 at 5:09 PM, Ryan Hallisey >> wrote: >> >>> > So while sure adding this flag seems to fix one aspect of it, albeit a >>> > key aspect, it would be better to see a proposal on dev experience from >>> > a developer perspective. And try to address the issues outlined and >>> > discussed. That discussion might lead to this exact patch, but it will >>> > be seen in the broader picture of how to fix the dev experience. >>> > >>> Sounds good, let's go with a broader dev proposal. Philip, is that >>> something you would be wiling to start? Here's a link to the template >>> https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/proposal-template.md >>> >>> -Ryan >>> >>> On Wed, Feb 14, 2018 at 11:49 AM, jesus m. rodriguez >>> wrote: >>> >>>> On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote: >>>> > > > I don?t know if I feel comfortable with adding this logic to the >>>> > > > primary >>>> > > > code path for deprovision. This is mostly me being conservative >>>> > > > with >>>> > >>>> > adding >>>> > > > configuration values that can allow things to get deleted from >>>> > > > our >>>> > >>>> > storage. >>>> > > > >>>> > > >>>> > > The developer experience is not acceptable right now, but I have to >>>> > > agree with Shawn. >>>> > > >>>> > >>>> > Agreed, the dev experience is really rough with deprovision. For >>>> > instance, >>>> > if you are testing your provision playbook with the broker and your >>>> > deprovision playbook fails, then you can't test provision again >>>> > without >>>> > some manually steps. But, I think Phillip's patch is a good way to >>>> > provide >>>> > significant improvement to the dev experience with minimal code >>>> > changes. >>>> > The meat of his code is 4 lines: >>>> > >>>> > ```go >>>> > if a.brokerConfig.ForceDelete { >>>> > log.Infof("Deprovision failed. Attempting to clean up related >>>> > resources. >>>> > User should ensure clean up is successful") >>>> > cleanupDeprovision(&instance, a.dao) // Return a 200 to the >>>> > service-catlog >>>> > } >>>> > ``` >>>> >>>> I think the problem is not necessarily that it is a seemingly small >>>> patch. But that there is an overall bigger issue that the dev >>>> experience isn't completely thought out yet. >>>> >>>> So while sure adding this flag seems to fix one aspect of it, albeit a >>>> key aspect, it would be better to see a proposal on dev experience from >>>> a developer perspective. And try to address the issues outlined and >>>> discussed. That discussion might lead to this exact patch, but it will >>>> be seen in the broader picture of how to fix the dev experience. >>>> >>>> My hesitation with applying this right now is I'd rather see what the >>>> broader list of dev experience problems are. How we can address them? >>>> Do we have a single flag that enables a bunch of things? Do we have a >>>> set of dev flags that can be flipped for individual things? Etc. >>>> >>>> We already have a dev_broker flag. Now this patch is adding a >>>> force_delete flag. While it is to fix a dev experience problem, how do >>>> I know that flag is just for dev? What are the implications of enabling >>>> said flag in a production environment? It's the list of subtleties that >>>> I'd like to at least see or anticipate before addressing just one >>>> aspect of a problem. >>>> >>>> > >>>> > > Unless I missed it, let's backup and describe the high-level >>>> > > problem >>>> > > in a proposal and >>>> > > submit solutions there. That's been our approach thus far and I >>>> > > think >>>> > > it applies here well. >>>> > >>>> > To make this the default behaviour, I agree needs a proposal. >>>> >>>> I would rather have a proposal to discuss the dev experience and needs. >>>> Then have a series of PRs to address the needs that come from that >>>> proposal. Again this patch fixes only one aspect of the dev experience. >>>> >>>> jesus >>>> >>>> _______________________________________________ >>>> Ansible-service-broker mailing list >>>> Ansible-service-broker at redhat.com >>>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>>> >>> >>> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Wed Feb 14 20:37:24 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 14 Feb 2018 15:37:24 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> Message-ID: <250B78BA-79DC-4C1C-BF09-C871D4C676C6@redhat.com> Maybe I don?t really understand this that well. I thought the issue has always been that 1. We have other scripts/deployment methods that rely on the deployment-template: https://github.com/openshift/ansible-service-broker/blob/master/templates/deploy-ansible-service-broker.template.yaml 2. this means when you update that template and change something the script is expecting/not expecting to do then a bunch of people have issues deploying the broker. What I was hoping is that it should be assumed that if you create a script and point to the master branch of the deployment template that this will change and we will not make changes to the deployment template to support that script. then we should have deployment-templates for either each sprint, git commit tagged, that set a specific broker image based on the sprint tag that people who want to know their script will always work in the similar way. This deployment template should also use the sprint tag for the APBs so we now that will also work. This is what the run_latest_build.sh should point to IMO. Catasb appears to already have the ability to determine with template you want to use, so we should just make sure that this is documented and we can default to master branch deployment template. > On Feb 14, 2018, at 3:27 PM, Erik Nelson wrote: > >> 1. Tag every deployment template to use a specific version of the broker. > > Do we have an official support list? I'm concerned with one and only > template, and I don't think we should be supporting much else: > I am confused by official support list sorry, can you explain more? > https://github.com/openshift/ansible-service-broker/blob/master/templates/deploy-ansible-service-broker.template.yaml > >> 4. Need help to understand what mini shift should do, @erik would the combination of branch and image tag be enough? > > I have the minishift addon to pull this from github, pegged to a tag. > It's hard set to our latest release, and requires manual updates. > It's an explicit desire to have this pegged, but easy to update as we move. So minishift already behaves as I have described above except the deployment template that it points to does not specify a specific version of the broker and APBs to use? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Wed Feb 14 21:41:09 2018 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 14 Feb 2018 16:41:09 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <250B78BA-79DC-4C1C-BF09-C871D4C676C6@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <250B78BA-79DC-4C1C-BF09-C871D4C676C6@redhat.com> Message-ID: > 1. We have other scripts/deployment methods that rely on the > deployment-template: > https://github.com/openshift/ansible-service-broker/blob/master/templates/deploy-ansible-service-broker.template.yaml > 2. this means when you update that template and change something the script > is expecting/not expecting to do then a bunch of people have issues > deploying the broker. There are a few issue at play here. The aforementioned template *is* the golden source. I have personally introduced a number of other simplified templates for specific purposes that have been picked up and run with in ways they were never intended for. It's our responsibility to make it known they are not to be used outside of their specific intention. > What I was hoping is that it should be assumed that if you create a script > and point to the master branch of the deployment template that this will > change and we will not make changes to the deployment template to support > that script. 100% agree that it if you are writing scripts against master, you should expect change that will move out from under you. That said, the deployment template should remain in sync with anything else in the same branch/checkout. If that's not true, we messed up. > then we should have deployment-templates for either each sprint, git commit > tagged, that set a specific broker image based on the sprint tag that people > who want to know their script will always work in the similar way.This > deployment template should also use the sprint tag for the APBs so we now > that will also work. This is what the run_latest_build.sh should point to > IMO. No doubt. Let me ask: what do we actually expect run_latest_build.sh to do? To be frank, no developers use this script. When it breaks (and it will continue to do so), its only going to be users that report it. Can we get a consensus on the future of this script? I want to shut it down, or figure out its purpose and maintain it. From shurley at redhat.com Wed Feb 14 21:53:02 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 14 Feb 2018 16:53:02 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <250B78BA-79DC-4C1C-BF09-C871D4C676C6@redhat.com> Message-ID: <475776EA-2E57-432A-B620-F769F9BFA0CF@redhat.com> > On Feb 14, 2018, at 4:41 PM, Erik Nelson wrote: > >> 1. We have other scripts/deployment methods that rely on the >> deployment-template: >> https://github.com/openshift/ansible-service-broker/blob/master/templates/deploy-ansible-service-broker.template.yaml >> 2. this means when you update that template and change something the script >> is expecting/not expecting to do then a bunch of people have issues >> deploying the broker. > > There are a few issue at play here. The aforementioned template *is* > the golden source. I have personally introduced a number of other simplified > templates for specific purposes that have been picked up and run with in > ways they were never intended for. It's our responsibility to make it known > they are not to be used outside of their specific intention. > >> What I was hoping is that it should be assumed that if you create a script >> and point to the master branch of the deployment template that this will >> change and we will not make changes to the deployment template to support >> that script. > > 100% agree that it if you are writing scripts against master, you > should expect change > that will move out from under you. That said, the deployment template > should remain > in sync with anything else in the same branch/checkout. If that's not > true, we messed up. > >> then we should have deployment-templates for either each sprint, git commit >> tagged, that set a specific broker image based on the sprint tag that people >> who want to know their script will always work in the similar way.This >> deployment template should also use the sprint tag for the APBs so we now >> that will also work. This is what the run_latest_build.sh should point to >> IMO. > > No doubt. Let me ask: what do we actually expect run_latest_build.sh to do? > > To be frank, no developers use this script. When it breaks (and it > will continue to do so), > its only going to be users that report it. Can we get a consensus on the > future of this script? I want to shut it down, or figure out its > purpose and maintain it. +1 I want this script to be a wrapper around OC that does same thing as minishift deploying the broker IMO From jesusr at redhat.com Wed Feb 14 21:59:35 2018 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 14 Feb 2018 16:59:35 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <36254AED-4D41-47CF-BEC2-43948A8CBAC4@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <1518637727.11898.49.camel@redhat.com> <36254AED-4D41-47CF-BEC2-43948A8CBAC4@redhat.com> Message-ID: <1518645575.11898.50.camel@redhat.com> On Wed, 2018-02-14 at 15:02 -0500, Shawn Hurley wrote: > > On Feb 14, 2018, at 2:48 PM, jesus m. rodriguez > > wrote: > [snip] > > > > > > 1. Tag every deployment template to use a specific version of the > > > broker. > > > > tag how? git? naming convention? > > We should set the version for the broker image in the template. right > now each template defaults to latest. Ah okay, +1 jesus From rhallise at redhat.com Wed Feb 14 23:26:36 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Wed, 14 Feb 2018 18:26:36 -0500 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: <1518645575.11898.50.camel@redhat.com> References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <1518637727.11898.49.camel@redhat.com> <36254AED-4D41-47CF-BEC2-43948A8CBAC4@redhat.com> <1518645575.11898.50.camel@redhat.com> Message-ID: That all sounds good to me. -Ryan On Wed, Feb 14, 2018 at 4:59 PM, jesus m. rodriguez wrote: > On Wed, 2018-02-14 at 15:02 -0500, Shawn Hurley wrote: > > > On Feb 14, 2018, at 2:48 PM, jesus m. rodriguez > > > wrote: > > > [snip] > > > > > > > > > 1. Tag every deployment template to use a specific version of the > > > > broker. > > > > > > tag how? git? naming convention? > > > > We should set the version for the broker image in the template. right > > now each template defaults to latest. > > Ah okay, +1 > > jesus > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzager at redhat.com Thu Feb 15 17:08:30 2018 From: dzager at redhat.com (David Zager) Date: Thu, 15 Feb 2018 17:08:30 +0000 Subject: [Ansible-service-broker] Deployment Templates Backwards Compatibility In-Reply-To: References: <09E77902-4DBE-4594-9D3A-1F5F0AC4FB95@redhat.com> <1518637727.11898.49.camel@redhat.com> <36254AED-4D41-47CF-BEC2-43948A8CBAC4@redhat.com> <1518645575.11898.50.camel@redhat.com> Message-ID: This goes to both the "Published apb tag" discussion from earlier and this one so I'm going to try and wrap both those threads into one. I went ahead and created 'release-1.0' and 'release-1.1' tags for the broker and our APBs. For brevity, I'll just point you to the broker ( https://hub.docker.com/r/ansibleplaybookbundle/origin-ansible-service-broker/tags/). I'm working on a PR to lock down the templates and CI in the 'release-1.0' branch of our broker to use 'release-1.0' images ( https://github.com/openshift/ansible-service-broker/pull/767). I intend to take whatever comments/changes are needed and make those on that PR and then make a similar set of changes for the 'release-1.1' branch. The process for keeping these image tags up to date, at least right now, is a little kludgy (really just the APBs) but it should be enough to limit the amount of searching that needs to be done to get broker + APB versions in line. On Wed, Feb 14, 2018 at 6:33 PM Ryan Hallisey wrote: > That all sounds good to me. > > -Ryan > > On Wed, Feb 14, 2018 at 4:59 PM, jesus m. rodriguez > wrote: > >> On Wed, 2018-02-14 at 15:02 -0500, Shawn Hurley wrote: >> > > On Feb 14, 2018, at 2:48 PM, jesus m. rodriguez >> > > wrote: >> > >> [snip] >> >> > > > >> > > > 1. Tag every deployment template to use a specific version of the >> > > > broker. >> > > >> > > tag how? git? naming convention? >> > >> > We should set the version for the broker image in the template. right >> > now each template defaults to latest. >> >> Ah okay, +1 >> >> jesus >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Tue Feb 20 18:33:01 2018 From: shurley at redhat.com (Shawn Hurley) Date: Tue, 20 Feb 2018 13:33:01 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker Message-ID: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> Hello All, I wanted to send out a note to make sure that everyone was ok with the approach for the k8s like client for broker CRDs. I was thinking that we would create a new repo, I assume we need a new org (automationbroker or something similar), and this would contain the broker-client-go. The client would be generated using the k8s generate client scripts and code. Here is a blog post about how this works for some context: https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/ This client then would be added to the broker through glide/dep. If the above is agreeable some help/guidence on next steps for making the new repo would be appreciated. Thanks, Shawn Hurley -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Tue Feb 20 18:43:37 2018 From: cbrookes at redhat.com (cbrookes at redhat.com) Date: Tue, 20 Feb 2018 18:43:37 +0000 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> Message-ID: <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> I think that is a great way of doing it! We use the generators for our mobile crd types and it is working well for us. I would really like if the service catalog had taken the approach of a separate repo for the client maybe we could suggest it? Craig > On 20 Feb 2018, at 18:33, Shawn Hurley wrote: > > Hello All, > > I wanted to send out a note to make sure that everyone was ok with the approach for the k8s like client for broker CRDs. > > I was thinking that we would create a new repo, I assume we need a new org (automationbroker or something similar), and this would contain the broker-client-go. > > The client would be generated using the k8s generate client scripts and code. Here is a blog post about how this works for some context: https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/ > > This client then would be added to the broker through glide/dep. > > If the above is agreeable some help/guidence on next steps for making the new repo would be appreciated. > > Thanks, > > Shawn Hurley > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Tue Feb 20 18:57:37 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 20 Feb 2018 13:57:37 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> Message-ID: Would the broker-client-go be essentially a vendorable dependency like the client-go package in kubernetes? Do I understand that correctly? At a high level, what would be in the broker-client-go? -Ryan On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com wrote: > I think that is a great way of doing it! We use the generators for our > mobile crd types and it is working well for us. I would really like if the > service catalog had taken the approach of a separate repo for the client > maybe we could suggest it? > > Craig > > On 20 Feb 2018, at 18:33, Shawn Hurley wrote: > > Hello All, > > I wanted to send out a note to make sure that everyone was ok with the > approach for the k8s like client for broker CRDs. > > I was thinking that we would create a new repo, I assume we need a new org > (automationbroker or something similar), and this would contain the > broker-client-go. > > The client would be generated using the k8s generate client scripts and > code. Here is a blog post about how this works for some context: > https://blog.openshift.com/kubernetes-deep-dive-code-generation- > customresources/ > > This client then would be added to the broker through glide/dep. > > If the above is agreeable some help/guidence on next steps for making the > new repo would be appreciated. > > Thanks, > > Shawn Hurley > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Tue Feb 20 19:01:08 2018 From: shurley at redhat.com (Shawn Hurley) Date: Tue, 20 Feb 2018 14:01:08 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> Message-ID: <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> Yes that is correct about the venerable dependency. An example of what this would look like is here: https://github.com/openshift-evangelists/crd-code-generation . In a nut shell the client is like every other client-go for k8s resources. it has listers/informers and the interface/impl for crud operations. Thanks, Shawn > On Feb 20, 2018, at 1:57 PM, Ryan Hallisey wrote: > > Would the broker-client-go be essentially a vendorable dependency like the client-go package in kubernetes? Do I understand that correctly? At a high level, what would be in the broker-client-go? > > -Ryan > > On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com > wrote: > I think that is a great way of doing it! We use the generators for our mobile crd types and it is working well for us. I would really like if the service catalog had taken the approach of a separate repo for the client maybe we could suggest it? > > Craig > > On 20 Feb 2018, at 18:33, Shawn Hurley > wrote: > >> Hello All, >> >> I wanted to send out a note to make sure that everyone was ok with the approach for the k8s like client for broker CRDs. >> >> I was thinking that we would create a new repo, I assume we need a new org (automationbroker or something similar), and this would contain the broker-client-go. >> >> The client would be generated using the k8s generate client scripts and code. Here is a blog post about how this works for some context: https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/ >> >> This client then would be added to the broker through glide/dep. >> >> If the above is agreeable some help/guidence on next steps for making the new repo would be appreciated. >> >> Thanks, >> >> Shawn Hurley >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Tue Feb 20 19:14:07 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 20 Feb 2018 14:14:07 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> Message-ID: Sounds good to me Shawn. This is a good step towards being vendorable. Looks like the git org https://github.com/AutomationBroker already exists. Does someone here own it? It looks abandoned. Maybe we can ask git to delete it. -Ryan On Tue, Feb 20, 2018 at 2:01 PM, Shawn Hurley wrote: > Yes that is correct about the venerable dependency. > An example of what this would look like is here: https://github.com/ > openshift-evangelists/crd-code-generation. > > In a nut shell the client is like every other client-go for k8s resources. > it has listers/informers and the interface/impl for crud operations. > > Thanks, > > Shawn > > On Feb 20, 2018, at 1:57 PM, Ryan Hallisey wrote: > > Would the broker-client-go be essentially a vendorable dependency like the > client-go package in kubernetes? Do I understand that correctly? At a high > level, what would be in the broker-client-go? > > -Ryan > > On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com > wrote: > >> I think that is a great way of doing it! We use the generators for our >> mobile crd types and it is working well for us. I would really like if the >> service catalog had taken the approach of a separate repo for the client >> maybe we could suggest it? >> >> Craig >> >> On 20 Feb 2018, at 18:33, Shawn Hurley wrote: >> >> Hello All, >> >> I wanted to send out a note to make sure that everyone was ok with the >> approach for the k8s like client for broker CRDs. >> >> I was thinking that we would create a new repo, I assume we need a new >> org (automationbroker or something similar), and this would contain the >> broker-client-go. >> >> The client would be generated using the k8s generate client scripts and >> code. Here is a blog post about how this works for some context: >> https://blog.openshift.com/kubernetes-deep-dive- >> code-generation-customresources/ >> >> This client then would be added to the broker through glide/dep. >> >> If the above is agreeable some help/guidence on next steps for making the >> new repo would be appreciated. >> >> Thanks, >> >> Shawn Hurley >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Thu Feb 22 16:40:06 2018 From: shurley at redhat.com (Shawn Hurley) Date: Thu, 22 Feb 2018 11:40:06 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> Message-ID: <326B30C5-7F6D-4EEE-8E28-6C84EFFD77AC@redhat.com> Hello All, I am expecting to call the generated client https://github.com/automationbroker/broker-client-go Does anyone think the name should be different? I don?t have strong opinions but the name is attempting to implicate that it is similar to the client-go but specifically for the broker. I could see maybe just client-go because it is in the automation broker repo? Thanks, Shawn Hurley > On Feb 20, 2018, at 2:14 PM, Ryan Hallisey wrote: > > Sounds good to me Shawn. This is a good step towards being vendorable. > > Looks like the git org https://github.com/AutomationBroker already exists. Does someone here own it? It looks abandoned. Maybe we can ask git to delete it. > > -Ryan > > On Tue, Feb 20, 2018 at 2:01 PM, Shawn Hurley > wrote: > Yes that is correct about the venerable dependency. > An example of what this would look like is here: https://github.com/openshift-evangelists/crd-code-generation . > > In a nut shell the client is like every other client-go for k8s resources. it has listers/informers and the interface/impl for crud operations. > > Thanks, > > Shawn > >> On Feb 20, 2018, at 1:57 PM, Ryan Hallisey > wrote: >> >> Would the broker-client-go be essentially a vendorable dependency like the client-go package in kubernetes? Do I understand that correctly? At a high level, what would be in the broker-client-go? >> >> -Ryan >> >> On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com > wrote: >> I think that is a great way of doing it! We use the generators for our mobile crd types and it is working well for us. I would really like if the service catalog had taken the approach of a separate repo for the client maybe we could suggest it? >> >> Craig >> >> On 20 Feb 2018, at 18:33, Shawn Hurley > wrote: >> >>> Hello All, >>> >>> I wanted to send out a note to make sure that everyone was ok with the approach for the k8s like client for broker CRDs. >>> >>> I was thinking that we would create a new repo, I assume we need a new org (automationbroker or something similar), and this would contain the broker-client-go. >>> >>> The client would be generated using the k8s generate client scripts and code. Here is a blog post about how this works for some context: https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/ >>> >>> This client then would be added to the broker through glide/dep. >>> >>> If the above is agreeable some help/guidence on next steps for making the new repo would be appreciated. >>> >>> Thanks, >>> >>> Shawn Hurley >>> >>> _______________________________________________ >>> Ansible-service-broker mailing list >>> Ansible-service-broker at redhat.com >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Thu Feb 22 17:05:55 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Thu, 22 Feb 2018 12:05:55 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: <326B30C5-7F6D-4EEE-8E28-6C84EFFD77AC@redhat.com> References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> <326B30C5-7F6D-4EEE-8E28-6C84EFFD77AC@redhat.com> Message-ID: broker-client-go is good with me. -Ryan On Thu, Feb 22, 2018 at 11:40 AM, Shawn Hurley wrote: > Hello All, > > I am expecting to call the generated client https://github.com/ > automationbroker/broker-client-go > > Does anyone think the name should be different? I don?t have strong > opinions but the name is attempting to implicate that it is similar to the > client-go but specifically for the broker. I could see maybe just client-go > because it is in the automation broker repo? > > Thanks, > > Shawn Hurley > > > On Feb 20, 2018, at 2:14 PM, Ryan Hallisey wrote: > > Sounds good to me Shawn. This is a good step towards being vendorable. > > Looks like the git org https://github.com/AutomationBroker already > exists. Does someone here own it? It looks abandoned. Maybe we can ask > git to delete it. > > -Ryan > > On Tue, Feb 20, 2018 at 2:01 PM, Shawn Hurley wrote: > >> Yes that is correct about the venerable dependency. >> An example of what this would look like is here: https://github.com/opens >> hift-evangelists/crd-code-generation. >> >> In a nut shell the client is like every other client-go for k8s >> resources. it has listers/informers and the interface/impl for crud >> operations. >> >> Thanks, >> >> Shawn >> >> On Feb 20, 2018, at 1:57 PM, Ryan Hallisey wrote: >> >> Would the broker-client-go be essentially a vendorable dependency like >> the client-go package in kubernetes? Do I understand that correctly? At a >> high level, what would be in the broker-client-go? >> >> -Ryan >> >> On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com > > wrote: >> >>> I think that is a great way of doing it! We use the generators for our >>> mobile crd types and it is working well for us. I would really like if the >>> service catalog had taken the approach of a separate repo for the client >>> maybe we could suggest it? >>> >>> Craig >>> >>> On 20 Feb 2018, at 18:33, Shawn Hurley wrote: >>> >>> Hello All, >>> >>> I wanted to send out a note to make sure that everyone was ok with the >>> approach for the k8s like client for broker CRDs. >>> >>> I was thinking that we would create a new repo, I assume we need a new >>> org (automationbroker or something similar), and this would contain the >>> broker-client-go. >>> >>> The client would be generated using the k8s generate client scripts and >>> code. Here is a blog post about how this works for some context: >>> https://blog.openshift.com/kubernetes-deep-dive-cod >>> e-generation-customresources/ >>> >>> This client then would be added to the broker through glide/dep. >>> >>> If the above is agreeable some help/guidence on next steps for making >>> the new repo would be appreciated. >>> >>> Thanks, >>> >>> Shawn Hurley >>> >>> _______________________________________________ >>> Ansible-service-broker mailing list >>> Ansible-service-broker at redhat.com >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >>> >>> _______________________________________________ >>> Ansible-service-broker mailing list >>> Ansible-service-broker at redhat.com >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Fri Feb 23 14:17:13 2018 From: ernelson at redhat.com (Erik Nelson) Date: Fri, 23 Feb 2018 09:17:13 -0500 Subject: [Ansible-service-broker] CRD Client for the Service Broker In-Reply-To: References: <2AF309C3-1179-48D3-8029-5C928E9AFDA4@redhat.com> <43E34BD9-39ED-44F8-9C79-44944137BD7C@redhat.com> <07A52B87-DA61-46FE-BEB0-D3394CE537ED@redhat.com> <326B30C5-7F6D-4EEE-8E28-6C84EFFD77AC@redhat.com> Message-ID: +1 On Thu, Feb 22, 2018 at 12:05 PM, Ryan Hallisey wrote: > broker-client-go is good with me. > > -Ryan > > On Thu, Feb 22, 2018 at 11:40 AM, Shawn Hurley wrote: >> >> Hello All, >> >> I am expecting to call the generated client >> https://github.com/automationbroker/broker-client-go >> >> Does anyone think the name should be different? I don?t have strong >> opinions but the name is attempting to implicate that it is similar to the >> client-go but specifically for the broker. I could see maybe just client-go >> because it is in the automation broker repo? >> >> Thanks, >> >> Shawn Hurley >> >> >> On Feb 20, 2018, at 2:14 PM, Ryan Hallisey wrote: >> >> Sounds good to me Shawn. This is a good step towards being vendorable. >> >> Looks like the git org https://github.com/AutomationBroker already exists. >> Does someone here own it? It looks abandoned. Maybe we can ask git to >> delete it. >> >> -Ryan >> >> On Tue, Feb 20, 2018 at 2:01 PM, Shawn Hurley wrote: >>> >>> Yes that is correct about the venerable dependency. >>> An example of what this would look like is here: >>> https://github.com/openshift-evangelists/crd-code-generation. >>> >>> In a nut shell the client is like every other client-go for k8s >>> resources. it has listers/informers and the interface/impl for crud >>> operations. >>> >>> Thanks, >>> >>> Shawn >>> >>> On Feb 20, 2018, at 1:57 PM, Ryan Hallisey wrote: >>> >>> Would the broker-client-go be essentially a vendorable dependency like >>> the client-go package in kubernetes? Do I understand that correctly? At a >>> high level, what would be in the broker-client-go? >>> >>> -Ryan >>> >>> On Tue, Feb 20, 2018 at 1:43 PM, cbrookes at redhat.com >>> wrote: >>>> >>>> I think that is a great way of doing it! We use the generators for our >>>> mobile crd types and it is working well for us. I would really like if the >>>> service catalog had taken the approach of a separate repo for the client >>>> maybe we could suggest it? >>>> >>>> Craig >>>> >>>> On 20 Feb 2018, at 18:33, Shawn Hurley wrote: >>>> >>>> Hello All, >>>> >>>> I wanted to send out a note to make sure that everyone was ok with the >>>> approach for the k8s like client for broker CRDs. >>>> >>>> I was thinking that we would create a new repo, I assume we need a new >>>> org (automationbroker or something similar), and this would contain the >>>> broker-client-go. >>>> >>>> The client would be generated using the k8s generate client scripts and >>>> code. Here is a blog post about how this works for some context: >>>> https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/ >>>> >>>> This client then would be added to the broker through glide/dep. >>>> >>>> If the above is agreeable some help/guidence on next steps for making >>>> the new repo would be appreciated. >>>> >>>> Thanks, >>>> >>>> Shawn Hurley >>>> >>>> _______________________________________________ >>>> Ansible-service-broker mailing list >>>> Ansible-service-broker at redhat.com >>>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>>> >>>> >>>> _______________________________________________ >>>> Ansible-service-broker mailing list >>>> Ansible-service-broker at redhat.com >>>> https://www.redhat.com/mailman/listinfo/ansible-service-broker >>>> >>> >>> >> >> > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > From mhrivnak at redhat.com Tue Feb 27 14:56:00 2018 From: mhrivnak at redhat.com (Michael Hrivnak) Date: Tue, 27 Feb 2018 09:56:00 -0500 Subject: [Ansible-service-broker] article on opensource.com Message-ID: For the moment we are first on the front page for opensource.com! In case you don't catch it there, here is a direct link to the article: https://opensource.com/article/18/2/automated-provisioning-kubernetes -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhrivnak at redhat.com Tue Feb 27 15:08:10 2018 From: mhrivnak at redhat.com (Michael Hrivnak) Date: Tue, 27 Feb 2018 10:08:10 -0500 Subject: [Ansible-service-broker] new twitter account Message-ID: The project is now on twitter! If you're into that sort of thing, please follow us here: https://twitter.com/autom8broker -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From c at petersen-glombek.de Tue Feb 27 20:09:18 2018 From: c at petersen-glombek.de (Christian Glombek) Date: Tue, 27 Feb 2018 20:09:18 +0000 Subject: [Ansible-service-broker] Ansible Runner Containers Message-ID: Hello everyone, I stumbled across the openshift/cluster-operator project and noticed they use an ANSIBLE_IMAGE (namely fake-openshift-ansible:canary). I am not familiar with that project but I thought it sounded similar to what's being done here with apb-base. I've heard of plans to use Ansible Runner for this purpose in the future and I was wondering whether you were aware of cluster-operator. Maybe there are synergies that can be leveraged =) https://github.com/openshift/cluster-operator https://github.com/brennerm/ansible-runner https://github.com/ansibleplaybookbundle/apb-base Cheers, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhallise at redhat.com Wed Feb 28 17:23:30 2018 From: rhallise at redhat.com (Ryan Hallisey) Date: Wed, 28 Feb 2018 12:23:30 -0500 Subject: [Ansible-service-broker] Automation Broker Community Meeting Message-ID: Folks, The broker community has been talking about starting a weekly IRC meeting. The plan is to have folks gather in the Freenode channel (#asbroker) and go over things that have been happening in the community. Here's a link to the google doc with the format. The first order of business is to find a time that works. Can folks fill out the doodle poll with all the times that work for you and we'll select the time that most people can make it. If you want to add any times to the poll let me know. Thanks, - Ryan google doc: https://docs.google.com/document/d/1Mj7bVYJ8NK-TwU_mxeZLprmBBZZ-xOq-Hg4CiD3E6pM/edit?usp=sharing doodle poll: https://doodle.com/poll/qu75f5xatq32wekd -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoullia at redhat.com Wed Feb 28 20:44:32 2018 From: cmoullia at redhat.com (Charles Moulliard) Date: Wed, 28 Feb 2018 21:44:32 +0100 Subject: [Ansible-service-broker] Issue with playbook of ansible service broker - missing networkpolicies Message-ID: Hi, There is still an issue with the ansible playbook installing ASB on openshift 3.7 When the inventory is configured using these parameters git clone -b release-3.7 git at github.com:openshift/openshift-ansible.git openshift_enable_service_catalog=true ansible_service_broker_registry_whitelist=['.*-apb$'] ansible_service_broker_image_tag=v3.7 then, the following error is reported within the APB pod during serviceinstance creation [2018-02-28T20:33:59.585Z] [NOTICE] - Creating RoleBinding apb-49d8c2a2-6d12-474c-87a2-a220bda6ba0d [2018-02-28T20:33:59.598Z] [ERROR] - *unable to create network policy object - User "system:serviceaccount:openshift-ansible-service-broker:asb" cannot create networkpolicies.networking.k8s.io in the namespace "project31": User "system:serviceaccount:openshift-ansible-service-broker:asb" cannot create networkpolicies.networking.k8s.io in project "project31" (post networkpolicies.networking.k8s.io )* project "project31" (post networkpolicies.networking.k8s.io) As you can see, the clusterrole of asb-auth is still missing the following info https://goo.gl/HfJnj8 Can somebody fix the error please for ansible openshift 3.7 ? Regards Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Feb 28 21:45:02 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 28 Feb 2018 21:45:02 +0000 Subject: [Ansible-service-broker] Automation Broker Community Meeting In-Reply-To: References: Message-ID: looking forward to this ! On Wed, Feb 28, 2018 at 5:23 PM, Ryan Hallisey wrote: > Folks, > > The broker community has been talking about starting a weekly IRC > meeting. The plan is to have folks gather in the Freenode channel > (#asbroker) and go over things that have been happening in the community. > Here's a link to the google doc > > with the format. > > The first order of business is to find a time that works. Can folks fill > out the doodle poll with all > the times that work for you and we'll select the time that most people can > make it. If you want to add any times to the poll let me know. > > Thanks, > - Ryan > > google doc: https://docs.google.com/document/d/1Mj7bVYJ8NK-TwU_ > mxeZLprmBBZZ-xOq-Hg4CiD3E6pM/edit?usp=sharing > doodle poll: https://doodle.com/poll/qu75f5xatq32wekd > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From shurley at redhat.com Wed Feb 28 23:42:58 2018 From: shurley at redhat.com (Shawn Hurley) Date: Wed, 28 Feb 2018 18:42:58 -0500 Subject: [Ansible-service-broker] Issue with playbook of ansible service broker - missing networkpolicies In-Reply-To: References: Message-ID: <9F8A0664-4F7E-418C-ACDF-3922A71BE373@redhat.com> Hi Charles, v3.7 should not be attempting to anything with network policies, can you please double check the deployment config and tell us the version of the image that is being deployed. If it is 3.7 then we have another issue that we will need to solve. ansible_service_broker_image_tag should override the tag value, if that is not working then we will need to do a deeper dive on the openshift-ansible code. If you would like to just ?work around? this then you could add a cluster role binding and role to grant access to the asb service account to manipulate the network policies. Regards, Shawn Hurley > On Feb 28, 2018, at 3:44 PM, Charles Moulliard wrote: > > Hi, > > There is still an issue with the ansible playbook installing ASB on openshift 3.7 > When the inventory is configured using these parameters > > git clone -b release-3.7 git at github.com:openshift/openshift-ansible.git > > openshift_enable_service_catalog=true > ansible_service_broker_registry_whitelist=['.*-apb$'] > ansible_service_broker_image_tag=v3.7 > > then, the following error is reported within the APB pod during serviceinstance creation > > [2018-02-28T20:33:59.585Z] [NOTICE] - Creating RoleBinding apb-49d8c2a2-6d12-474c-87a2-a220bda6ba0d > [2018-02-28T20:33:59.598Z] [ERROR] - unable to create network policy object - User "system:serviceaccount:openshift-ansible-service-broker:asb" cannot create networkpolicies.networking.k8s.io in the namespace "project31": User "system:serviceaccount:openshift-ansible-service-broker:asb" cannot create networkpolicies.networking.k8s.io in project "project31" (post networkpolicies.networking.k8s.io ) > project "project31" (post networkpolicies.networking.k8s.io ) > > As you can see, the clusterrole of asb-auth is still missing the following info > https://goo.gl/HfJnj8 > > Can somebody fix the error please for ansible openshift 3.7 ? > > Regards > > Charles > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernelson at redhat.com Wed Feb 28 23:47:18 2018 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 28 Feb 2018 18:47:18 -0500 Subject: [Ansible-service-broker] Issue with playbook of ansible service broker - missing networkpolicies In-Reply-To: <9F8A0664-4F7E-418C-ACDF-3922A71BE373@redhat.com> References: <9F8A0664-4F7E-418C-ACDF-3922A71BE373@redhat.com> Message-ID: Charles, you guys are deploying upstream origin with openshift-ansible? We discovered today thanks to your report that the upstream openshift-ansible code was configured to default to "latest" broker images, which is our 3.9 image. I will see if I can reproduce your issue as well. +1 to shurley's comment, we have to confirm what version of the image you are running, via tag. On Wed, Feb 28, 2018 at 6:42 PM, Shawn Hurley wrote: > Hi Charles, > > v3.7 should not be attempting to anything with network policies, can you > please double check the deployment config and tell us the version of the > image that is being deployed. If it is 3.7 then we have another issue that > we will need to solve. > > ansible_service_broker_image_tag should override the tag value, if that is > not working then we will need to do a deeper dive on the openshift-ansible > code. > > If you would like to just ?work around? this then you could add a cluster > role binding and role to grant access to the asb service account to > manipulate the network policies. > > Regards, > > Shawn Hurley > > On Feb 28, 2018, at 3:44 PM, Charles Moulliard wrote: > > Hi, > > There is still an issue with the ansible playbook installing ASB on > openshift 3.7 > When the inventory is configured using these parameters > > git clone -b release-3.7 git at github.com:openshift/openshift-ansible.git > > openshift_enable_service_catalog=true > ansible_service_broker_registry_whitelist=['.*-apb$'] > ansible_service_broker_image_tag=v3.7 > > then, the following error is reported within the APB pod during > serviceinstance creation > > [2018-02-28T20:33:59.585Z] [NOTICE] - Creating RoleBinding > apb-49d8c2a2-6d12-474c-87a2-a220bda6ba0d > [2018-02-28T20:33:59.598Z] [ERROR] - unable to create network policy object > - User "system:serviceaccount:openshift-ansible-service-broker:asb" cannot > create networkpolicies.networking.k8s.io in the namespace "project31": User > "system:serviceaccount:openshift-ansible-service-broker:asb" cannot create > networkpolicies.networking.k8s.io in project "project31" (post > networkpolicies.networking.k8s.io) > project "project31" (post networkpolicies.networking.k8s.io) > > As you can see, the clusterrole of asb-auth is still missing the following > info > https://goo.gl/HfJnj8 > > Can somebody fix the error please for ansible openshift 3.7 ? > > Regards > > Charles > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker > > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker >