new: [smtp-extern] new charm #33

Closed
bgallet wants to merge 1 commits from bgallet/0k-charms:boris/smtp-extern into master
bgallet commented 1 year ago
Collaborator

Est-ce qu’il y a besoin d’étoffer ?
ou bien le charm est assez clair et simple comme ça ?

Est-ce qu’il y a besoin d’étoffer ? ou bien le charm est assez clair et simple comme ça ?
bgallet added 1 commit 1 year ago
bgallet added 1 commit 1 year ago
bgallet force-pushed boris/smtp-extern from bb41c08846 to d18426be52 1 year ago
Poster
Collaborator

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é ?

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é ?
vlab commented 1 year ago
Owner

There are 3 notions:

  • service

    You run or set up services. Your compose.yml defines services. When they are
    up, 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 called smtp-stub, as it'll act as a real smtp service (implemented by a smtp charm, that doesn't exist yet !), but your charm smtp-stub doesn't really implement anything : it stands for a service that is managed externally from compose.

It manages to stand for a full server because it provides the same interface: it implements the relation smtp-server (which a full hypothetical smtp 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. The smtp-stub charm allows you to plug in values directly and allow the script smtp_server-relation-joined on the other end to implement its own intelligence to use the smtp-server values.

There are 3 notions: - service You `run` or set `up` services. Your `compose.yml` defines services. When they are up, 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 called `smtp-stub`, as it'll act as a real `smtp` service (implemented by a `smtp` charm, that doesn't exist yet !), but your charm `smtp-stub` doesn't really implement anything : it stands for a service that is managed externally from `compose`. It manages to stand for a full server because it `provides` the same interface: it implements the relation `smtp-server` (which a full hypothetical `smtp` 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. The `smtp-stub` charm allows you to plug in values directly and allow the script `smtp_server-relation-joined` on the other end to implement its own intelligence to use the smtp-server values.
vlab commented 1 year ago
Owner

I have made some minor changes, a few tests, and pushed your charm !
Many thanks !

I have made some minor changes, a few tests, and pushed your charm ! Many thanks !
vlab closed this pull request 1 year ago
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.