Hi Renuka/all,
Hi all
>
> As of now, *API Operator*[1] requires a lot of configurations if someone
> needs to *try it out *(PoC/quick start/demo). This breaks the user
> experience and will lose the interest of the users towards the API Operator.
> Following are some of the noticed issues from the initial discussion[2].
>
> 1. DockerHub account configuration (Kaniko job uses this configuration
> to push built runtime image of api microgateway).
> - Users have to go through *multiple editing* in configuration file
> - Users have to *encode* credentials with base64
> 2. Download multiple distributions.
> - *API Operator* distribution[3]
> - CLI tool: *apictl* distribution[4]
>
>
> *Solution:*
> Enable the *apictl* tool itself to install *API Operator* and configure
> docker registry configurations and credentials.
>
> *Proposed commands:*
>
apictl install operator
>
Shall we give this a specific name (eg: apictl install *api-operator*). If
we come up with more operators, we need to figure out a way to identify the
operators.
> After executing the above command, it would prompt the user to enter the
> following
>
> 1. Docker registry url (if the user is using a private docker
> registry, has to provide the value. Otherwise just press "return")
> 2. Docker registry repository name
> 3. Docker username
> 4. Docker password
>
> Once these things are provided, *apictl* will create a *kubernetes-secret*
> to be used by the Kaniko job. Finally, everything is configured and the
> operator is up and running.
>
As of now, we are giving 3 option when configuring the API Operator.
1. Via default resources hosted in GitHub.
- In this scenario, user would not have to provide any arguments to
the above command (apictl install api-operator). The *apictl* will
apply the k8s resources hosted in GitHub in the k8s cluster,
2. Ponting to a location file system
- User can download the api-operagtor distribution and make
configuration changes as the user needs. Once the k8s resources are
configured user can execute the above command pointing to the
configuration
located in the file system with "-f" flag.
- eg: *apictl install api-operator -f <file system's location to the
k8s configuration resources>*
3. Hosting artefacts within the local network.
- In some environments, internet access might not be available. In
that case, they can host these artefacts in their local network
after doing
configuration changes.
- We can use the same command as above, pointing to the api-operator
distribution's config directory hosted within the local network.
- eg: *apictl install api-operator -f <hosted location to the k8s
configuration resources>*
[1] https://operatorhub.io/operator/api-operator
> [2] Attached PDF
> [3] https://github.com/wso2/k8s-apim-operator/releases/tag/v1.0.1
> [4] https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.1
>
> Thanks
> Best Regards
>
> *Renuka Fernando* | Software Engineer | WSO2 Inc.
> (m) +9476 6678 752 | Email: ren...@wso2.com
> <http://wso2.com/signature>
>
--
*Dinusha Dissanayake* | Senior Software Engineer | WSO2 Inc
(m) +94 71 293 9439 | (e) dinus...@wso2.com
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
