Operator SIG meeting notes - 2019-July 16

Agenda:
(1) Binding imported applications with operator-backed services - Shoubhik Bose (Red Hat)
> slides: https://docs.google.com/presentation/d/19irVX7Stm_-rtAZYL6keX6h8QsW-QdFt/edit#slide=id.p1
> feedback: https://github.com/redhat-developer/service-binding-operator/labels/feedback

(2) Portworx Operator - Vick Kelkar (Portworx)
(3) Tremolo Operator - Marc Boorshtein (Tremolo)


Attendees:

Diane Mueller (Red Hat)
Rob Szumski (Red Hat)
Shoubhik Bose (Red Hat)
Otávio Fernandes(Red Hat)
Andre Tost (IBM)
Baiju Muthukadan (Red Hat)
Vick Kelkar (Portworx)
Piyush Nimbalkar (Portworx)
Marc Boorshtein (Tremolo)
Edward Callahan (LightBend)
Tamal Saha (AppsCode)
Jason Plum? (GitLab?)
Tom Armstrong (Gitlab)
Luis García (Dynatrace)
Tom Gates (NuoDB)
Pragash Vijayaragavan (Juniper)
John McKenzie (Red Hat)
Len DiMaggio (Red Hat)
Michael Hrivnak (Red Hat)
Tony Campbell (Red Hat)
Steve Speicher (Red Hat)
Dhriti Shikhar (Red Hat)
Roland Huß (Red Hat
Shawn Hurley (Red Hat)
Diane Feddema (Red Hat)
Roey
akshinde

Blue Jeans Chat Q/A:

@Andre Tost(IBM)
Question: this requires the secret to be mounted into the target pod and then that pod has to be restarted, right? 
          would there be a way to automate this into one step, i.e. deploy the app and the bind it at the same time?
@Otávio Fernandes(Red Hat)
Answer:   yes that's correct, the operator find what's "interesting for binding" and creates a temporary secret, which is then 
          given to the application (as `envFrom`) and yes, that would be possible, the operator would be looking for that 
          application object, and when available would then reconcile, which means, binding those two by start
@Otávio Fernandes(Red Hat)          
Follow-up:  i would assume that when you deploy the app, you basically know what target db (in this case) you want to bind 
            to and that target can vary between deployments for, say, dev, test or prod - you deploy the same app, but bind 
            to different targets
@Andre Tost(IBM)
Reply:      that's also correct, you have to have a single object as a backend, otherwise the operator would not be able to 
             reconcile


Raw Chat: 

Baiju Muthukadan8:56 AM
hi
Edward Callahan8:56 AM
Hello, hello
Shoubhik Bose8:58 AM
Hey everyone!
Shoubhik Bose8:58 AM
How does Helium taste? ;)
Len DiMaggio8:59 AM
hydrogen is more exciting ;-)
Len DiMaggio8:59 AM
helium powered web services........
Shoubhik Bose9:00 AM
This is our slide https://docs.google.com/presentation/d/19irVX7Stm_-rtAZYL6keX6h8QsW-QdFt
Shoubhik Bose9:00 AM
could we confirm that folks can access it
Edward Callahan9:00 AM
confirmed
Shoubhik Bose9:00 AM
Hey Tamal! Good to see you.
Shoubhik Bose9:00 AM
Thanks Edward.
9:06 AMMe
Meeting Notes here: https://gist.github.com/dmueller2001/ba96ec04443ceea1718f75ce632632e4
Steve Speicher9:06 AM
This is a new view planned for 4.2, so a nice little preview!
9:06 AMMe
;-)
Shoubhik Bose9:08 AM
Please add your feedback for this here
Shoubhik Bose9:08 AM
https://docs.google.com/document/d/1QrrRVpH32bJkbCuS3hKI3VYcuPipUz3WR7g-h_QZLds
Shoubhik Bose9:08 AM
( need a better place though we have github :) )
Tom Armstrong9:08 AM
gitlab :-)
Shoubhik Bose9:08 AM
haha
Otávio Fernandes9:11 AM
@Jason, please consider the project: https://github.com/redhat-developer/service-binding-operator
Andre Tost9:12 AM
sorry, i am in a very loud place and won't be able to talk on the phone, so let me ask my question here: this requires the secret to be mounted into the target pod and then that pod has to be restarted, right?
Andre Tost9:12 AM
would there be a way to automate this into one step, i.e. deploy the app and the bind it at the same time?
Otávio Fernandes9:13 AM
@Andre, yes that's correct, the operator find what's "interesting for binding" and creates a temporary secret, which is then given to the application (as `envFrom`)
Otávio Fernandes9:14 AM
and yes, that would be possible, the operator would be looking for that application object, and when available would then reconcile, which means, binding those two by start
Otávio Fernandes9:14 AM
(from start)
Rob Szumski9:14 AM
good question
Andre Tost9:14 AM
okay, cool - i would assume that when you deploy the app, you basically know what target db (in this case) you want to bind to
Andre Tost9:15 AM
and that target can vary between deployments for, say, dev, test or prod - you deploy the same app, but bind to different targets
Otávio Fernandes9:15 AM
@Andre, that's also correct, you have to have a single object as a backend, otherwise the operator would not be able to reconcile
Otávio Fernandes9:16 AM
and about splitting the environments, you can use labels to identify them, and I would also assume they are split by namespace
Andre Tost9:17 AM
so then the question is how do i use this same mechanism to bind to a remote service (that may or may not run as a container) - I would need some form of placeholder object that represents that remote service
Andre Tost9:17 AM
for example, if i am using a db service that runs in, say, AWS
Michael Hrivnak9:17 AM
You can create an operator that manages an external service.
Rob Szumski9:17 AM
headless service maybe?
Roey9:17 AM
perhaps create a config map
Roey9:18 AM
and each user of the DB gets it's own configmap
Roey9:18 AM
instead of status
Otávio Fernandes9:18 AM
@Andre, for a external service I don't think we would be able to do that right now, but that's a quite interesting subject to explore, maybe as @Rob puts, we could have a headless service in place
Andre Tost9:18 AM
this all looks a lot like OSB broker and bindings, just mapped into the operator space
Otávio Fernandes9:19 AM
what's a OSB broker?
Andre Tost9:19 AM
open service broker
Jason9:19 AM
open service broker
Otávio Fernandes9:19 AM
thanks :-) I'm going to check it out
Jason9:19 AM
and yes,.. that is that point correct?
Vick Kelkar9:19 AM
https://www.openservicebrokerapi.org/
Len DiMaggio9:19 AM
this? https://www.openservicebrokerapi.org/
Len DiMaggio9:19 AM
thx!
Otávio Fernandes9:20 AM
however, is good to keep in mind that we rely in the Operator Lifecycle manager to identify which informaiton is needed, so in case of a external service we would have to explore a different front
Andre Tost9:20 AM
there is a type called ServiceBinding in the service catalog feature for kubernetes that you may find interesting - it has some limitations, but it automates the secret generation, similar to what you guys have done
Otávio Fernandes9:21 AM
cool! thanks, Andre
Steve Speicher9:22 AM
I think we are trying to all work together to help solve these problems! Do we want to start a working group on this from this SIG?
Jason9:22 AM
ideally this approach and OSB would be unified in someway, so at least for app dev the "binding" concept is the same
Baiju Muthukadan9:23 AM
GitOps doesn't have order of execution?
Len DiMaggio9:23 AM
@Otavio - https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
Andre Tost9:23 AM
I would love for us to start a concerted effort to figure this out. This is a really important piece of the puzzle, in my opinion. And this is a great start!
Roey9:24 AM
I agree it's a great start!
Michael Hrivnak9:24 AM
If the order of resource creation mattered for this case, that would be a bug in one of the controllers. I think gitops with concurrent creation of resources should work just fine.
Otávio Fernandes9:25 AM
Thanks!
Shoubhik Bose9:26 AM
Andre, yes! OSB! You mean 'service catalog' right? ;)
Andre Tost9:26 AM
yes
Shoubhik Bose9:26 AM
You got it right, this is the equivalent experience ( and in a slightly simpler way ) for operators
Tamal Saha9:26 AM
Thanks for the demo Shoubhik and co. Feel free to reach me via email.
Andre Tost9:27 AM
i also feel like the discussions for the service catalog are focused on the catalog part, but i think the secret sauce is in the binding, i.e. just the kind of thing you have shown here
Jason9:27 AM
+1 @Andre
Len DiMaggio9:28 AM
Presentation mode please ;-)
Justin Pittman9:28 AM
now it's up
Len DiMaggio9:28 AM
it's there now
Roey9:28 AM
good now
Edward Callahan9:28 AM
thanks
Shoubhik Bose9:31 AM
Thanks Jaon and Andre!
Shoubhik Bose9:32 AM
@Tamal , folks, I've created feedback issues on Github https://github.com/redhat-developer/service-binding-operator/labels/feedback
Shoubhik Bose9:32 AM
Tamal, could you please fill in on the vault scenario please on the github issue?
9:39 AMMe
also if I got your names/affiliations wrong in the meeting notes, please let me know: https://gist.github.com/dmueller2001/ba96ec04443ceea1718f75ce632632e4
Rob Szumski9:41 AM
really great progress towards level 5!
Michael Hrivnak9:42 AM
Portworx: thanks! That was a great overview. In case you haven't already done so, it would be wonderful to have your feedback in the form of github issues so we can make sure they're tracked and carefully considered.
Tony Campbell9:42 AM
@piyush @portworx does your operator currently expose any prometheus metrics? If not, any plans to do so?
Piyush Nimbalkar9:44 AM
We do export portworx metrics from prometheus. We are going to expose those from the operator as well.
Tom9:44 AM
@Diane - Tom is Tom Gates (NuoDB).
9:45 AMMe
@here - anyone else have another topic for today?
9:45 AMMe
thanks tom
Shoubhik Bose9:47 AM
Link on the chat please?
9:48 AMMe
shoubhik? which link? tremolo operator?
Shoubhik Bose9:48 AM
yeah. This Github project being shown
Len DiMaggio9:50 AM
is this it? https://github.com/TremoloSecurity/openunison-k8s-operator
Shoubhik Bose9:50 AM
ah yes. thanks!
9:51 AMMe
here's the one in operatorhub.io https://operatorhub.io/operator/myvirtualdirectory
9:52 AMMe
(2nd one from tremolo)
9:52 AMMe
i think
Shoubhik Bose9:53 AM
Thanks Diane.
Pragash9:54 AM
@Diane - Pragash - Pragash Vijayaragavan ( Juniper )
9:54 AMMe
thanks!
Shoubhik Bose9:55 AM
Noob-ish opinion: Just recreate the missing triggers. ( kidding )
Vick Kelkar9:55 AM
@Diane you should have the portworx deck in your inbox. Thx for the opportunity today.
9:56 AMMe
thanks vick
9:57 AMMe
all - i am on the road this week, so the video will not be uploaded until friday morning
9:57 AMMe
fyi
9:57 AMMe
i will post notes and slide to google group

Len DiMaggio is Red Hat too. Thx! ;-)