-
Notifications
You must be signed in to change notification settings - Fork 11
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
171 changed files
with
37,689 additions
and
5,145 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7,681 changes: 7,681 additions & 0 deletions
7,681
_drafts/2012-03-06-iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii_init.md
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,164 @@ | ||
--- | ||
title: Git 简明教程 | ||
layout: post | ||
comments: true | ||
language: chinese | ||
category: [misc] | ||
keywords: flask,示例 | ||
description: 记录 Flask 常见的示例,可以用来作为参考使用。 | ||
--- | ||
|
||
|
||
<!-- more --> | ||
|
||
|
||
## 简介 | ||
|
||
![git code review openstack]({{ site.url }}/images/misc/git-code-review-openstack.png "git code review openstack"){: .pull-center width="80%" } | ||
|
||
<!-- | ||
对OpenStack提交代码更改的流程主要如下: | ||
配置Git与Gerrit环境 | ||
克隆目标项目的代码并在新branch上进行更改 | ||
commit到本地的repo后推送给远端Gerrit,然后由reviewer给出意见 | ||
根据reviewer的修改意见不断更新patch | ||
其中OpenStack使用Gerrit作为代码review系统,使用Jenkins系统对代码进行自动测试,使用tox工具可以在本地进行相同的代码测试。 | ||
基本前提 | ||
创建一个Launchpad账号(Gerrit使用Launchpad进行SSO) | ||
登录Gerrit,完成基本配置 | ||
加入OpenStack基金会 | ||
签署Contributor License Agreement | ||
安装 Git 和 git review | ||
--> | ||
|
||
git-review 工具是一组 git 子命令,主要用于 OpenStack 代码与 gerrit (review系统) 交互,可以在后面添加 -v 参数打印所有运行的 git 命令。 | ||
|
||
### 配置GIT | ||
|
||
{% highlight text %} | ||
----- 设置好全局参数,简化以后操作 | ||
$ git config --global user.name 'YourName' | ||
$ git config --global user.email [email protected] | ||
$ git config --global gitreview.username YourName | ||
|
||
----- 确认下配置项 | ||
$ gir config --list | ||
|
||
----- 克隆源码 | ||
$ git clone https://github.com/openstack/FOOBAR.git | ||
|
||
----- 切换到源码目录下 | ||
$ cd FOOBAR | ||
|
||
----- 建立git-review环境 | ||
$ git review -s | ||
{% endhighlight %} | ||
|
||
check out 到master分支,更新远端并将其pull到本地的master分支 | ||
$ git checkout master; git remote update; git pull origin master | ||
|
||
|
||
|
||
6. 在Launchpad上report 一个新的bug, 或者找一个尚未被解决的bug然后将它assign给自己,将bug的状态改为In progress, OpenStack使用Launchpad记录Blueprints和报告bugs。 | ||
7. 想要fix某个bug,就必须新建一个分支,然后在这个分支里对源代码进行修改,例如: | ||
$ git checkout -b fix-bug-#123456 | ||
上述命令创建并切换到新分支“fix-bug-#123456”,接下来所有的本地工作在这个分支里进行,直到所有fixation都完成后再commit, | ||
$ git commit -a | ||
|
||
提交时会要求输入commit message,commit message可以有下面的字段: | ||
Implements: blueprint BLUEPRINT | ||
Closes-Bug: #123456 | ||
Partial-Bug: #123456 | ||
Related-Bug: #123456 | ||
通过这些字段来标识自己工作相关的bug或者blueprint,一旦注明,CI系统会自动将你的commit和相同ID的bug对应起来。 | ||
|
||
上面的命令提交到本地repo后接下来就是push到Gerrit了。 | ||
$ git review -v | ||
|
||
Gerrit是OpenStack远端Git仓库的一道大门,所有的submission都要在这里经过review后才能被merge到master分支中,因此之前的工作一定不能在master分支进行,这样会产生一个merge commit,Gerrit默认是不接受merge commit的。 | ||
|
||
如果提交成功,Gerrit将返回一个显示你此次提交内容的URL,打开它就可以查看commit以及reviewer的评价了:http://review.openstack.org/nnnnnn | ||
|
||
如果需要修改commit怎么办? | ||
|
||
此时需要到http://review.openstack.org上查找自己的patch记录,然后记下这一个patch的review number,就是review.openstack.org对应patch页面的后几位数字:https://review.openstack.org/#/c/nnnnnn/ | ||
|
||
$ cd ourTargetProjectName #切换到项目源码目录 | ||
$ git review -d nnnnnn #把patch给check out,然后就可以编辑了 | ||
|
||
|
||
接着根据reviewer们的意见重新编辑patch,然后提交 | ||
$ git commit -a --amend #在本地commit | ||
$ git review | ||
|
||
对上一次的commit进行了修改,或者commit message没有写标准,都可以重新提交commit,但是一定要切换到自己上次提交commit的分支执行上面的命令。如果希望查看完整的git命令流,可以在git review命令后添加 -v选项。 | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
{% highlight text %} | ||
----- 如果用户名和邮箱开始配置有问题,可以通过如下方式修改 | ||
$ git commit --amend --author='foobar <[email protected]>' | ||
{% endhighlight %} | ||
|
||
其它的一些常见的情况包括了:代码审核未通过,返回修改;代码有冲突,不能合入代码库。这些情况,其解决方法都类似,都可以通过 amend 解决。 | ||
如果代码审核未通过,现在本地git log查看一下。最近的一条log是不是就是你要修改的那一个,是的话,OK,不 | ||
是的话,git reset --soft commit_id到你需要修改的那一个commit记录。 | ||
继续修改你要改的文件 | ||
git add | ||
git commit --amend | ||
repo upload | ||
三步,ok!注意如果你提交了3个文件,其中一个不过关,只需要修改、add 那一个文件就行。如果少提交了一个文件,也是add这个文件就ok了。 | ||
如果你多提交了一个文件,处理方法: | ||
mv filename newfilename #先把文件重命名,此时git status查看,可以看到多余commit的文件处于工作区delete状态。 | ||
git commit -a --amend | ||
然后git log --name-status -1 查看多余提交的文件已被撤销,此时可将之前重命名的文件再改回来重新upload后会生成一个patch set 2。 | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
注意:当审核未通过打回时,我们再修改完成之后,执行: | ||
git add 文件名 | ||
git commit --amend ##注意会保留上次的 change-id ,不会生成新的评审任务编号,重用原有的任务编号,将该提交转换为老评审任务的新补丁集 | ||
git review | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
http://blog.csdn.net/agileclipse/article/details/38980419 | ||
|
||
|
||
|
||
## 参考 | ||
|
||
[OpenStack git-review](http://docs.openstack.org/infra/git-review/index.html) | ||
|
||
|
||
<!-- | ||
OpenStack的Commit Message风格, | ||
这里对于每一次提交commit时commit message的风格有一定的介绍:https://wiki.openstack.org/wiki/GitCommitMessages | ||
OpenStack的bug分流, | ||
这里有OpenStack对不同程度的bug进行分流的介绍:https://wiki.openstack.org/wiki/BugTriage | ||
--> | ||
|
||
{% highlight text %} | ||
{% endhighlight %} |
118 changes: 118 additions & 0 deletions
118
_drafts/2014-02-01-network-collision-broadcast-domain_init.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,118 @@ | ||
--- | ||
Date: December 12, 2015 | ||
title: 冲突域和广播域,以及网桥 | ||
layout: post | ||
comments: true | ||
language: chinese | ||
category: [network, linux] | ||
--- | ||
|
||
|
||
<!-- more --> | ||
|
||
![network interface]({{ site.url }}/images/network/network-introduce-interface.png){: .pull-center width="500"} | ||
|
||
|
||
|
||
|
||
# 以太网简介 | ||
|
||
目前经常使用的是总线型以太网,通信信道只有一个,采用 CSMA/CD 介质访问方法,也就是说,每个站点在发送数据之前首先要侦听网络是否空闲,如果空闲就发送数据,否则,继续侦听直到网络空闲为止。 | ||
|
||
如果两个站点同时检测到介质空闲并同时发送出一帧数据,则会导致数据帧的冲突,双方的数据帧均被破坏。这时,两个站点将采用 "二进制指数退避" 的方法各自等待一段随机的时间再侦听、发送。 | ||
|
||
![If the picture doesn't exist]({{ site.url }}/images/network/introduce_concepts_ethernet_general.jpg "The files in our folder"){: .pull-center} | ||
|
||
如上图,主机 A 只是想发送一个单播数据包给主机 B,但由于传统以太网的广播性质,接入到总线上的所有主机都将收到此单播数据包。同时,此时如果任何第二方,包括主机 B 也要发送数据到总线上都将冲突,导致双方数据发送失败。我们称连接在总线上的所有主机共同构成了一个冲突域。 | ||
|
||
当主机 A 发送一个目标是所有主机的广播类型数据包时,总线上的所有主机都要接收该广播数据包,并检查广播数据包的内容,如果需要的话加以进一步的处理。我们称连接在总线上的所有主机共同构成了一个广播域。 | ||
|
||
* 冲突域:在同一个冲突域中的每一个节点都能收到所有被发送的帧,位于第一层(物理层)。 | ||
|
||
* 广播域:网络中能接收任一设备发出的广播帧的所有设备的集合,位于第二层(数据链路层)。 | ||
|
||
总的来说,冲突域就是连接在同一导线上的所有工作站的集合,或者说是同一物理网段上所有节点的集合,或以太网上竞争同一带宽的节点集合。比如某台特定设备在网段上发送一个数据包,迫使同一个网段上的其他设备都必须注意到这一点,在同一时刻,如果两台不同的设备试图发送数据包,就会发生冲突,此后,两台设备都必须重新发送数据包,同一时刻只能有一台设备发送。 | ||
|
||
|
||
|
||
<!-- | ||
在理解VLAN可以缩小广播域的作用时,总有许多读者朋友对什么是广播域、它与经常见到的冲突域之间有什么区别不是很清楚。 | ||
1.冲突域 | ||
冲突域(Collision Domain)是一种物理分段,是指连接在同一物理介质上的所有站点的集合。这些站点之间存在介质争用现象(如传统以太网中的CSMA/CD介质检测原理),也就是它们在数据通信时需要共享某部分公用介质。冲突域指的是不会产生冲突的最小范围。在同一冲突域中的计算机等设备互联时,会通过同一个物理通道,同一时刻只允许一个设备发送的数据在这条通道中通过,其他设备发送的数据则要等到这个通道处于"闲"时才可以通过,否则会出现冲突,这时就可能出现大量的数据包因为延时而被丢弃或者丢失。 | ||
冲突域的大小可以衡量设备的性能,我们知道以前的集线器、中继器都是典型的共享介质的集中连接设备,都是工作在OSI/RM第一层 物理层上的设备。连接在这些设备上的其他设备都处于同一个冲突域中,不能划分冲突域,即所有的端口上的数据报文都要排队等待通过。 | ||
工作在OSI/RM第二层 数据链路层上的设备,如网桥和交换机也有冲突域的概念,但是它们都是可以划分冲突域的,也可以连接不同的冲突域。如果我们把集线器、中继器上的传输通道看成是一根电缆的话,则可将网桥、交换机的交换通道看成是一束电缆,有多条独立的通道(是矩阵设计的),这样就可以允许同一时刻进行多方通信了。 | ||
网桥与中继器类似,传统的网桥只有两个端口,可用于连接不同的网段。也就是可以把网桥看成是可以连接两个冲突域的设备。连接在同一网桥上的两个网段各自成为一个冲突域。交换机则是网桥的扩展,它有许多端口,而且每个端口就是一个冲突域,即一个或多个端口的高速传输不会影响其他端口的传输,因为不同端口发送的数据不需要在同一条通道中排队通过,而只是在同一端口中的数据才要在对应端口通道中排队。 | ||
8.1.1节介绍了一个VLAN就相当于一台虚拟交换机,所以VLAN中的各个端口就是一个冲突域,也就是说VLAN可以划分和连接多个冲突域。 | ||
2.广播域 | ||
要理解广播域(Broadcast Domain),首先要理解什么是"广播"。如果一个数据包的目标地址是这个网段的广播IP地址(广播IP地址是对应子网的最后一个IP地址),或者目标计算机的MAC地址是FF-FF-FF-FF-FF-FF,那么这个数据包就会被这个网段的所有计算机接收并响应,这就叫做广播。广播域就是指可以接收相同广播消息的节点范围。在这个范围中的任何一个节点传输一个广播包,则该范围中的所有其他节点都可以接收到。广播域是OSI/RM中的第二层概念,所以像集线器、网桥和交换机等设备所连接的节点被认为都是在同一个广播域,当然这是指各节点处于同一IP网段情况下;如果连接的各设备是处于不同网段,则相当于路由器功能了。而路由器、三层交换机这样的设备可以划分广播域,即可以连接不同的广播域,就是说一个可路由端口所连接的网段就是一个广播域。 | ||
通常广播消息是用来进行ARP寻址等用途,但是广播域无法控制也会对网络健康带来严重影响,主要是带宽和网络延迟。二层的交换机是转发广播的,所以不能分割广播域,而路由器一般不转发广播,所以可以分割或定义广播域。 | ||
VLAN是用来把一个大的网络划分成多个小的虚拟网络,也就是它具有划分多个广播域、缩小广播域大小的功能。因为不同VLAN间是不能直接通信的,VLAN间的通信必须依靠三层路由,就像不同子网间的连接一样,所以VLAN也是不转播广播包的,可以起到缩小广播域的作用。 | ||
--> | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
## 中继器 (Repeater) | ||
|
||
通常中继器只有两个端口,只是简单的将一个端口收到的信号传送给另外一个,它并不知道所谓的 frame、packet 等,其主要作用是:1)扩展网络距离,将衰减信号经过再生;2)实现粗细同轴电缆以太网的互连。 | ||
|
||
现在中继器已经很少见了,主要是由于网桥提供了相似的功能,而且价格基本相似。 | ||
|
||
|
||
通过中继器虽然可以延长信号传输的距离、实现两个网段的互连。但并没有增加网络的可用带宽。如图2所示,网段1和网段2经过中继器连接后构成了一个单个的冲突域和广播域。<br><br> | ||
|
||
<center><img src="pictures/Concepts_Repeater.jpg" height="290" width="400"><br><br> | ||
<font face="arial" size="2">中继器连接的网络</font></center><br> | ||
</p> | ||
|
||
<br id="hub"><br><h2>集线器(HUB)</h2><p> | ||
集线器实际上相当于多端口的中继器,通常有8个、16个或24个等数量不等的接口。可以延长网络的通信距离,或连接物理结构不同的网络,但主要还是作为一个主机站点的汇聚点,将连接在集线器上各个接口上的主机联系起来使之可以互相通信。它的每个端口是分享带宽的,也就是说,要是100mb的hub,10个端口,那每个口就只有10mb的带宽。<br><br> | ||
|
||
如图3所示,所有主机都连接到中心节点的集线器上构成一个物理上的星型连接。但实际上,在集线器内部,各接口都是通过背板总线连接在一起的,在逻辑上仍构成一个共享的总线。因此,集线器和其所有接口所接的主机共同构成了一个冲突域和一个广播域。 | ||
|
||
<center><img src="pictures/Concepts_HUB.jpg" height="290" width="400"><br><br> | ||
<font face="arial" size="2">集线器连接的网络</font></center><br> | ||
</p> | ||
|
||
|
||
|
||
## 网桥 () | ||
|
||
|
||
<br id="bridge"><br><h2>网桥(Bridge)</h2><p> | ||
可以隔离冲突域,不能隔离广播域。<br><br> | ||
|
||
网桥(Bridge)又称为桥接器。和中继器类似,传统的网桥只有两个端口,用于连接不同的网段。和中继器不同的是,网桥具有一定的"智能"性,可以"学习"网络上主机的地址,同时具有信号过滤的功能。<br><br> | ||
|
||
如图4所示,网段1的主机A发给主机B的数据包不会被网桥转发到网段2。因为,网桥可以识别这是网段1内部的通信数据流。同样,网段2的主机X发给主机Y的数据包也不会被网桥转发到网段1。可见,网桥可以将一个冲突域分割为两个。其中,每个冲突域共享自己的总线信道带宽。<br><br> | ||
|
||
但是,如果主机C发送了一个目标是所有主机的广播类型数据包时,网桥要转发这样的数据包。网桥两侧的两个网段总线上的所有主机都要接收该广播数据包。因此,网段1和网段2仍属于同一个广播域。 | ||
|
||
<center><img src="pictures/collision_broadcast_domain/Concepts_Bridge.jpg" height="290" width="400"><br><br> | ||
<font face="arial" size="2">网桥连接的网络</font></center><br> | ||
</p> | ||
|
||
|
||
|
||
{% highlight c %} | ||
{% endhighlight %} |
Oops, something went wrong.