Skip to content
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

Add resource set funcs into generate library #137

Merged
merged 1 commit into from
Jul 21, 2016

Conversation

haiyanmeng
Copy link
Contributor

The PR adds functions setting the linux resource cpu and memory fields into the generate library.

Signed-off-by: Haiyan Meng hmeng@redhat.com

Signed-off-by: Haiyan Meng <hmeng@redhat.com>
@haiyanmeng
Copy link
Contributor Author

haiyanmeng commented Jul 21, 2016

@mrunalp , PTAL.
This PR only adds the library funcs, and does not expand the ocitools generate command arguments.

I plan to expand the ocitools generate command arguments in a separate issue and PR.

@mrunalp
Copy link
Contributor

mrunalp commented Jul 21, 2016

LGTM

@mrunalp mrunalp merged commit 3c4fc86 into opencontainers:master Jul 21, 2016
@wking
Copy link
Contributor

wking commented Jul 21, 2016 via email

@mrunalp
Copy link
Contributor

mrunalp commented Jul 21, 2016

@wking Good point and I have thought about it and gone back and forth.
One option is for the user to get back the spec using GetSpec and then modify it directly. For now adding the most common options seems fine. If it becomes too many we can reconsider the approach.

@haiyanmeng haiyanmeng deleted the expand_libgen branch July 21, 2016 20:59
@haiyanmeng
Copy link
Contributor Author

@mrunalp , @wking , I indeed felt the pain when I tried to add some func like SetLinuxResourcesCPURealtimePeriod into the generate library.
I kind of want to make the func name corresponding to the hierarchy of the runtime-spec config, but it looks it is a little too much.
Let me know if you have some good suggestions for this.

@wking
Copy link
Contributor

wking commented Jul 21, 2016

On Thu, Jul 21, 2016 at 01:57:41PM -0700, Mrunal Patel wrote:

One option is for the user to get back the spec using GetSpec and
then modify it directly.

Just make the spec public 1. No need for a getter unless you want
to do something to the private content or perform a auth check or some
such on the way out.

wking added a commit to wking/ocitools-v2 that referenced this pull request Nov 6, 2016
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Nov 22, 2016
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Nov 23, 2016
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Nov 23, 2016
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Feb 14, 2017
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Feb 14, 2017
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, aside from the
getter/setter for the config itself.  I'd called for this back when we
started adding these methods [1], and Mrunal was sounding more
positive about the public-attribute approach a few weeks ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 12, 2018
This makes the attribute public, since quite a few config
manipulations are easier using Go's types than they are via
getter/setter/mutator methods.  This also means that we can drop
methods that are more awkward than direct access (although we'll want
to keep methods that are more convenient than direct access).  I
haven't done any method-dropping in this commit though, although I
have deprecated a few of the more redundant methods.  I'd called for
this back when we started adding these methods [1], and Mrunal was
sounding more positive about the public-attribute approach a few weeks
ago [2].

I've also renamed this from "spec" to "config", because it is a
config.  I'm not sure why runtime-spec decided to call the main
config.go type 'Spec' [3], but I don't think we should repeat that
idiosyncrasy.

[1]: opencontainers#137 (comment)
[2]: opencontainers#253 (comment)
[3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc2/specs-go/config.go#L6

Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants