[Ansible-service-broker] Automation Broker 4-3-18 IRC Meeting

Ryan Hallisey rhallise at redhat.com
Thu Apr 5 14:23:14 UTC 2018


===================================
#asbroker: Automation Broker 4-3-18
===================================


Meeting started by rhallisey at 13:33:09 UTC. The full logs attached.



Meeting summary
---------------
* Attendance  (rhallisey, 13:33:19)

* News  (rhallisey, 13:34:04)
  * bundle-lib 0.1.1  (rhallisey, 13:34:22)
  * Migration command  (rhallisey, 13:35:26)
  * LINK: https://trello.com/c/KlFLeFI0   (rhallisey, 13:35:35)
  * 3.10  (rhallisey, 13:39:45)

* Bugs/Issue triage  (rhallisey, 13:41:03)
  * LINK: https://github.com/openshift/ansible-service-broker/issues/868
    (rhallisey, 13:41:13)
  * LINK:

https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/issues/253
    (rhallisey, 13:44:14)
  * LINK: https://github.com/openshift/ansible-service-broker/issues/818
    (rhallisey, 13:49:56)
  * LINK: https://github.com/automationbroker/bundle-lib/pull/46
    (rhallisey, 13:50:22)
  * LINK: https://github.com/dymurray/depro-creds-apb   (dymurray,
    13:50:23)
  * LINK: https://github.com/dymurray/depro-creds-apb   (rhallisey,
    13:50:35)

* Features  (rhallisey, 13:53:00)
  * LINK:

https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/pull/257
    (rhallisey, 13:53:07)

* Open Discussion  (rhallisey, 13:57:50)
  * Bundle-lib development environment  (rhallisey, 13:57:55)
  * ACTION: jmrodri: create a PR for folks to add ways how they use
    bundle-lib  (rhallisey, 14:08:01)
  * Passing Parameters broker  (rhallisey, 14:15:33)
  * ACTION: community: write a proposal to better define _apb params.
    Let's see if we can split them up into user/system apb params
    (rhallisey, 14:23:16)

* Labeling resources an apb creates  (rhallisey, 14:24:59)
  * LINK:

https://github.com/ansibleplaybookbundle/hello-world-apb/blob/master/templates/deployment.yml#L6-L9
    for an example (hello-world-apb)  (dzager, 14:28:29)
  * ACTION: rhallisey: write up a PR/proposal to service-bundle contract
    (rhallisey, 14:29:59)
  * Automation Broker APB  (rhallisey, 14:30:10)
  * LINK:
    https://github.com/automationbroker/automation-broker-apb/pull/1
    (rhallisey, 14:30:19)

Meeting ended at 14:32:15 UTC.




Action Items
------------
* jmrodri: create a PR for folks to add ways how they use bundle-lib
* community: write a proposal to better define _apb params.  Let's see
  if we can split them up into user/system apb params
* rhallisey: write up a PR/proposal to service-bundle contract




Action Items, by person
-----------------------
* jmrodri
  * jmrodri: create a PR for folks to add ways how they use bundle-lib
* rhallisey
  * rhallisey: write up a PR/proposal to service-bundle contract
* **UNASSIGNED**
  * community: write a proposal to better define _apb params.  Let's see
    if we can split them up into user/system apb params




