- kata-dev - lists.katacontainers.io

[PUBLIC] [Discussion] Sandbox Resource Limits
by Tim Allclair (via Google Docs) 10 Apr '18

10 Apr '18

I've shared an item with you: [PUBLIC] [Discussion] Sandbox Resource Limits https://docs.google.com/document/d/1FtPFc8hhAVBWwTvU0BWrn34Salh2zZk0GXJz8il… It's not an attachment -- it's stored online. To open this item, just click the link above. Discussion questions around resource management for kubernetes sandboxes. To be discussed at sig-node tomorrow (2018-04-10)

1 0

Fast booting KVM guests w/o firmware and Qemu pc-lite
by Maran Wilson 07 Apr '18

07 Apr '18

There was some discussion about Qemu pc-lite vs upstream Qemu in the Architecture Committee meeting today. As Jesse Butler briefly mentioned on Slack, a few of us have been working on upstreaming a different approach to starting KVM guests without firmware that should be more acceptable for upstream maintainers. We are treating it as a more general purpose interface, but hopefully this framework will go a long way towards closing the gap between pc-lite and upstream Qemu in terms of guest startup time for solutions like Kata containers. We have already posted a set of Linux kernel patches upstream that seem to be well received so far by the community. See https://lkml.org/lkml/2018/3/20/717 for the latest version. We are currently working on cleaning up the corresponding Qemu patches and getting them ready for upstream review as well. Based on the RFC discussions we have had with upstream maintainers regarding high level design, I'm cautiously optimistic that we won't run into any deal breakers when we do post the qemu patches. The high level idea is that we could use this approach to achieve the same goal of booting directly to the uncompressed Linux kernel (without running firmware), but in a way that is acceptable to the upstream community since we aren't introducing any new Linux OS specific (zero-page) initialization in Qemu. So for anyone interested in the Qemu/KVM side of Kata containers and how we might be able to start VMs more quickly, please take a look at the patches we have posted so far and feel free to join the discussion on the upstream mailing lists. Thanks, -Maran

4 5

Volunteer for regular Kata status blog?
by Anne Bertucio 07 Apr '18

07 Apr '18

Hi all, In today’s Working Committee meeting, the idea of a weekly or bi-weekly status blog came up. This would be a regularly occurring, short post to help those who are watching Kata approach a 1.0 release but aren’t involved in the details stay up to date. You don’t have to be a seasoned writer; I’m happy to edit and polish your posts, we just need a volunteer to take charge on the drafts. The Kata homepage will have a blog page up in the next two weeks or less, which is where these posts would live. Any takers? Cheers, Anne Bertucio anne(a)openstack.org | irc: annabelleB

4 12

Question: Kata Containers release and packaging process
by Venegas Munoz, Jose Carlos 06 Apr '18

06 Apr '18

Hi Folks, I would like to raise some questions about do an early 0.1 release for Kata. Eric Cardona is working on provide some packaging tooling for Kata Containers. The tools are an automation to build packages in OBS[1]. Seems that OBS system does not allow to access to internet, this is something that is needed today to build a Kata Containers image. The image builder will pull some extra packages to build the rootfs and the agent to create it. One option we have is to pre-build the images we will ship before each release. The rest of the time if a developer want a fresh image with the latest Kata agent, it can be generated with a osbuilder scripts[2]. If you are agree with this approach, I would like to do early 0.1 release for kata containers. The steps would be. - Tag all the repositories with the version 0.1 (currently most of the have a file called VERSION that has the version 0.1) - Create a release in github with its proper releases notes. - In the agent github release, attach the images (raw and initrd) - The published images in the agent release will be used by the packaging. So I would like to as if is there any concern about do an early 0.1 release with the current kata state? For Clear Containers we had some scripts to automate most of the process we could Use them for kata (tagging, release notes generation, version bump in the projects files). Having the tags will help to tests the packaging of a kata release. This also may help us to identify gaps for a final 1.0 release. - Cheers! Carlos Venegas [1] https://build.opensuse.org/ [2] https://github.com/kata-containers/osbuilder

