August 2017 - cc-devel

by Jovi Zhangwei

Hi, I have some questions about using docker command in Clear Container, I didn't found any clear answer in doc about these issues, so wish some experts would give me some clues, great thanks. 1. does cc-oci-runtime support Pod? many containers runs in one vm? 2. 'docker stats' doesn't show anything. 3. Support setting memory and cpu resource through via docker CLI, like "docker run -m MEMORY" and "docker run --cpus CPU", instead use fixed configuration. Reference: https://github.com/01org/cc-oci-runtime/wiki/ Limitations#15cpu-and-memory

2 years, 10 months

3
4
0 / 0

Improving unit test coverage for cc-runtime (developers please read)

by Hunt, James O

Hi All, = TL;DR = [1], [2] and [3] have now landed meaning if you have issues assigned to you to improve cc-runtime's unit-test coverage (you know who you are), you can now see how close you can get to 100% for the files you are working on :-) = Details = The runtime now has access to a mock implementation of virtcontainers for testing. = Rationale = We have introduced the test mock to allow for fine-grained unit testing at the runtime-level without duplicating test code (virtcontainers already has a lot of tests, plus the runtime exercises the virtcontainers API using other types of testing). The reason the implementation is being hosted in the virtcontainers package is that certain virtcontainers types (Pod and Container) only contain private fields and since some of the virtcontainers API calls return these types, it is necessary to introduce interfaces to allow tests to override these types and fully implement the virtcontainers API. = HOWTO = The runtime has been updated so that rather than calling vc.API(), it now calls vci.API(). For example, this: vc.CreatePod() ... is now: vci.CreatePod() vci is not a package alias, but a variable that defines the particular virtcontainers implementation that the runtime is using. In normal operation, that of course is the official implementation [4]. However, the runtime tests switch that variable to the VCMock implementation [5], meaning that all the runtime tests will use a fake version of virtcontainers. This is achieved as follows: // official virtcontainer implementation var virtcontainersImpl = &vc.VCImpl{} // testingImpl is a mock virtcontainers implementation used for testing var testingImpl = &vcMock.VCMock{} // XXX: vci is a variable used to access a particular virtcontainers implementation. // (The tests switch to the VCMock implementation by assigning "vci = testingImpl"). var vci vc.VC = virtcontainersImpl By default (and assuming a virtcontainers API call actually returns a value), the VCMock implementation will return an error. This error will contain information about the call being made (method name and parameter details). You can (and should!) test if the error comes from the mock framework as appropriate using the helper function like this: assert = assert.New(t) : : assert.Error(err) assert.True(vcMock.IsMockError(err)) Or, assert.Error(err) assert.False(vcMock.IsMockError(err)) If you don't want a particular virtcontainers (mock) API call to return an error, define a handler. For example, func TestFoo(t *testing.T) { testingImpl.CreatePodFunc = func(podConfig vc.PodConfig) (vc.VCPod, error) { vc.VCPod{}, nil } pod, err := vci.CreatePod(config) // calls function above now rather than returning a vcMock error. } There is a handler for all the virtcontainers API calls [6][7]. For examples of tests showing the different behaviour of the mock (either returning an error, or calling a handler), see [8]. = Helper functions = I've also added a bunch of utility functions to make writing the remaining unit tests easier [9]. Any problems, just shout (or jump on #clearcontainers on freenode to chat). Cheers, James [1] - https://github.com/containers/virtcontainers/pull/348 [2] - https://github.com/clearcontainers/runtime/pull/448 [3] - https://github.com/clearcontainers/runtime/pull/450 [4] - https://github.com/containers/virtcontainers/ [5] - https://github.com/containers/virtcontainers/tree/master/pkg/vcMock [6] - https://github.com/containers/virtcontainers/blob/master/pkg/vcMock/mock.go [7] - Note that the mock doesn't include the virtcontainers "oci" package. It's possible we'll need to add that later, but from what I can see, I don't think this will be necessary. [8] - https://github.com/containers/virtcontainers/blob/master/pkg/vcMock/mock_... [9] - https://github.com/clearcontainers/runtime/pull/452 ----- https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

2 years, 10 months

1
1
0 / 0

Clear Containers 3.0.0-beta.1

by Venegas Munoz, Jose Carlos

Hi, We have released Clear Containers 3.0.0-beta.1[1][2]. Highlights for this release: - Switch to the new agent: Now the Clear-Containers agent[1] is used by default as process spawner. Clear Containers VM now uses a new VM-agent. The VM-agent allows to spawn processes on behalf of pod/container(s) running inside the virtual machine. The runtime now uses Clear Containers Agent by default.The Clear Containers Agent relies heavily on libcontainer used by runc (standard to run containers on bare metal). - Switch QEMU machine type Switched from pc-lite to pc machine type. In the long term we are looking to move to an upstream-QEMU supplied machine type which includes some of the optimizations that were made for Clear Containers. In the short term we have encountered issues around functional support of PCI hotplug and vhost-user support in pc-lite, so made the decision to move to pc while we await a fully supported upstream option. As a result of this change, the runtime is now booting using a compressed kernel (vmlinuz). - Proxy handles KILL and TERM signals in create state. State transition from "ready" to "stopped" is possible for a container created by virtcontainers/runtime. Compatibility with Docker: Clear Containers 3.0.0-beta.1 is compatible with Docker v17.06-ce More information: [1]https://github.com/clearcontainers/agent [2]https://github.com/clearcontainers/runtime/releases/tag/3.0.0-beta.1 [3]https://github.com/clearcontainers/proxy/releases/tag/3.0.0-beta.1

2 years, 11 months

1
0
0 / 0

Clear Containers 3.0: The march to release

by Ernst, Eric

While release of Clear Containers 3.0 beta is just about imminent, I wanted to make sure that everyone is aware of the major items we have between now and Clear Containers 3.0 release. We are hoping to make the 3.0 release in early September. -- 1. Updated externally facing CI: This has been a moving target and source of a lot of discussion. We have been using SemaphoreCI to date, but there are a handful of limitations associated with it (it is based on a much older distro which has hamstrung us). Based on discussions with the team over the last week, we are going to do a POC with using Jenkins + Azure, and otherwise consider internal-to-Intel solutions which could be made externally facing. Salvador, Sebastien Mario and myself have expressed interest in jumping on this, and we're looking to have a proposal put together early next week. 2. QA Tests at Parity with 2.1 + added testing for new features. I know Gaby has been very active on this, as well as Salvador. It sounds like this is still a WIP, but on track. 3. Testing framework (unit test mocking) + increased unit test coverage for runtime. Thanks James for opening the issues yesterday. There are more than a couple there, and these issues are critical for completing. Luckily there are enough of them to share amongst the team! 4. Bringing our 3.0 PnP tests + automation up to parity with 2.1 5. Documentation / release notes. Carlos has added a PR for auto-generation of a baseline for our release notes, which will help greatly. We still have more work to do around documenting debug methods, architecture, etc. 6. Bug fixxing (for release blocking bugs). 7 openshift + cri + clear containers e2e testing / documentation -- These are the major work items as far as I know, and reflect what I see in our waffle.io: https://waffle.io/01org/cc-oci-runtime For bug fixing, I think we should evaluate and scrub through the issue list and agree whether they should be release blocking or not. There are several issues open for new features as well, but these should be considered after release and not before. A couple notes for our !intel contributors: 1. If there are some delay with merging/reviewing your PRs, this current march towards release is the reason. 2. I plan to setup a weekly forum (perhaps alternating geographies) over the next week or two where we can do a general bug scrub and status update for the project We have a pretty short run way before we're hoping to make our Clear Containers 3.0 release, so I wanted to make sure that we're all on the same page. There are a lot of exciting features that we'll jump on post-release, but the list above is what's most important *right now.* Let me know if you feel I'm missing anything - looking forward to working through this final push for release! -Eric

2 years, 11 months

1
0
0 / 0

message for mailing list

by Ernst, Eric

While release of Clear Containers 3.0 beta is just about imminent, I wanted to make sure that everyone is aware of the major items we have between now and Clear Containers 3.0 release. -- 1. Updated externally facing CI: This has been a moving target and source of a lot of discussion. We have been using SemaphoreCI to date, but there are a handful of limitations associated with it (it is based on a much older distro which has hamstrung us). Based on discussions with the team over the last week, we are going to do a POC with using Jenkins + Azure, and otherwise consider internal-to-Intel solutions which could be made externally facing. Salvador, Sebastien Mario and myself have expressed interest in jumping on this, and we're looking to have a proposal put together early next week. 2. QA Tests at Parity with 2.1 + added testing for new features. I know Gaby has been very active on this, as well as Salvador. It sounds like this is still a WIP, but on track. 3. Testing framework (unit test mocking) + increased unit test coverage for runtime. Thanks James for opening the issues yesterday. There are more than a couple there, and these issues are critical for completing. Luckily there are enough of them to share amongst the team! 4. Bringing our 3.0 PnP tests + automation up to parity with 2.1 5. Documentation / release notes. Carlos has added a PR for auto-generation of a baseline for our release notes, which will help greatly. We still have more work to do around documenting debug methods, architecture, etc. 6. Bug fixxing (for release blocking bugs). 7 openshift + cri + clear containers e2e testing / documentation -- These are the major work items as far as I know, and reflect what I see in our waffle.io: https://waffle.io/01org/cc-oci-runtime For bug fixing, I think we should evaluate and scrub through the issue list and agree whether they should be release blocking or not. There are several issues open for new features as well, but these should be considered after release and not before. A couple notes for our !intel contributors: 1. If there are some delay with merging/reviewing your PRs, this current march towards release is the reason. 2. I plan to setup a weekly forum (perhaps alternating geographies) over the next week or two where we can do a general bug scrub and status update for the project We have a pretty short run way before we're hoping to make our Clear Containers 3.0 release, so I wanted to make sure that we're all on the same page. There are a lot of exciting features that we'll jump on post-release, but the list above is what's most important *right now.* Let me know if you feel I'm missing anything - looking forward to working through this final push for release! -Eric

2 years, 11 months

1
0
0 / 0

"bitesize" tasks for anyone interested in getting involved!

by Hunt, James O

Hi All, I've just added a "bitesize" label to the new runtime repo and tagged a few issues with it [1]. The idea of this label is to highlight relatively quick/easy fixes I've also added this label to all the other main repos (of which there are now quite a few - see the list on [2]). If you're interested in getting involved with Clear Containers, "bitesize" issues are probably a good place to start. Feel free to join us on irc to discuss any of this! Remember, before contributing, please read [3]. = For the existing development team = Please take a look through the outstanding issues and add the "bitesize" label as appropriate. Also, when raising new issues, think about whether you should add this label. Cheers, James --- [1] - https://github.com/clearcontainers/runtime/issues?q=is%3Aissue+is%3Aopen+... [2] - https://github.com/clearcontainers/runtime/wiki [3] - https://github.com/clearcontainers/runtime/blob/master/CONTRIBUTING.md ----- https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

2 years, 11 months

1
0
0 / 0

IRC channel

by Hunt, James O

Hi All, A quick note to say that we're now starting to use our public IRC channel a lot more than previously. If you'd like to join us, feel free to jump on: #clearcontainers @ freenode.net Cheers, James ----- https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

2 years, 11 months

1
0
0 / 0

2020

2019

2018

2017

2016

cc-devel August 2017