[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Jan. 13 2017

[hu . zhijiang]

Sorry for providing the agenda late.

1) Roll Call
2) OPNFV: Daisy CI Progress
3) OPNFV: Daisy Support Escalator
4) OpenStack: Kolla Image Versioning 
5) AoB

B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Cancelled: IRC meeting 0800UTC Jan. 6 2017

[hu . zhijiang]

Hi Team,

Due to there is no topic to be discussed, I suggest to cancel the meeting.

B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Dec. 16 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-12-16-07.59.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-12-16-07.59.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-12-16-07.59.log.html
 



B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Dec. 16 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Daisy CI Progress
3) OpenStack Version management
4) AoB

B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Dec. 9 2016

[hu . zhijiang]

1) Roll Call
2) Shanghai Telecom Support (Storage & Bare Metal) 
3) OPNFV: Daisy CI Progress
4) AoB

B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Dec. 2 2016

[hu . zhijiang]

1) Roll Call
2) China Telecom Support (Storage & Bare Metal) 
3) OPNFV: Daisy CI Progress
4) AoB


B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fw: Re: Re: [kolla] Obtaining version information for Docker container

[hu . zhijiang]

Adrian,

Thank you for the information.

B.R.,
Zhijiang




发件人: Adrian Mouat 
收件人: hu.zhiji...@zte.com.cn, 
抄送:   "OpenStack Development Mailing List (not for usage questions)" 

日期:   2016-12-01 23:49
主题:   Re: Re: [openstack-dev] [kolla] Obtaining version information for 
Docker container



You can get labels without pulling the full image (it's part of the 
metadata rather than the image itself. For example, Skopeo (
https://github.com/projectatomic/skopeo)  can do this:

./skopeo inspect docker://amouat/network-utils
{
"Name": "docker.io/amouat/network-utils",
"Digest": 
"sha256:fcb208490240b82af947a24b233cbc208ee9761035731bddbeb888bb33b71d14",
"RepoTags": [
"latest"
],
"Created": "2016-11-11T12:59:09.461996171Z",
"DockerVersion": "1.12.3",
"Labels": {
"org.label-schema.build-date": "2016-11-11 12:57:22+00:00",
"org.label-schema.docker.dockerfile": "/Dockerfile",
"org.label-schema.vcs-type": "Git",
"org.label-schema.vcs-url": "
https://github.com/amouat/network-utils-container;
},
"Architecture": "amd64",
"Os": "linux",
"Layers": [

"sha256:386a066cd84a33a04d560c42bef66d1dd64ebfc76de78550e5fd0f8d57778bca",

"sha256:44f8daaa54e7d5a2fc678d26ae691ab0f7c6a51bb7346fbdd581697f22b1a120",

"sha256:c6a1e73879c72e17e7a917b197d0927494f48f42bd560f2ff61ab8efa3814830"
]
}


On Thu, Dec 1, 2016 at 10:57 AM,  wrote:
For #1, I think the requirement is that before pulling the image to local
registry, one can get its metadata about the version info before hand,
thus save time and space spend on pulling wrong images. I don't know if
the info in docker label can be retrieved before before pulling the image
to local registry. If not, holding such info in docker label may be not a
good solution since we have to pull the image first.

Another thought is how about let the kolla build command to generate a
report about what component version it used to build for each image and
just let it output this report to a file or stdout? Then this well
formatted output can be published along with the images(docker save...)
but not inside of images.


B.R.,
Zhijiang




发件人: Pete Birley 
收件人: "OpenStack Development Mailing List (not for usage
questions)" , Adrian Mouat
,
日期:   2016-11-19 02:17
主题:   Re: [openstack-dev] [kolla] Obtaining version information for
Docker container



I've been thinking about this a bit as well, and think that we should
consider using the docker label schema (http://label-schema.org/rc1/) as a
solution for #1, it would be possible to add labeling to kolla-build to
add these labels simply. This solution is gaining traction in the docker
community, and integrates well with external tools e.g.
https://microbadger.com. One of the maintainers of this project (Adrian
Mouat) works in the same room as me and I've cc'd him in case he has any
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and
currently it is not possible to query labels from within a container. I
think Steve's suggestion of a simple shell tool to query the containers
package manager(s) and produce a report is probably the right way to go:
but we should draw up a specification that scoped what data we collected
in such a manifest as if we simply do the equivalent of 'rpm -qa' then I
think Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake) 
wrote:
Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider
audience.  I don’t have a clear solution to obtaining version manifests
for container content or the upstream container version.  Perhaps someone
in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run
with docker exec to obtain a proper version manifest of both 1 and 2
(formatted in YAML or plaintext).  This could be placed in the base
container image to enable a general diagnostic and certificate of origin
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake 
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running
container or image.
you know , the version info is wrapped by the container, it is not easy to
get them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by 

Re: [openstack-dev] [kolla] Obtaining version information for Docker container

[hu . zhijiang]

For #1, I think the requirement is that before pulling the image to local 
registry, one can get its metadata about the version info before hand, 
thus save time and space spend on pulling wrong images. I don't know if 
the info in docker label can be retrieved before before pulling the image 
to local registry. If not, holding such info in docker label may be not a 
good solution since we have to pull the image first. 

Another thought is how about let the kolla build command to generate a 
report about what component version it used to build for each image and 
just let it output this report to a file or stdout? Then this well 
formatted output can be published along with the images(docker save...) 
but not inside of images. 


B.R.,
Zhijiang




发件人: Pete Birley 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , Adrian Mouat 
, 
日期:   2016-11-19 02:17
主题:   Re: [openstack-dev] [kolla] Obtaining version information for 
Docker container



I've been thinking about this a bit as well, and think that we should 
consider using the docker label schema (http://label-schema.org/rc1/) as a 
solution for #1, it would be possible to add labeling to kolla-build to 
add these labels simply. This solution is gaining traction in the docker 
community, and integrates well with external tools e.g. 
https://microbadger.com. One of the maintainers of this project (Adrian 
Mouat) works in the same room as me and I've cc'd him in case he has any 
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and 
currently it is not possible to query labels from within a container. I 
think Steve's suggestion of a simple shell tool to query the containers 
package manager(s) and produce a report is probably the right way to go: 
but we should draw up a specification that scoped what data we collected 
in such a manifest as if we simply do the equivalent of 'rpm -qa' then I 
think Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake)  
wrote:
Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider 
audience.  I don’t have a clear solution to obtaining version manifests 
for container content or the upstream container version.  Perhaps someone 
in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run 
with docker exec to obtain a proper version manifest of both 1 and 2 
(formatted in YAML or plaintext).  This could be placed in the base 
container image to enable a general diagnostic and certificate of origin 
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake 
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running 
container or image.
you know , the version info is wrapped by the container, it is not easy to 
get them 
there are two type of versions 
one: version in a image, two: version in a running container 
two is easy, for example , we can get it by calling docker exec... 
but how to get the one, Is there any way, Thanks.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Pete Birley / Director 
pete@port.direct / +447446862551
PORT.DIRECT 
United Kingdom 
https://port.direct


This e-mail message may contain confidential or legally privileged 
information and is intended only for the use of the intended recipient(s). 
Any unauthorized disclosure, dissemination, distribution, copying or the 
taking of any action in reliance on the information herein is prohibited. 
E-mails are not secure and cannot be guaranteed to be error free as they 
can be intercepted, amended, or contain viruses. Anyone who communicates 
with us by e-mail is deemed to have accepted these risks. Port.direct is 
not responsible for errors or omissions in this message and denies any 
responsibility for any damage arising from the use of e-mail. Any opinion 
and other statement contained in this message and any attachment are 
solely those of the author and do not necessarily represent those of the 
company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] Question about OpenStack release model

[hu . zhijiang]

Hi All,

I'm running a project which is a OpenStack related project currently.

My questions is:　Is being part of Big Tent a requirement before a project 
can 
follow one of those 3 release models(cycle-with-milestones, 
cycle-with-intermediary, and cycle-trailing) as described in
http://docs.openstack.org/project-team-guide/release-management.html ？


Thank you

B.R.,
Zhijiang

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Nov. 25 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.log.html
 


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 25 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: CI Progress
3) OPNFV: Escalator Support
4) nominate Ya to be daisycloud-core core reviewer.
5) Newton

B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 18 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: CI Progress
4) Core Code Abstraction
5) Newton


B.R.,
Zhijiang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Nominating Ya Zhou for daisycloud-core reviewer

[hu . zhijiang]

Daisycloud-core team,

I'd like to nominate Ya Zhou(IRC name 'zhouya') for daisycloud-core core 
reviewer.