3 2

PR backlog - please help to review
by Hunt, James O 04 Apr '18

04 Apr '18

Hi All, We have 40 open PRs across the Kata repos: - https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+org%3Akata-cont… Please could we all take a few minutes to help review the backlog so we can keep the momentum and hopefully get this code landed. If you've never reviewed a PR, no problem! Take a look at the following for ideas on how to comment constructively: - https://github.com/clearcontainers/runtime/wiki/PR-Review-HOWTO Cheers, James --- https://katacontainers.io/ | https://github.com/clearcontainers Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 0

Off-schedule meeting to discuss VM-templating
by Ernst, Eric 04 Apr '18

04 Apr '18

Lai, Xu et al – Some contributors from EU and west coast are pretty keen to get an update on the VM-templating proposal for Kata. Can we setup a slack and/or zoom to discuss this what we started in arch committee earlier this week? I want to propose 6am pacific (9pm for you) on Thursday April 5th. What do you think? We could also do after 8:30am (11:30pm in PRC), though I know this will be very late for you. Please advise. Thanks, Eric

2 1

The drive to 1.0 release, labels, requirements
by Ernst, Eric 03 Apr '18

03 Apr '18

Kata-zins, TL;DR: We need to start tracking issues closely, clearly define release criteria, track the required missing features (with owners) and I suggest we target release of June 1st. In detail: I think that the requirements document, [1], put together by the organization represents our criteria for 1.0 release, though we can add some more details with respect to what is required for the CRI friendly API (which is in [2]). One of the most common questions I get when talking about Kata is when the 1.0 release will be. I think we’re at a point where we track release gating features and picking a release date. ==Firstly on tracking== To aid in this, I started marking obviously-release-gating issues with the self descriptive label “release-gating”. The key ones can be seen at [3], [4]. I acknowledge more are needed (meeting our testing and documentation requirements, at least). Since we work across a few different repositories, for my own sanity I usually look @ the issues via waffle, [5]. Disclaimer: I’m not saying waffle is what we use for getting an aggregated view (just something easy I use myself), but I am advocating for the consistent use of a few key labels as we itemize and measure ourselves against release, get more involvement from developers and keep things focused. Key labels for issues that I am suggesting we adopt are: * release-gating: feature or bug which must work in our 1.0 release. We should make sure there is agreement from the architecture committee on what is marked release-gating. * bug: unexpected behavior (not a new feature, not an optimization) * feature: new functionality to add * enhancement: optimization or improvement * help wanted: feature/bug/optimization/test which we are looking for owner on * good first issue: An issue which may be a good fit (based on priority and complexity) for something looking to first get involved in the project. These exist today in the github repos we are using. If there’s consensus we can have this documented in kata-containers/documentation. If you have feel a color chosen for label is offensive or if we could use improved labels and/or descriptions, please provide feedback. ==Secondly, on Release== After taking an independent look at the feature list and where we are today, listening to what Kata-users want, I think that June 1st is a good target for our 1.0 release (shortly after open stack summit, where we can have a f2f working “sprint”, still within first half of the year, etc). I’m looking for feedback from the community (and we will need to clarify exact release criteria closely), but I think this is feasible and a good starting point to work towards. To meet this schedule I think we need to make sure that each release-gating feature has a clear owner and we can start tracking on a regular cadence the status of these. I can help track this, though as a starting point we need to be 100% clear who is working on which feature (ie: who is owner of issue, and already working on implementation). I’ll follow up on these details tomorrow in a follow up mail (after the standing developer community meeting @ 7am pacific). Thx, Eric [1] - https://github.com/kata-containers/documentation/blob/master/design/kata-de… [2] - https://github.com/kata-containers/documentation/blob/master/design/kata-ap… [3] - https://github.com/kata-containers/runtime/labels/release-gating [4] - https://github.com/kata-containers/packaging/labels/release-gating [5] - https://waffle.io/kata-containers/runtime?search=release-gating

