1 |
On 12/01/2015 10:19 AM, William Hubbs wrote: |
2 |
> On Tue, Dec 01, 2015 at 11:26:19AM -0600, William Hubbs wrote: |
3 |
>> On Tue, Dec 01, 2015 at 09:00:55AM -0800, Zac Medico wrote: |
4 |
>>> On 12/01/2015 08:50 AM, William Hubbs wrote: |
5 |
>>>> The "container" keyword, being generic, would have its meaning expanded |
6 |
>>>> to cover new container systems as they come along. This means if a |
7 |
>>>> service script has the keyword "-container" it will not work under any |
8 |
>>>> current or future container systems. On the other hand, adding |
9 |
>>>> "container" means it will work under all of them. |
10 |
>>> |
11 |
>>> If it's similar to how license groups work, then there is room for doing |
12 |
>>> things like "-@container docker" which means no containers except |
13 |
>>> docker, or "@container -docker" which means all containers except |
14 |
>>> docker. Keyword groups can be implemented using a simple expansion |
15 |
>>> mechanism, just like license groups. |
16 |
>> |
17 |
>> Keyword groups are an interesting idea; I'll think about this approach. |
18 |
> |
19 |
> One question that comes to mind is,, who defines which keywords go in |
20 |
> each group? |
21 |
> |
22 |
> The containers or virtualization systems themselves can be autodetected |
23 |
> so they are the same everywhere, but keyword groups are not able to be |
24 |
> detected. |
25 |
|
26 |
The groups should go in a configuration file somewhere. For example, |
27 |
they could be defined in rc.conf with a variable setting like this: |
28 |
|
29 |
rc_keyword_group_container="docker lxc openvz vserver" |
30 |
-- |
31 |
Thanks, |
32 |
Zac |