Ya started to work on Daisycloud-core since the beginning of the project 
and he has made significant contribution to project in last three months 
including adding Kolla backend, implementing extensible framework, etc. 
The most important work is introducing extensible framework to 
daisycloud-core, it makes our product a more open design to adapt more new 
technology such as bifrost, HWM, and any other third-party plugins. 

I have had a nice talk with him offline and he expressed willing to 
contribute more to daisycloud-core project and I believe he will make a 
great addition to the core review team.

So please put your +1 or -1 here no matter if you are core member or 
contributor. I will collect the result in seven days and use the majority 
voting policy to get the final result.

Thanks you so much!

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 11 2016

[hu . zhijiang]

Please feel free to add what you need to discuss.

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: CI Progress
4) Core Code Abstraction
5) Newton




B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Nov. 4 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-04-08.00.log.html
 


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 4 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 28 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction
5) Newton Release Related

Action items follow-up

1) Newton deployment

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 21 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.log.html
 



B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 21 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction
5) Newton Release Related

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 14 2016

[hu . zhijiang]

Meeting ended Fri Oct 14 08:58:52 2016 UTC.  Information about MeetBot at 
http://wiki.debian.org/MeetBot . (v 0.1.4) 
Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-14-08.02.log.html
 



B.R.,
Zhijiang




发件人: HuZhiJiang180967/user/zte_ltd
收件人: openstack-dev@lists.openstack.org, 
日期:   2016-10-15 10:05
主题:   [openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 
0800UTC Oct. 14 2016



B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 14 2016

[hu . zhijiang]

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 14 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Host Interface Configration Function Regression
5) Core Code Abstraction


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 30 2016

[hu . zhijiang]

1) Roll Call
2) Core Code Abstraction
3) Bifrost/Ironic Integration
4) OPNFV: Daisy4nfv CI Framework Progress
5) Bare Metal Deployment(PXE/IPMI) demo2 doc and artifact

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 30 2016

[hu . zhijiang]

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Sep. 23 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-23-07.59.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-23-07.59.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-23-07.59.log.html
 


Have a good weekend!

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 23 2016

[hu . zhijiang]

1) Roll Call
2) Core Code Abstraction
3) Bifrost/Ironic Integration
4) OPNFV: Daisy4nfv CI Framework Progress
5) Bare Metal Deployment(PXE/IPMI) Test


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 9 2016

[hu . zhijiang]

1) Roll Call
2) Unit Test Progress
3) Bifrost/Ironic Integration
4) OPNFV: Daisy4nfv CI Framework Progress
5) Bare Metal Deployment(PXE/IPMI) Status Update
6) Bare Metal Related DB Development Status Update



B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Sep. 2 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-02-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-02-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-09-02-08.00.log.html
 



B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 2 2016

[hu . zhijiang]

1) Roll Call
2) Unit Test
3) OPNFV: Daisy4nfv CI Framework Progress
4) Bare Metal Deployment(PXE/IPMI) Status Update
5) Bare Metal Related DB Development Status Update
6) Bifrost/Ironic Integration

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting Aug. 26 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-08-26-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-08-26-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-08-26-08.00.log.html
 






B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 26 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV CI Evolution Study Progress
3) Bare Metal Deployment(PXE/IPMI) Status Update
4) Bare Metal Related DB Deployment Status Update
5) Bifrost/Ironic Integration (does ironic provide all data we need)


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [bifrost] Question about the "nics" argument provide to ansible os_ironic module.

[hu . zhijiang]

Hi Bifrost Team,

>From the code study about Bifrost and Shade I found that the "nics" 
argument provide to ansible's os_ironic module is used for creating ports 
for a bare metal. I think it is related to neutron. But for bifrost which 
uses ironic in standalone mode, there is no need to create ports like 
this. So I don't know why we need to provide the "nics" argument. Is it 
optional or even shall be hidden from Bifrost user's eyes?

Thanks.

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 19 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV CI Evolution Study Progress
3) Bare Metal Deployment(PXE/IPMI) Status Update
4) Daisy Bare Metal Related DB Deployment Status Update
5) Bifrost/Ironic Integration


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: Re: [daisycloud-core] Daisy installer demo is out

[hu . zhijiang]

Hi Will,

Yes, Daisy needs httpd to drive the Web UI. And thanks for reminding to 
add httpd as Daisy's dependency.

About you said "daisy work in two VMs", I don't understand what you were 
meaning. Basically, you can put Daisy into one single VM to reduce the 
foot print impacted on the bare metal. I that case thers is no need to 
split Daisy into two part and put into "two VMs". 

But if you mean "if Dasiy can deploy OpenStack onto two VMs and setup HA", 
then you definitely can do that. But keep in mind that you may need to 
setup neutron to let your VMs to support more than one IPs on each port. 
For example, you might need to do this:
 
neutron port-update  --allowed_address_pairs list=true 
type=dict ip_address=192.168.0.2 ip_address=< An floating IP use for HA 
,such as 192.168.0.233>




B.R.,
Zhijiang




发件人: Will Zhou 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-08-16 11:35
主题:   Re: [openstack-dev] [daisycloud-core] Daisy installer demo is out



Hello Zhijiang,

I hit the following issue when trying to run 'installdaisy_el7_noarch.bin'

No package httpd available.
Error: Nothing to do
Failed to issue method call: No such file or directory
Failed to issue method call: Unit httpd.service failed to load: No such 
file or directory.
httpd start failed.


So we need to run 'yum install httpd' before it. Thanks.

BTW, can daisy work in two VMs? Thanks.



On Mon, Aug 15, 2016 at 10:44 AM  wrote:
Hi All,

Daisycloud-core team are pleased to annonce the first release of Daisy
OpenStack Installer. You can download the demo from
http://www.daisycloud.org/static/files/installdaisy_el7_noarch.bin. and
the corresponding document is here:
http://www.daisycloud.org/static/files/demo_how_to.docx

In this phase, Daisy OpenStack Installer is just a friendly web UI for
deploying openstack mitaka by using kolla. It will support baremetal
deployment by using ironic (also bifrost may be). To sum up, Daisy
installer are trying to make the most use of the upstream projects for
deploying OpenStack and make them easy to use.

Thanks!


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- 

-
​周正喜
Mobile: 13701280947
​WeChat: 472174291
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Daisy installer demo is out

[hu . zhijiang]

Hi All,

Daisycloud-core team are pleased to annonce the first release of Daisy 
OpenStack Installer. You can download the demo from 
http://www.daisycloud.org/static/files/installdaisy_el7_noarch.bin. and 
the corresponding document is here: 
http://www.daisycloud.org/static/files/demo_how_to.docx

In this phase, Daisy OpenStack Installer is just a friendly web UI for 
deploying openstack mitaka by using kolla. It will support baremetal 
deployment by using ironic (also bifrost may be). To sum up, Daisy 
installer are trying to make the most use of the upstream projects for 
deploying OpenStack and make them easy to use.

Thanks!


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 12 2016

[hu . zhijiang]

Sorry for publishing agenda so late.

1) Roll Call
2) Daisycloud: Daisy Demo and doc
3) Daisycloud: Ironic status update
4) Daisycloud: Get backend type by calling host_get_all()
5) Daisy4nfv: Related status update


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Question about kolla git tag

[hu . zhijiang]

Hi 

The image we built before is tagged automatically as 2.0.2. and now the 
kolla code has been upgrade to 2.0.3. I would like to ask if it is OK to 
use code 2.0.3 do deploy images 2.0.2, or we'd better to sync the version 
by using "git tag" command according to the image version? 

B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [daisycloud-core] Agenda for IRC meeting Aug. 5 2016

[hu . zhijiang]

Forgot to mentioned , the channel has been changed from #daisycloud to 
#openstack-meeting

B.R.,
Zhijiang




发件人: HuZhiJiang180967/user/zte_ltd
收件人: hu.zhiji...@zte.com.cn, huzhiji...@gmail.com, 
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn, 
kong.w...@zte.com.cn, janonymous.codevult...@gmail.com, 
WuWei10166727/user/zte_ltd@ZTE_LTD, jiang.zhif...@zte.com.cn, 
yangjian...@chinamobile.com, jianfei.zh...@nokia.com, 
suvendu.mi...@nokia.com, 
抄送:   "OpenStack Development Mailing List (not for usage questions)" 

日期:   2016-08-05 12:40
主题:   [openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 5 
2016


1) Roll Call
2) Daisy Call Graph doc and CI doc
3) Git tag sync between Kolla code and images
4) Getting backend type and its use cases
5) Image 2.0.3 login problem
6) Daisy4nfv related status update


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 5 2016

[hu . zhijiang]