1 0

Features/proposals to review
by Boeuf, Sebastien 30 Mar '18

30 Mar '18

Hi folks, Here are 2 discussions about features that we might need pretty quickly and on which I'd like to get some feedback from every one. Posting to this list to make sure everybody is aware about it: https://github.com/kata-containers/runtime/issues/113 https://github.com/kata-containers/runtime/issues/115 Thanks, Sebastien

1 1

Proposal to migrate to a Slack alternative
by Anne Bertucio 27 Mar '18

27 Mar '18

Hi all, With some of the changes to Slack’s terms of service and integrations with IRC, I wanted to raise the idea of moving to an open source alternative to Slack. The driver behind having an alternative to IRC was 1) some find IRC intimidating 2) some are more likely to get involved in our community if there’s a communication GUI that they’re familiar with. One alternative would be Rocket.chat. I’d love to your thoughts on migrating and if anyone has experience with rocket chat or other platforms. Cheers, Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

13 15

Re: [kata-dev] Proposal to migrate to a Slack alternative
by Fox, Kevin M 27 Mar '18

27 Mar '18

Sorry, dropped off the list by mistake. ________________________________ From: Fox, Kevin M Sent: Monday, March 26, 2018 12:48 PM To: Sean McGinnis Subject: RE: [kata-dev] Proposal to migrate to a Slack alternative There are other projects in the openstack umbrella that have to cross the k8s/openstack line, such as kolla, openstack-helm, cloud-provider-openstack, maybe magnum, etc. And I expect the number to grow in the future. It is not just isolated to kata containers. Thanks, Kevin ________________________________ From: Sean McGinnis [sean.mcginnis(a)gmail.com] Sent: Monday, March 26, 2018 12:41 PM To: Fox, Kevin M Subject: Re: [kata-dev] Proposal to migrate to a Slack alternative The OpenStack community is already all in on IRC, so a slack discussion isn't too relevant there. And since Kata Containers is part of the OpenStack Foundation, but under its own governance, the OpenStack TC does not have any say on technical decisions made by the kata community. We can certainly provide opinions (we have no shortage of those ;) ) but this would not be the TC's place. I do not think K8s needs to lift and shift from Slack in order for Kata to do so. Since there is a lot of overlap for contributors, this likely means this would be adding a second (or likely third) communication channel for them to install, login, and monitor. But if we gated Kata choosing a different, more open, platform on getting adjacent communities to also make that switch, then I think we are already dead in the water. I think this needs to be a community decision based on the needs of this specific community. So I think the Kata community needs to decide if "open"-ness is important, and if so, what alternative is the easiest and most attractive to the overall group. Personally, I would love to see IRC as the near-realtime communication channel of choice, but I think there have been other equally functional alternatives. But with already good support from the OpenStack infra team [1], and many client choices [2][3][4][5], the only thing I think would be missed would be all the shiny emojis and gifs. :) [1] http://eavesdrop.openstack.org/irclogs/ [2] http://webchat.freenode.net/ [3] https://www.irccloud.com/ [4] https://thelounge.chat/ [5] https://www.slant.co/topics/1323/~irc-clients-for-linux Opinions aside, I do think moving away from Slack is a very good thing to discuss. On Mon, Mar 26, 2018 at 2:23 PM, Fox, Kevin M <Kevin.Fox(a)pnnl.gov<mailto:Kevin.Fox@pnnl.gov>> wrote: It sounds like there are a lot of reasons to consider getting off slack. +1 for discussions around it. -1 for doing it too much *here*. The Kubernetes and OpenStack communities should be doing it as a whole. Shouldn't this be done at the openstack-dev list or the openstack-tc? and some equivalent at k8s? If kata-containers does it in isolation, then the solution kata-containers comes up with very well could isolate it from the other communities based on the other communities choices. Lets work together. Thanks, Kevin ________________________________ From: Anne Bertucio [anne(a)openstack.org<mailto:anne@openstack.org>] Sent: Monday, March 26, 2018 11:06 AM To: Graham Hayes Cc: kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] Proposal to migrate to a Slack alternative Graham hits on many of my concerns about Slack. Slack was built for organizations where everyone is an employee—was never intended for open source collaboration, and they’re not building for us as they build future features (or take existing ones away). A major concern I have with OSS projects using Slack is that it does not have the guardrails that help everyone feel safe in a community—for example, individuals cannot block individuals. Another concern is the lost historical knowledge through the lack of logging. We are already losing information through the message limit (although we capture it currently via eavesdrop on IRC). Logging is only available to paid accounts, and while they give steep discounts to nonprofits (open source projects housed at foundations meets those requirements), the per-user fee adds up to be nontrivial, and there are many better ways to spend those community dollars. User inertia is real, and “Oh no not another tool” is a downside to migrating. That said, I think there is a balance between defining our own principles as a community, and being pressured into the trends set by others. Anne Bertucio OpenStack Foundation anne(a)openstack.org<mailto:anne@openstack.org> | irc: annabelleB