People Present (lines said)
---------------------------
* rhallisey (97)
* shurley (45)
* jmrodri (44)
* mhrivnak (30)
* brokerbot (29)
* dymurray (20)
* ernelson (17)
* dzager (14)
* jmontleon (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ansible-service-broker/attachments/20180405/de82eff6/attachment.htm>
-------------- next part --------------
13:33:09 <rhallisey> #startmeeting Automation Broker 4-3-18
13:33:09 <brokerbot> Meeting started Tue Apr  3 13:33:09 2018 UTC.  The chair is rhallisey. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:33:09 <brokerbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:33:09 <brokerbot> The meeting name has been set to 'automation_broker_4-3-18'
13:33:09 <brokerbot> rhallisey: startmeeting Meeting Agenda https://docs.google.com/document/d/1Mj7bVYJ8NK-TwU_mxeZLprmBBZZ-xOq-Hg4CiD3E6pM/edit?usp=sharing
13:33:19 <rhallisey> #topic Attendance
13:33:19 <brokerbot> rhallisey: topic
13:33:19 <shurley> thats better!
13:33:21 <rhallisey> o/
13:33:25 <shurley> here
13:33:26 <jmrodri> present
13:33:42 <ernelson> heyo
13:34:04 <rhallisey> #topic News
13:34:04 <brokerbot> rhallisey: topic
13:34:20 <shurley> news - bundle-lib 0.1.1 helm adapter, follow www-authenticate for openshift adapter
13:34:22 <rhallisey> #info bundle-lib 0.1.1
13:34:22 <brokerbot> rhallisey: info
13:34:46 <rhallisey> nice shurley
13:35:00 <shurley> sorry waws a little quick, also removed automationbroker/config as a dependancy and moved to typed structs
13:35:10 <shurley> just a heads up for everyone what went in
13:35:15 <rhallisey> cool
13:35:26 <rhallisey> #info Migration command
13:35:26 <brokerbot> rhallisey: info
13:35:28 <jmrodri> shurley: nice
13:35:35 <rhallisey> #link https://trello.com/c/KlFLeFI0
13:35:35 <brokerbot> rhallisey: link
13:35:48 <shurley> second set of news is migration command is merged and will allow you to move etcd resources to CRDs
13:36:36 <rhallisey> that's awesome
13:36:54 <rhallisey> shurley, I didn't see, but are there any tests around this?
13:37:10 <shurley> rhallisey: unit tests?
13:37:52 <rhallisey> ya
13:38:09 <rhallisey> maybe we could consider having a ci job?
13:38:13 <rhallisey> idk just thoughts
13:38:42 <rhallisey> shurley, we don't have to cover this now, just throwing it out there
13:38:46 <shurley> no, being that I am using actual versions of the daos it might be harder to make units tests
13:38:46 <mhrivnak> +1 that's a good idea.
13:39:00 <shurley> if someone wants to take that up I am not opposed
13:39:04 <rhallisey> just to make sure we don't break the migration on any backports
13:39:21 <rhallisey> ok wfm
13:39:28 <rhallisey> #info 3.10 release
13:39:28 <brokerbot> rhallisey: info
13:39:42 <rhallisey> #undo
13:39:42 <brokerbot> Removing item from minutes: INFO by rhallisey at 13:39:28 : 3.10 release
13:39:45 <rhallisey> #info 3.10
13:39:45 <brokerbot> rhallisey: info
13:39:55 <rhallisey> 3.10 has been a little bumpy
13:40:30 <rhallisey> so if folks are having trouble setting up a dev env jmontleon had a useful email on how to get something working on 3.9
13:40:43 <rhallisey> I'll probably forward that to the upstream list
13:40:52 <jmrodri> rhallisey: +1
13:41:03 <rhallisey> #topic Bugs/Issue triage
13:41:04 <brokerbot> rhallisey: topic
13:41:13 <rhallisey> #link https://github.com/openshift/ansible-service-broker/issues/868
13:41:13 <brokerbot> rhallisey: link
13:41:56 <jmontleon> rhallisey, after I talk to jmatthews and if we decide to keep the release-1.1 branch I was going to change the default tag to v3.9 and the asb_template_url to point at the ansible-service-broker release-1.1 branch template so there's no special config required
13:41:57 <rhallisey> mhrivnak, you reported this, but I added it for discussion because I think it's some low hanging fruit
13:41:59 <jmontleon> switch branch and go
13:42:11 <mhrivnak> rhallisey yeah I agree it's low hanging fruit.
13:42:25 <rhallisey> jmontleon, awesome, thanks
13:42:36 <mhrivnak> Perhaps the kind of thing someone could knock out if they finish their sprint work a little early.
13:42:40 <jmrodri> rhallisey: it's low, I marked it as tech-debt since it is mostly good for our debugging
13:42:52 <jmrodri> and it is to keep the logs informative vs full of noise
13:42:55 <rhallisey> mhrivnak, +1
13:42:57 <mhrivnak> jmrodri FWIW I think it's a little more than that.
13:43:15 <mhrivnak> It's quite misleading, and it caused me to waste some time debugging a problem that didn't exist.
13:43:26 <mhrivnak> So I think normal users could easily be thrown off by it.
13:43:36 <jmrodri> more than tech-debt?
13:43:40 <jmrodri> oh I understand now, +1
13:43:42 <mhrivnak> Yep.
13:43:58 <rhallisey> ok that's all I had for that issue
13:44:01 <mhrivnak> Certainly it's still relatively low-priority.
13:44:14 <rhallisey> #link https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/issues/253
13:44:14 <brokerbot> rhallisey: link
13:44:38 <jmrodri> rhallisey: for this issue there was a comment to my pnt internal blog post
13:44:57 <ernelson> this is easily possible, at least with minishift docker-env
13:45:02 <jmrodri> where they might not have root on a machien to install docker
13:45:05 <rhallisey> dymurray, does this require a apb tool change?
13:45:12 <jmrodri> or don't have openshift installed locally.
13:45:12 <ernelson> that's what you're doing when you run that command; you're seutp to use the remote cluster
13:45:18 <ernelson> we can emulate that
13:45:19 <dymurray> rhallisey, sorry yeah so quick explanation on this
13:45:42 <ernelson> (there's actually already a branch in the apb code that does this)
13:45:48 <dymurray> there is a desire for developers who are used to having images built in openshift to follow a similar workflow
13:45:49 <ernelson> sort of
13:46:08 <dymurray> so this leads into the PR I linked in the features section
13:46:21 <dymurray> I wrote up a document that should allow the internal registry adapter to work with `oc new-app`
13:46:40 <rhallisey> dymurray, +1
13:46:42 <dymurray> But I would love to get other peoples suggestions and potential workarounds documented too. So I would appreciate people testing this out and providing usability improvements
13:47:11 <dymurray> We don't want to follow the minishift process... because most devs won't be able to get the docker certs from the remote cluster
13:47:52 <rhallisey> make sense dymurray.  Will add any comments in the issue
13:48:05 <shurley> dymurray: we are calling this a work around right
13:48:06 <mhrivnak> Yeah, and allowing them direct access to docker on the cluster may be a security concern.
13:48:15 <dymurray> mhrivnak, +1
13:48:17 <shurley> and that it is not really a "feature" that we support directly?
13:48:21 <dymurray> shurley, yes, just documenting the workaround
13:48:44 <dymurray> shurley, well we *do* support bootstrapping images from the interal openshift registry
13:48:50 <dymurray> so this is just another way to get the image there
13:49:19 <rhallisey> Any more issues/bugs folks want to discuss?
13:49:34 <rhallisey> dymurray, was the issue with bind creds reaching deprovision solved?
13:49:56 <rhallisey> #link https://github.com/openshift/ansible-service-broker/issues/818
13:49:56 <brokerbot> rhallisey: link
13:50:11 <dymurray> rhallisey, I used mhrivnak's suggestion to create a configmap with the service instance ID
13:50:22 <rhallisey> #link https://github.com/automationbroker/bundle-lib/pull/46
13:50:22 <brokerbot> rhallisey: link
13:50:23 <dymurray> https://github.com/dymurray/depro-creds-apb
13:50:35 <rhallisey> #link https://github.com/dymurray/depro-creds-apb
13:50:35 <brokerbot> rhallisey: link
13:51:07 <dymurray> so the broker issue can be closed if we agree that we will us the apb-state proposal to solve this use case
13:51:12 <dymurray> use*
13:51:16 <shurley> +1
13:51:50 <rhallisey> ok
13:52:15 <mhrivnak> Seems reasonable.
13:52:16 <rhallisey> dymurray, can you add that to the state proposal? Or issue?
13:52:25 <dymurray> rhallisey, yup
13:52:48 <rhallisey> thanks
13:53:00 <rhallisey> #topic Features
13:53:00 <brokerbot> rhallisey: topic
13:53:07 <rhallisey> #link https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/pull/257
13:53:08 <brokerbot> rhallisey: link
13:53:33 <dymurray> rhallisey, this is the PR I mentioned earlier. My documented workaround using `oc new-app`
13:54:34 <rhallisey> dymurray, gotcha.  I think this is covered
13:54:38 <dymurray> +1
13:54:46 <rhallisey> anyone want to discuss any more features?
13:55:38 <rhallisey> jmontleon, I saw your CFME adaptor PR.  Is that something you want to mention?
13:56:50 <rhallisey> my understanding is that it allows CFME service to be available in the catalog
13:57:11 <jmrodri> rhallisey: that is also my understanding.
13:57:30 <rhallisey> cool stuff
13:57:43 <rhallisey> ok we'll move to open discussion
13:57:50 <rhallisey> #topic Open Discussion
13:57:50 <brokerbot> rhallisey: topic
13:57:55 <rhallisey> #info Bundle-lib development environment
13:57:55 <brokerbot> rhallisey: info
13:58:13 <rhallisey> I've done this a number of ways
13:58:37 <rhallisey> but I'm curious how other folks are doing dev work with bundle-lib
13:58:45 <ernelson> shurley: had an approach I was interested in
13:58:57 <dymurray> +1 I heard shurley's in scrum I think was interested in that one personally
13:59:10 <shurley> ernelson: so I have done it two to ways
13:59:25 <shurley> 1. I delete the vendor dir in bundle-lib
13:59:48 <shurley> and then mv the bundle-lib from the vendor of ASB to a .bak
14:00:04 <shurley> and then you can build ASB and it will use the GOPATH version
14:00:12 <ernelson> that never seemed to work for me
14:00:21 <ernelson> because it techincally thought those were of a different type for some reason
14:00:28 <jmontleon> rhallisey, Yes, it will load Service Templates from CFME and generate APB Specs. Parameters will come from Dialog Fields
14:00:35 <shurley> you need to delete the vendor of bundle-lib
14:00:49 <shurley> and have all of its deps either in GOPATH or in the vendor of ASB
14:00:50 <ernelson> definitely did that but I can try again
14:00:58 <jmrodri> for the broker vendoring I've been making changes to broker branch, then rsync the files to my samplebroker vendor tree :)
14:01:06 <rhallisey> jmontleon, +1
14:01:13 <jmontleon> It's more a proof of concept at the moment though (and still being roughed out at this point, so the PR doesn't contain much; although maybe I'll push what I have by EOD)
14:01:17 <jmrodri> not ideal but it has been working for me.
14:01:19 <rhallisey> jmrodri, nice :)
14:01:43 <shurley> the other way is to use the source and branch fields in GoPkg.toml
14:01:47 <jmrodri> I've also done gendiff for small changes. I'll edit bundle-lib files directly in vendor, then use gendiff to create a patch and apply to the bundle-lib tree
14:02:16 <shurley> If I have to update the vendor dirs then this is the easiest way
14:02:19 <jmrodri> but I haven't found a single way of doing it. Depends on what I'm doing and how fast I need to make the turn around
14:02:29 <shurley> so you create a branch for bundle lib in your fork
14:02:40 <shurley> set the source and branch to your fork and your branch
14:03:01 <shurley> then dev and push to your fork and just run dep ensure -update ..... to get the updated code in ASB
14:03:10 <shurley> that has been the ways that I do it
14:03:17 <rhallisey> one way I did it was to point the bundle-lib repo at git.  Then I think I pulled and removed vendor directory inside bundle-lib
14:03:25 <jmrodri> that branch field has worked for me, but hasn't worked for quick turn around. I found it most useful for pegging a version I wanted to start from.
14:03:28 <dzager> ^ I've done this way. Not a short cycle but it works
14:03:47 <ernelson> I've personally been bind mounting the dependency into the consumer's vendor, then I symlink to the actual project at the top level so I can index both projects with ctl_p. Works well, except for the bind mount part.
14:03:50 <jmrodri> dep ensure seems to do weird things to me, like take a long time or update a bunch of stuff I didn't expect while I"m working
14:04:00 <dzager> jmrodri: yeah. I agree, not short at all. It worked for me since I was basically finished with the helm-adapter.
14:04:11 <ernelson> I don't like having a bunch of intermediate steps to propogate changes
14:04:32 <jmrodri> right now I'm thinking there isn't one way to do this :)
14:04:49 <ernelson> probably just going to have to share what everyone is doing and choose what suits you
14:05:07 <jmrodri> I wonder if it would be useful to document some of these TIPS on our broker docs in developer guide?
14:05:08 <rhallisey> agreed jmrodri, I think there might be a few ways.  But I think we can all agree it would be good to have a doc or something around this?
14:05:19 <rhallisey> jmrodri, +!
14:05:20 <rhallisey> +!
14:05:22 <rhallisey> +1*
14:05:28 <jmrodri> thanks for the excitement rhallisey :)
14:05:39 <dzager> such excitement much !
14:05:45 <rhallisey> my pinking was glued to shift lol
14:05:52 <rhallisey> pinky
14:05:56 <rhallisey> I can't type right now...
14:06:26 <jmrodri> we can all add our ways of doing it, and folks can pick and choose what works best for them. We could document the long way I think that's using the branch in a fork and dep ensure -update way
14:06:40 <jmrodri> make that the first suggestion, then go into the others.
14:07:00 <rhallisey> does anyone want to take on starting this doc?
14:07:02 <jmrodri> I know gendiff won't work on Mac (at least I don't think they have gendiff :)
14:07:15 <jmrodri> I can start it but not until later this week
14:07:16 <rhallisey> I think we can have each person contribute a way to do that they use
14:07:21 <jmrodri> definitely before next IRC meeting
14:07:46 <jmrodri> it will be done before next meeting
14:08:01 <rhallisey> #action jmrodri: create a PR for folks to add ways how they use bundle-lib
14:08:01 <brokerbot> rhallisey: action
14:08:28 <rhallisey> jmrodri, if the pr is up before next meeting that would be awesome. Then we can collaborate on adding other ways in meeting
14:08:41 <jmrodri> perfect
14:08:42 <shurley> rhallisey: jmrodri ernelson 1 last thing
14:08:53 <shurley> is that eventually/soon they should not be linked
14:08:57 <shurley> IMO
14:09:17 <jmrodri> what should not be linked?
14:09:25 <jmrodri> bundle-lib and broker?
14:09:31 <shurley> they should be seperate steps in an implementation. First the ability to do X thing using hydro/bundle-lib
14:09:38 <shurley> and then the implementation in broker
14:10:03 <shurley> that is not the case right now, but I think that is the what we should expect the future to be IMO
14:10:20 <jmrodri> I think I'm missing something.
14:10:40 <jmrodri> I think the problem we're trying to solve right now is when I need a change in the library I'm using to support the change in the broker I'm working on.
14:11:24 <dzager> maybe we can add automation to bundle-lib/hydro to build a broker with our changes?
14:11:29 <shurley> right, and eventually it should be I add a feature to the library and then I change the broker. We should not be working on a feature for the broker
14:11:43 <jmrodri> and ultimately once I'm done how those changes get to the respective code bases falls under each projects submission guidelines
14:11:47 <ernelson> I'm not sure I agree, in practice that's how changes are made but there are plently of examples where a change will cross both boundaries and it's a very common pattern to have a main consume + a library with the core logic
14:11:49 <shurley> we should be adding a feature for bundle-lib and then implementing in the broker
14:12:11 <jmrodri> shurley: well I think it will always be BOTH
14:12:32 <jmrodri> there will be times where the library is gettnig a change that is needed by something that uses it (not necessarily the broker).
14:12:47 <jmrodri> then there are times the broker has a feature that requires a change in the library.
14:13:00 <jmrodri> shurley: so your point is valid, but not exclusive
14:13:54 <mhrivnak> Yeah, I think people often want to develop features in libraries and be able to use the feature in-practice during development.
14:14:33 <dzager> I have something for the open discussion when an opening arrives
14:14:56 <rhallisey> for this topic, let's start with the doc
14:15:04 <rhallisey> and we'll move on to other open items
14:15:21 <rhallisey> dzager, can you add it to the list
14:15:33 <rhallisey> #info Passing Parameters broker
14:15:33 <brokerbot> rhallisey: info
14:15:56 <shurley> I added this one, while consuming the executor code from a new project
14:16:05 <jmrodri> rhallisey: +1
14:16:19 <shurley> I realized how opaque the _apb params are to a caller
14:16:44 <shurley> especailly becuase some are needed (plan, service_instance_id....)
14:17:16 <shurley> I was wondering if we could have a quick discussion of ways to maybe make this less of a mystry to a consumer
14:17:41 <mhrivnak> Would this be improved by changing the service bundle contract to separate these different kinds of inputs, and reflecting that change in the experience here also?
14:17:42 <dzager> I think mhrivnak had some good thoughts on this
14:17:46 <mhrivnak> lol
14:18:46 <shurley> > and reflecting that change in the experience here also? can you elaborate?
14:19:15 <ernelson> mhrivnak: +1, the set of them reflect sort of "system" level parameters that the broker provides
14:19:18 <ernelson> makes sense to capture that in a type
14:19:37 <mhrivnak> I haven't seen this part of bundle-lib, but speculating... we could separate the two (maybe more) kinds of data, yes as ernelson is describing.
14:19:46 <mhrivnak> system input vs. user-provided params
14:20:15 <mhrivnak> It all ends up in one pile when the bundle gets run, but the interface to bundle-lib could receive them separately.
14:20:51 <mhrivnak> for now, and then eventually we'll separate them in the contract also and change how the input is passed into the pod.
14:21:38 <rhallisey> just so I have an action item on this.  Where should this change first happen
14:21:39 <jmrodri> that makes sense to me.
14:21:40 <mhrivnak> so I call bundle-lib.DoSomething(userParams, otherEnvironmentalStuffAndContext)
14:22:06 <rhallisey> should start with a pr to the contract?
14:22:16 <mhrivnak> rhallisey probably we need to define an end goal first for how to separate out all the data in a reasonable way.
14:22:22 <jmrodri> rhallisey:  first thing is an overarching proposal I think. Covering the concept at a high level, then digging into this notion of a system paramters.
14:22:37 <dzager> jmrodri: +1
14:22:37 <shurley> mhrivnak: the problem is that right now they all come in the through the APB.ServiceInstance
14:22:43 <jmrodri> then dig into how to implement them into bundle-lib and bundles
14:23:00 <shurley> we need to break up the types of "ServiceInstance" I thihnk
14:23:07 <jmrodri> shurley: so they've already been collapsed?
14:23:10 <mhrivnak> shurley gotcha, yeah I was afraid this might be difficult based on where it was coming from.
14:23:16 <rhallisey> #action community: write a proposal to better define _apb params.  Let's see if we can split them up into user/system apb params
14:23:16 <brokerbot> rhallisey: action
14:23:21 <shurley> and then you have to make sure to update the conversions and that stuff
14:23:30 <shurley> a proposal would be nice
14:23:49 <rhallisey> thanks for bringing it up shurley.  Let's start with a proposal
14:23:50 <shurley> we can deal with all of this
14:23:55 <mhrivnak> And this can also be part of the discussion about general improvements to the contract.
14:24:02 <shurley> just letting you know the current state
14:24:07 <jmrodri> mhrivnak: +1
14:24:09 <shurley> +1 +1
14:24:16 <rhallisey> I left that as an action item for the community does anyone want to take that on?
14:24:39 <rhallisey> if not, we'll move on
14:24:46 <jmrodri> rhallisey: leave it open for now
14:24:47 <mhrivnak> I have a standing action to move the contract improvement discussion forward.
14:24:53 <rhallisey> ok wfm
14:24:59 <rhallisey> #topic Labeling resources an apb creates
14:24:59 <brokerbot> rhallisey: topic
14:25:09 <rhallisey> I noticed this in the template-service-broker
14:25:21 <rhallisey> they add a label to each resource a template creates
14:25:39 <mhrivnak> That would be super-nice. tiller does something similar.
14:25:40 <ernelson> +1 wrt shurley's proposal idea
14:25:49 <rhallisey> I was thinking that we could too so that we have an idea what resources an apb created
14:26:21 <mhrivnak> yeah, and that would make cleanup more definite in cases where deprovision failed or wasn't possible for some reason.
14:26:27 <dzager> I still don't see how this can be done without action from the APB developer
14:26:33 <rhallisey> mhrivnak, ya that's what I was thinking too
14:27:04 <mhrivnak> dzager identified the key problem I think
14:27:39 <dzager> I had originally wondered if there was some way to get all the of the objects created by a particular service account, via an audit of sorts and then annotate them after an action is complete
14:27:43 <mhrivnak> Since a service bundle can create stuff through "any means necessary", it's hard for us to intercept create operations and add a label.
14:27:47 <rhallisey> dzager, yes, I'm thinking the apb FQName will be availble in the apb.  We can make note that the dev add a label for it
14:28:10 <rhallisey> this make belong as a bundle-contract proposal
14:28:18 <rhallisey> may*
14:28:29 <dzager> https://github.com/ansibleplaybookbundle/hello-world-apb/blob/master/templates/deployment.yml#L6-L9 for an example (hello-world-apb)
14:28:43 <rhallisey> dzager, +1
14:28:43 <mhrivnak> It would be good if we can get the service instance ID on the resources.
14:29:07 <shurley> personally, I think that these are all nice to haves, but I wouldn't want the broker dependant on them
14:29:15 <mhrivnak> In theory you could provision the same bundle twice in the same namespace, and I think we still want to differentiate them via a label.
14:29:31 <rhallisey> shurley, right, I think it's hard to mandate, but it would be good to have
14:29:38 <dzager> yeah. we have had a lot of good discussion about this. I think adding this to the service bundle contract would be a good start. But we can't really (en)force this behavior
14:29:42 <mhrivnak> agreed on nice-to-have for now
14:29:46 <mhrivnak> maybe forever
14:29:59 <rhallisey> #action rhallisey: write up a PR/proposal to service-bundle contract
14:29:59 <brokerbot> rhallisey: action
14:30:10 <rhallisey> #info Automation Broker APB
14:30:10 <brokerbot> rhallisey: info
14:30:19 <rhallisey> #link https://github.com/automationbroker/automation-broker-apb/pull/1
14:30:19 <brokerbot> rhallisey: link
14:30:45 <dzager> So I got really frustrated over the past few weeks with all of the varying ways of deploying the broker. Enter the automation-broker-apb
14:31:04 <rhallisey> woo
14:31:11 <dzager> I'm still working through some kinks as the k8s_raw does not handle crds or the servicecatalog objects very well
14:31:13 <jmrodri> nice
14:31:36 <dzager> but I am currently able to deploy an 'automation-broker' in the 'automation-broker' and get it talking to the service catalog
14:31:42 <rhallisey> very nice
14:31:49 <dymurray> +1 very cool
14:31:57 <rhallisey> thanks for bringing it up dzager
14:32:02 <rhallisey> I think we're all out of time
14:32:07 <rhallisey> thanks folks!
14:32:14 <dymurray> bye :)
14:32:15 <rhallisey> #endmeeting
-------------- next part --------------
===================================
#asbroker: Automation Broker 4-3-18
===================================