1) Roll Call
2) Daisy Call Graph doc and CI doc
3) Git tag sync between Kolla code and images
4) Getting backend type and its use cases
5) Image 2.0.3 login problem
6) Daisy4nfv related status update


B.R.,
Zhijiang


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] IRC Meeting Log 20160722

[hu . zhijiang]

Hi Team,

About the daisy4nfv things we did not have time to discuss, I want to add 
that: I thought in the future, when we move to work with OPNFV world, we 
will still use this channel to discuss not only daisycloud but also 
daisy4nfv. I personaly do not want to maintain two meeting by myself. But 
your opinions are more than welcome.




20160722 Agenda
===
1) roll call
2) Agenda bashing
3) Approved Wei (kong.w...@zte.com.cn) as daisycloud core reviewer
4) daisycloud status update
5) daisy4nfv status update and disscussion in daisycloud channel


Log
===

? daisycloud-core project weekly meeting 
huzhj
Hello 
zhouya
hi 
→ lu has joined 
? lu is now known as Guest25493 
← Guest25493 has left 
huzhj
Yao is on the sick leave, so may be we can not reach her 
zhouya
ok 
huzhj
Let's wait for more people come online 
→ luyao has joined 
huzhj
OK 
Let's start 
→ King has joined 
← King has quit (Client Quit) 
huzhj
Today's agenda 
1) roll call 
2) Agenda bashing 
3) Approved Wei (kong.w...@zte.com.cn) as daisycloud core reviewer 
4) daisycloud status update 
5) daisy4nfv status update 
6) daisy4nfv disscussion in daisycloud channel 
1) roll call 
zhouya
o/ 
→ Sun has joined 
luyao
o/ 
huzhj
roll call is a convention that everyone write them name with a "+" as the 
preffix 
Sun
O/ 
huzhj
Next topic, Agenda bashing 
zhouya
+zhouya 
Sun
+sunjing 
luyao
+luyao 
huzhj
Agenda bashing is a way for modifing the agenda right before starting 
meeting 
so if you have anything to disscuss please feel free to ask me to add to 
the agenda list 
If nothing to modify, we will go to next topic 
Sun
Ok with me 
huzhj
Ok, next topic Approved Wei (kong.w...@zte.com.cn) as daisycloud core 
reviewer 
luyao
ok 
huzhj
As the result of the voting on the mailing list, Wei has successfully been 
approved as our core reviewer 
luyao
congratulation 
huzhj
Hope he can do more great jobs for the project in future :) 
congratulations! 
But he is not online ~~ 
Sun
congratulations 
zhouya
he is busy with tempest 
← luyao has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC 
client) 
zhouya
with my joy respectfully 
huzhj
Yes, our tempest is one the way, Wei will make it work for us soon. 
→ luyao has joined 
→ kongwei has joined 
kongwei
hi 
huzhj
We are still open for discuss about who will be and how he/she can be the 
next core reviewer 
Hi Wei 
We are talking about you. thanks for the great work on the tempest things 
Next topic 
4) daisycloud status update 
Same old way, do it in alphabet order 
huzhj
I wil be the first, keepalived/haproxy problem during kolla deploying has 
been solved 
the problem is that there are more than one clusters on our shared network 
using the same virtual_router_id in /etc/keepalived/keepalived.conf 
the virtual_router_id is choosed by kolla script which is a number 
beetween 0 and 255 
luyao
good 
huzhj
it is easy to conflicted , so the resolution is for us to not to use 
shared network to deploy many clusters at the same time. 
zhouya
OK 
huzhj
Next thing is that i have been cut off the size of kolla images tarball by 
simply build what we really needs 
Sun
the globals.yml give a default value 51 
huzhj
@Sun , good catch! 
luyao
we can set diff value by daisy 
zhouya
so modify globals.yml？ 
huzhj
Yes, that will be a greate help for our development atleast 
Sun
maybe wo can set diff value according ip of vm 
huzhj
Due to the time limit let's talk about it in more details offline 
The current list of images to build is as follows: 
luyao
ok 
huzhj
192.168.0.48:4000/kollaglue/centos-binary-neutron-openvswitch-agent 
192.168.0.48:4000/kollaglue/centos-binary-neutron-server 
192.168.0.48:4000/kollaglue/centos-binary-neutron-metadata-agent 
192.168.0.48:4000/kollaglue/centos-binary-neutron-dhcp-agent 
192.168.0.48:4000/kollaglue/centos-binary-neutron-l3-agent 
192.168.0.48:4000/kollaglue/centos-binary-nova-libvirt 
192.168.0.48:4000/kollaglue/centos-binary-nova-compute 
192.168.0.48:4000/kollaglue/centos-binary-nova-scheduler 
192.168.0.48:4000/kollaglue/centos-binary-nova-conductor 
192.168.0.48:4000/kollaglue/centos-binary-nova-novncproxy 
192.168.0.48:4000/kollaglue/centos-binary-nova-consoleauth 
192.168.0.48:4000/kollaglue/centos-binary-nova-ssh 
192.168.0.48:4000/kollaglue/centos-binary-nova-api 
192.168.0.48:4000/kollaglue/centos-binary-heat-api 
192.168.0.48:4000/kollaglue/centos-binary-heat-api-cfn 
192.168.0.48:4000/kollaglue/centos-binary-heat-engine 
192.168.0.48:4000/kollaglue/centos-binary-glance-api 
192.168.0.48:4000/kollaglue/centos-binary-glance-registry 
192.168.0.48:4000/kollaglue/centos-binary-horizon 
192.168.0.48:4000/kollaglue/centos-binary-keystone 
192.168.0.48:4000/kollaglue/centos-binary-openvswitch-db-server 
192.168.0.48:4000/kollaglue/centos-binary-openvswitch-vswitchd 
192.168.0.48:4000/kollaglue/centos-binary-heka 
192.168.0.48:4000/kollaglue/centos-binary-kolla-toolbox 
192.168.0.48:4000/kollaglue/centos-binary-rabbitmq 

[openstack-dev] [daisycloud-core] Today(20160722)'s weekly meeting agenda

[hu . zhijiang]

20160722 Agenda
1) roll call
2) Agenda bashing
3) Approved Wei (kong.w...@zte.com.cn) as daisycloud core reviewer
4) daisycloud status update
5) daisy4nfv status update
6) daisy4nfv disscussion in daisycloud channel





B.R.,
Zhijiang


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Why base image always be built each time build a specific image.

[hu . zhijiang]

Hi,

When I use the following command to build keystone image, I saw 
base/openstack-base image was built for the first time as the dependances, 
which is OK. 

kolla-build --registry 127.0.0.1:4000 --push keystone

But right after that, when I was building another image (for example 
rabbitmq), I saw base image was built again. Why that happend and is that 
necessary? Is there any way to keep the already built images to save 
building time? 


Thanks,
Zhijiang


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

[hu . zhijiang]

OK, we got a consensus.

I will add Wei as core committor soon.


B.R.,
Zhijiang




发件人: LuYao00184532/user/zte_ltd
收件人: HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 
抄送:   openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
zhou...@zte.com.cn, sun.jin...@zte.com.cn, kong.w...@zte.com.cn, 
janonymous.codevult...@gmail.com, WuWei10166727/user/zte_ltd@ZTE_LTD
日期:   2016-07-19 11:59
主题:   答复: [daisycloud-core] Nnominate Wei Kong as core for 
daisycloud-core project


+1





发件人: 胡智江180967/user/zte_ltd
收件人: openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn, 
kong.w...@zte.com.cn, janonymous.codevult...@gmail.com, 
WuWei10166727/user/zte_ltd@ZTE_LTD, HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 

