-
Notifications
You must be signed in to change notification settings - Fork 553
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
Introducing Solaris in OCI #411
Conversation
nicely. On the whole, LGTM |
@@ -0,0 +1,88 @@ | |||
# Solaris Application Container Configuration | |||
|
|||
Solaris application containers can be configured using the following properties, all of the below properties are the same as given in zonecfg(1M) man page, except milestone. The Solaris specification is entirely optional. |
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.
I'm not clear on “entirely optional”. If you're aiming that at runtime authors (e.g. “authors of Linux runtimes can ignore this”), I don't think we need to call it out explicitly (all platform-specific specification can be ignored by runtime targeting other platforms). If it's targeting bundle authors (e.g. “all settings in this section are optional, so even if you're writing a bundle targeting Solaris, you can leave this section out”), then I'd rather that get spelled out in more detail. For example:
solaris
(object, optional) Solaris-specific configuration. Even configurations targeting Solaris MAY leave this field unset.
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.
"entirely optional" means as you said, "solaris (object, optional) Solaris-specific configuration. Even configurations targeting Solaris MAY leave this field unset."
Having said that, would it be more appropriate to the the above text in config.md as opposed to config-solaris.md and have a entry for each platform to say if the platform-specific section is required by the said platform.
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.
On Fri, Apr 29, 2016 at 11:06:00AM -0700, Abhijeeth Nuthan wrote:
Having said that, would it be more appropriate to the the above text
in config.md as opposed to config-solaris.md and have a entry for
each platform to say if the platform-specific section is required by
the said platform.
Yeah, putting something more structured in 1 would be good. It
looks like you're softening the existing SHOULD to a MAY. I think
that's also the case for Linux, but I'm not sure, and having each
field listed with our usual:
{key}
({type}, {when-needed}) {description}
would make it more obvious.
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.
Sounds like we need a separate PR to address the restructuring, if 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.
On Fri, Apr 29, 2016 at 11:28:12AM -0700, Abhijeeth Nuthan wrote:
Sounds like we need a separate PR to address the restructuring, if required. :)
I just filed #414.
@anuthan Overall LGTM. Is there an implementation of this Spec that users can play with today? |
@vishh : The implementation of this spec is actively being worked on. I cannot comment on the timeline when this would be available. All I can say is coming soon to a Solaris store near you. :) |
// Specify a name for the automatically created VNIC datalink. | ||
Linkname string `json:"linkname,omitempty"` | ||
// Specify the link over which the VNIC will be created. | ||
Lowerlink string `json:"lower-link,omitempty"` |
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.
These need to be camel case and not include -
to be consistent with the rest of the spec.
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.
@crosbymichael : As stated previously, the names of the properties which appear in the config.json , such as capped-cpu, capped-memory, lower-link, etc., have been part of Solaris virtualization for a long time.
We prefer to keep the same name and structure to how it is defined in https://docs.oracle.com/cd/E36784_01/html/E36871/zonecfg-1m.html .
Sorry if that ruins consistency.
Looks good overall but all your json fields need to be camel case and not include
|
## Network | ||
|
||
### Automatic Network (anet) | ||
anet is specified as an array that is used to setup networking for Solaris application containers. The anet resource represents the automatic creation of a network resource for an application container. When such a container is started, a temporary VNIC(Virtual NIC) is automatically created for the container. The VNIC is deleted when the container is torn down. |
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.
One sentence per line.
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.
@mrunalp : done.
LGTM, I would like @anuthan to add a link or some explanatory text about the lifecycle of networking in Solaris is tied to a particular process as this is quite different than Linux where a majority of the expertise is coming from. |
Signed-off-by: Abhijeeth Nuthan <abhijeeth.nuthan@oracle.com>
@philips : I have added text for life-cycle of networking and a pointer to our documentation, which is a man page of our administrative daemon. @crosbymichael : camel case'd everything. |
LGTM |
1 similar comment
LGTM |
@vbatts Thanks. Also thanks to all who reviewed. |
Fixup for 7c9daeb (Introducing Solaris in OCI, 2016-04-25, opencontainers#411) along the lines of b373a15 (config: Split platform-specific configuration into its own section, 2016-05-02, opencontainers#414). Signed-off-by: W. Trevor King <wking@tremily.us>
This should have been part of 759ee79 (config: Add platform-specific entry for 'solaris', 2016-05-06, opencontainers#431), since the example has playform.os set to 'linux'. There was some (brief) discussion of this point before the 'solaris' section landed [1], but the "should only be set if" wording landed in parallel via b373a15 (config: Split platform-specific configuration into its own section, 2016-05-02, opencontainers#414), and I'd forgotten to go back and apply that logic to opencontainers#411. Having a full Solaris example would be useful, but I think it should be a separate, Solaris-only example. [1]: opencontainers#411 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
This should have been part of 759ee79 (config: Add platform-specific entry for 'solaris', 2016-05-06, opencontainers#431), since the example has platform.os set to 'linux'. There was some (brief) discussion of this point before the 'solaris' section landed [1], but the "should only be set if" wording landed in parallel via b373a15 (config: Split platform-specific configuration into its own section, 2016-05-02, opencontainers#414), and I'd forgotten to go back and apply that logic to opencontainers#411. Having a full Solaris example would be useful, but I think it should be a separate, Solaris-only example. [1]: opencontainers#411 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Fixup for 7c9daeb (Introducing Solaris in OCI, 2016-04-25, opencontainers#411) along the lines of b373a15 (config: Split platform-specific configuration into its own section, 2016-05-02, opencontainers#414). Signed-off-by: W. Trevor King <wking@tremily.us>
This should have been part of 759ee79 (config: Add platform-specific entry for 'solaris', 2016-05-06, opencontainers#431), since the example has platform.os set to 'linux'. There was some (brief) discussion of this point before the 'solaris' section landed [1], but the "should only be set if" wording landed in parallel via b373a15 (config: Split platform-specific configuration into its own section, 2016-05-02, opencontainers#414), and I'd forgotten to go back and apply that logic to opencontainers#411. Having a full Solaris example would be useful, but I think it should be a separate, Solaris-only example. [1]: opencontainers#411 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
The note is from 7c9daeb (Introducing Solaris in OCI, 2016-04-25, opencontainers#411), but as I pointed out there [1], this is also true for Linux. 08908d6 (config: Explicit container namespace for uid, gid, and additionalGids, 2016-04-29, opencontainers#412) landed in parallel with more explicit namepacing for these fields, so we no longer need the overly-specific Solaris note. [1]: opencontainers#411 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
This PR introduces Solaris application container configuration parameters to OCI.
Signed-off-by: Abhijeeth Nuthan abhijeeth.nuthan@oracle.com