0k
/
0k-charms
6
3
Fork 2
Code Issues 11 Pull Requests 6 Releases Wiki Activity
Labels Milestones
New Pull Request

new: [smtp-extern] new charm #33

Closed
bgallet wants to merge 1 commits from bgallet/0k-charms:boris/smtp-extern into master
Conversation 3 Commits 1 Files Changed 2
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
bgallet commented 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 12 months 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 12 months 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 12 months ago
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
Request review
No reviewers
Labels
Apply labels
Clear labels
bug
Something is not working duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong question
More information is needed win wontfix
This won't be fixed
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

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
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