-
Notifications
You must be signed in to change notification settings - Fork 7
Client: Separate plugin file system #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
461f69f
fefc02b
a04beeb
8f9fbec
8d0844d
47a4551
8d22021
e032053
7d5b098
349ab44
1fdf1e5
748f727
8f26804
509b3d5
0cc6a50
738ab79
0849ca7
e1cb5b6
ba929a2
1d26830
85c40f2
7c46442
d9543c9
b9ade44
e336fbc
c2d5976
65e6f48
7b6ca63
296e32c
384e97d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,3 +16,32 @@ Also, if Qiita is running with the default server SSL certificate, you need to e | |
|
||
export QIITA_ROOT_CA=<QIITA_INSTALL_PATH>/qiita_core/support_files/ci_rootca.crt | ||
``` | ||
|
||
Configure for cloud computing | ||
----------------------------- | ||
In the default scenario, Qiita main and Qiita plugins are executed on the same | ||
machines, maybe spread across a Slurm or other grid compute cluster, but main | ||
and plugins have direct access to all files in `BASE_DATA_DIR`. | ||
|
||
This can be different, if you set up Qiita within a cloud compute environment, | ||
where main and plugins do **not** share one file system. In this case, input- | ||
files must first be transferred from main to plugin, then plugin can do its | ||
processing and resulting files must be transferred back to main, once | ||
processing is finished. To achieve this, the qiita_client, as it is part of | ||
each plugin, provides the two functions for this file transfer | ||
`fetch_file_from_central` and `push_file_to_central`. According to | ||
`self._plugincoupling`, these functions operate on different "protocols"; | ||
as of 2025-08-29, either "filesystem" or "https". Switch to **"https"** for | ||
cloud environments, default is **filesystem**. | ||
|
||
The plugin coupling protocoll can be set in three ways | ||
|
||
1. default is always `filesystem`, i.e. `_DEFAULT_PLUGIN_COUPLINGS` | ||
This is to be downward compatible. | ||
2. the plugin configuration can hold a section `network` with an | ||
option `PLUGINCOUPLING`. For old config files, this might not | ||
(yet) be the case. Therefore, we are double checking existance | ||
of this section and parameter here. | ||
Comment on lines
+41
to
+44
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This confuses me, why have the config-file and the environmental variable? I think just leaving the env var should suffice, but I might be missing something .... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it CAN all be done just by the environment variable. However, qiita collects the plugin configuration files in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see what you are saying but then this will set that variable for that plugin, meaning that we might need multiple plugins for the same command based on the configuration; right? For example, deblur would need a plugin that uses filesystem and another for https; which I believe we decided it was not desirable but I also know that we are still figuring out this. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it is fine as is for your Slurm setup, but agree the config file and env seem a bit redundant. In a container scenario, the config file would also live within the container and let the plugin know how to communicate with main - no need to obtain this value from the DB. Thus you can have two different container, holding the same plugin, but communicating differently (maybe interesting for long / short distances around the globe?) The DB would then just need to decide which URL to use for triggering, but doesn't need to worry about the protocol There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it - sorry that this is taking longer than expected, but just to confirm, then wouldn't the container always have the env variable set to https; thus, making the config file redundant? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. env variable would NOT be set by default, so container reads from config file, except you forcefully want to make the container change its behavior: in this case you can override via env variable There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, thank you. |
||
3. you can set the environment variable `QIITA_PLUGINCOUPLING` | ||
Precedence is 3, 2, 1, i.e. the environment variable overrides | ||
the other two ways. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this like required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 107 is to removed
//
from some of the urlsline 108 is necessary for the nginx test instance to point to the actual
BASE_DATA_DIR
within the github action: https://github.com/qiita-spots/qiita/blob/a34dcebc44ea6408340d31ecaf0efd1f78e3cc6b/qiita_pet/nginx_example.conf#L57-L63