Use email api #252
Use email api #252
Conversation
Using the official API will reduce code in this role. Furthermore, using an official API remove the need to deploy dedicated scripts. And such deploy can be annoying depending on the overall deployment (native, docker, docker-compose, kubernetes). So, using official API will offer the ability to reuse easier this role in much more context.
gbonnefille
force-pushed
the
use-email-api
branch
from
74555c9
to
add7930
Compare
|
Thanks for this PR and for your interest. I will review shortly. Using the API wherever possible is on my todo list. Not only to reduce code in the role (which has already drastically decreased in terms of groovy scripts), but also because sonatype change their internal API quite often (at least on the last releases....) which breaks the existing scripts. An obvious candidate is the setup_ldap script which is blindly using an unpublished internal API... Meanwhile, there are some place places in which we might want to keep the scripts for performance reasons (e.g. creating repos from a list, where the api will need a call for each repo). Furthermore, it is not always easy to reach idempotency with rest API without being very verbose. |
I already have a working code for that. I can submit an other PR.
I'm currently trying to create repos from API... Ideally, a plugin able to read a complete description of the expected status would be better for provisioning. I also found nexus-claim an external Go program to configure Nexus. Could be an other solution instead of trying to recreate everything in Ansible. I don't know currently. |
There was a problem hiding this comment.
Apart from context comment about the variable.... The idea is definitely going in the correct direction. But if we have to fully walk this path, I'd rather start working on a set of custom modules with a common lib to manage communication with the api and ensure idempotency.
If we go on just calling the module for each possible operation, the result will be worse than the current groovy script implementation and, on the contrary of your initial statement, will augment the amount of code in the role.
I have to think a bit about all that.
| @@ -72,6 +72,7 @@ nexus_public_hostname: 'nexus.vm' | |||
| nexus_public_scheme: https | |||
|
|
|||
| # How should the role access the API for provisionning | |||
| nexus_rest_api_endpoint_base: "service/rest" | |||
There was a problem hiding this comment.
This name is conflicting/confusing. There is a version based detection of the rest endpoint in nexus_install.yml which sets nexus_rest_api_endpoint used in call_script.yml, declare_script_each.ymlandnexus_install.yml`.
Unfortunately, at this point, the var is pointing directly to the script endpoint (which is historically the only one used).
To clean-up the role's code, I'm considering dropping support for nexus version < 3.11 which would remove this detection (along wiht some other path's detection) and would let us refactor the existing files to use a base as above for all api interactions.
|
I pushed an other example of conversion (LDAP) in #254. I hope that help to design the next step for this role. |
|
Any news on this topic? |
Use official API for setting email instead of groovy script Fixes #252 Fixes #282 --------- Co-authored-by: Guilhem Bonnefille <[email protected]>
This pull-request initiate a first usage of new API endpoints.
Using the official API can bring many interesting feature.
First; sing the official API will reduce code in this role. And less code == better code.
Furthermore, using an official API remove the need to deploy the dedicated scripts. As such deploy can be annoying depending on the overall deployment (native, docker, docker-compose, kubernetes), this will offer the ability to reuse easier this role in much more context.
Cf. #86 and #172