日期:   2016/07/19 10:21
主题:   [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core 
project


Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

[hu . zhijiang]

Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.


B.R.,
Zhijiang



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

[hu . zhijiang]

Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [daisycloud-core] [kolla] Kolla Mitakarequirementssupported by CentOS

[hu . zhijiang]

Steve,

I agree with you on that Kolla can use EPEL, because Kolla is not a 
function part of OpenStack but a deployment tool. In the same vein, is 
that means Kolla do not need to catch up with the global requirements of 
OpenStack? For example, instead of using oslo required by OpenStack, can 
Kolla be more open to be compatible with an old oslo? This is a big deal 
because if installers such as daisycloud-core want to use Kolla as 
underlying deployment tool, they should keep the same requirements 
updating cadence as kolla, but sometimes that is not necessary for 
OpenStack installers. 




发件人: "Steven Dake (stdake)" 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-07-06 02:03
主题:   [probably forge email可能是仿冒邮件]Re: [openstack-dev] 
[daisycloud-core] [kolla] Kolla Mitakarequirementssupported by CentOS



Hu,

I am open to not using EPEL in the containers themselves.  I didn't even 
know all the dependencies were available without EPEL.  I am on vacation 
at present, but I'll try a build without EPEL and see if it actually 
builds correctly.  This does raise the question were ansible, docker, and 
git tools come from.  I am not keen to pull them from COPRs because I want 
them distributed via the CDN for HA purposes.

Are you planning to pull ansible, docker, and the git tools into 
delorean-deps?  One thing I am not keen on doing is yum install with an 
URL.

Also for source builds we absolutely require EPEL because we need gcc and 
other development tools.



As for the deployment host, we do require EPEL which is perfectly normal. 

From: "hu.zhiji...@zte.com.cn" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Monday, July 4, 2016 at 1:02 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka 
requirementssupported by CentOS

> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> It's proven very hard to prevent EPEL pushing broken updates, or push
> updates to fit OpenStack requirements.

> Actually, all the dependency above but ansible, docker and git python
> modules are in CentOS Cloud SIG repositories.
> If you are interested to work w/ CentOS Cloud SIG, we can add missing
> dependencies in our repositories.

I added [kolla] key word in the mail subject. Hope can get response from 
Kolla team about how to choose repos.


Thanks, 
Zhijiang 



发件人: Haïkel 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期: 2016-07-03 05:18
主题:[probably forge email可能是仿冒邮件]Re: [openstack-dev] 
[daisycloud-core] Kolla Mitaka requirementssupported by CentOS



2016-07-02 20:42 GMT+02:00 jason :
> Pip Package Name Supported By Centos CentOS Name Repo Name
> 
==
> ansible   yes
> ansible1.9.noarchepel
> docker-py  yes
> python-docker-py.noarchextras
> gitdb  yes
> python-gitdb.x86_64epel
> GitPython  yes
> GitPython.noarchepel
> oslo.config yes
> python2-oslo-config.noarch centos-openstack-mitaka
> pbryes
> python-pbr.noarch   epel
> setuptools yes
> python-setuptools.noarchbase
> six yes
> python-six.noarch base
> pycryptoyes
> python2-crypto  epel
> graphvizno
> Jinja2no (Note: Jinja2 2.7.2 will be installed as
> dependency by ansible)
>

As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
It's proven very hard to prevent EPEL pushing broken updates, or push
updates to fit OpenStack requirements.

Actually, all the dependency above but ansible, docker and git python
modules are in CentOS Cloud SIG repositories.
If you are interested to work w/ CentOS Cloud SIG, we can add missing
dependencies in our repositories.


>
> As above table shows, only two (graphviz and Jinja2) are not supported
> by centos currently. As those not supported packages are definitly not
> used by OpenStack as well as Daisy. So basicaly we can use pip to
> install them after installing other packages by yum. But note that
> Jinja2 2.7.2 will be installed as dependency while yum install
> ansible, so we need to using pip to install jinja2 2.8 after that to
> overide the old one. Also note that we must make sure pip is ONLY used
> for installing those two not supported packages.
>
> But before you trying to use pip, please consider these:
>
> 1) graphviz is just for 

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [daisycloud-core] Kolla Mitaka requirementssupported by CentOS

[hu . zhijiang]

Hi Haïkel

> Actually, all the dependency above but ansible, docker and git python
> modules are in CentOS Cloud SIG repositories.
> If you are interested to work w/ CentOS Cloud SIG, we can add missing
> dependencies in our repositories.

So currently Jinja2 version >= 2.8 is already in the  CentOS Cloud SIG 
repository. could you please point a way to get it? That will be a great 
help for us to use kolla, because currenly we are using fedora repo  
http://koji.fedoraproject.org/koji/packageinfo?packageID=6506 to get 
Jinja2 version >= 2.8, but we are sure that  CentOS Cloud SIG repository 
will be a more better choise than fedora repo.  




发件人: Haïkel 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-07-03 05:18
主题:   [probably forge email可能是仿冒邮件]Re: [openstack-dev] 
[daisycloud-core] Kolla Mitaka requirementssupported by CentOS



2016-07-02 20:42 GMT+02:00 jason :
> Pip Package Name Supported By Centos CentOS Name Repo Name
> 
==
> ansible   yes
> ansible1.9.noarchepel
> docker-py  yes
> python-docker-py.noarchextras
> gitdb  yes
> python-gitdb.x86_64epel
> GitPython  yes
> GitPython.noarchepel
> oslo.config yes
> python2-oslo-config.noarch centos-openstack-mitaka
> pbryes
> python-pbr.noarch   epel
> setuptools yes
> python-setuptools.noarchbase
> six yes
> python-six.noarch base
> pycryptoyes
> python2-crypto  epel
> graphvizno
> Jinja2no (Note: Jinja2 2.7.2 will be installed as
> dependency by ansible)
>

As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
It's proven very hard to prevent EPEL pushing broken updates, or push
updates to fit OpenStack requirements.

Actually, all the dependency above but ansible, docker and git python
modules are in CentOS Cloud SIG repositories.
If you are interested to work w/ CentOS Cloud SIG, we can add missing
dependencies in our repositories.


>
> As above table shows, only two (graphviz and Jinja2) are not supported
> by centos currently. As those not supported packages are definitly not
> used by OpenStack as well as Daisy. So basicaly we can use pip to
> install them after installing other packages by yum. But note that
> Jinja2 2.7.2 will be installed as dependency while yum install
> ansible, so we need to using pip to install jinja2 2.8 after that to
> overide the old one. Also note that we must make sure pip is ONLY used
> for installing those two not supported packages.
>
> But before you trying to use pip, please consider these:
>
> 1) graphviz is just for saving image depend graph text file and is not
> used by default and only used in build process if it is configured to
> be used.
>
> 2) Jinja2 rpm can be found at
> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
> think is suitable for CentOS. I have tested it.
>
> So, as far as Kolla deploy process concerned, there is no need to use
> pip to install graphviz and Jinja2. Further more, if we do not install
> Kolla either then we can get ride of pip totally!
>
> I encourage all of you to think about not using pip any more for
> Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
> may be overide back and force if not using them carefully. So not
> using pip will make things easier and make jump server more cleaner.
> Any ideas?
>
>
> Thanks,
> Zhijiang
>
> --
> Yours,
> Jason
>
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__

Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka requirementssupported by CentOS

[hu . zhijiang]

> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
> It's proven very hard to prevent EPEL pushing broken updates, or push
> updates to fit OpenStack requirements.

> Actually, all the dependency above but ansible, docker and git python
> modules are in CentOS Cloud SIG repositories.
> If you are interested to work w/ CentOS Cloud SIG, we can add missing
> dependencies in our repositories.

I added [kolla] key word in the mail subject. Hope can get response from 
Kolla team about how to choose repos.


Thanks,
Zhijiang



发件人: Haïkel 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-07-03 05:18
主题:   [probably forge email可能是仿冒邮件]Re: [openstack-dev] 
[daisycloud-core] Kolla Mitaka requirementssupported by CentOS



2016-07-02 20:42 GMT+02:00 jason :
> Pip Package Name Supported By Centos CentOS Name Repo Name
> 
==
> ansible   yes
> ansible1.9.noarchepel
> docker-py  yes
> python-docker-py.noarchextras
> gitdb  yes
> python-gitdb.x86_64epel
> GitPython  yes
> GitPython.noarchepel
> oslo.config yes
> python2-oslo-config.noarch centos-openstack-mitaka
> pbryes
> python-pbr.noarch   epel
> setuptools yes
> python-setuptools.noarchbase
> six yes
> python-six.noarch base
> pycryptoyes
> python2-crypto  epel
> graphvizno
> Jinja2no (Note: Jinja2 2.7.2 will be installed as
> dependency by ansible)
>

As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
It's proven very hard to prevent EPEL pushing broken updates, or push
updates to fit OpenStack requirements.

Actually, all the dependency above but ansible, docker and git python
modules are in CentOS Cloud SIG repositories.
If you are interested to work w/ CentOS Cloud SIG, we can add missing
dependencies in our repositories.


>
> As above table shows, only two (graphviz and Jinja2) are not supported
> by centos currently. As those not supported packages are definitly not
> used by OpenStack as well as Daisy. So basicaly we can use pip to
> install them after installing other packages by yum. But note that
> Jinja2 2.7.2 will be installed as dependency while yum install
> ansible, so we need to using pip to install jinja2 2.8 after that to
> overide the old one. Also note that we must make sure pip is ONLY used
> for installing those two not supported packages.
>
> But before you trying to use pip, please consider these:
>
> 1) graphviz is just for saving image depend graph text file and is not
> used by default and only used in build process if it is configured to
> be used.
>
> 2) Jinja2 rpm can be found at
> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
> think is suitable for CentOS. I have tested it.
>
> So, as far as Kolla deploy process concerned, there is no need to use
> pip to install graphviz and Jinja2. Further more, if we do not install
> Kolla either then we can get ride of pip totally!
>
> I encourage all of you to think about not using pip any more for
> Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
> may be overide back and force if not using them carefully. So not
> using pip will make things easier and make jump server more cleaner.
> Any ideas?
>
>
> Thanks,
> Zhijiang
>
> --
> Yours,
> Jason
>
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] 答复: [probably forge email可能是仿冒邮件] [kolla] version of python2-oslo-config