1 0

Fwd: Proposal to migrate to a Slack alternative
by Sean McGinnis 27 Mar '18

27 Mar '18

Sorry, I noticed after I sent that Reply wasn't set up to go to the list. ---------- Forwarded message ---------- The OpenStack community is already all in on IRC, so a slack discussion isn't too relevant there. And since Kata Containers is part of the OpenStack Foundation, but under its own governance, the OpenStack TC does not have any say on technical decisions made by the kata community. We can certainly provide opinions (we have no shortage of those ;) ) but this would not be the TC's place. I do not think K8s needs to lift and shift from Slack in order for Kata to do so. Since there is a lot of overlap for contributors, this likely means this would be adding a second (or likely third) communication channel for them to install, login, and monitor. But if we gated Kata choosing a different, more open, platform on getting adjacent communities to also make that switch, then I think we are already dead in the water. I think this needs to be a community decision based on the needs of this specific community. So I think the Kata community needs to decide if "open"-ness is important, and if so, what alternative is the easiest and most attractive to the overall group. Personally, I would love to see IRC as the near-realtime communication channel of choice, but I think there have been other equally functional alternatives. But with already good support from the OpenStack infra team [1], and many client choices [2][3][4][5], the only thing I think would be missed would be all the shiny emojis and gifs. :) [1] http://eavesdrop.openstack.org/irclogs/ [2] http://webchat.freenode.net/ [3] https://www.irccloud.com/ [4] https://thelounge.chat/ [5] https://www.slant.co/topics/1323/~irc-clients-for-linux Opinions aside, I do think moving away from Slack is a very good thing to discuss. On Mon, Mar 26, 2018 at 2:23 PM, Fox, Kevin M <Kevin.Fox(a)pnnl.gov> wrote: > It sounds like there are a lot of reasons to consider getting off slack. > +1 for discussions around it. > > -1 for doing it too much *here*. The Kubernetes and OpenStack communities > should be doing it as a whole. Shouldn't this be done at the openstack-dev > list or the openstack-tc? and some equivalent at k8s? > > If kata-containers does it in isolation, then the solution kata-containers > comes up with very well could isolate it from the other communities based > on the other communities choices. Lets work together. > > Thanks, > Kevin > ------------------------------ > *From:* Anne Bertucio [anne(a)openstack.org] > *Sent:* Monday, March 26, 2018 11:06 AM > *To:* Graham Hayes > *Cc:* kata-dev(a)lists.katacontainers.io > *Subject:* Re: [kata-dev] Proposal to migrate to a Slack alternative > > Graham hits on many of my concerns about Slack. Slack was built for > organizations where everyone is an employee—was never intended for open > source collaboration, and they’re not building for us as they build future > features (or take existing ones away). > > A major concern I have with OSS projects using Slack is that it does not > have the guardrails that help everyone feel safe in a community—for > example, individuals cannot block individuals. > > Another concern is the lost historical knowledge through the lack of > logging. We are already losing information through the message limit > (although we capture it currently via eavesdrop on IRC). Logging is only > available to paid accounts, and while they give steep discounts to > nonprofits (open source projects housed at foundations meets those > requirements), the per-user fee adds up to be nontrivial, and there are > many better ways to spend those community dollars. > > User inertia is real, and “Oh no not another tool” is a downside to > migrating. That said, I think there is a balance between defining our own > principles as a community, and being pressured into the trends set by > others. > > > Anne Bertucio > OpenStack Foundation > anne(a)openstack.org | irc: annabelleB > >

