-
Notifications
You must be signed in to change notification settings - Fork 1
/
hot
248 lines (148 loc) · 13.5 KB
/
hot
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
330 North Bayshore Boulevard
San Mateo
CA 94401
https://goo.gl/maps/Yrjxk9i8WWF2
https://www.google.com/maps/@37.7729359,-122.4198144,10z
Hi,
We would like to start having rkt community sync meets for both
developers and users. It should be an opportunity to discuss the next
features and hear about the different use cases people have for rkt.
The next one will be on Wednesday 16th December, 17:00 UTC (18:00 CET,
9:00 PST) on Google Hangouts.
https://plus.google.com/events/co5e0ranuts2eq1vhtrtsoh07l4
Please submit ideas to the agenda: https://goo.gl/gKvQZ6
Cheers,
Alban
Proposal One
Proposer
Chenye Liang (liangchenye@163.com)
Speakers
Meaglith Ma (maquanyi@huawei.com)
Title: ContainerOps – The Next Generation DevOps Concept
Biography:
Meaglith Ma is open source expert in Huawei Corporation, senior architect, full stack developer and open source container & Golang evangelist, contributor in some open source projects. He interested in Container, DevOps, Golang, AngularJS and open source economy. Ma also is a organizer and host of Docker meetup in many cities in China, member of some container conference expert committees, speaker in many architect and DevOps conferences. Ma propose the ContainerOps of new DevOps concept and application version control system concept beyond the source version control like Git.
Description
Since Docker becomes the hottest open source project, the container technology is the biggest challenge to DevOps domain. ContainerOps redesigns the a new DevOps architecture base on container following OCI & CNCF specs. It consists of application version control, continuous integration of micro service workflow and continuous deployment with Kubernetes.
Abstract
Since Docker becomes the hottest open source project, the container technology is the biggest challenge to DevOps domain. ContainerOps abandons all the aspects of old architectures, redesigns the a new DevOps architecture base on container following OCI & CNCF specs.
ContainerOps consists of application version control, continuous integration of micro service workflow and continuous deployment with Kubernetes.
The application version control is a redesign system with base on git and container image. It’s backward compatible with Git, and rewrite the bare repository storage format with distributed key/value database and distributed object storage service. The system could store over 30T Git repositories easily and many large files storage with LFS (git-lfs.github.com). It has different source view with other major VCS like Github or Gitlab. The main view is the container image detail what builded from source successfully and could be used for CI or CD. The image id already linked with git commit id in database. It have branch and tag same as Git and sync from Git repository.
Continuous integration system is a automate and streamline test workflow for complex applications of base container. Unlike the Jenkins, it build from the ground up with pipelines which consists of stage. You can easily configure dependencies, parallel and sequential pipeline with stage which execute different task , configure global or local parameters and deliver them when the pipeline execute from stage to another. The container image already builded in the application version control system, so you could remove the Jenkins from DevOps tools.
Continuous deployment system manage a cluster of Linux containers with Kubernetes as a single system. The system provide DaaS (Database as a service) with TiDB which is a distributed sql database. So it’s well supported micro service applications of any scale.
Proposal Two:
Proposer
Chenye Liang (liangchenye@163.com)
Speakers
Genping Liu (liugenping@huawei.com)
Title: Analysis Between OCI and APPC Specification
Biography:
Genping is a senior engineer in Huawei who has 10 years experience in software design and development. He has deep understanding about software license and container technology.
Description
OCI and APPC specification define the container runtime from root directory, mount, isolation, security and so on. This topic describes their common points , differences and their implementations (runc and rkt) .
Abstract
OCI and APPC specifications are two main container specifications. runc and rkt respectively implement the OCI and APPC specifications. This topic describes the two specifications, including their common points and differences, as well as runc and rkt runtime implementation details.
In the past two years, there has been rapid growth in both interest in and usage of container-based solutions. Almost all major IT vendors and cloud providers have announced container-based solutions. The container application portability requires the establishment of certain standards around format and runtime, so the oci and appc specification appeared.
OCI and APPC specification define the container runtime from root directory, mount, isolation, security and so on. runc uses namespace , cgroup and chroot technology to implement the OCI runtime. But rkt is different, it use systemd which package the namespace and cgroup to implement APPC runtime.
Proposal Three:
Proposer
Chenye Liang (liangchenye@163.com)
Speakers
Chenye Liang (liangchenye@huawei.com)
Title: OCT - a container based testing framework
Biography
Chengye Liang is now working in Huawei open source team, focus on container technology. Before join Huawei, Chenye worked in SUSE Linux as a Desktop team leader and has good experience in openSUSE and GNOME community.
Description
The Open Container Testing (OCT) is a testing framework based on the container technology. It uses container to generate the testing environment and using the underlying orchestration system to deploy the test job. Following the container life cycle defined in OCI,all the tests could be run in a `industry standard`. The testing report will deliver to the user afterwards.
Abstract
The Open Container Testing (OCT) is a testing framework based on the container technology.It defines a simple testing specification. Anyone could write a test case easily, just like write a dockerfile.
OCT generates the testing environment by the case and deploy the case to the suitable servers/containers by the underlying orchestration.
Following the container life cycle defined in Open Container Initiative, all the tests will be run in an `industry standard` way, the testing report will deliver to the user afterwards.
The case is infrastructure independent and could be store in any type of case repo. The developer/user could be sure his/her application is totally reliable with OCT.
Proposal Four:
Proposer
Chenye Liang (liangchenye@163.com)
Speakers
Yang Wang (victor.wangyang@huawei.com)
Title: How to initiate a successful open source project: Practice and Lessons
Biography
Yang Wang currently works as an open-source evangelist at Huawei, who is focusing on container, devops, cloud-native and microservice. Prior to that, he is a principle software engineer on Linux, Virtualization and networking. Yang has not only more than 10+ years C programming practice, but also vast experience in telecommunication.
Description
Huawei has been involved in Container Ecosystem deeply these years and initiated a series of open source projects. Yang Wang is going to introduce what these projects are about, why did they decide to open source these projects, how do they operate these projects and what kind of lesson do they learn from.
Abstract
Open Source has been accepted by almost all major IT/CT vendors as an efficiency collaboration and innovation way. Since 2014, Huawei has been deeply involved in Container Ecosystem and initiated a series of open source projects including OCT, Dockyard, Harbour, ContainerOps. Anyone and any company which just begins adopting open source will face the common challenges with Huawei.
In this presentation, Yang Wang is going to introduce a little bit about these projects firstly. And then will share why they decide to open source these projects while there are so many projects existing, how do they initiate and operate these projects successfully and what kind of lessons do they learn from.
Audiences could benefit from this presentation and improve open source innovation within their organization.
#!/bin/bash
#use ubuntu image to create a docker container,and print "hello, world" in the container.
ret=0
var=`docker run --rm ubuntu bash -c "echo hello, world"`
if [ "$var"x != "hello, world"x ];then
echo "FAILD"
ret=1
else
echo "PASS"
fi
exit $ret
#!/bin/bash
#get images from docker hub.
ret=0
docker pull busybox
if [ $? -ne 0 ];then
echo "FAILED"
ret=1
else
echo "PASS"
fi
docker images | grep busybox
if [ $? -ne 0 ];then
echo "FAILED"
ret=2
else
echo "PASS"
fi
exit $ret
https://conferences.oreilly.com/oscon
TITLE
OCT: A new testing framework in the container era
Description.
The Open Container Testing (OCT) is a testing framework based on the container technology.
It uses container to generate the testing enviornment and using the underliny orchestration system to deploy the test job.
Following the container life circle defined in OCI,all the tests could be run in a `industry standard` way. The testing report will deliver to the user afterwards.
Abstract
The Open Container Testing (OCT) is a testing framework based on the container technology.
It defines a simple testing specification. Following the spec, anyone could write a test case easily, just like write a dockerfile.
OCT generates the testing enviornment by the case and use the underling orchestration to deploy the test.
Following the container life circle defined in Open Container Initiative, all the tests will be run in an `industry standard` way.
The testing report will deliver to the user afterwards.
The case is infrastructure independent and could be store in any type of case repo.
The developer/user could be sure that his/her application is totally reliable with OCT's assistance.
In the container era, sending the test case to the OCT server before releasing a container application will be a new fashion.
Why are you doing this now?
At CoreOS we have large, serious users running in enterprise environments.
We cannot in good faith continue to support Docker’s broken security model without addressing these issues.
Additionally, in the past few weeks Docker has demonstrated that it is on a path to include many facilities
beyond basic container management, turning it into a complex platform. Our primary users have existing platforms
that they want to integrate containers with.
We need to fill the gap for companies that just want a way to securely and portably run a container.
Application containers are useful because they put developers in full control of the exact versions of software
dependencies for their applications. This reduces surprises that can arise because of discrepancies between different
environments (like development, test, and production), while freeing the underlying OS from worrying about shipping
software specific to the applications it will run.
This decoupling of concerns increases the ability for the OS and application to be serviced for updates and security patches.
Docker：
IBM 在docker 上有两个团队，美国和印度。目前docker on power已经得到了SUSE/Ubuntu/Redhat的支持http://server.51cto.com/Prod-477908.htm 。 他们的研发经理也是这么说的。北京这边可以测试，测试有两种，一种是去IBM测试机房；另一种由代理云， 介绍人说可以联系CSDN。
IBM开源：
IBM开源团队非常庞大，比如仅仅Spark目前就有上千人，按照他们的计划还会持续招人。他们自己的说法是，从2000年开始，IBM服务器的收入就不断下降，下降主要原因是来自Linux等开源领域的挑战，尤其是他们在Unix上的收入。比较讽刺的是，Linux这些年的最大推动者就是IBM，所以一个问题是：为什么要养虎为患。他们的回答是：
开源的趋势不可逆转，与其被其他人颠覆，不如自己颠覆自己。
在谈到kvm虚拟化等IBM贡献很高的项目时，他们的回答是主要动机就是能够让自己的机器上，比如power系列上，能够完美运行KVM，那么另外一个问题是：非power相关的模块是否会参与。他们的回答是：
优先级会排在power模块之后，但是也会参与，扩大影响力。
这个和HP的策略完全不一样，我之前和HP中国的开源团队总监聊过，他们只参与HP相关的模块，比如说HP推出新的服务器，那么会参与社区这方面的优化和驱动的实现。
而其他的一些开源项目，IBM也是很积极参与，按照他们经理的说法是：
担心成为非主流。
开源趋势下一个项目能够被客户认可需要和主流项目兼容，客户越来越不倾向一个被某一客户完全锁定的解决方案。当然，另外一个解读是他（经理）也不完全知道高层参与开源的全动机。
以上是IBM参与社区项目的一些情况，我也问了IBM自己项目的开源情况，他们的回答是：
会把一部分模块开源出去，作为社区项目某个模块的替代，并没有完全开放一个项目的所有模块。
IBM power
按照他们的说法，power在中国的最大目的就是把芯片实现完全摆在政府面前，避免政府担心里面内置某些监听的功能。
Power定位还是比较高端，但是开放（授权）之后国内厂家已经有和x86价格差不多的实现。
IBM推power有一段时间了，方法包括： 成立联盟，厂商合作，路演推广等。