Meeting started by rhallisey at 13:33:09 UTC. The full logs are
available at asbroker/2018/asbroker.2018-04-03-13.33.log.html .



Meeting summary
---------------
* Attendance  (rhallisey, 13:33:19)

* News  (rhallisey, 13:34:04)
  * bundle-lib 0.1.1  (rhallisey, 13:34:22)
  * Migration command  (rhallisey, 13:35:26)
  * LINK: https://trello.com/c/KlFLeFI0   (rhallisey, 13:35:35)
  * 3.10  (rhallisey, 13:39:45)

* Bugs/Issue triage  (rhallisey, 13:41:03)
  * LINK: https://github.com/openshift/ansible-service-broker/issues/868
    (rhallisey, 13:41:13)
  * LINK:
    https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/issues/253
    (rhallisey, 13:44:14)
  * LINK: https://github.com/openshift/ansible-service-broker/issues/818
    (rhallisey, 13:49:56)
  * LINK: https://github.com/automationbroker/bundle-lib/pull/46
    (rhallisey, 13:50:22)
  * LINK: https://github.com/dymurray/depro-creds-apb   (dymurray,
    13:50:23)
  * LINK: https://github.com/dymurray/depro-creds-apb   (rhallisey,
    13:50:35)

* Features  (rhallisey, 13:53:00)
  * LINK:
    https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/pull/257
    (rhallisey, 13:53:07)