1 0

Re: [kata-dev] Proposal to migrate to a Slack alternative
by Ronald Pagani, Jr. 23 Mar '18

23 Mar '18

About 2 years ago, I setup Rocket chat for a client for a similar motivation (alternative to Slack). It worked ok, however we didn't attempt to enable the IRC integration so I can't comment on that. I recall the mobile apps had some issues (performance and interaction issues). Maybe those have since been resolved. (Sent from mobile, please excuse grammatical errors) Best Regards, Ronald Pagani Jr., Principal Open Technology Partners, LLC > On Mar 23, 2018, at 7:36 AM, Anne Bertucio <anne(a)openstack.org> wrote: > > Hi all, > > With some of the changes to Slack’s terms of service and integrations with IRC, I wanted to raise the idea of moving to an open source alternative to Slack. The driver behind having an alternative to IRC was 1) some find IRC intimidating 2) some are more likely to get involved in our community if there’s a communication GUI that they’re familiar with. > > One alternative would be Rocket.chat. I’d love to your thoughts on migrating and if anyone has experience with rocket chat or other platforms. > > Cheers, > Anne Bertucio > OpenStack Foundation > anne(a)openstack.org | irc: annabelleB > > > > > > _______________________________________________ > kata-dev mailing list > kata-dev(a)lists.katacontainers.io > http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev

1 0

Proposal for metrics CI for Kata
by Whaley, Graham 22 Mar '18

22 Mar '18

Hi all, Re: https://github.com/kata-containers/ci/issues/6 I have a presentation I'd to show in the next Architecture meeting on Monday April 2nd (although that is a public holiday here in the UK, so it may be presented by another member of the team), detailing what I think we'd like to get from a metrics CI system for Kata, and how we architect and implement that. The proposal covers implementing a Jenkins driven CI system that will track and feedback metrics on PRs and also track master branch merges to gather historical data and provide a database with analysis and visualization front end. This system is very much modelled on the working infrastructure we have been using for Clear Containers, and leverages a large percentage of the Jenkins infrastructure we have already for Kata QA CI. One requirement we don't have a good solution for yet is that the metrics runs need to be done on bare metal machines (for stable reproducible results). If anybody has ideas (or donations ;-), please bring them to the table. I'm currently working on a proof of concept bring up locally. Thanks, Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

First Week in Review Blog Draft available
by Cameron Seader 22 Mar '18

22 Mar '18

Please give criticism and thoughts about the blog. This is a rough outline for going forward. Maybe you have ideas on what might need to be added so please let me know. Its just a start. Also information that you would like to add to the notable pull request information that would be great as well especially if you have more details etc. https://github.com/kata-containers/community/wiki/March-11th-2018-Week-in-R… Thanks, -- Cameron Seader Technology Strategist SUSE cs(a)suse.com (P)+1 208.572.0095 (M)+1 208.420.2167

2 1

NEW SHIPPING CONTAINERS PRODUCTION 2018
by Polar Container 20 Mar '18

20 Mar '18

