pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [pulsar] jerrypeng commented on a change in pull request #3735: Implementing authentication for Pulsar Functions
Date Thu, 14 Mar 2019 18:49:28 GMT
jerrypeng commented on a change in pull request #3735: Implementing authentication for Pulsar
URL: https://github.com/apache/pulsar/pull/3735#discussion_r265717831

 File path: pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/auth/KubernetesFunctionAuthProvider.java
 @@ -0,0 +1,42 @@
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.pulsar.functions.auth;
+import io.kubernetes.client.models.V1ServiceAccount;
+import io.kubernetes.client.models.V1StatefulSet;
+ * Kubernetes runtime specific functions authentication provider
+ */
+public interface KubernetesFunctionAuthProvider extends FunctionAuthProvider {
 Review comment:
   > It's a bad sign if for the first serious use of an abstraction you need to create
another abstraction to work work around shortcomings in the first abstraction. However, I
don't think it's even needed in this case.
   Why is that bad?  I designed this so that it is cleaner compared to AuthenticationDataSource
where you have a mixture of interfaces to support different authentication methods.  I imagine
in the future, different runtimes will have different requirements / interfaces needed to
support authentication.  It doesn't make sense to clutter them all together. 
   > The functionAuthData returned by cacheAuthData should contain the actual token. 
   Why should functionAuthData contain the actual token?  This is implementation specific
data.  Different implementations of FunctionAuthenticationProvider should have the flexibility
to use it in a way that makes sense for the implementation.
   > The caller of cacheAuthData can then create a secret, and then mount that secret on
each of the instance pods. 
   I think there is some misunderstanding here.  The architecture of Pulsar Function decouples
submitting functions and running functions.  The worker that the user actually submits the
function do is not necessarily going to be the same worker that is going to run the function.
 However, the auth data will only be passed to the worker that the user at first submits his
or her function to.  That is why that worker needs to be able to distribute that auth data
or data based on that auth data to the rest of the workers that will potentially need to run
a function instance.  The interface cacheAuthData returns the data that needs to be distributed
to the other workers via the function metadata topic. 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message