* Open Discussion  (rhallisey, 13:57:50)
  * Bundle-lib development environment  (rhallisey, 13:57:55)
  * ACTION: jmrodri: create a PR for folks to add ways how they use
    bundle-lib  (rhallisey, 14:08:01)
  * Passing Parameters broker  (rhallisey, 14:15:33)
  * ACTION: community: write a proposal to better define _apb params.
    Let's see if we can split them up into user/system apb params
    (rhallisey, 14:23:16)

* Labeling resources an apb creates  (rhallisey, 14:24:59)
  * LINK:
    https://github.com/ansibleplaybookbundle/hello-world-apb/blob/master/templates/deployment.yml#L6-L9
    for an example (hello-world-apb)  (dzager, 14:28:29)
  * ACTION: rhallisey: write up a PR/proposal to service-bundle contract
    (rhallisey, 14:29:59)
  * Automation Broker APB  (rhallisey, 14:30:10)
  * LINK:
    https://github.com/automationbroker/automation-broker-apb/pull/1
    (rhallisey, 14:30:19)

Meeting ended at 14:32:15 UTC.




Action Items
------------
* jmrodri: create a PR for folks to add ways how they use bundle-lib
* community: write a proposal to better define _apb params.  Let's see
  if we can split them up into user/system apb params
* rhallisey: write up a PR/proposal to service-bundle contract




Action Items, by person
-----------------------
* jmrodri
  * jmrodri: create a PR for folks to add ways how they use bundle-lib
* rhallisey
  * rhallisey: write up a PR/proposal to service-bundle contract
* **UNASSIGNED**
  * community: write a proposal to better define _apb params.  Let's see
    if we can split them up into user/system apb params




People Present (lines said)
---------------------------
* rhallisey (97)
* shurley (45)
* jmrodri (44)
* mhrivnak (30)
* brokerbot (29)
* dymurray (20)
* ernelson (17)
* dzager (14)
* jmontleon (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


More information about the Ansible-service-broker mailing list