Mar 2018 Dear Sir / Madam NEW SHIPPING CONTAINERS PRODUCTION 2018 Polar Container is a Shipping Container manufacturer located in Beautiful City of Jiangsu Province, China. 40minutes drive from Port of Shanghai, the biggest port in the world. Our factory yard covers area of 12,000 square meters with 2 production lines and 100 professional workers capable of achieving a production capacity of 50tues per day. Our products range from 20'GP, 40'GP, 40'HQ, Open side, Open Top, to all kinds of special containers and customizable to your requirement. Specification of these containers is available on our website. If you want to purchase your first lot of shipping container directly from Polar Container factory with speedy delivery to your depot @ free of freight or @ lowest cost, please send us an inquiry with Details of the Type, Quantity, Color of Container, as well as the Port of Delivery. We will respond with our immediate offer. If you are a Dealers, Distributors or Trader of New Shipping Container. We are keen to further discuss with your good company on how to cooperate and represents us in your region. Best Regards POLAR CONTAINER Marketing Department <http://www.polarcontainer.com/> http://www.PolarContainer.com Office: <tel:+86%2021%203368%200716> +86 21 3368 0716 Fax: <tel:+86%2021%203368%200716> +86 21 3368 0716 Email: <mailto:kelvin@polarcontainer.com> kelvin(a)polarcontainer.com Skype: live:daa9169c9a1837fa

2 1

Moving to UTC meeting times
by Anne Bertucio 20 Mar '18

20 Mar '18

Hi all, I wanted to propose a change to our current meeting times. Currently, Arch and Working Committee times are kept in Pacific Time, and both meetings moved last week to adjust for US daylight saving time. I want to propose that we keep the meeting times as they currently are (15:00 UTC and 00UTC), but bump them to UTC, and keep it in UTC going forward. (This means the meetings would not move again for US fall daylight saving changes—sorry, west coasters, we’d just have to get up early.) Thoughts? Cheers, Anne Bertucio anne(a)openstack.org | irc: annabelleB

4 3

Real time collaboration session for Kata PRs and Issues
by Ernst, Eric 17 Mar '18

17 Mar '18

With the API extension and runtime merge work progressing, I think it’d be helpful to hold a collaboration/scrub session for contributors/developers/maintainers. This is meant to allow for real-time discussion of pending PRs and issues which have otherwise taken several days to achieve consensus and resolution. I think slack would be a useful medium for this, though am open for feedback and we can re-evaluate after the first session. I propose we hold the first session on Tuesday March 20th at 7am Pacific and we can schedule the next ones after (I think 2x a week when we don’t have arch committee may be helpful during this initial design and drive to release period, but let’s agree after the first one). Feedback? Anne, can you help with how to appropriately post this on katacontainers.io? Thanks, Eric

4 3

minutes: architecture meeting - 3/05
by Ernst, Eric 05 Mar '18

05 Mar '18