[hu . zhijiang]

Sorry I used the wrong branch of Kolla, in stable/Mitaka , Kolla only 
requires oslo-config ver 3.7




发件人: hu.zhiji...@zte.com.cn
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-06-28 19:34
主题:   [probably forge email可能是仿冒邮件][openstack-dev] [kolla] 
version of python2-oslo-config



Hi Kolla team, 

Base upon requirement.txt, Kolla needs oslo-config version 3.10. But 
CentOS Mitaka uses 3.9 ,which is 
python2-oslo-config-3.9.0-1.el7.noarch.rpm. 

I want to know if Kolla can also work on oslo-config-3.9.0. If it can, 
then will be a benefit because pip is conflict with rpm on 
python2-oslo-config package. For example, the rpm version has the ability 
to find config file in /usr/share/keystone/keystone-dist.conf but the pip 
version not. 


Thanks 
Zhijiang, 


ZTE Information Security Notice: The information contained in this mail 
(and any attachment transmitted herewith) is privileged and confidential 
and is intended for the exclusive use of the addressee(s).  If you are not 
an intended recipient, any disclosure, reproduction, distribution or other 
dissemination or use of the information contained is strictly prohibited. 
If you have received this mail in error, please delete it and notify us 
immediately.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] version of python2-oslo-config

[hu . zhijiang]

Hi Kolla team,

Base upon requirement.txt, Kolla needs oslo-config version 3.10. But 
CentOS Mitaka uses 3.9 ,which is 
python2-oslo-config-3.9.0-1.el7.noarch.rpm.

I want to know if Kolla can also work on oslo-config-3.9.0. If it can, 
then will be a benefit because pip is conflict with rpm on 
python2-oslo-config package. For example, the rpm version has the ability 
to find config file in /usr/share/keystone/keystone-dist.conf but the pip 
version not.


Thanks
Zhijiang,

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件] [kolla] reclaimed the kolla namespace on docker

[hu . zhijiang]

Could you please tell me how to get all Kolla images for Mitaka from 
Docker registry if I don't want to build them locally? 

Thank you
Zhijiang




发件人: "Steven Dake (stdake)" 
收件人: "openstack-dev@lists.openstack.org" 
, 
日期:   2016-06-14 06:27
主题:   [probably forge email可能是仿冒邮件][openstack-dev] [kolla] 
reclaimed the kolla namespace on docker



Hey folks,

Kuan Yi Ming @ Docker helped us reclaim the kolla namespace for our 
images.  If you are a core reviewer and would like access to push to the 
docker hub in the kolla namespace, please send me your email address 
offline with your interest.

Thanks
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] IRC weekly meeting logistics

[hu . zhijiang]

Hi Team,

Here is the IRC weekly meeting logistics: 
 

Weekly on Friday at 1200 UTC, You can check out your local time here: 
http://www.timeanddate.com/worldclock/fixedtime.html?hour=12=0=0
IRC channel: #daisycloud at freenode

So our first meeting will be on this friday (Jun 17). The Agenda mainly 
is:

1. Rollcall
2. Welcome Jaivish and everyone introduce him/herself, for the very first 
time over this IRC channel.
3. Daisy status update
4. Daisy for NFV update



Could anyone please help me to update logistics info as well as 
contributors info to https://wiki.openstack.org/wiki/Daisy ? Because I can 
not log into https://wiki.openstack.org any more, I dont know why, I think 
it is a problem of the wiki.openstack.org website. Every time I trying to 
login it show me a blank page, and if I refresh it, it shows error: "Nonce 
already used or out of range"   


Our current active contributor list

-
NameIRC Nick  Email
-
Zhijiang Hu huzhj hu.zhiji...@zte.com.cn
Jaivish Kothari janonymousjanonymous.codevult...@gmail.com 
Wei Kong  kong.w...@zte.com.cn
Yao Lulu.yao...@zte.com.cn
Ya Zhou   zhou...@zte.com.cn
Jing Sun  sun.jin...@zte.com.cn 


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Neutron][Kolla][ovs-discuss] error whenstarting neutron-openvswitch-agent service

[hu . zhijiang]

Hi Liyong,

I think may be that is a consequent. At least it is not the reason for the 
following error, 


2016-06-06 09:19:45.236 1 ERROR neutron.agent.ovsdb.impl_vsctl 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Unable to execute 
['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'--columns=type', 'list', 'Interface', 'int-br-ex']. Exception: Exit code: 
1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: no row "int-br-ex" in table 
Interface 

because with those interfaces down, i can still execute 

ovs-vsctl --timeout=10 --oneline --format=json -- --columns=type 
list Interface int-br-ex

 successfully manually.


Thank you,
Zhijiang



发件人: "Qiao, Liyong" 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2016-06-06 23:01
主题:   [probably forge email可能是仿冒邮件]Re: [openstack-dev] 
[Neutron][Kolla][ovs-discuss] error whenstarting neutron-openvswitch-agent 
service



6: ovs-system:  mtu 1500 qdisc noop state DOWN 
link/ether 3e:c8:1d:8e:b5:5b brd ff:ff:ff:ff:ff:ff 
7: br-ex:  mtu 1500 qdisc noop state DOWN 
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff 
8: br-int:  mtu 1500 qdisc noop state DOWN 
link/ether 32:0d:72:8d:d6:42 brd ff:ff:ff:ff:ff:ff 
9: br-tun:  mtu 1500 qdisc noop state DOWN 
link/ether ea:d4:72:22:e2:4f brd ff:ff:ff:ff:ff:ff
 
 
I noted that these devices are not in UP state, you’d better to check 
them first.
 
Best Regards,
Qiao, Liyong (Eli) OTC SSG Intel

此致
敬礼！
英特尔（中国）有限公司软件与服务部开源技术中心 乔立勇
 
 
 
From: hu.zhiji...@zte.com.cn [mailto:hu.zhiji...@zte.com.cn] 
Sent: Monday, June 06, 2016 6:54 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][Kolla][ovs-discuss] error when starting 
neutron-openvswitch-agent service
 
Hi Guys, 

I am new to Neutron Kolla and OVS, I was trying to deploy Mitaka on 
CeontOS in a all-in-one environment using Kolla. After a successful 
deploying I realized that I should disable NetworkManager service roughly 
according to: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/3/html/Installation_and_Configuration_Guide/Disabling_Network_Manager.html
 


But when I disabled NetworkManager and restarted network service (probably 
host machine also restarted), I cannot ping from my gateway through the 
external interface. 

Here is the relevant log of ovs:   

