From tsanders at redhat.com Thu Jun 1 19:07:08 2017 From: tsanders at redhat.com (Todd Sanders) Date: Thu, 1 Jun 2017 15:07:08 -0400 Subject: [Ansible-service-broker] Deploying Multi-Container Applications on OpenShift with the Ansible Service Broker - Recording Link Message-ID: For those who may have missed our OpenShift Commons Briefing yesterday, here is the recording: Deploying Multi-Container Applications on OpenShift with the Ansible Service Broker OpenShift Commons Briefing https://www.youtube.com/watch?v=kDJveLN5UOs The Kubernetes Service Catalog and Open Service Broker API are creating a new way for users to provision and manage services on OpenShift through a collection of Service Brokers. One of these brokers, the Ansible Service Broker, is focused on providing a mechanism for allowing applications defined with Ansible to be exposed to the Service Catalog. We call this application definition an Ansible Playbook Bundle (APB); a lightweight definition that is essentially a few Ansible playbooks named for each of the Open Service Broker API methods. The bundle is packaged as a container image with an Ansible runtime for distribution to be consumed by the Ansible Service Broker. In this talk we will introduce the concept of the Ansible Playbook Bundle and Ansible Service Broker. Additionally, we will walk through a few use cases demonstrating how to define and deploy multi-container applications. Presenters: Todd Sanders ? Director, Software Engineering John Matthews ? Principal Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesusr at redhat.com Fri Jun 2 17:55:58 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Fri, 2 Jun 2017 13:55:58 -0400 Subject: [Ansible-service-broker] broker repo moved to openshift Message-ID: <4e5f869f-7511-e047-3084-0c06df734922@redhat.com> Hey folks, Wanted to let the community know that we've graduated from fusor org to the openshift org. https://github.com/openshift/ansible-service-broker The other projects will remain under the fusor org: ansible-playbook-bundle - https://github.com/fusor/ansible-playbook-bundle apb-examples - https://github.com/fusor/apb-examples catasb - https://github.com/fusor/catasb If you have any questions feel free to ping any of us on freenode at the #asbroker channel or email this list. Thanks for your patience through this transition. Sincerely, jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From ernelson at redhat.com Thu Jun 8 14:58:12 2017 From: ernelson at redhat.com (Erik Nelson) Date: Thu, 8 Jun 2017 10:58:12 -0400 Subject: [Ansible-service-broker] Fwd: Thoughts on dynamic svc accounts In-Reply-To: References: Message-ID: I'm forwarding my original message to the list because it really should have been sent here in the first place and I can't seem to get gmail to forward the thread... RFC. ---------- Forwarded message ---------- From: Erik Nelson Date: Wed, Jun 7, 2017 at 9:01 PM Subject: Thoughts on dynamic svc accounts To: John Matthews Cc: Jesus Rodriguez , tsanders John et.al., Had some success creating k8s resources using client libs from within the broker today. I've got an idea where I *think* we need to go, so I wanted to run that by you to make sure it makes sense and also have some q's about the implementation. First, "Bindings" are used to associate Roles to users/groups/serviceaccounts. Speaking briefly with Paul, we need to use RoleBindings instead of ClusterRoleBindings, difference being RoleBindings are scoped to a specific project, so an apb would be authorized to act within its requested namespace, but no others. Looking over the default roles, we should be able to lock things down to the *edit* level for our apbs. This means they can't write to Roles or RoleBindings to affect permissions within the namespace, but can read/write other resources within the namespace. I can see a case for relaxing this, but it's a good thing to bring up for discussion: https://kubernetes.io/docs/admin/authorization/rbac/#default-roles-and-role-bindings Here are my current thoughts, would really like feedback to see if this makes sense: RoleBindings scope permissions within a project. Pods running apb actions are authorized within a project via the serviceaccounts they run as (which are authorized by their project scoped RoleBindings). Based on this, **it feels like everything should be scoped within the requested namespace that's passed into the broker**. That means the broker needs to create the project if it doesn't already exist, create a ServiceAccount scoped to the namespace, assign the edit role to that ServiceAccount scoped to the namespace, then run the apb action as a Pod scoped to that namespace as the newly created service account. Significant changes here are: * Broker needs to create the requested project if it doesn't already exist ! * APBs are run inside of the requested project, not ansible-service-broker * APBs are strictly authorized to whatever permissions the RoleBinding grants the ServiceAccount identity for the life of the ServiceAccount. APB ServiceAccounts exist temporarily until the broker destroys the ServiceAccount at the conclusion of the APBs pod action. Q's -> Does this make sense to you? -> If this is what we need to do, everything above is vanilla k8s except Projects, and we generally are talking about Projects when discussing things like where APBs need to run. I hear people use Project and Namespace interchangeably (I did so throughout this mail), but I don't think that's actually fair. A Project is not a Namespace, it's a superset that's a strict OCP concept. I can't create a Project from the k8s client. + If I need to create a Project to scope this work in OCP, I don't know how to interface with OCP from go. I only have an interface into k8s. Do I need a unique Openshift client? + When scoping these k8s objects, can I reference a Namespace that shares its name with a Project created with the Openshift client? i.e, if I create a Project, I get a Namespace with the same name ID for free? Please challenge anything you see here that doesn't make sense, and if it does, looking for people to help me answer these questions. NOTE: This is entirely separate from the broker's service account. I think I've got a decent handle on how to deal with that, so trying to ferret out the unknowns around dynamic apb svcaccts. NOTE++: Reading again, sorry for the wall of text. Kind of a brain dump :) - Erik From ernelson at redhat.com Mon Jun 19 17:19:34 2017 From: ernelson at redhat.com (Erik Nelson) Date: Mon, 19 Jun 2017 13:19:34 -0400 Subject: [Ansible-service-broker] Make install Message-ID: Looking over this again, we run a set of commands to install the broker with make install: https://github.com/openshift/ansible-service-broker/blob/master/Makefile#L15 This does *not* actually use go install, which I find to be a little strange, but all go install will do is build and drop the bin into $GOBIN. make install additionally sets up the config, but that's really an implementation detail. Semantically, the target should fully "install" the broker into a system and do whatever it needs in order to accomplish that. I don't really have a change suggestion here, but I want to raise some questions if even just for my own edification. * Should make install be using go install? - If it does, how should we handle configuration and other installation tasks? The broker can't be started with a simple go install && broker; you at least need to provide a config. * If RPMs don't care about make install, who is this target for? Developers probably don't want to be doing system installations, and admins should install from RPMs. From jesusr at redhat.com Mon Jun 19 17:27:31 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Mon, 19 Jun 2017 13:27:31 -0400 Subject: [Ansible-service-broker] Make install In-Reply-To: References: Message-ID: <7e48e7f3-4e3e-6f3d-bde3-a456d09dd695@redhat.com> On 06/19/2017 01:19 PM, Erik Nelson wrote: > Looking over this again, we run a set of commands to install the > broker with make install: > > https://github.com/openshift/ansible-service-broker/blob/master/Makefile#L15 > > This does *not* actually use go install, which I find to be a little > strange, but all go install will do is build and drop the bin into > $GOBIN. make install additionally sets up the config, but that's > really an implementation detail. Semantically, the target should fully > "install" the broker into a system and do whatever it needs in order > to accomplish that. > > I don't really have a change suggestion here, but I want to raise some > questions if even just for my own edification. > > * Should make install be using go install? > - If it does, how should we handle configuration and other > installation tasks? The broker can't be started with a simple go > install && broker; you at least need to provide a config. That's fine and makes sense. If the intent is to install the broker on a system then we can keep it. > * If RPMs don't care about make install, who is this target for? > Developers probably don't want to be doing system installations, and > admins should install from RPMs. When we created the Makefile, there was build and run. Build would do a go install which put the broker in $GOPATH/bin (the first entry of the GOPATH). Then make run would launch that passing in the appropriate dev config. The RPM is following the Fedora golang packaging guidelines which uses go build since many go projects won't have a Makefile and expect to be built with go build. So my *biggest* gripe, which I plan on posting a PR for, was make run relying on the system installed broker. make run is truly a dev task. Leave make install as is then. I'll change make run. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From ernelson at redhat.com Mon Jun 19 17:44:07 2017 From: ernelson at redhat.com (Erik Nelson) Date: Mon, 19 Jun 2017 13:44:07 -0400 Subject: [Ansible-service-broker] Make install In-Reply-To: <7e48e7f3-4e3e-6f3d-bde3-a456d09dd695@redhat.com> References: <7e48e7f3-4e3e-6f3d-bde3-a456d09dd695@redhat.com> Message-ID: > So my *biggest* gripe, which I plan on posting a PR for, was make run > relying on the system installed broker. make run is truly a dev task. > > Leave make install as is then. I'll change make run. +1, totally agree. That's what it's always been there for. From rhallise at redhat.com Mon Jun 19 17:46:20 2017 From: rhallise at redhat.com (Ryan Hallisey) Date: Mon, 19 Jun 2017 13:46:20 -0400 Subject: [Ansible-service-broker] Make install In-Reply-To: <7e48e7f3-4e3e-6f3d-bde3-a456d09dd695@redhat.com> References: <7e48e7f3-4e3e-6f3d-bde3-a456d09dd695@redhat.com> Message-ID: On Mon, Jun 19, 2017 at 1:27 PM, jesus m. rodriguez wrote: > On 06/19/2017 01:19 PM, Erik Nelson wrote: >> >> Looking over this again, we run a set of commands to install the >> broker with make install: >> >> >> https://github.com/openshift/ansible-service-broker/blob/master/Makefile#L15 >> >> This does *not* actually use go install, which I find to be a little >> strange, but all go install will do is build and drop the bin into >> $GOBIN. make install additionally sets up the config, but that's >> really an implementation detail. Semantically, the target should fully >> "install" the broker into a system and do whatever it needs in order >> to accomplish that. >> >> I don't really have a change suggestion here, but I want to raise some >> questions if even just for my own edification. >> >> * Should make install be using go install? >> - If it does, how should we handle configuration and other >> installation tasks? The broker can't be started with a simple go >> install && broker; you at least need to provide a config. > > > That's fine and makes sense. If the intent is to install the broker on a > system then we can keep it. > > >> * If RPMs don't care about make install, who is this target for? >> Developers probably don't want to be doing system installations, and >> admins should install from RPMs. > > > When we created the Makefile, there was build and run. Build would do a go > install which put the broker in $GOPATH/bin (the first entry of the GOPATH). > Then make run would launch that passing in the appropriate dev config. > > The RPM is following the Fedora golang packaging guidelines which uses go > build since many go projects won't have a Makefile and expect to be built > with go build. > > So my *biggest* gripe, which I plan on posting a PR for, was make run > relying on the system installed broker. make run is truly a dev task. > > Leave make install as is then. I'll change make run. Agreed. `make run` is only for dev work and possibly gating in the future. -Ryan > > jesus > > -- > jesus m. rodriguez | jesusr at redhat.com > principal software engineer | irc: zeus > red hat systems management | 919.754.4413 (w) > rhce # 805008586930012 | 919.623.0080 (c) > +---------------------------------------------+ > | "you will be assimilated; | > | resistance is futile" | > | -- Borg | > +---------------------------------------------+ > > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker From ernelson at redhat.com Thu Jun 22 00:49:23 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 21 Jun 2017 20:49:23 -0400 Subject: [Ansible-service-broker] Release branch and PRs Message-ID: Hey guys, So it sounds like after today we've decided to cut a release branch for TP1 and call that 0.9.0 (reserving 1.0.0 for the GA release). We've already ballooned to 10 outstanding PRs again; they aren't huge, but I'd really like to try to keep on top of them so we can avoid the situation we hit last week. What's the official plan with the release branch? We're expecting to do that tomorrow or Friday, and the outstanding PRs should be brought into master afterwards? From ernelson at redhat.com Thu Jun 22 00:54:27 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 21 Jun 2017 20:54:27 -0400 Subject: [Ansible-service-broker] Merged entrypoint change Message-ID: FYi, I merged Fabian's entrypoint change. Marked as needed for tech preview and John ACK'd it. Makes sense to me. https://github.com/openshift/ansible-service-broker/pull/211 From jesusr at redhat.com Thu Jun 22 00:54:31 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 21 Jun 2017 20:54:31 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: References: Message-ID: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> Yes, I have one more thing to fix with tito and cut the branch tomorrow. Also there is one pr that we talked about bringing in. The branch will be named release-0.9 unless that's objectionable. Sincerely, Jesus -------- Original Message -------- From: Erik Nelson Sent: Wed Jun 21 20:49:23 EDT 2017 To: ansible-service-broker at redhat.com Subject: [Ansible-service-broker] Release branch and PRs Hey guys, So it sounds like after today we've decided to cut a release branch for TP1 and call that 0.9.0 (reserving 1.0.0 for the GA release). We've already ballooned to 10 outstanding PRs again; they aren't huge, but I'd really like to try to keep on top of them so we can avoid the situation we hit last week. What's the official plan with the release branch? We're expecting to do that tomorrow or Friday, and the outstanding PRs should be brought into master afterwards? _______________________________________________ Ansible-service-broker mailing list Ansible-service-broker at redhat.com https://www.redhat.com/mailman/listinfo/ansible-service-broker From ernelson at redhat.com Thu Jun 22 00:55:25 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 21 Jun 2017 20:55:25 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> References: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> Message-ID: > The branch will be named release-0.9 unless that's objectionable. +1 From ernelson at redhat.com Thu Jun 22 01:46:41 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 21 Jun 2017 21:46:41 -0400 Subject: [Ansible-service-broker] Broker bind output Message-ID: Another point of discussion post-tech-preview: https://github.com/openshift/ansible-service-broker/pull/124#issuecomment-310049369 I think Ryan's made a pretty good argument for this to supplant the 3 approaches originally pitched for credential exfiltration. Should we run this by Clayton or the Openshift folks for a blessing? LGTM, any comments? From jesusr at redhat.com Thu Jun 22 03:05:34 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 21 Jun 2017 23:05:34 -0400 Subject: [Ansible-service-broker] Merged entrypoint change In-Reply-To: References: Message-ID: <394adf62-01df-14c7-03d7-fab0325efb7d@redhat.com> On 06/21/2017 08:54 PM, Erik Nelson wrote: > FYi, I merged Fabian's entrypoint change. Marked as needed for tech > preview and John ACK'd it. Makes sense to me. > > https://github.com/openshift/ansible-service-broker/pull/211 > Why did we remove the build-config.yaml? I htink this is why shawn & chris were getting into a crash loop when running make build-image. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From jesusr at redhat.com Thu Jun 22 03:09:15 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 21 Jun 2017 23:09:15 -0400 Subject: [Ansible-service-broker] Merged entrypoint change In-Reply-To: <394adf62-01df-14c7-03d7-fab0325efb7d@redhat.com> References: <394adf62-01df-14c7-03d7-fab0325efb7d@redhat.com> Message-ID: <527af015-ce60-cd95-f764-a86b69fda7e0@redhat.com> On 06/21/2017 11:05 PM, jesus m. rodriguez wrote: > On 06/21/2017 08:54 PM, Erik Nelson wrote: >> FYi, I merged Fabian's entrypoint change. Marked as needed for tech >> preview and John ACK'd it. Makes sense to me. >> >> https://github.com/openshift/ansible-service-broker/pull/211 >> > > Why did we remove the build-config.yaml? I htink this is why shawn & > chris were getting into a crash loop when running make build-image. > > jesus > Definitely breaks make build-image which is meant to create an image from the local source for development. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From rhallise at redhat.com Thu Jun 22 10:13:51 2017 From: rhallise at redhat.com (Ryan Hallisey) Date: Thu, 22 Jun 2017 06:13:51 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: References: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> Message-ID: If GA is suppose to be 1.0, then are we going to re tag 0.9 to be 1.0 and merge all the new stuff in master for that release? Also, do we need a branch with that code so we can do backports however we're going to do them? Sincerely, -Ryan On Wed, Jun 21, 2017 at 8:55 PM, Erik Nelson wrote: >> The branch will be named release-0.9 unless that's objectionable. > > +1 > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker From jesusr at redhat.com Thu Jun 22 10:22:55 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 22 Jun 2017 06:22:55 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: References: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> Message-ID: <96759274-56b3-4950-a85f-e292b78d7bc8@redhat.com> My thought was that TP will go in release-0.9. Then stuff for GA will end up in master. Once we get close to finishing it we branch to release-1.0. At that point GA changes go to release-1.0 branch and next release goes into master.? The cycle continues. -------- Original Message -------- From: Ryan Hallisey Sent: Thu Jun 22 06:13:51 EDT 2017 To: Erik Nelson Cc: "jesus m. rodriguez" , ansible-service-broker at redhat.com Subject: Re: [Ansible-service-broker] Release branch and PRs If GA is suppose to be 1.0, then are we going to re tag 0.9 to be 1.0 and merge all the new stuff in master for that release? Also, do we need a branch with that code so we can do backports however we're going to do them? Sincerely, -Ryan On Wed, Jun 21, 2017 at 8:55 PM, Erik Nelson wrote: >> The branch will be named release-0.9 unless that's objectionable. > > +1 > > _______________________________________________ > 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 Thu Jun 22 11:25:53 2017 From: rhallise at redhat.com (Ryan Hallisey) Date: Thu, 22 Jun 2017 07:25:53 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: <96759274-56b3-4950-a85f-e292b78d7bc8@redhat.com> References: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> <96759274-56b3-4950-a85f-e292b78d7bc8@redhat.com> Message-ID: What I meant to ask is are we merging features into GA or is it only bug fixes? -Ryan On Thu, Jun 22, 2017 at 6:22 AM, jesus m. rodriguez wrote: > My thought was that TP will go in release-0.9. Then stuff for GA will end up in master. Once we get close to finishing it we branch to release-1.0. At that point GA changes go to release-1.0 branch and next release goes into master. The cycle continues. > > > -------- Original Message -------- > From: Ryan Hallisey > Sent: Thu Jun 22 06:13:51 EDT 2017 > To: Erik Nelson > Cc: "jesus m. rodriguez" , ansible-service-broker at redhat.com > Subject: Re: [Ansible-service-broker] Release branch and PRs > > If GA is suppose to be 1.0, then are we going to re tag 0.9 to be 1.0 > and merge all the new stuff in master for that release? > Also, do we need a branch with that code so we can do backports > however we're going to do them? > > Sincerely, > -Ryan > > On Wed, Jun 21, 2017 at 8:55 PM, Erik Nelson wrote: >>> The branch will be named release-0.9 unless that's objectionable. >> >> +1 >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker > From jesusr at redhat.com Thu Jun 22 11:27:28 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 22 Jun 2017 07:27:28 -0400 Subject: [Ansible-service-broker] Release branch and PRs In-Reply-To: References: <031dddc7-1d02-4832-bad3-4d4e039fb4c2@redhat.com> <96759274-56b3-4950-a85f-e292b78d7bc8@redhat.com> Message-ID: <12b9c7cc-c578-4fef-b1d5-f6527d04948f@redhat.com> I would assume GA will be features and bugs while the work is being done in master. Once the branch is cut we should be at the bug stage. -------- Original Message -------- From: Ryan Hallisey Sent: Thu Jun 22 07:25:53 EDT 2017 To: "jesus m. rodriguez" Cc: Erik Nelson , ansible-service-broker at redhat.com Subject: Re: [Ansible-service-broker] Release branch and PRs What I meant to ask is are we merging features into GA or is it only bug fixes? -Ryan On Thu, Jun 22, 2017 at 6:22 AM, jesus m. rodriguez wrote: > My thought was that TP will go in release-0.9. Then stuff for GA will end up in master. Once we get close to finishing it we branch to release-1.0. At that point GA changes go to release-1.0 branch and next release goes into master. The cycle continues. > > > -------- Original Message -------- > From: Ryan Hallisey > Sent: Thu Jun 22 06:13:51 EDT 2017 > To: Erik Nelson > Cc: "jesus m. rodriguez" , ansible-service-broker at redhat.com > Subject: Re: [Ansible-service-broker] Release branch and PRs > > If GA is suppose to be 1.0, then are we going to re tag 0.9 to be 1.0 > and merge all the new stuff in master for that release? > Also, do we need a branch with that code so we can do backports > however we're going to do them? > > Sincerely, > -Ryan > > On Wed, Jun 21, 2017 at 8:55 PM, Erik Nelson wrote: >>> The branch will be named release-0.9 unless that's objectionable. >> >> +1 >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker > From jmatthew at redhat.com Thu Jun 22 13:04:20 2017 From: jmatthew at redhat.com (John Matthews) Date: Thu, 22 Jun 2017 09:04:20 -0400 Subject: [Ansible-service-broker] Merged entrypoint change In-Reply-To: <527af015-ce60-cd95-f764-a86b69fda7e0@redhat.com> References: <394adf62-01df-14c7-03d7-fab0325efb7d@redhat.com> <527af015-ce60-cd95-f764-a86b69fda7e0@redhat.com> Message-ID: This change was done so the broker would function properly as delivered for tech-preview. We can discuss the details in the 10-11:30 call. I think the heart of this is a disconnect with assumptions of how the broker will be configured for developer vs production deployments. On Wed, Jun 21, 2017 at 11:09 PM, jesus m. rodriguez wrote: > On 06/21/2017 11:05 PM, jesus m. rodriguez wrote: > >> On 06/21/2017 08:54 PM, Erik Nelson wrote: >> >>> FYi, I merged Fabian's entrypoint change. Marked as needed for tech >>> preview and John ACK'd it. Makes sense to me. >>> >>> https://github.com/openshift/ansible-service-broker/pull/211 >>> >>> >> Why did we remove the build-config.yaml? I htink this is why shawn & >> chris were getting into a crash loop when running make build-image. >> >> jesus >> >> > Definitely breaks make build-image which is meant to create an image from > the local source for development. > > > jesus > > -- > jesus m. rodriguez | jesusr at redhat.com > principal software engineer | irc: zeus > red hat systems management | 919.754.4413 (w) > rhce # 805008586930012 | 919.623.0080 (c) > +---------------------------------------------+ > | "you will be assimilated; | > | resistance is futile" | > | -- Borg | > +---------------------------------------------+ > > > _______________________________________________ > 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 jesusr at redhat.com Tue Jun 27 20:51:16 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Tue, 27 Jun 2017 16:51:16 -0400 Subject: [Ansible-service-broker] how often to run catasb Message-ID: How often do folks run catasb local? Do you usually just run it once then run make run on the broker? or do you destroy and rerun often? I've been doing oc cluster down, setup catasb local, then run the broker. But man this is super inefficient. So clearly I'm doing something wrong. On my laptop, I had to oc cluster down often because oc cluster up wouldn't reliably survive a suspend. that was quite a while ago. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From rhallise at redhat.com Tue Jun 27 20:59:50 2017 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 27 Jun 2017 16:59:50 -0400 Subject: [Ansible-service-broker] how often to run catasb In-Reply-To: References: Message-ID: I have hardware. So I rarely tear down an environment. Once every 3-4 weeks for me. -Ryan On Tue, Jun 27, 2017 at 4:51 PM, jesus m. rodriguez wrote: > How often do folks run catasb local? Do you usually just run it once then > run make run on the broker? or do you destroy and rerun often? > > I've been doing oc cluster down, setup catasb local, then run the broker. > But man this is super inefficient. So clearly I'm doing something wrong. > > On my laptop, I had to oc cluster down often because oc cluster up wouldn't > reliably survive a suspend. that was quite a while ago. > > jesus > > -- > jesus m. rodriguez | jesusr at redhat.com > principal software engineer | irc: zeus > red hat systems management | 919.754.4413 (w) > rhce # 805008586930012 | 919.623.0080 (c) > +---------------------------------------------+ > | "you will be assimilated; | > | resistance is futile" | > | -- Borg | > +---------------------------------------------+ > > > _______________________________________________ > 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 Tue Jun 27 21:07:30 2017 From: rhallise at redhat.com (Ryan Hallisey) Date: Tue, 27 Jun 2017 17:07:30 -0400 Subject: [Ansible-service-broker] how often to run catasb In-Reply-To: References: Message-ID: I was thinking for a team development environment we could setup an Origin cluster on dedicated hardware. Then run the broker locally and point it at the running cluster. That same cluster might be nice for CI too. -Ryan On Tue, Jun 27, 2017 at 4:59 PM, Ryan Hallisey wrote: > I have hardware. So I rarely tear down an environment. Once every 3-4 > weeks for me. > > -Ryan > > On Tue, Jun 27, 2017 at 4:51 PM, jesus m. rodriguez wrote: >> How often do folks run catasb local? Do you usually just run it once then >> run make run on the broker? or do you destroy and rerun often? >> >> I've been doing oc cluster down, setup catasb local, then run the broker. >> But man this is super inefficient. So clearly I'm doing something wrong. >> >> On my laptop, I had to oc cluster down often because oc cluster up wouldn't >> reliably survive a suspend. that was quite a while ago. >> >> jesus >> >> -- >> jesus m. rodriguez | jesusr at redhat.com >> principal software engineer | irc: zeus >> red hat systems management | 919.754.4413 (w) >> rhce # 805008586930012 | 919.623.0080 (c) >> +---------------------------------------------+ >> | "you will be assimilated; | >> | resistance is futile" | >> | -- Borg | >> +---------------------------------------------+ >> >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker From jesusr at redhat.com Wed Jun 28 02:27:35 2017 From: jesusr at redhat.com (jesus m. rodriguez) Date: Tue, 27 Jun 2017 22:27:35 -0400 Subject: [Ansible-service-broker] how often to run catasb In-Reply-To: References: Message-ID: <931f7db7-6a3e-2773-39ef-c05de79a82cb@redhat.com> On 06/27/2017 05:07 PM, Ryan Hallisey wrote: > I was thinking for a team development environment we could setup an > Origin cluster on dedicated hardware. > Then run the broker locally and point it at the running cluster. That > same cluster might be nice for CI too. > > -Ryan Well sounds like most folks run catasb and leave it running. I'll just set it up on my desktop vs laptop. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "you will be assimilated; | | resistance is futile" | | -- Borg | +---------------------------------------------+ From jmatthew at redhat.com Wed Jun 28 10:04:22 2017 From: jmatthew at redhat.com (John Matthews) Date: Wed, 28 Jun 2017 06:04:22 -0400 Subject: [Ansible-service-broker] how often to run catasb In-Reply-To: <931f7db7-6a3e-2773-39ef-c05de79a82cb@redhat.com> References: <931f7db7-6a3e-2773-39ef-c05de79a82cb@redhat.com> Message-ID: <29C96742-80F7-4127-8591-2A7DEE6020DD@redhat.com> What is the issue you are seeing? I will often run reset_environment.sh several times a day, takes about 5 minutes to complete. We will likely reduce this to 2-3 minutes by end of the sprint. > On Jun 27, 2017, at 10:27 PM, jesus m. rodriguez wrote: > >> On 06/27/2017 05:07 PM, Ryan Hallisey wrote: >> I was thinking for a team development environment we could setup an >> Origin cluster on dedicated hardware. >> Then run the broker locally and point it at the running cluster. That >> same cluster might be nice for CI too. >> -Ryan > > Well sounds like most folks run catasb and leave it running. I'll just set it up on my desktop vs laptop. > > jesus > > -- > jesus m. rodriguez | jesusr at redhat.com > principal software engineer | irc: zeus > red hat systems management | 919.754.4413 (w) > rhce # 805008586930012 | 919.623.0080 (c) > +---------------------------------------------+ > | "you will be assimilated; | > | resistance is futile" | > | -- Borg | > +---------------------------------------------+ > > > _______________________________________________ > Ansible-service-broker mailing list > Ansible-service-broker at redhat.com > https://www.redhat.com/mailman/listinfo/ansible-service-broker From ernelson at redhat.com Wed Jun 28 17:08:32 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 28 Jun 2017 13:08:32 -0400 Subject: [Ansible-service-broker] IMPORTANT: Bind credential extraction Message-ID: The long standing bind credential extraction has been ack'd and is getting close to a merge to broker master. https://github.com/openshift/ansible-service-broker/pull/124 It requires *all* apbs to support the new format via https://github.com/fusor/apb-examples/pull/25, so we'll need to merge that atomically. Does anyone have objection to this? I'm going to give this a few hours for objection and then merge. From tsanders at redhat.com Wed Jun 28 17:33:10 2017 From: tsanders at redhat.com (Todd Sanders) Date: Wed, 28 Jun 2017 13:33:10 -0400 Subject: [Ansible-service-broker] IMPORTANT: Bind credential extraction In-Reply-To: References: Message-ID: So do we have mods ready to go for all of our example apbs? or will we be broken? -Todd On Wed, Jun 28, 2017 at 1:08 PM, Erik Nelson wrote: > The long standing bind credential extraction has been ack'd and is > getting close to a merge to broker master. > > https://github.com/openshift/ansible-service-broker/pull/124 > > It requires *all* apbs to support the new format via > https://github.com/fusor/apb-examples/pull/25, so we'll need to merge > that atomically. > > Does anyone have objection to this? I'm going to give this a few hours > for objection and then merge. > > _______________________________________________ > 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 Jun 28 17:37:13 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 28 Jun 2017 13:37:13 -0400 Subject: [Ansible-service-broker] IMPORTANT: Bind credential extraction In-Reply-To: References: Message-ID: Thinking about it more, this is a breaking change for existing apbs. It seems we need a channel for "development" broker and apb as we continue to push forwards upstream. We can branch and version the apb repos to maintain stability, any alternative suggestions? On Wed, Jun 28, 2017 at 1:33 PM, Todd Sanders wrote: > So do we have mods ready to go for all of our example apbs? or will we be > broken? > > -Todd > > On Wed, Jun 28, 2017 at 1:08 PM, Erik Nelson wrote: >> >> The long standing bind credential extraction has been ack'd and is >> getting close to a merge to broker master. >> >> https://github.com/openshift/ansible-service-broker/pull/124 >> >> It requires *all* apbs to support the new format via >> https://github.com/fusor/apb-examples/pull/25, so we'll need to merge >> that atomically. >> >> Does anyone have objection to this? I'm going to give this a few hours >> for objection and then merge. >> >> _______________________________________________ >> Ansible-service-broker mailing list >> Ansible-service-broker at redhat.com >> https://www.redhat.com/mailman/listinfo/ansible-service-broker > > From jmatthew at redhat.com Wed Jun 28 19:46:31 2017 From: jmatthew at redhat.com (John Matthews) Date: Wed, 28 Jun 2017 15:46:31 -0400 Subject: [Ansible-service-broker] IMPORTANT: Bind credential extraction In-Reply-To: References: Message-ID: The path we decided on for this change is: Test the PRs for apb-examples/ansible-service-broker prior to merging Build broker locally, build apb-base, mediawiki/postgres and push to private dockerhub Test a provision/bind workflow with mediawiki and postgres If all looks good proceed with merge to master and rebuild. After we have merged the PRs into master we need to rebuild all the APB examples. This is a manual process at moment, we are talking about building under 10 images. This also implies that anyone running a development version of the broker will break, they will need to upgrade to the new broker image we will be pushing. No impact is planned for the 3.6 release as those images are branched/built in RHCC already, the 3.6 broker is configured to only pull from RHCC and is not expected to use the dockerhub adapter. On Wed, Jun 28, 2017 at 1:37 PM, Erik Nelson wrote: > Thinking about it more, this is a breaking change for existing apbs. > It seems we need a channel for "development" broker and apb as we > continue to push forwards upstream. We can branch and version the apb > repos to maintain stability, any alternative suggestions? > > On Wed, Jun 28, 2017 at 1:33 PM, Todd Sanders wrote: > > So do we have mods ready to go for all of our example apbs? or will we > be > > broken? > > > > -Todd > > > > On Wed, Jun 28, 2017 at 1:08 PM, Erik Nelson > wrote: > >> > >> The long standing bind credential extraction has been ack'd and is > >> getting close to a merge to broker master. > >> > >> https://github.com/openshift/ansible-service-broker/pull/124 > >> > >> It requires *all* apbs to support the new format via > >> https://github.com/fusor/apb-examples/pull/25, so we'll need to merge > >> that atomically. > >> > >> Does anyone have objection to this? I'm going to give this a few hours > >> for objection and then merge. > >> > >> _______________________________________________ > >> 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 Wed Jun 28 20:17:36 2017 From: ernelson at redhat.com (Erik Nelson) Date: Wed, 28 Jun 2017 16:17:36 -0400 Subject: [Ansible-service-broker] IMPORTANT: Bind credential extraction In-Reply-To: References: Message-ID: > Test the PRs for apb-examples/ansible-service-broker prior to merging > Build broker locally, build apb-base, mediawiki/postgres and push to > private dockerhub > Test a provision/bind workflow with mediawiki and postgres > If all looks good proceed with merge to master and rebuild. I will take this on tomorrow.