Wanted to send the notes from the call this morning, in case folks don’t know to check out the etherpad, [1]. We will plan to continue the discussion at the same time next week: March 12th, 8AM pacific. Will send meeting notice later. Thanks, Eric [1] - https://etherpad.openstack.org/p/katacontainers-2018-architecture-committee… Notes: === 2018-03-05 MEETING PARTICIPANTS (Add your name, company, email, timezone) Eric Ernst, Intel, eric.ernst(a)intel.com, UTC-8 Eric Adams, Intel, eric.adams(a)intel.com, UTC-8 Samuel Ortiz, samuel.ortiz(a)intel.com, UTC+1 Xu Wang, Hyper, xu(a)hyper.sh, UTC+8 Thierry Carrez, thierry(a)openstack.org, UTC+1 Wei Zhang, Huawei, zhangwei555(a)huawei.com, UTC+8 Julio Montes, Intel, julio.montes(a)intel.com, UTC-6 Jon Olson, Google, jonolson(a)google.com, UTC-8 Salvador Fuentes, Intel, salvador.fuentes(a)intel.com, UTC-6 Jonathan E. Magen, Cigna, jonathan.magen(a)cigna.com, UTC-5 Gabriela Cervantes, Intel, gabriela.cervantes.tellez(a)intel.com, UTC-6 Tim Pepper, VMware, tpepper(a)vmware.com, UTC-8 Archana Shinde,Intel, archana.m.shinde(a)intel.com, UTC-8 Carlos Venegas, Intel, jose.carlos.venegas.munoz(a)intel.com, UTC-6 Tao Peng, Hyper, bergwolf(a)hyper.sh, UTC+8 Jessie Frazelle, Microsoft, jessfraz(a)microsoft.com, UTC+5 James Hunt, Intel, james.o.hunt(a)intel.com, UTC Surya Naredla, Dell-EMC, surya.prabhakar(a)dell.com, UTC Tim Allclair, tallclair(a)google.com, UTC-8 AGENDA / NOTES (Please propose agenda here) 1. Handling docker swarm/compose up and network TC support: see https://github.com/clearcontainers/runtime/issues/1042#issuecomment-3700876… for details 1. The Design Documents (katacontainers/documentation #14, #16, #17) - https://github.com/kata-containers/documentation/pull/14 - https://github.com/kata-containers/documentation/pull/16 - https://github.com/kata-containers/documentation/pull/17 1. Discuss runtime API ( https://github.com/kata-containers/runtime/pull/32 , slides: https://docs.google.com/presentation/d/1BZvRQdJUnSmaeaKgJPS-E9RFTFb7qsM7ybe… ) 1. Discuss virtcontainer import PR: https://github.com/kata-containers/runtime/pull/41 1. Virtcontainer API definition: https://github.com/kata-containers/runtime/pull/32 Notes: * For agenda #1, didn't get a chance to discuss - will put query on mailing list and add to agenda for next architecture commitee meeting if still necessary * For agenda #2: * PR 14 is ready, while 17 should be mergable after taking review feedback into account * PR 16 - given amount of detail present in this, it'd be best to wait for resolution of API discussion before merging. * For agenda #4 - discussion of virtcontainer import PR: Didn't get chance to discuss. * Virtcontainer API discussion: * Xu gave presentation covering the API that has been proposed in runtime/pull/32. * lots of discussion about slide 3 and what happens with proxy/shim/cri server: in the frakti example, the shim/proxy are implemented within the CRI-shim itself * slide 4 APIs are mostly covered by existing virtcontainers API with exception of streaming and perhaps persistance API * No resolution based on presentation - still need more information to drive decision: * Need more information from Hyper engineers on what is missing from virtcontainers API (in detail), and we will use this as a basis for follow up discussion * Will add a meeting next week at same time to continue discussion * Drive to a decision of if virtcontainers will be the basis by the end of the meeting next week ===

2 1

This is a test, please ignore.
by Sarkar, Joy 05 Mar '18

05 Mar '18

Messaging Engg Team This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Gist on how to get Kata containers working with OpenStack Zun through DevStack
by Adams, Eric 03 Mar '18

03 Mar '18

Hello everyone, I was able to get DevStack Zun working with Kata containers by combining the Kata setup instructions with the DevStack Zun + CC 2.0 instructions. I basically setup OpenStack Zun and replaced the CC 2.0 runtime with the Kata runtime and everything seems to work fine. I've not exhaustively tested this with Zun but the basic test container works on the command line. I created a gist for Ubuntu 16.04 if anyone else wanted to try this. I just finished testing this on a clean install of Ubuntu and it worked without error. Hopefully your experience is the same. I grouped as many commands together to make copy/paste easier. https://gist.github.com/eadamsintel/86bd12acd7052ea061766f9698f69819 Thanks Eric

3 2

Sharing our Kubernetes CI experience
by Tim Allclair 02 Mar '18

02 Mar '18

Several folks from our Kubernetes test-infra team have agreed to share some of their experience with running Kubernetes CI, which was originally based on jenkins but now uses a custom built tool called prow <https://github.com/kubernetes/test-infra/blob/master/prow/README.md>. @Kata community - Feel free to respond with questions. @Ben, Sen & Cole - Thanks for sharing! Would you like to give a brief summary of the issues we had with Jenkins, and why we decided to build prow?

3 2

Updates from 2/21 Arch Meeting
by Anne Bertucio 22 Feb '18

22 Feb '18

Hi all, Two things to be aware of if you weren’t able to join yesterday’s Architecture Committee meeting: Moving forward with the virtcontainers proposal! (https://github.com/kata-containers/runtime/issues/33 <https://github.com/kata-containers/runtime/issues/33> Next step is to start outlining this architecture (happening in Issue 33) and move virtcontainers into kata-containers. CI update: Jenkins is up and running (thanks, Eric!), but the group talked about some of the downsides to Jenkins and alternatives. One option would be Zuul. If we go the Zuul route, the OpenStack Infra team has offered to run jobs for us. For now, Jenkins is running and we’re not at the scale to see some of the issues, so we’ll stay here and add this to the in-person agenda in Vancouver in May. The next Arch meeting is March 5 at 8am Pacific. Cheers, Anne Bertucio anne(a)openstack.org | irc: annabelleB

1 0

Cloud Users List
by rhonda.stewart＠rearson.com 21 Feb '18

21 Feb '18

<div dir="ltr">Hello there, I would like to know if you are interested in acquiring Cloud Users List? List Contains: Name, Company's Name, Phone Number, Fax Number, Job Title, Email address, Complete Mailing Address, SIC code, Company revenue, size, Web address etc. All Technology / Companies Partners and Users List, IT decision Makers from Fortune 500 Companies, IT Decision Makers from SME as well. Let me know if you are interested and I will get back to you with the counts and pricing. Regards, Rhonda Stewart Marketing Executive to opt out, please reply with Leave Out in the Subject Line.</div>  <a style='display: block; margin: 32px 0 40px 0; padding: 10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and email marketing software for Gmail.</a>

1 0

Kata Containers Jenkins CI
by Fuentes, Salvador 20 Feb '18

20 Feb '18

Hi all, Last week I enabled the Jenkins instance that will be verifying the PRs we raise in the Kata Containers repos. You can head to the Jenkins instance at: http://kata-jenkins-ci.westus2.cloudapp.azure.com/ I have created jobs that are currently checking the `tests` and `runtime` repository. In the coming days I will be creating more jobs for the rest of the components. Currently what we do in these Jenkins jobs is to setup the Kata Containers environment with latest changes in an Ubuntu 16.04 VM instance at Azure and execute the docker integration tests. All the CI scripts are located in the https://github.com/kata-containers/tests repository. Right now we have some instabilities issues with the results of the tests due to some random failures. I have opened https://github.com/kata-containers/runtime/issues/35 and after fixing this, we should have an stable CI. We well be continue working on enabling more distros and tests into this CI. Next steps: - Add jobs for the rest of the Kata Containers Components. - Add kata-containers-runv runtime in the tests. - Add other distros in addition to Ubuntu 16.04. - Add CRI-O, k8s and Openshift tests Any question, suggestion or comment is more than welcome. Thanks, Regards. Salvador Fuentes.

1 0

Kata Containers CI
by Fuentes, Salvador 17 Feb '18

17 Feb '18

Hi all, This week I enabled the Jenkins instance that will be verifying the PRs we raise in the Kata Containers repos. You can head to the instance at: http://kata-jenkins-ci.westus2.cloudapp.azure.com/ I have created jobs that are currently checking the `tests` and `runtime` repository. In the coming days I will be creating more jobs for the rest of the components. Currently what we do in these Jenkins jobs is to setup the Kata Containers environment with latest changes in an Ubuntu 16.04 VM instance at Azure and execute the docker integration tests. All the CI scripts are located in the https://github.com/kata-containers/tests repository. Right now we have some instabilities issues with the results of the tests due to some random failures. I have opened https://github.com/kata-containers/runtime/issues/35 and after fixing this, we should have an stable CI. We well be continue working on enabling more distros and tests into this CI. Next steps: - Add jobs for the rest of the Kata Containers Components. - Add kata-containers-runv runtime in the tests. - Add other distros in addition to Ubuntu 16.04. - Add CRI-O, k8s and Openshift tests Any question, suggestion or comment is more than welcome. Thanks, Regards. Salvador Fuentes.

1 0