new: [smtp-extern] new charm
#33
Closed
bgallet
wants to merge 1 commits from bgallet/0k-charms:boris/smtp-extern
into master
pull from: bgallet/0k-charms:boris/smtp-extern
merge into: 0k:master
0k:0k/dev/master
0k:backup
0k:bgallet/nextcloud
0k:boris/smtp-extern
0k:charm-codimd-new
0k:cups_service_alpha
0k:dev
0k:dev1
0k:dhcp
0k:element
0k:etherpad-upd
0k:framadate
0k:get-version
0k:lokavaluto/dev/master
0k:master
0k:matomo
0k:new-mailhog-charms
0k:new-monujo-options
0k:nj-collabra-office
0k:nj-keycloak-17.0
0k:nj-organice-charm
0k:nj-vaulwarden-migrate
0k:ntfy-install
0k:odoo_fix_webhook_url
0k:postgres
0k:rsync-stats
0k:test
0k:upd-docker
0k:update-latest-synapse
0k:wip
Reviewers
Request review
No reviewers
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
question
win
wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This pull request currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch 'bgallet/0k-charms:boris/smtp-extern'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Est-ce qu’il y a besoin d’étoffer ?
ou bien le charm est assez clair et simple comme ça ?
Je me demande s’il y a une raison pour que le charm s’appelle smtp-extern mais que le service s’appelle smtp-server (ou bien est-ce que c’est le nom de la relation smtp-server )?
J’ai eu l’impression en explicant à Stéphan que ça apportait de la confusion.
Ne faudrait-il pas tout renommer en "smtp-server-config" ou "smtp-extern-config" pour plus de clarté ?
There are 3 notions:
service
You
run
or setup
services. Yourcompose.yml
defines services. When they areup, they will provide functionalities. They often run in individual containers.
charm
A service is managed by a charm, that explains how to set it up. The charm is like
a recipee. You can have several services using the same rules to be managed, they
would then all use the same charm.
relation
services are connected by relations. The relation describe the type of connection
it want to establish with another service.
Your PR is providing us a new charm. It can't provide a service ! It doesn't make sense: services are what the charm are building and managing on each host that will use compose.
So your charm is called
smtp-extern
. It could be calledsmtp-stub
, as it'll act as a realsmtp
service (implemented by asmtp
charm, that doesn't exist yet !), but your charmsmtp-stub
doesn't really implement anything : it stands for a service that is managed externally fromcompose
.It manages to stand for a full server because it
provides
the same interface: it implements the relationsmtp-server
(which a full hypotheticalsmtp
charm would do also).So any other charm requiring to connect to a smtp server only has to ask for a service satisfying the relation
smtp-server
. Many different charms could actually implement that. Thesmtp-stub
charm allows you to plug in values directly and allow the scriptsmtp_server-relation-joined
on the other end to implement its own intelligence to use the smtp-server values.I have made some minor changes, a few tests, and pushed your charm !
Many thanks !