2016-06-06 09:19:37.278 1 INFO neutron.common.config [-] Logging enabled! 
2016-06-06 09:19:37.283 1 INFO neutron.common.config [-] 
/usr/bin/neutron-openvswitch-agent version 8.0.0 
2016-06-06 09:19:43.035 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Mapping physical 
network physnet1 to bridge br-ex 
2016-06-06 09:19:45.236 1 ERROR neutron.agent.ovsdb.impl_vsctl 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Unable to execute 
['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'--columns=type', 'list', 'Interface', 'int-br-ex']. Exception: Exit code: 
1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: no row "int-br-ex" in table 
Interface 

2016-06-06 09:19:49.979 1 INFO neutron.agent.l2.extensions.manager 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Loaded agent 
extensions: [] 
2016-06-06 09:19:52.185 1 WARNING neutron.agent.securitygroups_rpc 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Firewall driver 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver 
doesn't accept integration_bridge parameter in __init__(): __init__() got 
an unexpected keyword argument 'integration_bridge' 
2016-06-06 09:19:53.204 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Agent initialized 
successfully, now running... 
2016-06-06 09:19:53.733 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Configuring tunnel 
endpoints to other OVS agents



I use enp0s35 as both the VIP interface and the external interface because 
the host only has one interface... 



Here is the ip addr  result before the deployment of enp0s35: 

2: enp0s25:  mtu 1500 qdisc pfifo_fast 
state UP qlen 1000 
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff 
inet 10.43.114.40/24 brd 10.43.114.255 scope global dynamic enp0s25 
   valid_lft 10429sec preferred_lft 10429sec 
inet6 fe80::1e6f:65ff:fe05:3711/64 scope link 
   valid_lft forever preferred_lft forever 


Here is the ip addr result after the deployment 

2: enp0s25:  mtu 1500 qdisc pfifo_fast 
master ovs-system state UP qlen 1000 
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff 
 

[openstack-dev] [Neutron][Kolla][ovs-discuss] error when starting neutron-openvswitch-agent service

[hu . zhijiang]

Hi Guys,

I am new to Neutron Kolla and OVS, I was trying to deploy Mitaka on 
CeontOS in a all-in-one environment using Kolla. After a successful 
deploying I realized that I should disable NetworkManager service roughly 
according to: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/3/html/Installation_and_Configuration_Guide/Disabling_Network_Manager.html

But when I disabled NetworkManager and restarted network service (probably 
host machine also restarted), I cannot ping from my gateway through the 
external interface.

Here is the relevant log of ovs: 

2016-06-06 09:19:37.278 1 INFO neutron.common.config [-] Logging enabled!
2016-06-06 09:19:37.283 1 INFO neutron.common.config [-] 
/usr/bin/neutron-openvswitch-agent version 8.0.0
2016-06-06 09:19:43.035 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Mapping physical 
network physnet1 to bridge br-ex
2016-06-06 09:19:45.236 1 ERROR neutron.agent.ovsdb.impl_vsctl 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Unable to execute 
['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'--columns=type', 'list', 'Interface', 'int-br-ex']. Exception: Exit code: 
1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: no row "int-br-ex" in table 
Interface

2016-06-06 09:19:49.979 1 INFO neutron.agent.l2.extensions.manager 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Loaded agent 
extensions: []
2016-06-06 09:19:52.185 1 WARNING neutron.agent.securitygroups_rpc 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Firewall driver 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver 
doesn't accept integration_bridge parameter in __init__(): __init__() got 
an unexpected keyword argument 'integration_bridge'
2016-06-06 09:19:53.204 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Agent initialized 
successfully, now running...
2016-06-06 09:19:53.733 1 INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-5b36-4eae-45d0-8240-ed9e76b04a73 - - - - -] Configuring tunnel 
endpoints to other OVS agents



I use enp0s35 as both the VIP interface and the external interface because 
the host only has one interface...



Here is the ip addr  result before the deployment of enp0s35:

2: enp0s25:  mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff
inet 10.43.114.40/24 brd 10.43.114.255 scope global dynamic enp0s25
   valid_lft 10429sec preferred_lft 10429sec
inet6 fe80::1e6f:65ff:fe05:3711/64 scope link
   valid_lft forever preferred_lft forever


Here is the ip addr result after the deployment

2: enp0s25:  mtu 1500 qdisc pfifo_fast 
master ovs-system state UP qlen 1000
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff
inet 10.43.114.40/24 brd 10.43.114.255 scope global dynamic enp0s25
   valid_lft 7846sec preferred_lft 7846sec
inet 10.43.114.149/32 scope global enp0s25
   valid_lft forever preferred_lft forever
inet6 fe80::1e6f:65ff:fe05:3711/64 scope link
   valid_lft forever preferred_lft forever
6: ovs-system:  mtu 1500 qdisc noop state DOWN
link/ether 3e:c8:1d:8e:b5:5b brd ff:ff:ff:ff:ff:ff
7: br-ex:  mtu 1500 qdisc noop state DOWN
link/ether 1c:6f:65:05:37:11 brd ff:ff:ff:ff:ff:ff
8: br-int:  mtu 1500 qdisc noop state DOWN
link/ether 32:0d:72:8d:d6:42 brd ff:ff:ff:ff:ff:ff
9: br-tun:  mtu 1500 qdisc noop state DOWN
link/ether ea:d4:72:22:e2:4f brd ff:ff:ff:ff:ff:ff


Please help to see how to locate solve such kind of problem, many thanks!


Zhijiang



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About kolla-ansible reconfigure

[hu . zhijiang]

Hi Steven,


Thanks for the information. Some further questions:

> Reconfigure was not designed to handle changes to globals.yml.  I think 
its a good goal that it should be able to do so, but it does not today.

So waht is the prefered method to change kolla_internal_vip_address and 
make it effective?

> Reconfigure was designed to handle changes to /etc/kolla/config/* (where 
custom config for services live).  Reconfigure in its current incarnation 
in all our branches and master is really a misnomer �C it should be 
service-reconfgiure �C but that is wordy and we plan to make globals.yml 
reconfigurable if feasible �C but probably not anytime soon.

There is no /etc/kolla/config/* located in my env before or after 
successful deployment. Is that right? 





发件人: "Steven Dake (stdake)" 
收件人: "openstack-dev@lists.openstack.org" 
, 
日期:   2016-06-03 06:16
主题:   [probably forge email可能是仿冒邮件]Re: [openstack-dev] [Kolla] 
About kolla-ansible reconfigure



Hu,

Reconfigure was not designed to handle changes to globals.yml.  I think 
its a good goal that it should be able to do so, but it does not today.

Reconfigure was designed to handle changes to /etc/kolla/config/* (where 
custom config for services live).  Reconfigure in its current incarnation 
in all our branches and master is really a misnomer �C it should be 
service-reconfgiure �C but that is wordy and we plan to make globals.yml 
reconfigurable if feasible �C but probably not anytime soon.

Regards
-steve


From: "hu.zhiji...@zte.com.cn" 
Reply-To: "openstack-dev@lists.openstack.org" <
openstack-dev@lists.openstack.org>
Date: Wednesday, June 1, 2016 at 6:24 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [Kolla] About kolla-ansible reconfigure

Hi 

After modifying the kolla_internal_vip_address in /etc/kolla/global.yml , 
I use kolla-ansible reconfigure to reconfigure OpenStack. But I got the 
following error.

TASK: [mariadb | Restart containers] 
**
skipping: [localhost] => (item=[{'group': 'mariadb', 'name': 'mariadb'}, 
{'KOLLA_BASE_DISTRO': 'centos', 'PS1': '$(tput bold)($(printenv 
KOLLA_SERVICE_NAME))$(tput sgr0)[$(id -un)@$(hostname -s) $(pwd)]$ ', 
'KOLLA_INSTALL_TYPE': 'binary', 'changed': False, 'item': {'group': 
'mariadb', 'name': 'mariadb'}, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 
'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 
'invocation': {'module_name': u'kolla_docker', 'module_complex_args': 
{'action': 'get_container_env', 'name': u'mariadb'}, 'module_args': ''}, 
'KOLLA_SERVICE_NAME': 'mariadb', 'KOLLA_INSTALL_METATYPE': 'rdo'}, {'cmd': 
['docker', 'exec', 'mariadb', '/usr/local/bin/kolla_set_configs', 
'--check'], 'end': '2016-06-02 11:32:18.866276', 'stderr': 
'INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json\nINFO:__main__:Validating config 
file\nINFO:__main__:The config files are in the expected state', 'stdout': 
u'', 'item': {'group': 'mariadb', 'name': 'mariadb'}, 'changed': False, 
'rc': 0, 'failed': False, 'warnings': [], 'delta': '0:00:00.075316', 
'invocation': {'module_name': u'command', 'module_complex_args': {}, 
'module_args': u'docker exec mariadb /usr/local/bin/kolla_set_configs 
--check'}, 'stdout_lines': [], 'failed_when_result': False, 'start': 
'2016-06-02 11:32:18.790960'}]) 

TASK: [mariadb | Waiting for MariaDB service to be ready through VIP] 
*
failed: [localhost] => {"attempts": 6, "changed": false, "cmd": ["docker", 
"exec", "mariadb", "mysql", "-h", "10.43.114.148/24", "-u", "haproxy", 
"-e", "show databases;"], "delta": "0:00:03.924516", "end": "2016-06-02 
11:33:57.928139", "failed": true, "rc": 1, "start": "2016-06-02 
11:33:54.003623", "stdout_lines": [], "warnings": []}
stderr: ERROR 2005 (HY000): Unknown MySQL server host '10.43.114.148/24' 
(-2)
msg: Task failed as maximum retries was encountered

FATAL: all hosts have already failed -- aborting


It seems that mariadb was not restart as expected.



ZTE Information Security Notice: The information contained in this mail 
(and any attachment transmitted herewith) is privileged and confidential 
and is intended for the exclusive use of the addressee(s).  If you are not 
an intended recipient, any disclosure, reproduction, distribution or other 
dissemination or use of the information contained is strictly prohibited. 
If you have received this mail in error, please delete it and notify us 
immediately.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kolla] About kolla-ansible reconfigure

[hu . zhijiang]

Hi 

After modifying the kolla_internal_vip_address in /etc/kolla/global.yml , 
I use kolla-ansible reconfigure to reconfigure OpenStack. But I got the 
following error.

TASK: [mariadb | Restart containers] 
**
skipping: [localhost] => (item=[{'group': 'mariadb', 'name': 'mariadb'}, 
{'KOLLA_BASE_DISTRO': 'centos', 'PS1': '$(tput bold)($(printenv 
KOLLA_SERVICE_NAME))$(tput sgr0)[$(id -un)@$(hostname -s) $(pwd)]$ ', 
'KOLLA_INSTALL_TYPE': 'binary', 'changed': False, 'item': {'group': 
'mariadb', 'name': 'mariadb'}, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 
'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 
'invocation': {'module_name': u'kolla_docker', 'module_complex_args': 
{'action': 'get_container_env', 'name': u'mariadb'}, 'module_args': ''}, 
'KOLLA_SERVICE_NAME': 'mariadb', 'KOLLA_INSTALL_METATYPE': 'rdo'}, {'cmd': 
['docker', 'exec', 'mariadb', '/usr/local/bin/kolla_set_configs', 
'--check'], 'end': '2016-06-02 11:32:18.866276', 'stderr': 
'INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json\nINFO:__main__:Validating config 
file\nINFO:__main__:The config files are in the expected state', 'stdout': 
u'', 'item': {'group': 'mariadb', 'name': 'mariadb'}, 'changed': False, 
'rc': 0, 'failed': False, 'warnings': [], 'delta': '0:00:00.075316', 
'invocation': {'module_name': u'command', 'module_complex_args': {}, 
'module_args': u'docker exec mariadb /usr/local/bin/kolla_set_configs 
--check'}, 'stdout_lines': [], 'failed_when_result': False, 'start': 
'2016-06-02 11:32:18.790960'}])

TASK: [mariadb | Waiting for MariaDB service to be ready through VIP] 
*
failed: [localhost] => {"attempts": 6, "changed": false, "cmd": ["docker", 
"exec", "mariadb", "mysql", "-h", "10.43.114.148/24", "-u", "haproxy", 
"-e", "show databases;"], "delta": "0:00:03.924516", "end": "2016-06-02 
11:33:57.928139", "failed": true, "rc": 1, "start": "2016-06-02 
11:33:54.003623", "stdout_lines": [], "warnings": []}
stderr: ERROR 2005 (HY000): Unknown MySQL server host '10.43.114.148/24' 
(-2)
msg: Task failed as maximum retries was encountered

FATAL: all hosts have already failed -- aborting


It seems that mariadb was not restart as expected.

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Call for Commiters & Contributors for daisycloud-core project

[hu . zhijiang]

Hi All,

I would like to introduce to you a new OpenStack installer project 
Daisy(project name: daisycloud-core). Daisy used to be a closed source 
project mainly developed by ZTE, but currently we make it a OpenStack 
related project(http://www.daisycloud.org, 
https://github.com/openstack/daisycloud-core). 

Although it is not mature and still under development, Daisy concentrates 
on deploying OpenStack fast and efficiently for large data center which 
has hundreds of nodes. In order to reach that goal, Daisy was born to 
focus on many features that may not be suitable for small clusters, but 
definitely conducive to the deployment of big clusters. Those features 
include but not limited to the following: 

1. Containerized OpenStack Services 
In order to speed up installation and upgrading as a whole, Daisy decides 
to use Kolla as underlying deployment module to support containerized 
OpenStack services. 

2. Multicast 
Daisy utilizes multicast as much as possible to speed up imaging work flow 
during the installation. For example, instead of using centralized Docker 
registry while adopting Kolla, Daisy multicasts all Docker images to each 
node of the cluster, then creates and uses local registries on each node 
during Kolla deployment process. The Same things can be done for OS 
imaging too. 

3. Automatic Deployment 
Instead of letting users decide if a node can be provisioned and deserved 
to join to the cluster, Daisy provide a characteristics matching mechanism 
to recognize if a new node has the same capabilities as a current working 
computer nodes. If it is true, Daisy will start deployment on that node 
right after it is discovered and make it a computer node with the same 
configuration as that current working computer nodes. 

4. Configuration Template 
Using precise configuration file to describe a big dynamic cluster is not 
applicable, and it is not able to be reused when moving to another 
approximate environment either. Daisy’s configuration template only 
describes the common part of the cluster and the representative of the 
controller/compute nodes. It can be seen as a semi-finished configuration 
file which can be used in any approximate environments. During deployment, 
users only have to evaluate few specific parameters to make the 
configuration template a final configuration file. 

5. Your comments on anything else that can brings unique value to the 
large data center deployment? 

As the project lead, I would like to get feedback from you about this new 
project. You are more than welcome to join this project! 

Thank you 
Zhijiang


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] How to get prebuilt all images from dockerhub for a specific tag

[hu . zhijiang]

Hi, Kolla fellows,

The latest quickstart.rst says:

"the `dockerhub image registry https://hub.docker.com/u/kollaglue/`__ 
contains all images from each of Kolla’s major releases. "


So I decided to get images from above URL to save time for building them. 
But when I trying to get the all images from it with tag 2.0.0, I got the 
following error:

# docker pull hub.docker.com/u/kollaglue:2.0.0
Pulling repository hub.docker.com/u/kollaglue
invalid character '<' looking for beginning of value

Please help about this problem.


Thanks
Zhijiang
 


 


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] How to contribute to kolla

[hu . zhijiang]

Hi all kolla fellows,

Previously, I managed submit a code review to kolla repo but now I 
couldn't. Do I need additional rights or configurations? Below is my git 
remote -a output:

gerrit  https://hu...@review.openstack.org/openstack/kolla.git (fetch)
gerrit  https://hu...@review.openstack.org/openstack/kolla.git (push)
origin  https://hu...@review.openstack.org/openstack/kolla (fetch)
origin  https://hu...@review.openstack.org/openstack/kolla (push)

Please help to take look at this. 


Many thanks!

Zhijiang 

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Kolla rpm distribution

[hu . zhijiang]

Hi，

One of our application would like to use Kolla as an upstream deployment 
tools. As the application may run in the environment without internet 
connections, we are trying to packaging Kolla as well as its requirements, 
such as jinja2, into rpm packages and deliver them along with the 
application. We would like to get some advises about: 
1) Is it the right way to go for our application to build rpms for 
upstream python packages?
2) Is there any plan for Kolla project to implement rpm packaging. As we 
are working on that, I think we can do some contributions. 


Thank you,
Zhijiang

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [kolla] centos-binary-neutron-openvswitch-agent

[hu . zhijiang]

Hi Jeffrey,

Here is the output:

[root@forimg tools]# docker logs neutron_openvswitch_agent
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Removing existing destination: /etc/neutron/neutron.conf
INFO:__main__:Copying /var/lib/kolla/config_files/neutron.conf to 
/etc/neutron/neutron.conf
INFO:__main__:Setting permissions for /etc/neutron/neutron.conf
INFO:__main__:Removing existing destination: 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Copying /var/lib/kolla/config_files/ml2_conf.ini to 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Setting permissions for 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Writing out command to execute
Running command: 'neutron-openvswitch-agent --config-file 
/etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini'
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, 
so please use SIGUSR2 to generate reports.
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Removing existing destination: /etc/neutron/neutron.conf
INFO:__main__:Copying /var/lib/kolla/config_files/neutron.conf to 
/etc/neutron/neutron.conf
INFO:__main__:Setting permissions for /etc/neutron/neutron.conf
INFO:__main__:Removing existing destination: 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Copying /var/lib/kolla/config_files/ml2_conf.ini to 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Setting permissions for 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Writing out command to execute
Running command: 'neutron-openvswitch-agent --config-file 
/etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini'
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, 
so please use SIGUSR2 to generate reports.
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Removing existing destination: /etc/neutron/neutron.conf
INFO:__main__:Copying /var/lib/kolla/config_files/neutron.conf to 
/etc/neutron/neutron.conf
INFO:__main__:Setting permissions for /etc/neutron/neutron.conf
INFO:__main__:Removing existing destination: 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Copying /var/lib/kolla/config_files/ml2_conf.ini to 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Setting permissions for 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Writing out command to execute
Running command: 'neutron-openvswitch-agent --config-file 
/etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini'
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, 
so please use SIGUSR2 to generate reports.
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Removing existing destination: /etc/neutron/neutron.conf
INFO:__main__:Copying /var/lib/kolla/config_files/neutron.conf to 
/etc/neutron/neutron.conf
INFO:__main__:Setting permissions for /etc/neutron/neutron.conf
INFO:__main__:Removing existing destination: 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Copying /var/lib/kolla/config_files/ml2_conf.ini to 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Setting permissions for 
/etc/neutron/plugins/ml2/ml2_conf.ini
INFO:__main__:Writing out command to execute
Running command: 'neutron-openvswitch-agent --config-file 
/etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini'
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, 
so please use SIGUSR2 to generate reports.
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Loading config file at 
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Copying service configuration files
INFO:__main__:Removing existing destination: /etc/neutron/neutron.conf
INFO:__main__:Copying /var/lib/kolla/config_files/neutron.conf to 
/etc/neutron/neutron.conf
INFO:__main__:Setting permissions for /etc/neutron/neutron.conf
INFO:__main__:Removing existing destination: 
/etc/neutron/plugins/ml2/ml2_conf.ini

[openstack-dev] [kolla] centos-binary-neutron-openvswitch-agent

[hu . zhijiang]

Hi,

After I deployed OpenStack with Kolla the first time, I found that the 
centos-binary-neutron-openvswitch-agent container mainly in restarting 
status. Is it OK? Or can you show me some way on how to figure out and 
resolve this kind of problems?

Many thanks!


 

[root@forimg tools]# docker ps -a
CONTAINER IDIMAGE   COMMAND CREATED STATUS
PORTSNAMES
c621cc7beece127.0.0.1:4000/kollaglue/centos-binary-horizon:2.0.0   
   "kolla_start"26 minutes ago  Up 26 minutes  
 horizon
bf5575103f79 127.0.0.1:4000/kollaglue/centos-binary-heat-engine:2.0.0
"kolla_start"26 minutes ago  Up 26 minutes   heat_engine
5bcd73d19c47 127.0.0.1:4000/kollaglue/centos-binary-heat-api-cfn:2.0.0 
 "kolla_start"27 minutes ago  Up 27 minutes   heat_api_cfn
9917bebc92d7127.0.0.1:4000/kollaglue/centos-binary-heat-api:2.0.0  
 "kolla_start"27 minutes ago  Up 27 
minutesheat_api
9ad29113f48b 
127.0.0.1:4000/kollaglue/centos-binary-neutron-metadata-agent:2.0.0 
"kolla_start"29 minutes ago  Up 29 minutes   
neutron_metadata_agent
eb468e2c4c01 127.0.0.1:4000/kollaglue/centos-binary-neutron-l3-agent:2.0.0 
   "kolla_start"29 minutes ago  Up 29 minutes  
   neutron_l3_agent
51c941ac788a 
127.0.0.1:4000/kollaglue/centos-binary-neutron-dhcp-agent:2.0.0 
"kolla_start"29 minutes ago  Up 29 minutes   
neutron_dhcp_agent
8e30f48bd0c9 
127.0.0.1:4000/kollaglue/centos-binary-neutron-openvswitch-agent:2.0.0 
"kolla_start"29 minutes ago  Restarting (1) 25 seconds ago 
   neutron_openvswitch_agent
d7ab869e2494 127.0.0.1:4000/kollaglue/centos-binary-neutron-server:2.0.0   
"kolla_start"29 minutes ago  Up 29 minutes
neutron_server
7a39cdca36ba 
127.0.0.1:4000/kollaglue/centos-binary-openvswitch-vswitchd:2.0.0 
"kolla_start"29 minutes ago  Up 29 minutes   
openvswitch_vswitchd
379f808c6b7a 
127.0.0.1:4000/kollaglue/centos-binary-openvswitch-db-server:2.0.0 
"kolla_start"29 minutes ago  Up 29 minutes   
openvswitch_db
4b0f92e0d075127.0.0.1:4000/kollaglue/centos-binary-nova-ssh:2.0.0  
 "kolla_start"32 minutes ago  Up 32 
minutesnova_ssh
2ddae40d5543 127.0.0.1:4000/kollaglue/centos-binary-nova-compute:2.0.0 
 "kolla_start"32 minutes ago  Up 32 minutes   nova_compute
2bc3e1678bed 127.0.0.1:4000/kollaglue/centos-binary-nova-libvirt:2.0.0 
 "kolla_start"32 minutes ago  Up 32 minutes   nova_libvirt
b38c5ff13a4b 127.0.0.1:4000/kollaglue/centos-binary-nova-conductor:2.0.0   
"kolla_start"32 minutes ago  Up 32 minutes
nova_conductor
65d016a4900e 127.0.0.1:4000/kollaglue/centos-binary-nova-scheduler:2.0.0   
"kolla_start"32 minutes ago  Up 32 minutes
nova_scheduler
83d17df95a55 127.0.0.1:4000/kollaglue/centos-binary-nova-novncproxy:2.0.0  
  "kolla_start"32 minutes ago  Up 32 minutes   
nova_novncproxy
dea09147f370 127.0.0.1:4000/kollaglue/centos-binary-nova-consoleauth:2.0.0 
   "kolla_start"32 minutes ago  Up 32 minutes  
   nova_consoleauth
575d167ff64a127.0.0.1:4000/kollaglue/centos-binary-nova-api:2.0.0  
 "kolla_start"32 minutes ago  Up 32 
minutesnova_api
39e45462ed49 127.0.0.1:4000/kollaglue/centos-binary-glance-api:2.0.0   
"kolla_start"36 minutes ago  Up 36 minutes   glance_api
3bc5492a5bb1 127.0.0.1:4000/kollaglue/centos-binary-glance-registry:2.0.0  
  "kolla_start"36 minutes ago  Up 36 minutes   
glance_registry
10cbe341814f127.0.0.1:4000/kollaglue/centos-binary-keystone:2.0.0  
 "kolla_start"38 minutes ago  Up 38 
minuteskeystone
210c5ee382ca127.0.0.1:4000/kollaglue/centos-binary-rabbitmq:2.0.0  
 "kolla_start"39 minutes ago  Up 39 
minutesrabbitmq
6165a4ffbb52127.0.0.1:4000/kollaglue/centos-binary-mariadb:2.0.0   
   "kolla_start"About an hour ago   Up About an 
hour mariadb
ef0be084b4f6127.0.0.1:4000/kollaglue/centos-binary-memcached:2.0.0 
  "kolla_start"About an hour ago   Up About an 
hour memcached
2d88c7182503 127.0.0.1:4000/kollaglue/centos-binary-keepalived:2.0.0   
"kolla_start"

[openstack-dev] [kolla] How to get rpm locally during kolla build

[hu . zhijiang]

Hi,

I have network problem, it is unstable. Then `kolla-build --registry 
127.0.0.1:4000 --push ` always fail when building openstack-base  image 
like this:


INFO:kolla.cmd.build:openstack-base:
INFO:kolla.cmd.build:openstack-base:Install  132 Packages (+8 Dependent 
packages)
INFO:kolla.cmd.build:openstack-base:Total download size: 25 M
INFO:kolla.cmd.build:openstack-base:Installed size: 112 M
INFO:kolla.cmd.build:openstack-base:Downloading packages:
INFO:kolla.cmd.build:openstack-base:
http://trunk.rdoproject.org/centos7/ec/48/ec4848b9f0db227fdd03afd7e711d4c50d4af1fd_6112694a/python-manilaclient-1.7.1-0.20160303212256.eb1fde5.el7.centos.noarch.rpm:
 
[Errno 14] curl#56 - "Recv failure: Connection reset by peer"
INFO:kolla.cmd.build:openstack-base:Trying other mirror.
INFO:kolla.cmd.build:openstack-base:
INFO:kolla.cmd.build:openstack-base:
http://trunk.rdoproject.org/centos7/ec/48/ec4848b9f0db227fdd03afd7e711d4c50d4af1fd_6112694a/python-glanceclient-1.2.1-0.20160229192748.22a03fd.el7.centos.noarch.rpm:
 
[Errno 12] Timeout on 
http://trunk.rdoproject.org/centos7/ec/48/ec4848b9f0db227fdd03afd7e711d4c50d4af1fd_6112694a/python-glanceclient-1.2.1-0.20160229192748.22a03fd.el7.centos.noarch.rpm:
 
(28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 
seconds')
INFO:kolla.cmd.build:openstack-base:Trying other mirror.
INFO:kolla.cmd.build:openstack-base:
INFO:kolla.cmd.build:openstack-base:
http://trunk.rdoproject.org/centos7/ec/48/ec4848b9f0db227fdd03afd7e711d4c50d4af1fd_6112694a/python-novaclient-3.3.1-0.20160303082753.d63800d.el7.centos.noarch.rpm:
 
[Errno 14] curl#56 - "Recv failure: Connection reset by peer"
INFO:kolla.cmd.build:openstack-base:Trying other mirror.



I wonder if there is any way to put those rpms into local directory then 
the network problem can be work around.

Thanks!

B.R.,

Zhijiang.


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev