Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer
+1 nice work Mauricio Lima On Wed, May 18, 2016 at 11:03 AM, Swapnil Kulkarni wrote: > On Wed, May 18, 2016 at 12:30 AM, Steven Dake (stdake) > wrote: > > Hello core reviewers, > > > > I am proposing Mauricio (mlima on irc) for the core review team. He has > > done a fantastic job reviewing appearing in the middle of the pack for 90 > > days [1] and appearing as #2 in 45 days [2]. His IRC participation is > also > > fantastic and does a good job on technical work including implementing > > Manila from zero experience :) as well as code cleanup all over the code > > base and documentation. Consider my proposal a +1 vote. > > > > I will leave voting open for 1 week until May 24th. Please vote +1 > > (approve), or –2 (veto), or abstain. I will close voting early if there > is > > a veto vote, or a unanimous vote is reached. > > > > Thanks, > > -steve > > > > [1] http://stackalytics.com/report/contribution/kolla/90 > > [2] http://stackalytics.com/report/contribution/kolla/45 > > > > > __ > > 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 > > > > +1 > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Ansible 2.0.0 functional
1. the ansible 2.1 make lots of change compare to the ansible 2.0 about how the plugin works. So in default, kolla do not work with ansible 2.1 2. the compatible fix is merged here[0]. So the kolla works on both ansible 2.1 and ansible 2.0 [0] https://review.openstack.org/321754 On Wed, Jun 1, 2016 at 2:46 PM, Monty Taylor wrote: > On 06/01/2016 08:44 AM, Joshua Harlow wrote: > > Out of curiosity, what keeps on changing (breaking?) in ansible that > > makes it so that something working in 2.0 doesn't work in 2.1? Isn't the > > point of minor version numbers like that so that things in the same > > major version number still actually work... > > I'm also curious to know the answer to this. I expect the 2.0 port to > have had the possibility of breaking things - I do not expect 2.0 to 2.1 > to be similar. Which is not to say you're wrong about it not working, > but rather, it would be good to understand what broke so that we can > better track it in upstream ansible. > > > Steven Dake (stdake) wrote: > >> Hey folks, > >> > >> In case you haven't been watching the review queue, Kolla has been > >> ported to Ansible 2.0. It does not work with Ansible 2.1, however. > >> > >> Regards, > >> -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 > > > > > __ > > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Ansible 2.0.0 functional
David, is there any standard way to create the _tmp path? ansible 2.0 and ansible 2.1 have not the same function signature. [0] [0] https://github.com/openstack/kolla/blob/master/ansible/action_plugins/merge_configs.py#L45,L54 On Wed, Jun 1, 2016 at 9:53 PM, David Shrewsbury wrote: > I believe 2.1 was when Toshio introduced the new ziploader, which totally > changed how > the modules were loaded: > > https://github.com/ansible/ansible/pull/15246 > > That broke a few of the 2.x OpenStack modules, too. But that was mostly > our fault as > we didn't code some of them correctly to the proper standards. > > -Dave > > > On Wed, Jun 1, 2016 at 6:10 AM, Jeffrey Zhang > wrote: > >> 1. the ansible 2.1 make lots of change compare to the ansible 2.0 about >> how >>the plugin works. So in default, kolla do not work with ansible 2.1 >> >> 2. the compatible fix is merged here[0]. So the kolla works on both >>ansible 2.1 and ansible 2.0 >> >> [0] https://review.openstack.org/321754 >> >> On Wed, Jun 1, 2016 at 2:46 PM, Monty Taylor >> wrote: >> >>> On 06/01/2016 08:44 AM, Joshua Harlow wrote: >>> > Out of curiosity, what keeps on changing (breaking?) in ansible that >>> > makes it so that something working in 2.0 doesn't work in 2.1? Isn't >>> the >>> > point of minor version numbers like that so that things in the same >>> > major version number still actually work... >>> >>> I'm also curious to know the answer to this. I expect the 2.0 port to >>> have had the possibility of breaking things - I do not expect 2.0 to 2.1 >>> to be similar. Which is not to say you're wrong about it not working, >>> but rather, it would be good to understand what broke so that we can >>> better track it in upstream ansible. >>> >>> > Steven Dake (stdake) wrote: >>> >> Hey folks, >>> >> >>> >> In case you haven't been watching the review queue, Kolla has been >>> >> ported to Ansible 2.0. It does not work with Ansible 2.1, however. >>> >> >>> >> Regards, >>> >> -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 >>> > >>> > >>> __ >>> > 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 >>> >> >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> __ >> 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 >> >> > > > -- > David Shrewsbury (Shrews) > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Request for changing the meeting time to 1600 UTC for all meetings
it will be mid-night (0:00) in my local time. But i think i am OK with it. so +1 for this. On Wed, Jun 8, 2016 at 9:12 PM, Paul Bourke wrote: > +1 > > On 08/06/16 13:54, Swapnil Kulkarni (coolsvap) wrote: > >> Dear Kollagues, >> >> Some time ago we discussed the requirement of alternating meeting >> times for Kolla weekly meeting due to major contributors from >> kolla-mesos were not able to attend weekly meeting at UTC 1600 and we >> implemented alternate US/APAC meeting times. >> >> With kolla-mesos not active anymore and looking at the current active >> contributors, I wish to reinstate the UTC 1600 time for all Kolla >> Weekly meetings. >> >> Please let me know your views. >> >> > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] OSIC cluster accepteed
Cool. Do we have any test list now? and how can i help for this? I am very interested in this test. On Tue, Jun 7, 2016 at 4:52 PM, Paul Bourke wrote: > Michal, > > I'd be interested in helping with this. Keep us updated! > > -Paul > > > On 03/06/16 17:58, Michał Jastrzębski wrote: > >> Hello Kollagues, >> >> Some of you might know that I submitted request for 130 nodes out of >> osic cluster for testing Kolla. We just got accepted. Time window will >> be 3 weeks between 7/22 and 8/14, so we need to make most of it. I'd >> like some volunteers to help me with tests, setup and such. We need to >> prepare test scenerios, streamline bare metal deployment and prepare >> architectures we want to run through. I would also make use of our >> global distribution to keep nodes being utilized 24h. >> >> Nodes we're talking about are pretty powerful 256gigs of ram each, 12 >> ssd disks in each and 10Gig networking all the way. We will get IPMI >> access to it so bare metal provisioning will have to be there too >> (good time to test out bifrost right?:)) >> >> Cheers, >> Michal >> >> __ >> 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [Openstack] OpenStack Newton B1 for Ubuntu 16.04 LTS and Ubuntu 16.10
Very Cool! Wait this for long. we(kolla project) will enable the ubuntu binary deploy gate in the CI. On Mon, Jun 13, 2016 at 8:54 PM, Corey Bryant wrote: > Hi All, > > The Ubuntu OpenStack team is pleased to announce the general availability > of the OpenStack Newton B1 milestone in Ubuntu 16.10 and for Ubuntu 16.04 > LTS via the Ubuntu Cloud Archive. > > Ubuntu 16.04 LTS > > > You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on > Ubuntu 16.04 installations by running the following commands: > > echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu > xenial-updates/newton main" | sudo tee > /etc/apt/sources.list.d/newton-uca.list > sudo apt-get install -y ubuntu-cloud-keyring > sudo apt-get update > > The Ubuntu Cloud Archive for Newton includes updates for Cinder, > Designate, Glance, Heat, Horizon, Keystone, Manila, Neutron, Neutron-FWaaS, > Neutron-LBaaS, Neutron-VPNaaS, Nova, and Swift (2.8.0). > > You can check out the full list of packages and versions at [0]. > > Ubuntu 16.10 > -- > > No extra steps required; just start installing OpenStack! > > Branch Package Builds > --- > > We’ve resurrected the branch package builds of OpenStack projects that we > had in place a while back - if you want to try out the latest master branch > updates, or updates to stable branches, the following PPA’s are now > up-to-date and maintained: > >sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty >sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka >sudo add-apt-repository ppa:openstack-ubuntu-testing/newton > > bear in mind these are built per-commit-ish (30 min checks for new commits > at the moment) so ymmv from time-to-time. > > Reporting bugs > - > > Any issues please report bugs using the 'ubuntu-bug' tool: > > sudo ubuntu-bug nova-conductor > > this will ensure that bugs get logged in the right place in Launchpad. > > Thanks and have fun! > > Regards, > Corey > (on behalf of the Ubuntu OpenStack team) > > [0] > http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.html > > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] xenial or trusty
It is hard for kolla to support both release of Ubuntu.
Because docker separate the image build from deploy. We have no idea about
the Ubuntu version in Dockerfile
except runing command to test it. We build the image by using Dockerfile.
If we want support multi release of
Ubuntu, the Dockerfile will looks like:
RUN if [[ $(cat /etc/os-release | awk '/VERSION_ID/{print $2}') == '14.04'
]] then; \
apt-get install openjdk-7-jre \
elif $(cat /etc/os-release | awk '/VERSION_ID/{print $2}') == '16.04'
]] then; \
apt-get install openjdk-8-jre
fi
This is still possible. Think about how to use COPY in the Dockerfile to
support multi Ubuntu release? like
COPY sources.list /etc/apt/sources.list
As far as I can find out is:
COPY sources.list /etc/apt/sources.list
RUN if [[ $(cat /etc/os-release | awk '/VERSION_ID/{print $2}') == '14.04'
]] then; \
sed -i 's/UBUNTU_RELEASE/trusty/' /etc/apt/sources.list \
elif $(cat /etc/os-release | awk '/VERSION_ID/{print $2}') == '16.04'
]] then; \
sed -i 's/UBUNTU_RELEASE/xenial/' /etc/apt/sources.list \
fi
On Sat, May 7, 2016 at 12:51 AM, Jesse Pretorius
wrote:
> On 6 May 2016 at 16:27, Jeffrey Zhang wrote:
>
>>
>> On Fri, May 6, 2016 at 9:09 PM, Jesse Pretorius <
>> jesse.pretor...@gmail.com> wrote:
>>
>>> FWIW OpenStack-Ansible is choosing to support deployment on both Ubuntu
>>> 14.04 LTS and Ubuntu 16.04 LTS for both the Newton and Ocata cycles, with
>>> the current proposal to drop it in P. The intent is to provide our
>>> deployers the opportunity to transition with a mixed deployment.
>>
>>
>> Are you meaning the host/baremetal OS? the openstack-ansible deploy the
>> OpenStack in LXC.
>> So it really do not care about the host machine's OS. Kolla is not care
>> about it, too.
>> I think the openstack-ansible a specify LXC image, and do not support
>> multi base image.
>>
>> if not, could u provide any prove for this?
>>
>
> OSA supports the implementation of OpenStack on bare metal or in LXC
> machine containers, so we need to cater for both. When an LXC machine
> container is deployed we've chosen to use the strategy of always
> implementing the same OS in the container as is implemented on the host.
> This simplifies our testing greatly.
>
> For the sake of background information, seeing as you asked, the base LXC
> image we're using comes from https://images.linuxcontainers.org/ giving
> us the ability to support multiple versions, multiple distributions and
> multiple architectures, and it's especially nifty that the entire image
> build process is open source and therefore can be implemented and
> customised by our deployers.
>
> I guess this is similar for Kolla in a different way because the image
> pipeline is defined by the project and implemented through the docker image
> building processes.
>
> __
> 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
>
>
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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
Re: [openstack-dev] [kolla] Usage of Reno - all devs please read
On Tue, Jun 28, 2016 at 9:23 PM, Hui Kang wrote: > Do you mind giving some example of such reno release note? Thanks. like this https://review.openstack.org/#/c/235398/ . -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] [tools] OpenStack client in a Docker container
Gerard, i am Interested in you Ansible scripts. Could u share it? Thanks. On Wed, Jun 29, 2016 at 9:20 AM, Gerard Braad wrote: > Hi Steve, > > > How would you prefer me to approach this? At the moment I am > generating the images based on some ansible scripts I have in a > general playbook repository. > > regards, > > > Gerard > > On Tue, Jun 28, 2016 at 11:56 PM, Steven Dake (stdake) > wrote: > > Gerard, > > > > Yup we would take it in Kolla. Prevents dirtying a system for CLI based > > operations. > > > > Regards > > -steve > > > > From: "Fox, Kevin M" > > Date: Tuesday, June 28, 2016 at 4:41 AM > > To: Gerard Braad , "openst...@lists.openstack.org" > > , openstack-operators > > > > Subject: Re: [Openstack-operators] [openstack] [tools] OpenStack client > in a > > Docker container > > > > Cool. Maybe this could be contributed to the Kolla project? > > > > Thanks, > > Kevin > > -- > >Gerard Braad | http://gbraad.nl >[ Doing Open Source Matters ] > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?
In Kolla CI, we see[1] publicURL endpoint for compute service not found this error for many times. The bug is here[0] After some debug, I found the endpoint is exist in the DB. But when running `nova service-list` It says `publicURL endpoint for compute service not found `. After a few seconds, when you run the `nova service-list` again. it works as expected. I think the root cause it the keystone. seem that the keystone cached the catalog, and return the cached version without query it from the DB. So anyone can explain why it happen? and how to avoid this( any workaround?) The env: OS/Docker image: no matter, this happen on both CentOS and Ubuntu OpenStack: master branch [0] https://bugs.launchpad.net/kolla/+bug/1587226 [1] http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy-oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_298298 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] Build the docker images in a graceful way
Recently, Ansible release 2.1 version with lots of new feature. One of the interesting feature is the management for docker. Redhat also announced the Ansible Container project[0][1], which can build docker images by using Ansible Playbooks. No more write the ugly Dockerfile script. I think this will be more graceful. Here the explanation that why not use Dockerfile from ansible-container readme file. A Dockerfile is not much more than a script with hand-crafted shell commands. We're well past the point where we should be managing build processes with manually maintained series of shell scripts. That's why we wrote Ansible in the first place, and this is just as applicable to containers. Ansible Container permits orchestration even during the build process, whereas docker build does not. For example, in a Django project, your VCS may contain a bunch of sources for static assets that need to be compiled and then collected. With Ansible Container, you can compile the static assets in your Django container and then collect them into your static file serving container. Many people use Docker for development environments only but then use Ansible playbooks to push out to staging or production. This allows you to use the same playbooks and roles in your Docker dev environment as in your production environments. Ansible Container does all of this without installing SSH, leaving Ansible artifacts on your built images, or having excess layers to the union filesystem. I also pushed a PS to implement almost the same thing for Kolla[3]. There many benefit for this. 1. more easy to understand. The original base/Dockerfile is too long, mixed with different base image logical and different install type. Whereas in the new implement, it is more clearly. it is split into multi YAML file. 2. easy to extend. We can reuse the role concept for the Ansible. For example, when you want to extend the neutron-server container. You can write your own roles, like neutron-server-lbaas role, and just add this to the neutron-server playbooks. In this way, we can implement the customize issue. ( this will implement later.) 3. It is also possible to change the exist data. For example, i want to change the repo url to a internal ones. The user can provide a ansible variables file, which hold the new repo url and overwrite the exist one. This PS is in POC stage. Post this mail to gather any advise and better ideas. [0] https://github.com/ansible/ansible-container [1] https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/ [2] https://review.openstack.org/334208 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][keystone] is there chance the keystone cached the catalog and can not get the latest endpoints?
Yes it is the Bug. Thanks Kairat. On Wed, Jun 29, 2016 at 8:53 PM, Kairat Kushaev wrote: > Hi, > Looks like this bug is duplicate of > https://bugs.launchpad.net/oslo.cache/+bug/1590779 > HTH > > Best regards, > Kairat Kushaev > > On Wed, Jun 29, 2016 at 3:32 PM, Jeffrey Zhang > wrote: > >> In Kolla CI, we see[1] >> >> publicURL endpoint for compute service not found >> >> this error for many times. The bug is here[0] >> >> >> After some debug, I found the endpoint is exist in the DB. But when >> running `nova service-list` >> It says `publicURL endpoint for compute service not found >> `. After a few seconds, when you run >> the `nova service-list` again. it works as expected. >> >> I think the root cause it the keystone. seem that the keystone cached the >> catalog, and return >> the cached version without query it from the DB. So anyone can explain >> why it happen? and how to >> avoid this( any workaround?) >> >> The env: >> OS/Docker image: no matter, this happen on both CentOS and Ubuntu >> OpenStack: master branch >> >> [0] https://bugs.launchpad.net/kolla/+bug/1587226 >> [1] >> http://logs.openstack.org/91/328891/5/check/gate-kolla-dsvm-deploy-oraclelinux-source/3af433c/console.html#_2016-06-29_10_10_33_298298 >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> __ >> 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Build the docker images in a graceful way
On Wed, Jun 29, 2016 at 9:26 PM, Gerard Braad wrote: > "did Kolla drop support for > Fedora" ? > no one maintain the fedora and no gate for fedora too. So i am not sure whether the fedora works. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Build the docker images in a graceful way
On Wed, Jun 29, 2016 at 9:26 PM, Gerard Braad wrote: > Although I saw the Ansible Container repo, I wasn't that excited about > it at the moment. It still feels complicated when compared to how Chef > describes a container. However, it is still promising. > The ansible container is more complicated. I do not mean to using it directly. But using the concept that replace the raw scripts with ansible-playbook in the Dockerfile . The Dockerfile will become very simple and the main logical will enclos e the A nsible playbooks. Just like what your openstack client container does. > > On the reasons I did not choose to use it either is that Automated > builds only handle Dockerfiles. I'd rather run a script in a statement > to ensure it is one layer. and inside this script use Ansible to > orchestrate when necessary. > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Build the docker images in a graceful way
Hi all, the spec is here[0] [0] https://review.openstack.org/336757 On Wed, Jun 29, 2016 at 9:44 PM, Jeffrey Zhang wrote: > > On Wed, Jun 29, 2016 at 9:26 PM, Gerard Braad wrote: > >> Although I saw the Ansible Container repo, I wasn't that excited about >> it at the moment. It still feels complicated when compared to how Chef >> describes a container. However, it is still promising. >> > > The ansible container is more complicated. I do not mean to using it > directly. But using the concept that replace the > raw scripts with > ansible-playbook in the Dockerfile . The Dockerfile > will become very simple and the main logical will > > enclos > > e > > the > A > nsible > playbooks. > > Just like what your openstack client container does. > > >> >> On the reasons I did not choose to use it either is that Automated >> builds only handle Dockerfiles. I'd rather run a script in a statement >> to ensure it is one layer. and inside this script use Ansible to >> orchestrate when necessary. >> > > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [Kolla] [docker] Storage-driver and loopback usage?
Hi Gerard, Here is what the docker official recommend[0]. In the prod env, the they recommend using the direct-lvm driver. Kolla has no recommendation now. In the dev process, i know someone use overlayfs, some use btrfs. These two are both faster than others. [0] https://docs.docker.com/engine/userguide/storagedriver/selectadriver/ On Mon, Jul 4, 2016 at 11:00 AM, Gerard Braad wrote: > Hi guys, > > > This weekend I have been looking into some issues I encountered with > `ostree` inside a Docker container, and this seemed to have been > caused by the use of loopback storage with device mapper. After this > experience I was wondering what Kolla did... > > Usually for development purpose, or on a laptop, it is easy to just > work out-of-the-box. But I would not consider using devicemapper after > this experience as a pleasant experience. I moved to all development > environment using OverlayFS, and will evaluate this for the time > being... > > What do you guys think or use? And what about the quickstart? I was > unable to find a statement about this. I did find a change of the > storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what > is used in CI? > > regards, > > > Gerard > > -- > >Gerard Braad | http://gbraad.nl >[ Doing Open Source Matters ] > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer
+1 On Wed, Mar 30, 2016 at 8:25 AM, Angus Salkeld wrote: > +1 > > > On Wed, Mar 30, 2016 at 6:45 AM Michał Jastrzębski > wrote: > >> +1 >> >> On 29 March 2016 at 11:39, Ryan Hallisey wrote: >> > +1 >> > >> > - Original Message - >> > From: "Paul Bourke" >> > To: openstack-dev@lists.openstack.org >> > Sent: Tuesday, March 29, 2016 12:10:38 PM >> > Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot >> for Core Reviewer >> > >> > +1 >> > >> > On 29/03/16 17:07, Steven Dake (stdake) wrote: >> >> Hey folks, >> >> >> >> Consider this proposal a +1 in favor of Vikram joining the core >> reviewer >> >> team. His reviews are outstanding. If he doesn’t have anything useful >> >> to add to a review, he doesn't pile on the review with more –1s which >> >> are slightly disheartening to people. Vikram has started a trend >> >> amongst the core reviewers of actually diagnosing gate failures in >> >> peoples patches as opposed to saying gate failed please fix. He does >> >> this diagnosis in nearly every review I see, and if he is stumped he >> >> says so. His 30 days review stats place him in pole position and his >> 90 >> >> day review stats place him in second position. Of critical notice is >> >> that Vikram is ever-present on IRC which in my professional experience >> >> is the #1 indicator of how well a core reviewer will perform long term. >> >>Besides IRC and review requirements, we also have code requirements >> >> for core reviewers. Vikram has implemented only 10 patches so far, >> butI >> >> feel he could amp this up if he had feature work to do. At the moment >> >> we are in a holding pattern on master development because we need to >> fix >> >> Mitaka bugs. That said Vikram is actively working on diagnosing root >> >> causes of people's bugs in the IRC channel pretty much 12-18 hours a >> day >> >> so we can ship Mitaka in a working bug-free state. >> >> >> >> Our core team consists of 11 people. Vikram requires at minimum 6 +1 >> >> votes, with no veto –2 votes within a 7 day voting window to end on >> >> April 7th. If there is a veto vote prior to April 7th I will close >> >> voting. If there is a unanimous vote prior to April 7th, I will make >> >> appropriate changes in gerrit. >> >> >> >> Regards >> >> -steve >> >> >> >> [1] http://stackalytics.com/report/contribution/kolla-group/30 >> >> [2] http://stackalytics.com/report/contribution/kolla-group/90 >> >> >> >> >> >> >> __ >> >> 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 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 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 > > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch
+1 A lot of changes has been make in Mitaka. Backport is difficult. But using Mitaka deploy Liberty also has *much works*. For example, revert config file change which deprecated in Mitaka and Liberty support. A important one is the `keystone-manage bootstrap` command to create the keystone admin account. This is adderecently and only exist in the Mitaka branch. So when using this method, we should revert some commit and use the old way method. On Wed, Mar 30, 2016 at 1:23 PM, Michal Rostecki wrote: > +1 under the condition that there will be a path of migration from "old" > Liberty to the "new" Liberty. At least in form of documentation. > > If that wouldn't require any downtime of VM-s (except the Docker upgrade, > of course) and can be achieved just by running playbooks and some script > for volumes migration, then I'm fully +1. > > > __ > 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] centos-binary-neutron-openvswitch-agent
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"About an hour ago Up About an hour > keepalived > bb1f7facad40127.0.0.1:4000/kollaglue/centos-binary-haproxy:2.0.0 > "kolla_start"About an hour ago Up About > an hour haproxy > 62c5fb629d82127.0.0.1:4000/kollaglue/centos-binary-cron:2.0.0 >"kolla_start"About an hour ago Up About an > hour cron > 6815001be121 > 127.0.0.1:4000/kollaglue/centos-binary-kolla-toolbox:2.0.0 > "/bin/sleep infinity"About an hour ago Up About an hour > kolla_toolbox > b5a7bda2f76d127.0.0.1:4000/kollaglue/centos-binary-heka:2.0.0 >"kolla_start"About an hour ago Up About an > hour heka > 881ea88cd06fregistry:2 > "/bin/registry serve " 3 days ago Up 2 hours >0.0.0.0:4000->5000/tcp registry > > > > > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] deploy kolla on ppc64
this should be a bug. we do not support the custom base image now. I will try to fix this, anyway. On Fri, Apr 22, 2016 at 5:29 AM, Franck Barillaud wrote: > I've been using Kola to deploy Mitaka on x86 and it works great. Now I > would like to do the same thing on IBM Power8 systems (ppc64). I've setup a > local registry with an Ubuntu image. > I've docker and a local registry running on a Power8 system. When I issue > the following command: > > kolla-build --base ubuntu --type source --registry :4000 > --push > > I get an 'exec format error' message. It seems that the build process > pulls the Ubuntu amd64 image from the public registry and not the ppc64 > image from the local registry. Is there a configuration parameter I can > setup to force to pull the image from the local registry ? > > > Regards, > Franck Barillaud > Cloud Architect > Master Inventor > Ext Phone: (512) 286-5242Tie Line: 363-5242 > e-mail: fbari...@us.ibm.com > > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes
On Mon, Apr 25, 2016 at 11:05 AM, Tomasz Pa wrote: > Kolla images are simply to big and not properly layered. What it means > that if you today want to upgrade one of the packages: ie: python-nova > (assuming images are build from RPMs) you're upgrading whole layer > which contains all it's dependencies added by yum. So at the end > simple 12MB upgrades turns to be 120MB (right now this is the size of > the kolla image layer which contains python-nova). > I do not think this is the issue of Kolla. It is a issue of Docker images. All the docker images has such issue. This should be solved in the docker side. If you have any better solutions for this, please explain it. I think the Kolla Team will be very happy to accept the improvement. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes
FYI, in the current implementation, a single image seems big, around 300MB - 1G. But when push all the image to the registry service, you will find that the total size of the images is just 2GB. When distribute the image, It just takes less 30s to transfer images( 2GB / 100MB/s < 30s ). This is what the Steve said above. Kolla leverage the docker parent image and the total size of the images is smaller than you think. On Mon, Apr 25, 2016 at 4:49 PM, Fox, Kevin M wrote: > I really hadnt thought about distro deps for non containers leaking into > containers like nova->libvirt. What about making a kolla-container rpm that > provides a virtual libvirt package and anything else not actually needed in > the container? > > Thanks, > Kevin > > -- > *From:* Steven Dake (stdake) > *Sent:* Monday, April 25, 2016 1:01:16 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [kolla][kubernetes] Mirantis participation > in kolla-mesos project and shift towards Kubernetes > > Tomasz, > Response inline. > > On 4/25/16, 12:32 AM, "Tomasz Pa" wrote: > > >On Mon, Apr 25, 2016 at 5:51 AM, Jeffrey Zhang > >wrote: > >> > >> I do not think this is the issue of Kolla. It is a issue of Docker > >> images. All the docker images has such issue. This should be solved > >> in the docker side. > >> > > > >It's a kolla issue and they way project build images. Calling yum > >install in Dockerfile is not the best idea (you endup with multiple > >dependent packages put into the single image layer). Having some good > >DSL would mean that you can place each package into separate image > >layer (ie: RUN rpm -i ./python-nova-.rpm) and take advantage of > >that during build (reusing cached layers). > > In the case were there are a common set of packages that end up in every > layer, Kolla has optimized for the general build and use case by > extracting the commonly used dependencies into a base image used by all > containers. > > Reference from binary: > https://github.com/openstack/kolla/blob/master/docker/openstack-base/Docker > file.j2#L129 > > > Reference from source: > https://github.com/openstack/kolla/blob/master/docker/openstack-base/Docker > file.j2#L320 > > > Kolla developers essentially count the number of times that requests > package would be installed in a dependent container, and if it reaches a > threshold, Kolla installs it in a parent image of every openstack-service > container. > > I agree it is possible to end up with multiple same dependencies in > different containers, which is why we have this openstack-base image in > the first place - to serve as a MACRO optimization to solve the very > problem you point out. > > I fail to see how a DSL would improve on this master openstack-base image. > > My build times on my gear are 14 minutes for 115+ containers. I do have > Intel 750 NVME SSD and gige internet, however, even folks with slower > storage and networking report 30-35 minute build times which are in the > window of "not too long to do once in awhile". > > But I'll grant you, I personally think every time I rebuild all my images > on my host I could be doing something better with my time. I just don't > think a DSL would help speed up build times as you have claimed, except > for the one-off case of nova (because of its dependency on libvirt). > > What I'd hate to see happen is a DSL invented and used in Kolla that > specifies each specific dependency to install for binary-packaging. That > is what rpm/deb is designed to handle. > > For the case of source builds, requirements.txt serves the same purpose. > > Regards > -steve > > > > > > >-- > >Tomasz Paszkowski > >SS7, Asterisk, SAN, Datacenter, Cloud Computing > >+48500166299 > > > >__ > >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 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic
+1 On Tue, Apr 26, 2016 at 6:00 AM, Ryan Hallisey wrote: > +1 > > - Original Message - > From: "Angus Salkeld" > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Sent: Sunday, April 24, 2016 11:01:38 AM > Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in > openstack-attic > > > > +1 > On Sat, 23 Apr 2016 3:08 am Michał Rostecki < michal.roste...@gmail.com > > wrote: > > > +1 > > __ > 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 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] rax-ord misbehaving in the gate
see this fix[0]. It has been there for days. Please review it. thanks. [0] https://review.openstack.org/290238 On Mon, May 2, 2016 at 8:53 AM, Steven Dake (stdake) wrote: > Hey folks, > > We really need to solve rax-ord in the gate. For awhile it was removed > because consistently across openstack this gate jobs were failing. Does > anyone have any idea why it is failing in the Kolla case? > > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][gate] Add a gating check job for precheck
does Kolla really need a new job to run the precheck? why not run the precheck before deploying the kolla in the current logical? On Tue, May 3, 2016 at 12:45 PM, Hui Kang wrote: > Steve, > Ok, I created a bp for this. Feel free to edit > https://blueprints.launchpad.net/kolla/+spec/gate-job-precheck > > Best regards, > - Hui > > On Mon, May 2, 2016 at 11:50 PM, Steven Dake (stdake) > wrote: > > Hui, > > > > I am planning to add a general gating blueprint with work items for the > 24 > > gates we identified. Just g o ahead and get started and I'll have the > > gate blueprint ready to go by tomorrow. > > > > Regards > > -steve > > > > On 5/2/16, 8:41 PM, "Hui Kang" wrote: > > > >>Fellow kolla developers, > >>I am wondering if anyone is working on adding a gate job for precheck. > >>If not, I'd like to kick off the task by adding a bp. Any comment? > >>Thanks. > >> > >>- Hui Kang > >>IRC: huikang > >> > > >>__ > >>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 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kubernetes] One repo vs two
repo worked very well for us and would encourage > >> you to replicate that again. Having one repo doing one thing makes the > >> goal of the repo obvious and makes the api between the images and > >> deployment clearer (also the stablity of that > >> api and things like permissions *cough* drop-root). > >> > >> -Angus > >> > >> > >> If you are on this list: > >> > >> * Ryan Hallisey > >> * Britt Houser > >> > >> * mark casey > >> > >> * Steven Dake (delta-alpha-kilo-echo) > >> > >> * Michael Schmidt > >> > >> * Marian Schwarz > >> > >> * Andrew Battye > >> > >> * Kevin Fox (kfox) > >> > >> * Sidharth Surana (ssurana) > >> > >> * Michal Rostecki (mrostecki) > >> > >> *Swapnil Kulkarni (coolsvap) > >> > >> *MD NADEEM (mail2nadeem92) > >> > >> *Vikram Hosakote (vhosakot) > >> > >> *Jeff Peeler (jpeeler) > >> > >> *Martin Andre (mandre) > >> > >> *Ian Main (Slower) > >> > >> * Hui Kang (huikang) > >> > >> * Serguei Bezverkhi (sbezverk) > >> > >> * Alex Polvi (polvi) > >> > >> * Rob Mason > >> > >> * Alicja Kwasniewska > >> > >> * sean mooney (sean-k-mooney) > >> > >> * Keith Byrne (kbyrne) > >> > >> * Zdenek Janda (xdeu) > >> > >> * Brandon Jozsa (v1k0d3n) > >> > >> * Rajath Agasthya (rajathagasthya) > >> * Jinay Vora > >> * Hui Kang > >> * Davanum Srinivas > >> > >> > >> > >> Please speak up if you are in favor of a separate repository or a > >> unified repository. > >> > >> The core reviewers will still take responsibility for determining if > >> we proceed on the action of implementing kubernetes in general. > >> > >> Thank you > >> -steve > >> > >>_________ > >>_ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> > >><http://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 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] lock the distro version in the stable branch
Hey guys, Recently, the ubuntu 16.04 is out and it crashed kolla when using ubuntu:lastest to build the images. even though kolla support multi base-tag, the kolla will failed when using other base-tag except for centos:7, ubuntu:14.04, rhel:7. And it is also hard to support all kind of the image tag. So I support that kolla should restrict the base-tag. the lastest tag is mutable and we should not use it, especially in the stable branch. When using a mutable image, it is never a *stable* release. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kolla-k8s] Core team
agree. at the beginning, the kolla-k8s core team should accept new core reviewers in the very high frequency, for example 1-2 member every 1 week, which will be helpful for the growth of the core team. On Wed, May 4, 2016 at 12:48 AM, Michał Jastrzębski wrote: > Hello, > > Since it seems that we have voted for separation of kolla-k8s repos > (yay!) I would like to table another discussion (but let's wait till > its official). > > Core Team. > > We need to build up new core team that will guard the gates on our > brand new repo (when it arrives). One of ideas Steven pointed out is > to add people from etherpad to core team, but I'd like to throw > different idea to the mix, to keep things interesting. > > Idea is: let's start with current kolla core team and for the time > being add new cores to kolla-k8s by invitation by existing core > member. For example, I'm kolla core, working with k8s and I see some > guy doing great job and investing time into it, I would propose him > for core, and instead of normal voting, he will get his +2 powers > immediately. This would allow quick core team buildout and not start > with bunch of people who doesn't necessary want to contribute or even > know each other. > > Cheers, > Michal > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [Kolla] lock the distro version in the stable branch
On Wed, May 4, 2016 at 1:30 AM, Hui Kang wrote: > This commit fixes the tag: > > https://github.com/openstack/kolla/commit/e2fa75fce6f90de8b2766070bb65d0b80bcad8c8 > that fix is just a workaround. the end-user know nothing about this and will be confused about the result. > > > But I think fixing the tag in dockerfile of base container image is better > Yes that will better. I intend to change the default config option. and check the base and base_tag in the Dockerfile of base. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] better solution for the non-ini format configure file
Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to the globals.yml file. Because there is no chance to change the horizon/apache configure file now. The root cause is that: Kolla do not support non-ini format configure file. for the ini-format file, we use a merge_config module[1] to merge all the found file. But it will be not work for configure file for apache, rabbitmq and so on. I would like to the current merge_config implementation. It is directly and easy to use. Not like the puppet, we have to remember the variable name defined in the module. we have no chance to add some user-defined variable. Export the variable to global is very bad and ugly. It will became a disaster when more and more variables is exported. So we should catch up a better solution to handle the configure file. One solution I have is use overwrite mechanism. for example when there is a file in /etc/kolla/config/apache.conf, it will overwrite the templates in the roles. But this is still not ideal. Any body has better solution? [0] https://review.openstack.org/306928 [1] http://git.openstack.org/cgit/openstack/kolla/tree/ansible/action_plugins/merge_configs.py -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] xenial or trusty
I'd like to lock the tag version in certain branch. One branch only support one distro release. For example, the mitaka branch only build on Trusty and the master/newton branch only build on Xenial. So, the branch and OS matrix should like ( fix me and the ?) Ubuntu CentOS Debian OracleLinux Liberty14.047 ? ? Mitaka 14.047 ? ? Master 16.047 ? ? this is enough and easy to maintain. On Thu, May 5, 2016 at 1:14 AM, Mauricio Lima wrote: > Which will be the default when kolla begin to support xenial? Xenial or > Trusty? > > One proposal is to support both, at least in this beginning and just do > some checks to get which version that the user is using. > > Regards, > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] xenial or trusty
On Fri, May 6, 2016 at 9:09 PM, Jesse Pretorius wrote: > FWIW OpenStack-Ansible is choosing to support deployment on both Ubuntu > 14.04 LTS and Ubuntu 16.04 LTS for both the Newton and Ocata cycles, with > the current proposal to drop it in P. The intent is to provide our > deployers the opportunity to transition with a mixed deployment. Are you meaning the host/baremetal OS? the openstack-ansible deploy the OpenStack in LXC. So it really do not care about the host machine's OS. Kolla is not care about it, too. I think the openstack-ansible a specify LXC image, and do not support multi base image. if not, could u provide any prove for this? -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] CentOS binary and source gate failed due to the rabbitmq
Recently, the centos binary and source gate failed due to the rabbitmq container existed. After making some debug. I do not found the root cause. does anyone has any idea for this? see this PS gate result[0] centos binary gate failed[1] CentOS source gate failed[2] [0] https://review.openstack.org/313838 [1] http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-binary/ea293fe/ [2] http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-source/d4cb127/ -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04
Please check this[0]. The root cause is that the > While all kernels should work for Docker, some older kernels may have > issues with some of the different Docker backends such as AUFS and OverlayFS. [0] http://docs.openstack.org/developer/kolla/quickstart.html#installing-dependencies On Sun, May 8, 2016 at 4:45 PM, Steve Kowalik wrote: > On 08/05/16 08:11, lương hữu tuấn wrote: > >> Hi, >> >> @Robert: I was successful to update the kernel without change the image. >> > > But that was Robert's point entirely. Installing the kernel will work > fine, but it does not get you running that kernel -- also like Robert > said, you need to change the image to run a different kernel than what > it has installed. > > -- > Steve > "Stop breathing down my neck!" > "My breathing is merely a simulation." > "So is my neck! Stop it anyway." > - EMH vs EMH, USS Prometheus > > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] CentOS binary and source gate failed due to the rabbitmq
I deploy the Kolla by using centos+source on centos host always. Never see such kinda of issue. So i can not re-produce this locally, now. On Mon, May 9, 2016 at 8:31 AM, Hui Kang wrote: > Hi, Jeffrey, > I tried deploying centos binary and source on my ubuntu host, which > completed successfully. Looking at the VMs on the failed gate, they > are centos VMs. > > I think we need to debug this problem locally by deploying centos > kolla on centos hosts. Is my understanding correct? Thanks. > > - Hui > > On Sat, May 7, 2016 at 9:54 AM, Jeffrey Zhang > wrote: > > Recently, the centos binary and source gate failed due to the rabbitmq > > container > > existed. After making some debug. I do not found the root cause. > > > > does anyone has any idea for this? > > > > see this PS gate result[0] > > centos binary gate failed[1] > > CentOS source gate failed[2] > > > > [0] https://review.openstack.org/313838 > > [1] > > > http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-binary/ea293fe/ > > [2] > > > http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-source/d4cb127/ > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > > > __ > > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04
hi hui, On Mon, May 9, 2016 at 12:41 AM, Hui Kang wrote: > Then the precheck should check for backend overlay fs on Ubuntu > trusty, rather than the kernel version. > i do not have more info about this in pre-check. just copy from the doc. Maybe we need re-consider this. what's the root cause that we need upgrade the kernel. normally, upgrade the trusty kernel is unacceptable. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] deploy kolla on ppc64
This is fixed on master branch. please try and test it.[0][1] [0] https://git.openstack.org/cgit/openstack/kolla/commit/?id=070bf258357c85a7b4411dc97f75df7d19e9792c [1] https://bugs.launchpad.net/kolla/+bug/1573544 On Fri, Apr 22, 2016 at 7:15 PM, Jeffrey Zhang wrote: > this should be a bug. we do not support the custom base image now. I > will try to fix this, anyway. > > On Fri, Apr 22, 2016 at 5:29 AM, Franck Barillaud > wrote: > >> I've been using Kola to deploy Mitaka on x86 and it works great. Now I >> would like to do the same thing on IBM Power8 systems (ppc64). I've setup a >> local registry with an Ubuntu image. >> I've docker and a local registry running on a Power8 system. When I issue >> the following command: >> >> kolla-build --base ubuntu --type source --registry :4000 >> --push >> >> I get an 'exec format error' message. It seems that the build process >> pulls the Ubuntu amd64 image from the public registry and not the ppc64 >> image from the local registry. Is there a configuration parameter I can >> setup to force to pull the image from the local registry ? >> >> >> Regards, >> Franck Barillaud >> Cloud Architect >> Master Inventor >> Ext Phone: (512) 286-5242Tie Line: 363-5242 >> e-mail: fbari...@us.ibm.com >> >> >> __ >> 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 >> >> > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Location of Heka Lua plugins
+1 for this. +2 for putting the plugins to its own repo. On Thu, Feb 4, 2016 at 9:45 PM, Michal Rostecki wrote: > On 02/04/2016 10:55 AM, Eric LEMOINE wrote: > >> Hi >> >> As discussed yesterday in our IRC meeting we'll need specific Lua >> plugins for parsing OpenStack, MariaDB and RabbitMQ logs. We already >> have these Lua plugins in one of our Fuel plugins [*]. So our plan is >> to move these Lua plugins in their own Git repo, and distribute them >> as deb and rpm packages in the future. This will allow to easily >> share the Lua plugins between projects, and having a separate Git repo >> will facilitate testing, documentation, etc. >> >> But we may not have time to do that by the 4th of March (for Mitaka >> 3), so my suggestion is to copy the Lua plugins that we need in Kolla. >> This would be a temporary thing. When our Lua plugins are >> available/distributed as deb and rpm packages we will remove the Lua >> plugins from the kolla repository and change the Heka Dockerfile to >> install the Lua plugins from the package. >> >> Please tell me if you agree with the approach. Thank you! >> >> [*] < >> https://github.com/openstack/fuel-plugin-lma-collector/tree/master/deployment_scripts/puppet/modules/lma_collector/files/plugins/decoders >> > >> >> > +1 > But of course when git repos will be available (even without packaging), > I'd switch to them immediately. > > Cheers, > Michal > > > __ > 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty
I am going to keep voting open for *2* weeks this time. The >> reason for the >> > two weeks is I would like a week of discussion before people >> just blindly >> > vote ;) >> > >> > Voting begins now and concludes March 4th. Since this is a >> policy decision, >> > no veto votes are permitted, just a +1 and a -1. Abstaining >> is the same as >> > voting –1. >> > >> > > I'm +1, but under condition that we will provide some script to migrate > from supervisord-container to thin-containers (even if such a script will > bring risk of downtime of the cloud). > > > __ > 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core
+1 Nick work! On Mon, Feb 22, 2016 at 10:27 AM, Ryan Hallisey wrote: > +1. Nice work Angus! > > -Ryan > > > On Feb 19, 2016, at 11:51 PM, Michał Jastrzębski > wrote: > > > > +1 on condition that he will appear in kolla itself, after > > all...you'll be a kolla core as well right?;) > > > >> On 19 February 2016 at 21:44, Sam Yaple wrote: > >> +1 of course. I mean, its Angus. Who can say no to Angus? > >> > >> Sam Yaple > >> > >> On Fri, Feb 19, 2016 at 10:57 PM, Michal Rostecki < > mroste...@mirantis.com> > >> wrote: > >>> > >>>> On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote: > >>>> > >>>> Angus is already in kolla-mesos-core but doesn't have broad ability to > >>>> approve changes for all of kolla-core. We agreed by majority vote in > >>>> Tokyo that folks in kolla-mesos-core that integrated well with the > >>>> project would be moved from kolla-mesos-core to kolla-core. Once > >>>> kolla-mesos-core is empty, we will deprecate that group. > >>>> > >>>> Angus has clearly shown his commitment to Kolla: > >>>> He is #9 in reviews for Mitaka and #3 in commits(!) as well as shows a > >>>> solid PDE of 64 (meaning 64 days of interaction with either reviews, > >>>> commits, or mailing list participation. > >>>> > >>>> Count my vote as a +1. If your on the fence, feel free to abstain. A > >>>> vote of –1 is a VETO vote, which terminates the voting process. If > >>>> there is unanimous approval prior to February 26, or a veto vote, the > >>>> voting will be closed and appropriate changes made. > >>>> > >>>> Remember now we agreed it takes a majority vote to approve a core > >>>> reviewer, which means Angus needs a +1 support from at least 6 core > >>>> reviewers with no veto votes. > >>>> > >>>> Regards, > >>>> -steve > >>> > >>> +1 > >>> Good job, Angus! > >>> > >>> > __ > >>> 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 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] New Meeting Times altrernating 16:30 and 23; 00 UTC.
hi Steven, did you make some mistake? this week is the 9th( odd week). So the meeting time should be on wednesday at 2300 UTC. Every two weeks (on even weeks) on Wednesday at 1630 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=30&sec=0> in #openstack-meeting-4 (IRC webclient <https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting-4&prompt=1&uio=d4> ) Every two weeks (on odd weeks) on Wednesday at 2300 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?hour=23&min=00&sec=0> in #openstack-meeting-4 (IRC webclient <https://webchat.freenode.net/?randomnick=1&channels=%23openstack-meeting-4&prompt=1&uio=d4> ) On Wed, Feb 24, 2016 at 8:50 PM, Steven Dake (stdake) wrote: > Hey folks, > > We agreed some time ago to be more inclusive and have an APAC/US meeting. > I am happy to announce that work has completed. > > Please see: > > http://eavesdrop.openstack.org/#Kolla_Team_Meeting > > From there you can download an ical file which will insert directly into > your calendar for your connivance. > > NB the next meeting is held Wednesday February 24th @ t 16:30 UTC . The > meeting on March 4th will be held at 23:00UTC. The 23:00 UTC time is our > UTC timeslot. > > Regards > -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 > > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer
+1 nice job! On Sun, Mar 6, 2016 at 8:57 PM, Ryan Hallisey wrote: > +1 Nice Job Alicja! > > -Ryan > > - Original Message - > From: "Eric LEMOINE" > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Sent: Friday, March 4, 2016 5:04:10 PM > Subject: Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska > for core reviewer > > > > +1 > > Looking forward to more collaboration on Diagnostics and other stuff :) > > > Le 4 mars 2016 17:58, "Steven Dake (stdake)" < std...@cisco.com > a écrit > : > > > > Core Reviewers, > > > > Alicja has been instrumental in our work around jinja2 docker file > creation, removing our symlink madness. She has also been instrumental in > actually getting Diagnostics implemented in a sanitary fashion. She has > also done a bunch of other work that folks in the community already know > about that I won't repeat here. > > > > I had always hoped she would start reviewing so we could invite her to > the core review team, and over the last several months she has reviewed > quite a bit! Her 90 day stats[1] place her at #9 with a solid ratio of 72%. > Her 30 day stats[2] are even better and place her at #6 with an improving > ratio of 67%. She also just doesn't rubber stamp reviews or jump in reviews > at the end; she sticks with them from beginning to end and finds real > problems, not trivial things. Finally Alicja is full time on Kolla as > funded by her employer so she will be around for the long haul and always > available. > > > > Please consider my proposal to be a +1 vote. > > > > To be approved for the core reviewer team, Alicja requires a majority > vote of 6 total votes with no veto within the one week period beginning now > and ending Friday March 11th. If your on the fence, you can always abstain. > If the vote is unanimous before the voting ends, I will make appropriate > changes to gerrit's acls. If their is a veto vote, voting will close prior > to March 11th. > > > > Regards, > > -steve > > > > [1] http://stackalytics.com/report/contribution/kolla-group/90 > > [2] http://stackalytics.com/report/contribution/kolla-group/30 > > > > > __ > > 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 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] [infra] Size of images built in the gate
right now, there is no extra disk in the test vms. we set up a loop device by manually. see these two link[0][1]. I think we can increase the value to a bigger one. [0] https://github.com/openstack/kolla/blob/master/tools/setup_RedHat.sh#L13 [1] https://github.com/openstack/kolla/blob/master/tools/setup_Debian.sh#L29 On Mon, Mar 14, 2016 at 11:25 PM, Paul Bourke wrote: > Hi all, > > I'm currently working to add new gates for the oraclelinux image base type > (https://blueprints.launchpad.net/kolla/+spec/oraclelinux-gate) and had a > question on size available in the gate VMs. > > Right now the binary build is running out of space in the gate, as it > exceeds the 10GB we're allocating for /var/lib/docker. For me, a current > local build using binary+oraclelinux is clocking in at 10.01GB, where as > the centos+binary is a little smaller at 8.89GB. > > Is it written anywhere exactly what space is available in the gate VMs? > Sam mentioned briefly that different providers used in the gate give a > variety of disk sizes, so do we have an idea what we can reasonably bump > the docker partition to? > > The above number indicates centos will likely soon run into the same > problem as we dockerise more of the big tent, so I think it's a good idea > to check this now before more gates start falling over. > > Thanks, > -Paul > > p.s. if people are interested here's lists sorted by name of the > oraclelinux and centos builds: > > oraclelinux: http://paste.fedoraproject.org/339672/96915914 > centos: http://paste.fedoraproject.org/339673/57969163 > > __ > 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches
+1 On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey wrote: > +1 for sure > > -Ryan > > - Original Message - > From: "Paul Bourke" > To: openstack-dev@lists.openstack.org > Sent: Friday, March 25, 2016 11:43:06 AM > Subject: Re: [openstack-dev] [kolla][vote] deprecation of > icehosue/juno/kilo branches > > +1 > > On 25/03/16 15:36, Steven Dake (stdake) wrote: > > Hey folks, > > > > These branches are essentially unmaintained and we have completely given > > up on them. That’s ok – they were paths of our development. I didn't > > really want to branch them in the first place, but the community > > demanded it, so I delivered that :) > > > > Now that our architecture is fairly stable in liberty and mitaka, I > > think it makes sense to do the following > > 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol > > 2. Ask infrastructure to remove the branches from git > > > > This is possible; I have just verified in openstack-infra. I'd like a > > vote from the core review team. If you would like to see the kilo > > branch stay, please note that, and if there is a majority on > > icehosue/juno but not kilo I'll make the appropriate arrangements with > > openstack-infra. > > > > I will leave voting open for 1 week until Saturday April 2nd. I will > > close voting early if there is a majority vote. > > > > Regards > > -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 > > > > __ > 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 > -- Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [networking-sfc] Stable/Ocata Version
any update for releasing stable/ocata branch or tag? It is Mar already. On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie wrote: > Gary, > >The plan is to have a stable/ocata branch by end of month. > > -Louis > > > > *From:* Gary Kotton [mailto:gkot...@vmware.com] > *Sent:* Sunday, February 19, 2017 4:29 AM > *To:* OpenStack List > *Subject:* [openstack-dev] [networking-sfc] Stable/Ocata Version > > > > Hi, > > When will this repo have a stable/ocata branch? > > Thanks > > Gary > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][infra] does someone cares about Jenkins? I stopped.
thanks for noticing the gate related issue. for #1, feel free to push a patch to improve this. Kolla is very open for code change and gate change. So if you have any idea, try to push it. for #2, yes. Network causes some issue when building or pulling images. OpenStack-infra provide lots of mirrors already and Kolla is already configured to use them[0]. But the issue is Kolla depends on lots of other repo. like elasticsearch, rdo trunk repo etc. I hope OpenStack-infra could add more mirror repos, but it should be hard to mirror those, especially for RDO trunk. on the other hand, when building kolla images, yum/apt are trying to run clean for each image, and most images are trying to install the same package, for example, nova-compute and nova-libvirt are installing qemu both. So I am thinking set up a proxy with cache in gate's VM, and it will speed up then building and reduce the issue caused network. I will try this. At the end, hope more guys could pay attention to the Kolla gate issue and try to improve it. [0] https://github.com/openstack/kolla/blob/master/tools/setup_gate.sh#L52,L77 On Fri, Mar 3, 2017 at 6:12 AM, Marcin Juszkiewicz < marcin.juszkiew...@linaro.org> wrote: > W dniu 02.03.2017 o 20:19, Joshua Harlow pisze: > >> 1. Kolla output is nightmare to debug. > >> > >> There is --logs-dir option to provide separate logs for each image build > >> but it is not used. IMHO it should be as digging through such logs is > >> easier. > >> > > > > I to find the kolla output a bit painful, and I'm willing to help > > improve it, what would you think is a better approach (that we can try > > to get to). > > Once I discovered --logs-dir option I stopped caring of normal kolla > output. If Jenkins jobs could be changed to make use of it and to > provide those logs it would make not only me happy. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [neutron][sfc] stable/ocata version
This is talked in [0]. sfc team said > we will pull a stable/ocata branch around end of Feb or early March the latest. [0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton wrote: > Hi, > > We are pretty blocked at the moment with our gating on stable/ocata. This > is due to the fact that there is no networking-sfc version tagged for ocata. > > Is there any ETA for this? > > Thanks > > Gary > > > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [neutron][sfc][release] stable/ocata version
Add [release] tag in subject. Do not follow the OpenStack release schedule will cause lots of issues. Like requirements changes, patches is merged which should not be merged into stable. It also may break the deploy project release schedule( like Kolla will not be released until sfc release ocata branch and tag ). I hope sfc team could follow the OpenStack release schedule, even though it may cause some cherry-pick, but it is safer and how OpenStack project live. On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton wrote: > Please note that things are going to start to get messy now – there are > changes in neutron that break master and these will affect the cutting of > the stable version. One example is https://review.openstack.org/441654 > > > > So I suggest cutting a stable ASAP and then cherrypicking patches > > > > *From: *Gary Kotton > *Reply-To: *OpenStack List > *Date: *Sunday, March 5, 2017 at 9:36 AM > > *To: *OpenStack List > *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version > > > > Thanks! > > > > *From: *Jeffrey Zhang > *Reply-To: *OpenStack List > *Date: *Sunday, March 5, 2017 at 9:12 AM > *To: *OpenStack List > *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version > > > > This is talked in [0]. sfc team said > > > > > we will pull a stable/ocata branch around end of Feb or early March the > latest. > > > > [0] http://lists.openstack.org/pipermail/openstack-dev/ > 2017-February/112580.html > > > > On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton wrote: > > Hi, > > We are pretty blocked at the moment with our gating on stable/ocata. This > is due to the fact that there is no networking-sfc version tagged for ocata. > > Is there any ETA for this? > > Thanks > > Gary > > > > > __ > 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 > > > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > <https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw&m=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA&s=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc&e=> > > ______ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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][keyston] better way to rotate and distribution keystone fernet keys in container env
Kolla have support keystone fernet keys. But there are still some topics worth to talk. The key issue is key distribution. Kolla's solution is like * there is a task run frequently by cronjob to check whether the key should be rotate. This is controlled by `fernet_token_expiry` variable * When key rotate is required, the task in cron job will generate a new key by using `keystone-manage fernet-rotate` and distribute all keys in /etc/keystone/fernet-keys folder to other by using `rsync --delete` one issue is: there is no global lock in rotate and distribute steps. above command is ran on all controllers. it may cause issues if all controllers run this at the same time. Since we are using Ansible as deployment tools. there is not daemon agent at all to keep rotate and distribution atomic. Is there any easier way to implement a global lock? possible solution: 1. configure cron job with different time on each controller 2. implement a global lock? ( no idea how ) [0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env
fix subject typo On Mon, Mar 6, 2017 at 12:28 PM, Jeffrey Zhang wrote: > Kolla have support keystone fernet keys. But there are still some > topics worth to talk. > > The key issue is key distribution. Kolla's solution is like > > * there is a task run frequently by cronjob to check whether > the key should be rotate. This is controlled by > `fernet_token_expiry` variable > * When key rotate is required, the task in cron job will generate a > new key by using `keystone-manage fernet-rotate` and distribute all > keys in /etc/keystone/fernet-keys folder to other by using > `rsync --delete` > > one issue is: there is no global lock in rotate and distribute steps. > above command is ran on all controllers. it may cause issues if > all controllers run this at the same time. > > Since we are using Ansible as deployment tools. there is not daemon > agent at all to keep rotate and distribution atomic. Is there any > easier way to implement a global lock? > > possible solution: > 1. configure cron job with different time on each controller > 2. implement a global lock? ( no idea how ) > > [0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [neutron][sfc] stable/ocata version
great. thanks. On Tue, Mar 7, 2017 at 3:14 AM, Dariusz Śmigiel wrote: > 2017-03-06 11:27 GMT-06:00 Henry Fourie : > > Gary, > > > >Awaiting approval: > > > > https://review.openstack.org/#/c/439200 > > > > -Louis > > > It's merged. Stable branch is created. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [release][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March
Sorry for late. But Kolla project need a new release candidate. I will push it today. On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500: > > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500: > > > > > > Release Tasks > > > - > > > > > > Liaisons for cycle-trailing projects should prepare their final > > > release candidate tags by Monday 6 March. The release team will > > > prepare a patch showing the final release versions on Wednesday 7 > > > March, and PTLs and liaisons for affected projects should +1. We > > > will then approve the final releases on Thursday 8 March. > > > > We have 13 cycle-trailing deliverables without final releases for Ocata. > > All have at least one release candidate, so if no new release candidates > > are proposed *today* I will prepare a patch using these versions as the > > final and we will approve that early Wednesday. > > > > If you know that you need a new release candidate, please speak up now. > > > > If you know that you do not need a new release candidate, please also > > let me know that. > > > > Thanks! > > Doug > > > > $ list-deliverables --series ocata --missing-final -v > > fuel fuel 11.0.0.0rc1 other >cycle-trailing > > instack-undercloud tripleo 6.0.0.0rc1 other >cycle-trailing > > kolla-ansible kolla4.0.0.0rc1 other >cycle-trailing > > kolla kolla4.0.0.0rc1 other >cycle-trailing > > openstack-ansible OpenStackAnsible 15.0.0.0rc1 other >cycle-trailing > > os-apply-configtripleo 6.0.0.0rc1 other >cycle-with-milestones > > os-cloud-configtripleo 6.0.0.0rc1 other >cycle-with-milestones > > os-collect-config tripleo 6.0.0.0rc1 other >cycle-with-milestones > > os-net-config tripleo 6.0.0.0rc1 other >cycle-with-milestones > > os-refresh-config tripleo 6.0.0.0rc1 other >cycle-with-milestones > > tripleo-heat-templates tripleo 6.0.0.0rc1 other >cycle-trailing > > tripleo-image-elements tripleo 6.0.0.0rc1 other >cycle-trailing > > tripleo-puppet-elementstripleo 6.0.0.0rc1 other >cycle-trailing > > > > I have lined up patches with the final release tags for all 3 projects. > Please review and +1 or propose a new patch with an updated release > candidate. > > Ansible: https://review.openstack.org/442138 > Kolla: https://review.openstack.org/442137 > TripleO: https://review.openstack.org/442129 > > Doug > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env
On Mon, Mar 6, 2017 at 6:05 PM, Paul Bourke wrote: > Two initial ideas: > > We could create a specific ansible task to rotate the keys, and document > that operator should set up a cron job on the deployment node to run this > periodically. > > We could also look at making use of VRRP (keepalived). Potentially the > cron job could run on every controller, but only take action if it > identifies it's the one with the VIP. > > The second seems preferable to me as it requires no additional effort on > the part of the operator. Maybe there's problems with this though that I'm > not thinking of. > > -Paul > Thanks Paul, second seems better. We can implement a file lock to ensure only one rotate and distribute process is running at the same time. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env
On Tue, Mar 7, 2017 at 2:09 AM, Matt Fischer wrote: > I don't think it would cause an issue if every controller rotated all at > once. The issues are more along the lines of rotating to key C when there > are tokens out there that are encrypted with keys A and B. In other words > over-rotation. As long as your keys are properly staged, do the rotation > all at once or space them out, should not make any difference. > The issue is "at once". It takes some time to rotate and distribute the keys. There is one case that. controller A and controller B generate a new different keys. Then they copy the key to other by using rsync. A: 0 1 2 3 B: 0' 1' 2 3 When distributing, the 0/0' and 1/1' may be overrode(rsync hold the delete file handler and copy it to other one). it will lead to A: 0' 1' 2 3 B: 0 1 2 3 next rotation, it may become A: 0' 1' 2' 3 B: 0 1 2 3 after distribute , it become A: 0 1 2 3 B: 0' 1' 2' 3 Next rotation and distribute, issue happen. This is a small probability， but it still possible. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [networking-sfc] Stable/Ocata Version
roger. thanks all guys. On Tue, Mar 7, 2017 at 3:26 AM, Cathy Zhang wrote: > Just completed. > > > > Cathy > > > > *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com] > *Sent:* Friday, March 03, 2017 6:59 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [networking-sfc] Stable/Ocata Version > > > > any update for releasing stable/ocata branch or tag? It is Mar already. > > > > On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie > wrote: > > Gary, > >The plan is to have a stable/ocata branch by end of month. > > -Louis > > > > *From:* Gary Kotton [mailto:gkot...@vmware.com] > *Sent:* Sunday, February 19, 2017 4:29 AM > *To:* OpenStack List > *Subject:* [openstack-dev] [networking-sfc] Stable/Ocata Version > > > > Hi, > > When will this repo have a stable/ocata branch? > > Thanks > > Gary > > > __ > 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 > > > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud archive ocata repo bust
Kolla deploy ubuntu gate is red now. here is the related bug[0]. libvirt failed to access the console.log file when booting instance. After made some debugging, i got following. # how console.log works nova create a empty console.log with nova:nova ( this is another bug workaround actually[1]), then libvirt ( running with root ) will change the file owner to qemu process user/group ( configured by dynamic_ownership ). Now qemu process can write logs into this file. # what's wrong now libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to write logs into console.log file # other test * ubuntu + fallback libvirt 1.3.x works [2] * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to nova:nova works, too.[3] * centos + libvirt 2.0.0 works, never saw such issue in centos. # conclusion I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654 [1] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2922,L2952 [2] https://review.openstack.org/442673 [3] https://review.openstack.org/442850 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Proposing duonghq for core
+1 from me On Wed, Mar 8, 2017 at 2:41 PM, Michał Jastrzębski wrote: > Hello, > > I'd like to start voting to include Duong (duonghq) in Kolla and > Kolla-ansible core teams. Voting will be open for 2 weeks (ends at > 21st of March). > > Consider this my +1 vote. > > Cheers, > Michal > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud archive ocata repo bust
Thanks Corey, But i tried ocata proposed repo, the issue is still happening. On Wed, Mar 8, 2017 at 10:03 PM, Corey Bryant wrote: > > > On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang > wrote: > >> Kolla deploy ubuntu gate is red now. here is the related bug[0]. >> >> libvirt failed to access the console.log file when booting instance. After >> made some debugging, i got following. >> >> > Jeffrey, This is likely fixed in ocata-proposed and should be promoted to > ocata-updates soon after testing completes. https://bugs.launchpad.net/ > ubuntu/+source/libvirt/+bug/1667033. > > Corey > > > # how console.log works >> nova create a empty console.log with nova:nova ( this is another bug >> workaround actually[1]), then libvirt ( running with root ) will change >> the >> file owner to qemu process user/group ( configured by dynamic_ownership >> ). >> Now qemu process can write logs into this file. >> >> # what's wrong now >> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to >> write >> logs into console.log file >> >> # other test >> >> * ubuntu + fallback libvirt 1.3.x works [2] >> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to >> nova:nova works, too.[3] >> * centos + libvirt 2.0.0 works, never saw such issue in centos. >> >> # conclusion >> I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership >> >> >> [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654 >> [1] https://github.com/openstack/nova/blob/master/nova/virt/ >> libvirt/driver.py#L2922,L2952 >> [2] https://review.openstack.org/442673 >> [3] https://review.openstack.org/442850 >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Tags, revisions, dockerhub
I think we have two topics and improvements here 1. images in https://hub.docker.com/r/kolla/ 2. tag in end-user env. # images in hub.docker.com we are building kolla tag image and push them into hub.docker.com. After this, we do nothing for these images. The issue is 1. any security update is not included in these images. solution: I do not think use 4.0.0-1 4.0.0-2 in hub.docker.com is a good idea. if so, we need mark what 4.0.0-1 container and what's the difference with 4.0.0-2. This will make another chaos. And any prod env shouldn't depend on hub.docker.com's images, which is vulnerable to attack and is mutable. 2. branch images are not pushed. solution: we can add a job to push branch images into hub.docker.com like inc0 said. For example: centos-source-nova-api:4.0.0 centos-source-nova-api:ocata centos-source-nova-api:pike centos-source-nova-api:master But branch tag images is not stable ( even its name is stable/ocata ), users are not recommended to use these images # images in end-user env I recommended end user should build its own image rather then use hub.docker.com directly. in my env, I build images with following tag rule. when using 4.0.0 to build multi time, i use different tag name. For example 1st: 4.0.0.1 2nd: 4.0.0.2 3rd: 4.0.0.3 ... The advantage in this way is: keep each tag as immutable ( never override ) On Tue, Apr 18, 2017 at 6:46 AM, Steve Baker wrote: > > > On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann > wrote: > >> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700: >> > My dear Kollegues, >> > >> > Today we had discussion about how to properly name/tag images being >> > pushed to dockerhub. That moved towards general discussion on revision >> > mgmt. >> > >> > Problem we're trying to solve is this: >> > If you build/push images today, your tag is 4.0 >> > if you do it tomorrow, it's still 4.0, and will keep being 4.0 until >> > we tag new release. >> > >> > But image built today is not equal to image built tomorrow, so we >> > would like something like 4.0.0-1, 4.0.0-2. >> > While we can reasonably detect history of revisions in dockerhub, >> > local env will be extremely hard to do. >> > >> > I'd like to ask you for opinions on desired behavior and how we want >> > to deal with revision management in general. >> > >> > Cheers, >> > Michal >> > >> >> What's in the images, kolla? Other OpenStack components? > > > Yes, each image will typically contain all software required for one > OpenStack service, including dependencies from OpenStack projects or the > base OS. Installed via some combination of git, pip, rpm, deb. > > >> Where does the >> 4.0.0 come from? >> >> > Its the python version string from the kolla project itself, so ultimately > I think pbr. I'm suggesting that we switch to using the > version.release_string[1] which will tag with the longer version we use for > other dev packages. > > [1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py > > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade pbr, docker-py and oslo.utils
imo, we should follow global requirements restrict and upgrade the package when openstack/requirements upgrade it. several reason. 1. Even if you do not co-install kolla with other project, it also affect the distro packaging. For example RDO package kolla now and we should provide a good requirements.txt for them. And we do not prevent user to co-install kolla with other project too. 2. requirements upgrade may related to vulnerable bug. 3. It is hard to maintain the requirements for kolla with project/requirements. On Thu, Apr 20, 2017 at 11:45 AM, wrote: > Hello, > > > As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] , > > docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on > > oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of > uuid.uuid4() to > > generate UUID. > > > IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to, > > and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean > > If we keep Kolla's requirement in Ocata as what it was in Newton, upper > layer > > user of Kolla like daisycloud-core project can still keep other things > unchanged > > to upgrade Kolla from stable/newton to stable/ocata. Otherwise, we have to > > upgrade from centos-release-openstack-newton to > > centos-release-openstack-ocata(we do not use pip since it conflicts with > yum > > on files installed by same packages). But this kind of upgrade may be too > > invasive that may impacts other applications. > > > I know that there were some discusstions about global requirements update > > these days. So if not really need to do these upgrades by Kolla itself, can > > we just keep the requirement unchanged as long as possible? > > > My 2c. > > > [1] https://github.com/openstack/kolla/commit/ > 2f50beb452918e37dec6edd25c53e407c6e47f53 > > [2] https://github.com/openstack/kolla/commit/ > 85abee13ba284bb087af587b673f4e44187142da > > [3] https://github.com/openstack/kolla/commit/ > cee89ee8bef92914036189d02745c08894a9955b > > > > > > > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core
+1 On Wed, May 3, 2017 at 12:31 AM, Steven Dake (stdake) wrote: > +1 > > > -Original Message- > From: Michał Jastrzębski > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, May 2, 2017 at 8:30 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau > for kolla and kolla-ansible core > > Hello, > > It's my pleasure to start another core reviewer vote. Today it's > Bertrand (blallau). Consider this mail my +1 vote. Members of > kolla-ansible and kolla core team, please cast your votes:) Voting > will be open for 2 weeks (until 16th of May). > > I also wanted to say that Bertrand went through our core mentorship > program (if only for few weeks because he did awesome job before too) > :) > > Thank you, > Michal > > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [TripleO][Kolla] default docker storage backend for TripleO
btrfs and direct-lvm is recommended for prod env. overlay is bad. On Thu, May 18, 2017 at 8:38 AM, Fox, Kevin M wrote: > I've only used btrfs and devicemapper on el7. btrfs has worked well. > devicemapper ate may data on multiple occasions. Is redhat supporting > overlay in the el7 kernels now? > > Thanks, > Kevin > > From: Dan Prince [dpri...@redhat.com] > Sent: Wednesday, May 17, 2017 5:24 PM > To: openstack-dev > Subject: [openstack-dev] [TripleO][Kolla] default docker storage backend > forTripleO > > TripleO currently uses the default "loopback" docker storage device. > This is not recommended for production (see 'docker info'). > > We've been poking around with docker storage backends in TripleO for > almost 2 months now here: > > https://review.openstack.org/#/c/451916/ > > For TripleO there are a couple of considerations: > > - we intend to support in place upgrades from baremetal to containers > > - when doing in place upgrades re-partitioning disks is hard, if not > impossible. This makes using devicemapper hard. > > - we'd like to to use a docker storage backend that is production > ready. > > - our target OS is latest Centos/RHEL 7 > > As we approach pike 2 I'm keen to move towards a more production docker > storage backend. Is there consensus that 'overlay2' is a reasonable > approach to this? Or is it too early to use that with the combinations > above? > > Looking around at what is recommended in other projects it seems to be > a mix as well from devicemapper to btrfs. > > [1] https://docs.openshift.com/container-platform/3.3/install_config/in > stall/host_preparation.html#configuring-docker-storage > [2] http://git.openstack.org/cgit/openstack/kolla/tree/tools/setup_RedH > at.sh#n30 > > > Dan > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kolla-ansible] Proposing Surya (spsurya) for core
+1 nice jobs ;) On Wed, Jun 14, 2017 at 11:52 PM, Paul Bourke wrote: > +1, thanks Surya for all your work > > > On 14/06/17 16:46, Michał Jastrzębski wrote: > >> Hello, >> >> With great pleasure I'm kicking off another core voting to >> kolla-ansible and kolla teams:) this one is about spsurya. Voting will >> be open for 2 weeks (till 28th Jun). >> >> Consider this mail my +1 vote, you know the drill:) >> >> Regards, >> Michal >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] why common_options type is dictionary ?
there are lots of non-plain variables in kolla, dict or list in Ansible.
if you do not want to override the dict, you can add following into
globals.yml file.
docker_common_options:
auth_email: "{{ docker_registry_email }}"
auth_password: "{{ docker_registry_password }}"
auth_registry: "{{ docker_registry }}"
auth_username: "{{ docker_registry_username }}"
environment:
KOLLA_CONFIG_STRATEGY: "{{ config_strategy }}"
custom_key: custom value
restart_policy: "{{ docker_restart_policy }}"
restart_retries: "{{ docker_restart_policy_retry }}"
On Tue, Jul 11, 2017 at 4:55 PM, Paul Bourke wrote:
> Because its a series of key value pairs: https://github.com/openstack/k
> olla-ansible/blob/master/ansible/group_vars/all.yml#L96-L105
>
> Is there another type you feel would fit better?
>
>
> On 11/07/17 05:22, Margin Hu wrote:
>
>> Hi Guys:
>>
>> I want to set docker_common_options parameter but find its type is
>> dictionary. why?
>>
>> ansible/roles/zun/tasks/pull.yml:5:common_options: "{{
>> docker_common_options }}"
>> tests/test_kolla_docker.py:44: common_options=dict(required=False,
>> type='dict', default=dict()),
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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
Re: [openstack-dev] [kolla] failed to download image from TryStack
first of all, this site is not trystack, it is tarballs.openstack.org. I asked openstack infra team. got following feedback > this was disabled yesterday since the images produced massive load. fungi started putting up a caching proxy for these. This is disabled and will be enabled in the future. On Tue, Jul 11, 2017 at 9:22 AM, Margin Hu wrote: > Hi Guys > > I want to try community image , bug failed to download. > > [root@server opt]# wget https://tarballs.openstack.org > /kolla/images/centos-source-registry-ocata.tar.gz > --2017-07-11 09:12:37-- https://tarballs.openstack.org > /kolla/images/centos-source-registry-ocata.tar.gz > Resolving tarballs.openstack.org (tarballs.openstack.org)... > 23.253.108.137, 2001:4800:7817:104:be76:4eff:fe05:dbee > Connecting to tarballs.openstack.org > (tarballs.openstack.org)|23.253.108.137|:443... > connected. > HTTP request sent, awaiting response... 403 Forbidden > 2017-07-11 09:12:37 ERROR 403: Forbidden. > > > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][kolla-k8s] Installation in ubuntu 14.04
technically, it should work. But this is not tested, at least on kolla CI gate. On Tue, Aug 8, 2017 at 10:13 AM, ESWAR RAO wrote: > Hi All, > > I am trying to install openstack containers using kolla-k8s. > > I am following below link: > https://docs.openstack.org/kolla-kubernetes/latest/deployment-guide.html# > > As per link, its only supported/validated for ubuntu 16.04. > > Please let me know if any version 0.6/0.5.0.4 is supported for ubuntu > 14.04. > Its not mentioned in release notes. > > Also how to determine upfront which openstack version does it support. > > Thanks > Eswar Rao > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team
+1 On Sun, Aug 13, 2017 at 12:38 AM, Serguei Bezverkhi (sbezverk) < sbezv...@cisco.com> wrote: > +1 > > well deserved > > Serguei > > *From: *"Vikram Hosakote (vhosakot)" > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Friday, August 11, 2017 at 7:31 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum > to core team > > > > Rich? Well, um ;) > > > > Although I’m not a kolla-kubernetes core and my vote does not matter at > all, I’ll still give > > my +1 to Rich J. > > > > Amazing work in kolla-kubernetes Rich especially your recent contribution > of the Python > > tool to automate the deployment of kolla-kubernetes. > > > > https://review.openstack.org/#/c/487972/ > > > > Regards, > > Vikram Hosakote > > IRC: vhosakot > > > > *From: *Michał Jastrzębski > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Friday, August 11, 2017 at 12:01 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *[openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to > core team > > > > Hello, > > > > It's my pleasure to start another core team vote. This time for our > > colleague rwellum. I propose that he joins kolla-kubernetes team. > > > > This is my +1 vote. Every kolla-kubernetes core has a vote and it can > > be veto'ed. > > > > Voting will last 2 weeks and will end at 25th of August. > > > > Cheers, > > Michal > > > > __ > > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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][puppet][openstack-ansible] Better way to run wsgi service.
We are moving to deploy service via WSGI[0]. There are two recommended ways. - apache + mod_wsgi - nginx + uwsgi later one is more better. For traditional deployment, it is easy to implement. Use one uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc). Then one nginx process to forward the http require into uwsgi server. But kolla is running one process in one container. If we use the recommended solution, we have to use two container to run nova-api container. and it will generate lots of containers. like: nginx-nova-api, uwsig-nova-api. i propose use uwsgi native http mode[1]. Then one uwsgi container is enough to run nova-api service. Base one the official doc, if there is no static resource, uWSGI is recommended to use as a real http server. So how about this? [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html [1] http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.
thanks mnaser and sam for the advice. i think uwsgi + native http is not a good solution, nova. A http server + uwsgi is better. So i am imaging that the deployment architecture will be like haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc. As mnaster said, one http server serve for others uwsgi services. on the other hand, which following solution is better? - apache + mod_uwsgi ( not recommended by uwsgi ) - apache + mode_proxy_uwsgi ( recommended by uwsgi) - nginx + uwsgi So the question is why community choose apache rather than nginx? [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple wrote: > I have been running api services behind uwsgi in http mode from Newton > forward. I recently switched to the uwsgi+nginx model with 2 containers > since I was having wierd issues with things that I couldn't track down. > Mainly after I started using keystone with ldap. There would be timeouts > and message-to-long type errors that all went away with nginx. > > Additionally, running with HTTPS was measurably faster with nginx proxying > to a uwsgi socket. > > This was just my experience with it, if you do want to switch to > uwsgi+http make sure you do thorough testing of all the components or you > may be left with a component that just won't work with your model. > > > On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser > wrote: > >> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang >> wrote: >> > We are moving to deploy service via WSGI[0]. >> > >> > There are two recommended ways. >> > >> > - apache + mod_wsgi >> > - nginx + uwsgi >> > >> > later one is more better. >> > >> > For traditional deployment, it is easy to implement. Use one >> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc). >> > Then one nginx process to forward the http require into uwsgi server. >> > >> > But kolla is running one process in one container. If we use >> > the recommended solution, we have to use two container to run >> > nova-api container. and it will generate lots of containers. >> > like: nginx-nova-api, uwsig-nova-api. >> > >> > i propose use uwsgi native http mode[1]. Then one uwsgi >> > container is enough to run nova-api service. Base one the official >> > doc, if there is no static resource, uWSGI is recommended to use >> > as a real http server. >> > >> > So how about this? >> >> I think this is an interesting approach. At the moment, the Puppet >> modules currently allow deploying for services using mod_wsgi. >> Personally, I don't think that relying on the HTTP support of uWSGI is >> very favorable. It is quite difficult to configure and 'get right' >> and it leaves a lot to be desired (for example, federated auth relies >> on Apache modules which would make this nearly impossible). >> >> Given that the current OpenStack testing infrastructure proxies to >> UWSGI, I think it would be best if that approach is taken. This way, >> a container (or whatever service) would expose a UWSGI API, which you >> can connect whichever web server that you need. >> >> In the case of Kolla, the `httpd` container would be similar to what >> the `haproxy` is. In the case of Puppet, I can imagine this being >> something to be managed by the user (with some helpers in there). I >> think it would be interesting to add the tripleo folks on their >> opinion here as consumers of the Puppet modules. >> >> > >> > >> > [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in >> -wsgi.html >> > [1] >> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-u >> se-uwsgi-s-http-capabilities-in-production >> > >> > -- >> > Regards, >> > Jeffrey Zhang >> > Blog: http://xcodest.me >> > >> > ___ >> > OpenStack-operators mailing list >> > openstack-operat...@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > >> >> ___ >> OpenStack-operators mailing list >> openstack-operat...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms
Hi Kendall, Kolla project would like to have a on-boarding session too. thanks. On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson wrote: > Added Nova to my list with Dan, Melanie, and Ed as speakers. > > Thanks Matt, > -Kendall (diablo_rojo) > > On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann > wrote: > >> On 10/9/2017 4:24 PM, Kendall Nelson wrote: >> > Wanted to keep this thread towards the top of inboxes for those I >> > haven't heard from yet. >> > >> > About a 1/4 of the way booked, so there are still slots available! >> > >> > -Kendall (diablo_rojo) >> >> I've tricked the following people into running a Nova on-boarding room: >> >> - "Super" Dan Smith >> - Melanie "Structured Settlement" Witt >> - Ed "Alternate Hosts" Leafe >> >> -- >> >> Thanks, >> >> Matt >> >> >> __ >> 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms
I am the speaker. Michal couldn't be Sydney this summit. On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson wrote: > Added Kolla to my list. Would the speakers be you and Michal? > > -Kendall (diablo_rojo) > > > On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang > wrote: > >> Hi Kendall, >> >> Kolla project would like to have a on-boarding session too. >> >> thanks. >> >> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson >> wrote: >> >>> Added Nova to my list with Dan, Melanie, and Ed as speakers. >>> >>> Thanks Matt, >>> -Kendall (diablo_rojo) >>> >>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann >>> wrote: >>> >>>> On 10/9/2017 4:24 PM, Kendall Nelson wrote: >>>> > Wanted to keep this thread towards the top of inboxes for those I >>>> > haven't heard from yet. >>>> > >>>> > About a 1/4 of the way booked, so there are still slots available! >>>> > >>>> > -Kendall (diablo_rojo) >>>> >>>> I've tricked the following people into running a Nova on-boarding room: >>>> >>>> - "Super" Dan Smith >>>> - Melanie "Structured Settlement" Witt >>>> - Ed "Alternate Hosts" Leafe >>>> >>>> -- >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> >>>> __ >>>> 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 >>> >>> >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> __ >> 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team
+1 On Fri, Nov 3, 2017 at 9:46 AM, Xinliang Liu wrote: > +1, as I know hrw makes great contribution on ARM. > > On 2 November 2017 at 23:58, Michał Jastrzębski wrote: > > It's my great pleasure to start another voting for core team addition! > > > > Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM! > > Voting will be open for 14 days (until 16th of Nov). > > > > Consider this mail my +1 vote > > > > Regards, > > Michal > > > > > __ > > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Ansiblize init-runonce script
hi check this [0]. I tried to convert it to ansible playbooks. [0] https://review.openstack.org/523072 On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani wrote: > Hi, > > While exploring kolla-ansible I ran into a few issues with > init-runonce script. This lead to following bugs and patches: > > https://launchpad.net/bugs/1732963 > https://review.openstack.org/51 > https://review.openstack.org/521190 > > But it was highlighted that instead of fixing/changing the > script, 'ansibilzing' it would be the ideal solution. > Hence I hereby formally propose the same. > > My thoughts: > * Playbook Name: init-stack.yml > > * Playbook path can be: > kolla-ansible/ansible/init-stack.yml > > * The play can be executed like: > $ kolla-ansible init-stack -i > > * The cirros test image should be downloaded in /tmp > > * What should be the behavior if the play is run multiple times > against the same stack? > - some error message OR > - simply ignore the action > > Kindly provide suggestions. > > -- > Best Regards, > Ravi J. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Ansiblize init-runonce script
in my opinion, idempotent scrip t is very necessary. for several reason - there is already some idempotent logical in the script - it is common that this script failed by wrong configuration, after fix the config, ops will want to run this script again. On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke wrote: > I think this came up before at one stage. My position is I don't see the > need to ansible-ise small shell scripts. init-runonce is currently just an > easy to understand sequence of openstack commands provided to help people > test/demo their setups. Unless we want to make it more than that, i.e. make > it idempotent, customizable, etc. I don't see the need to wheel in Ansible. > > On 28/11/17 03:23, Jeffrey Zhang wrote: > >> hi >> >> check this [0]. I tried to convert it to ansible playbooks. >> >> [0] https://review.openstack.org/523072 >> >> On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani < >> rsjeth...@gmail.com <mailto:rsjeth...@gmail.com>> wrote: >> >> Hi, >> >> While exploring kolla-ansible I ran into a few issues with >> init-runonce script. This lead to following bugs and patches: >> >> https://launchpad.net/bugs/1732963 <https://launchpad.net/bugs/17 >> 32963> >> https://review.openstack.org/51 >> <https://review.openstack.org/51> >> https://review.openstack.org/521190 >> <https://review.openstack.org/521190> >> >> But it was highlighted that instead of fixing/changing the >> script, 'ansibilzing' it would be the ideal solution. >> Hence I hereby formally propose the same. >> >> My thoughts: >> * Playbook Name: init-stack.yml >> >> * Playbook path can be: >> kolla-ansible/ansible/init-stack.yml >> >> * The play can be executed like: >> $ kolla-ansible init-stack -i >> >> * The cirros test image should be downloaded in /tmp >> >> * What should be the behavior if the play is run multiple times >> against the same stack? >>- some error message OR >>- simply ignore the action >> >> Kindly provide suggestions. >> >> -- >> Best Regards, >> Ravi J. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me <http://xcodest.me/> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Ansiblize init-runonce script
yes. it is not recommend to use in prod env, i never used this script. But the reality is lots users are using it, at least in the test environment. and there are patches trying to make this script idempotent recently. 2017年11月28日 23:28，"Sam Yaple" 写道： > For what its worth, this init-runonce script was never meant for > production usage. Ops *shouldn't* be running it like you suggest. It was > historically for use in the gate and a quick-n-dirty environment setup for > testing. > > If you want to get into writing operations scripts, thats your > prerogative, but it was discussed before and mostly considered a bad idea. > > Thanks, > SamYaple > > > > Original Message > Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script > Local Time: November 28, 2017 8:10 AM > UTC Time: November 28, 2017 1:10 PM > From: zhang.lei@gmail.com > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > > in my opinion, > > > idempotent scrip > t is very necessary. > for several reason > > - there is already some idempotent logical in the script > - it is common that this script failed by wrong configuration, > after fix the config, > ops will want to run this script again. > > On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke > wrote: > >> I think this came up before at one stage. My position is I don't see the >> need to ansible-ise small shell scripts. init-runonce is currently just an >> easy to understand sequence of openstack commands provided to help people >> test/demo their setups. Unless we want to make it more than that, i.e. make >> it idempotent, customizable, etc. I don't see the need to wheel in Ansible. >> >> On 28/11/17 03:23, Jeffrey Zhang wrote: >> >>> hi >>> >>> check this [0]. I tried to convert it to ansible playbooks. >>> >>> [0] https://review.openstack.org/523072 >>> >>> On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani < >>> rsjeth...@gmail.com <mailto:rsjeth...@gmail.com>> wrote: >>> >>> Hi, >>> >>> While exploring kolla-ansible I ran into a few issues with >>> init-runonce script. This lead to following bugs and patches: >>> >>> https://launchpad.net/bugs/1732963 <https://launchpad.net/bugs/17 >>> 32963> >>> https://review.openstack.org/51 >>> <https://review.openstack.org/51> >>> https://review.openstack.org/521190 >>> <https://review.openstack.org/521190> >>> >>> But it was highlighted that instead of fixing/changing the >>> script, 'ansibilzing' it would be the ideal solution. >>> Hence I hereby formally propose the same. >>> >>> My thoughts: >>> * Playbook Name: init-stack.yml >>> >>> * Playbook path can be: >>> kolla-ansible/ansible/init-stack.yml >>> >>> * The play can be executed like: >>> $ kolla-ansible init-stack -i >>> >>> * The cirros test image should be downloaded in /tmp >>> >>> * What should be the behavior if the play is run multiple times >>> against the same stack? >>>- some error message OR >>>- simply ignore the action >>> >>> Kindly provide suggestions. >>> >>> -- >>> Best Regards, >>> Ravi J. >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org?subject:un >>> subscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >>> >>> >>> >>> >>> -- >>> Regards, >>> Jeffrey Zhang >>> Blog: http://xcodest.me <http://xcodest.me/> >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>&g
Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.
i guess you didn't enabled one of following[0] enable_neutron_dvr: yes enable_neutron_provider_networks: yes I hit this recently. i am thinking we should remove this or make enable_neutron_provider_network=yes in default. [0] https://github.com/openstack/kolla-ansible/blob/master/ansible/group_vars/all.yml#L607 On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa wrote: > Hi Kolla Team, > > I have tried deploying Kolla OpenStack multinode and I am facing this > issue vxlan_peers_not_created > <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/> > in every deployment and I* tried the workaround* i.e restart the network > containers to get the vxlan peers > > But when I see *ip addr show *in my compute node. > > *P.S:* "ens8" is the interface I specified as > *neutron_external_interface** in globals.yml* > > > * Globals.yml-* > > > > > *# This is the raw interface given to neutron as its external network > port. Even# though an IP address can exist on this interface, it will be > unusable in most# configurations. It is recommended this interface not be > configured with any IP# addresses for that reason.* > > *neutron_external_interface: "ens8"*3: ens8: > mtu 1500 qdisc pfifo_fast state UP > group default qlen 1000 > link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.218/24 scope global ens8 >valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:fe54:b350/64 scope link >valid_lft forever preferred_lft forever > > Which should be something like the below (as per my understanding) for the > Vms to be up and running. > > 3: ens8: mtu 1500 qdisc pfifo_fast *master > ovs-system* state UP group default qlen 1000 > link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff > inet 192.168.122.165/32 scope global ens8 >valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:fe22:4bcf/64 scope link >valid_lft forever preferred_lft forever > > Is this a known issue ?? > > If yes any workaround to solve?? > > Thanks in advance. > -- > Thanks!!! > Goutham Pratapa > > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Re: About maridb 10.1 on kolla
recently, a series patches about mariadb is pushed. Current issue is - using different mariadb binary from different repo ( from percona, Mariadb official, linux distro ) - using different version number of mariadb ( 10.0 and 10.1 ) To make life easier, some patches are pushed to unify all of these. Here is my thought about this - try to bump to 10.1, which is released long time ago - use mariadb binary provided by linux disto as much as possible So here is plan - trying to upgrade to mariadb 10.1 [0][1] - use mariadb 10.1 provided by RDO on redhat family distro [2] - use mariadb 10.0 provided by UCA on ubuntu - it is told that, it not work as excepted [3] - if this does not work. we can upgrade to mariadb 10.1 provides by mariadb official on ubuntu. - use mariadb 10.1 provided by os repo on Debian. [0] https://review.openstack.org/#/c/529505/ - fix kolla-ansible for mariadb 10.1 [1] https://review.openstack.org/#/c/529199/ - fix kolla for mariadb 10.1 [2] https://review.openstack.org/#/c/468632/ - drop percona and mariadb repo [3] https://review.openstack.org/#/c/426953/ - Revert "Removed percona from ubuntu repos" On Thu, Dec 28, 2017 at 11:58 AM, Xinliang Liu wrote: > On 27 December 2017 at 20:25, Steven Dake (stdake) > wrote: > > Michal wanted to test on multinode. Not sure if he ever got there. > > > > Yep, hope someone can test on mutinode. Jeffrey4l also said to help test. > > > Anyway - feel free to take over the patch. Even though gerrit doesn't > care > > about co-authors, co-authors might, and we want to keep a tidy history of > > authorship for CLA reasons, so please use the > > > > "Co-AUthored-by: first last " at the conclusion of your commit > log. > > Done, spilt into two patches: > https://review.openstack.org/#/c/529199/ > https://review.openstack.org/#/c/468632/ > > Thanks very much. > Xinliang > > > > > Thanks > > > > > > CHeers > > -steve > > > > > > On December 26, 2017 at 2:03:44 AM, Xinliang Liu ( > xinliang@linaro.org) > > wrote: > > > > On 26 December 2017 at 15:47, Xinliang Liu > wrote: > >> On 26 December 2017 at 15:38, Marcin Juszkiewicz > >> wrote: > >>> > >>> > >>> 26.12.2017 08:05 "Xinliang Liu" napisał(a): > >>> > >>> Hi Steven, > >>> > >>> I have tested your patch[1] that works for one node Debian MariaDB > >>> 10.1 deployment. > >>> But the whole change seems be not updated for long time. Your last > >>> updated patch 12 was in May. > >>> > >>> > >>> Xinliang: you can update patch in review too. Gerrit cares about > >>> change-id > >>> field and do not care about author. So refresh patch from review and > send > >>> with "git review". > >> > >> OK. will update soon. > > > > Done. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Re: About maridb 10.1 on kolla
After using RDO mariadb, i found galera is fallback from galera-25.3.20 to 25.3.16. I am not sure what's the exact difference between these two version. But what i found is: > ‘SAFE TO BOOTSTRAP’ PROTECTION [1] > Starting with provider version 3.19, Galera has an additional protection > against attempting to boostrap the cluster using a node that may not > have been the last node remaining in the cluster prior to cluster shutdown. So the question is: it is safe to fallback galera version? [1] http://galeracluster.com/documentation-webpages/restartingcluster.html#safe-to-bootstrap-protection On Fri, Jan 5, 2018 at 1:15 AM, Marcin Juszkiewicz < marcin.juszkiew...@linaro.org> wrote: > W dniu 29.12.2017 o 07:58, Jeffrey Zhang pisze: > > recently, a series patches about mariadb is pushed. Current issue is > > > > - using different mariadb binary from different repo ( from percona, > > Mariadb official, linux distro ) > > - using different version number of mariadb ( 10.0 and 10.1 ) > > > > To make life easier, some patches are pushed to unify all of these. Here > > is my thought about this > > > > - try to bump to 10.1, which is released long time ago > > - use mariadb binary provided by linux disto as much as possible > > > > So here is plan > > > > - trying to upgrade to mariadb 10.1 [0][1] > > - use mariadb 10.1 provided by RDO on redhat family distro [2] > > - use mariadb 10.0 provided by UCA on ubuntu > > - it is told that, it not work as excepted [3] > > - if this does not work. we can upgrade to mariadb 10.1 provides by > > mariadb official on ubuntu. > > - use mariadb 10.1 provided by os repo on Debian. > > How we are with testing/merging? > > For Debian to be deployable we need 529199 in images as rest of changes > are kolla-ansible and can be cherry-picked before deployment. > > > > [0] https://review.openstack.org/#/c/529505/ - fix kolla-ansible for > > mariadb 10.1 > > merged > > > [1] https://review.openstack.org/#/c/529199/ - Fix MariaDB bootstrap > for 10.1 version > > [2] https://review.openstack.org/#/c/468632/ - Consume RDO packaged > mariadb version > > > [3] https://review.openstack.org/#/c/426953/ - Revert "Removed percona > > from ubuntu repos" > > merged > > ______ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Policy regarding template customisation
Thank Paul for pointing this out. for me, I prefer to consist with 2) There are thousands of configuration in OpenStack, it is hard for Kolla to add every key/value pair in playbooks. Currently, the merge_config is a more better solutions. On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote: > Hi all, > > I'd like to revisit our policy of not templating everything in > kolla-ansible's template files. This is a policy that was set in place very > early on in kolla-ansible's development, but I'm concerned we haven't been > very consistent with it. This leads to confusion for contributors and > operators - "should I template this and submit a patch, or do I need to > start using my own config files?". > > The docs[0] are currently clear: > > "The Kolla upstream community does not want to place key/value pairs in > the Ansible playbook configuration options that are not essential to > obtaining a functional deployment." > > In practice though our templates contain many options that are not > necessary, and plenty of patches have merged that while very useful to > operators, are not necessary to an 'out of the box' deployment. > > So I'd like us to revisit the questions: > > 1) Is kolla-ansible attempting to be a 'batteries included' tool, which > caters to operators via key/value config options? > > 2) Or, is it to be a solid reference implementation, where any degree of > customisation implies a clear 'bring your own configs' type policy. > > If 1), then we should potentially: > > * Update ours docs to remove the referenced paragraph > * Look at reorganising files like globals.yml into something more > maintainable. > > If 2), > > * We should make it clear to reviewers that patches templating options > that are non essential should not be accepted. > * Encourage patches to strip down existing config files to an absolute > minimum. > * Make this policy more clear in docs / templates to avoid frustration on > the part of operators. > > Thoughts? > > Thanks, > -Paul > > [0] https://docs.openstack.org/kolla-ansible/latest/admin/deploy > ment-philosophy.html#why-not-template-customization > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] our mascot - input needed
koala +1 On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey wrote: > koala bear > > -Ryan > > - Original Message - > From: "Vikram Hosakote (vhosakot)" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Saturday, July 16, 2016 1:24:08 PM > Subject: Re: [openstack-dev] [kolla] our mascot - input needed > > Sorry, I missed the kolla mid-cycle summit as I was at a conference. > > I will review the mid-cycle etherpad. > > Yes for the koala bear!! :) > > Regards, > Vikram Hosakote > IRC: vhosakot > > From: "Steven Dake (stdake)" < std...@cisco.com > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org > > Date: Thursday, July 14, 2016 at 1:08 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org > > Subject: [openstack-dev] [kolla] our mascot - input needed > > Hey folks, > > The OpenStack foundation is putting together mascots for every project with a > proper artist doing the work. The cool thing about this is we a) get stickers > b) have consistent look and feel among mascots in OpenStack. > > The downside is we have to make a decision. The foundation wants 3-5 choices. > > The mascot must be an animal and it can't involve glue or other inc007 > inspired ideas :) > > Obviously Koala bear is probably everyone's first choice since we have sort > of been using that as a mascot since day one. Anyone else have anything else > for me to provide the foundation with a choices 2-5? > > Please respond quickly, the foundation needs the information shortly. I'd > like to offer up two alternatives just in case. > > Regards > -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 > > __________ > 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 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag
+1 to apply I'd like to be the volunteer. On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap) wrote: > On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke wrote: >> Hi Steve, >> >> +1 to applying. I'll volunteer for the backport team also. >> >> -Paul >> >> >> On 18/07/16 13:07, Steven Dake (stdake) wrote: >>> >>> Hey Koalians, >>> >>> I'd like us to consider applying for the stable follows policy tag. >>> Full details are here: >>> >>> >>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst >>> >>> Because of the magic work we did to make liberty functional, it is >>> possible that we may not be able to apply for this tag until Liberty >>> falls into EOL. Still I personally believe intent matters most, and our >>> intent has always been for these to be stable low-rate-of-change >>> no-feature-backport branches. There are some exceptions I think we >>> would fit under for the Liberty case, so I think it is worth a shot. >>> >>> I'd need 2-4 people to commit to joining the stable backport team for >>> Kolla reviews specifically. These folks would be the only folks that >>> could ACK patches in the stable branch maintenance queue. Anyone could >>> continue to submit backport patches as they desire. >>> >>> I'll leave voting open for 1 week or until there I a majority (6 core >>> reviewers) or until there is a unanimous vote. If there is not, then we >>> won't apply. The deadline for this vote is July 25th. >>> >>> 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 >>> >> >> __ >> 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 > > +1 to apply for stable follows policy. > I would like to volunteer for the backport team. > > __ > 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 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] OpenStack Kolla - External Ceph
On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) wrote: > > At this point, I feel we are going a direction in which we try to wrap > everything anybody could possibly want to configure with Kolla by making > extensive use of global.yml. We would have to introduce flags indicating a > couple of different scenarios: > > 1. Deploy Ceph (already there: enable_ceph="yes") > 2. Use Ceph with Glance (enable_ceph_glance="yes") > 3. Use Ceph with Cinder (enable_ceph_cinder="yes") > 4. Use Ceph with Nova (enable_ceph_nova="yes") > > > I disagree. If ceph is enabled, then ceph should be used, if ceph is not > enabled, then ceph shouldn't be used. That implies all of OpenStack either > uses Ceph or not. So we really just need enable_ceph. why we need separate configuration for ceph? I think if ceph is enable, all the service should use ceph, too. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] OpenStack Kolla - External Ceph
Hi Fox, Clearly. Thanks for explanation. On Thu, Jul 21, 2016 at 3:26 PM, Mathias Ewald wrote: > @Kevin: full ack. > > Also, using S3 compliant storage for Glance is quite common, too. > > 2016-07-20 19:12 GMT+02:00 Fox, Kevin M : >> >> We use ceph with cinder and glance. I don't see a reason not to. >> >> We do not set nova to use it for anything but cinder volumes though. >> >> The reason being, if you set it up that way, your users have no way of >> opting out of the potential performance hit if using no local storage for >> non pets. >> >> If you leave it nova local, you can always still get ceph remote storage >> for the whole vm by requesting the root disk be volume backed. >> >> We also already have a ceph deployment managed without kolla, and that's >> unlikely to change. >> >> So, for our site, our settings would probably be: >> 1. Deploy Ceph (enable_ceph="no") >> 2. Use Ceph with Glance (enable_ceph_glance="yes") >> 3. Use Ceph with Cinder (enable_ceph_cinder="yes") >> 4. Use Ceph with Nova (enable_ceph_nova="no") >> >> Thanks, >> Kevin >> >> From: Jeffrey Zhang [zhang.lei@gmail.com] >> Sent: Wednesday, July 20, 2016 9:51 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph >> >> On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) >> wrote: >> > >> > At this point, I feel we are going a direction in which we try to wrap >> > everything anybody could possibly want to configure with Kolla by making >> > extensive use of global.yml. We would have to introduce flags indicating >> > a >> > couple of different scenarios: >> > >> > 1. Deploy Ceph (already there: enable_ceph="yes") >> > 2. Use Ceph with Glance (enable_ceph_glance="yes") >> > 3. Use Ceph with Cinder (enable_ceph_cinder="yes") >> > 4. Use Ceph with Nova (enable_ceph_nova="yes") >> > >> > >> > I disagree. If ceph is enabled, then ceph should be used, if ceph is >> > not >> > enabled, then ceph shouldn't be used. That implies all of OpenStack >> > either >> > uses Ceph or not. So we really just need enable_ceph. >> >> >> why we need separate configuration for ceph? I think if ceph is >> enable, all the service should use ceph, too. >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> __ >> 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 > > > > > -- > Mobil: +49 176 10567592 > E-Mail: mew...@evoila.de > > evoila GmbH > Wilhelm-Theodor-Römheld-Str. 34 > 55130 Mainz > Germany > > Geschäftsführer: Johannes Hiemer > > Amtsgericht Mainz HRB 42719 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If You > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Monitoring tooling
I am open to the choice of tools. But i am worried on thing: how to get all the host disk usage when containerized the monitor tool? On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald wrote: > Understood. > > 2016-07-25 7:34 GMT+02:00 Matthias Runge : >> >> On 25/07/16 06:38, Mathias Ewald wrote: >> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud >> > tenants rather than cloud ops? If that's the case I wont find info like >> > "controller cpu usage" or "hypervisor memory usage". >> > >> > Cheers >> > Mathias >> > >> Uhm, in this scenario, gnocchi just used as time-series database. It's >> up to you, what you feed in. collectd collects whatever you want and put >> it into your database. >> >> Best, >> Matthias >> >> -- >> Matthias Runge >> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Michael Cunningham, >> Michael O'Neill, Eric Shander >> >> __ >> 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 > > > > > -- > Mobil: +49 176 10567592 > E-Mail: mew...@evoila.de > > evoila GmbH > Wilhelm-Theodor-Römheld-Str. 34 > 55130 Mainz > Germany > > Geschäftsführer: Johannes Hiemer > > Amtsgericht Mainz HRB 42719 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If You > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Binary containers with pip install?
On Tue, Jul 26, 2016 at 5:00 PM, Dave Walker wrote: > - Add support to have per project build type, but this is likely a testing > scenario that cannot be reasonably assured. I think this is another feature we can overwrite some variables in certain image. > - Allow source installs in binary containers, but track it as a TODO bug > "Please package foo" (Launchpad has great support for linking to other bug > trackers). Then once this bug is closed, proper binary support can be > resolved. This has the benefit of 'best-effort' towards binary, with a > clear intent to move across. It also allows more testing of the binary > parts that are present, with just the source parts as required. (this is my > favourite) Love this too. Maybe we need a WARNING to the stdout to tell the operators. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Needing volunteers for Geography Coordinators for making use of OSIC cluster
+1 for APAC On Sat, Aug 6, 2016 at 12:11 AM, Steven Dake (stdake) wrote: > Typo is subject tag – please see inside :) > > From: Steven Dake > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Friday, August 5, 2016 at 6:52 AM > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: [openstack-dev] [kollla] Needing volunteers for Geography > Coordinators for making use of OSIC cluster > > Hey folks, > > The kind folks at OSIC have granted the Kolla team access to 132 nodes of > super high powered gear for scale testing Kolla. The objectives are 3 fold: > > Determine if Kolla can scale to 132 nodes for a variety of test cases – if > not fix bugs around those problems > If scalable to 132 nodes, record benchmark data around our various test > scenarios as outlined in the etherpad > Produce documentation in our repository at conclusion of OSIC scale testing > indicating the results we found > > The geography coordinators are responsible for coordinating various testing > going on within their respective geography to coordinate the activities > taking place on the loaned OSIC gear so we can "follow-the-sun" and make the > most use of the gear while we have it. The geo coordinators are also > responsible for ensuring all bugs related to problems found during osic > scale testing are tagged with "osic" in launchpad. > > We need a geo coordinator for APAC, EMEA, and US. First individual to > respond on list gets the job (per geo – need 3 volunteers) > > We have the gear for 4 weeks. We are making use of the first 3 weeks to do > scale testing of existing Kolla and the last week to test / validate / debug > Sean's bifrost automated bare metal deployment work at scale. > > The current state is the hardware is undergoing manual bare metal deployment > at present – closing in on this task being completed hopefully by end of day > (Friday Aug 5th, 2016). > > For more information, please reference the Etherpad here: > https://etherpad.openstack.org/p/kolla-N-midcycle-osic > > TIA to volunteers. > > Cheers, > -steak > > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)
+1 On Sat, Aug 20, 2016 at 1:07 AM, Swapnil Kulkarni wrote: > Thanks sdake. > > +1 :) > > On Aug 19, 2016 10:35 PM, "Steven Dake (stdake)" wrote: >> >> Coolsvap mentioned he wasn't receiving his emails at his home email >> server, so he will respond from a different mail service. Just bringing >> this up again so he can see the thread. >> >> Regards >> -steve >> >> On 8/19/16, 7:09 AM, "Kwasniewska, Alicja" >> wrote: >> >> >+1 :) >> > >> >-Original Message- >> >From: Ryan Hallisey [mailto:rhall...@redhat.com] >> >Sent: Friday, August 19, 2016 2:50 PM >> >To: OpenStack Development Mailing List (not for usage questions) >> > >> >Subject: Re: [openstack-dev] [vote][kolla] Core nomination proposal for >> >Eduardo Gonzalez Gutierrez (egonzales90 on irc) >> > >> >+1 >> > >> >-Ryan >> > >> >- Original Message - >> >From: "Steven Dake (stdake)" >> >To: "OpenStack Development Mailing List (not for usage questions)" >> > >> >Sent: Thursday, August 18, 2016 7:09:35 PM >> >Subject: [openstack-dev] [vote][kolla] Core nomination proposal for >> >Eduardo Gonzalez Gutierrez (egonzales90 on irc) >> > >> >Kolla Core Review Team: >> > >> >I am nominating Eduardo for the core reviewer team. His reviews are >> >fantastic, as I'm sure most of you have seen after looking over the >> >review queue. His 30 day stats place him at #3 by review count [1] and 60 >> >day stats [2] at #4 by review count. He is also first to review a >> >significant amount of the time which is impressive for someone new to >> >Kolla. He participates in IRC and he has done some nice code contribution >> >as well [3] including the big chunk of work on enabling Senlin in Kolla, >> >the dockerfile customizations work, as well as a few documentation fixes. >> >Eduardo is not affiliated with any particular company. As a result he is >> >not full time on Kolla like many of our other core reviewers. The fact >> >that he is part time and still doing fantastically well at reviewing is a >> >great sign of things to come :) >> > >> >Consider this nomination as my +1 vote. >> > >> >Voting is open for 7 days until August 24th. Joining the core review team >> >requires a majority of the core review team to approve within a 1 week >> >period with no veto (-1) votes. If a veto or unanimous decision is >> >reached prior to August 24th, voting will close early. >> > >> >Regards >> >-steve >> > >> >[1] http://stackalytics.com/report/contribution/kolla/30 >> >[2] http://stackalytics.com/report/contribution/kolla/60 >> >[3] >> >> > >https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2 >> >540gmail.com%253E%22 >> > >> >> > >__ >> >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 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 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)
+1 On Wed, Aug 24, 2016 at 4:45 AM, Steven Dake (stdake) wrote: > Kolla core reviewers, > > I am nominating Dave Walker for the Kolla core reviewer team. His 30 day > review stats [1] place him in the middle of the pack for reviewers and his > 60 day stats[2] are about equivalent. Dave participates heavily in IRC and > has done some good technical work including the Watcher playbook and > container. He also worked on Sensu, but since we are unclear if we are > choosing Sensu or Tig, that work is on hold. He will also be helping us > sort out how to execute with PBR going into the future on our stable and > master branches. Dave has proven to me his reviews are well thought out and > he understands the Kolla Architecture. Dave is part time like many Kolla > core reviewers and is independent of any particular affiliation. > > Consider this nomination as a +1 from me. > > As a reminder, a +1 vote indicates you approve of the candidate, an abstain > vote indicates you don't care or don't know for certain, and a –1 vote > indicates a veto. If a veto occurs or a unanimous response is reached prior > to our 7 day voting window which concludes on August 30th, voting will be > closed early. > > [1] http://stackalytics.com/report/contribution/kolla/30 > [2] http://stackalytics.com/report/contribution/kolla/60 > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Kolla configuration files owner and permission
Using the same user for running service and the configuration files is
danger. i.e. the service running user shouldn't be change the
configuration files.
a simple attack like:
* a hacker hacked into nova-api container with nova user
* he can change the /etc/nova/rootwrap.conf file and
/etc/nova/rootwrap.d file, which he can get much greater authority
with sudo
* he also can change the /etc/nova/nova.conf file to use another
privsep_command.helper_command to get greater authority
[privsep_entrypoint]
helper_command=sudo nova-rootwrap /etc/nova/rootwrap.conf
privsep-helper --config-file /etc/nova/nova.conf
So right rule should be: do not let the service running user have
write permission to configuration files,
about for the nova.conf file, i think root:root with 644 permission
or root:nova with 640 should be enough
for the directory file, root:root with 755 or root:nova with 750
should be enough.
On Tue, Aug 23, 2016 at 11:11 PM, Steven Dake (stdake) wrote:
>
>
>
>
>
> On 8/23/16, 7:05 AM, "Gerard Braad" wrote:
>
>>On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn wrote:
>>> I also prefer a dedicated user ("kolla" seems the best choice) as same > On
>>> Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke wrote:
>>>> In my experience operators prefer a dedicated user (kolla:kolla), though I
>>
>>kolla:kolla seems more logical and simpler to reason about.
>>
>
> kolla:kolla still works with multi-user approach and permissions 660 on
> /etc/kolla files.
>
> Regards
> -steve
>
>>
>>--
>>
>> Gerard Braad | http://gbraad.nl
>> [ Doing Open Source Matters ]
>>
>>__
>>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
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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
Re: [openstack-dev] [kolla] Kolla configuration files owner and permission
On Wed, Aug 24, 2016 at 5:24 PM, lương hữu tuấn wrote: > However, with config file as nova.conf or in this case e.g. kolla.conf, it > should be kolla:kolla and only owner can write as well, it means 644 since > the kolla service is run under the name of kolla user, it is the same with > other services in OpenStack. there is no kolla.conf file in any containers. > > With the folder, e.g. /etc/kolla or /etc/nova, it should be also > read/write/executable with kolla user and kolla group since kolla service > running with kolla user should have permission to get information from > kolla.conf. for the nova.conf, why the nova user need to write/change the nova.conf file? -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] which footer format we need
We introduced customization solution.
Now, we support two format of footer.
1. the legacy way: {{ include_footer }}
2. the new way: {% block footer %}{% endblock %}
there two conflict about this now[0][1].
I think the option 2 is better. We can get more consistent solution.
[0] https://review.openstack.org/#/c/357746
[1] https://review.openstack.org/#/c/361253
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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
Re: [openstack-dev] [kolla] which footer format we need
1. so i think we need add the deprecated status to the include_footer
option and print a warn.
2. when the use specifies both two footers, they should both work rather
than ignore one. it print warn already.
On Fri, Sep 2, 2016 at 11:42 AM, Swapnil Kulkarni
wrote:
> On Fri, Sep 2, 2016 at 8:32 AM, Jeffrey Zhang
> wrote:
> > We introduced customization solution.
> >
> > Now, we support two format of footer.
> >
> > 1. the legacy way: {{ include_footer }}
> > 2. the new way: {% block footer %}{% endblock %}
> >
> > there two conflict about this now[0][1].
> >
> > I think the option 2 is better. We can get more consistent solution.
> >
> > [0] https://review.openstack.org/#/c/357746
> > [1] https://review.openstack.org/#/c/361253
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> >
> __
> > 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
> >
>
>
> I tend towards #2, patchset [0] is corresponding to a discussion on
> #openstack-kolla and if we keep #2, we need to keep #1 in all
> dockerfiles with a deprecation warning for next cycle.
>
> Also what if user specifies both the footer blocks? We need to confirm
> we ignore #1 if #2 is chosen.
>
> __
> 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
>
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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
Re: [openstack-dev] [kolla] Problem regarding named volume data location
On Fri, Sep 2, 2016 at 11:48 PM, Paul Bourke wrote: > In our Kilo based solution we were solving this using host bind mounts, > e.g. -v /var/lib/nova:/var/lib/nova, where the directory on the left hand > side can be mounted wherever you like. Two major issues with this approach > are: > > 1) Kolla tasks have to be refactored in many places to replace > "nova_data:/var/lib/kolla" with "/var/lib/nova:/var/lib/nova" (easily > solvable) > > 2) This appears to be incompatible with the 'drop root' work done, as even > though /var/lib/nova is created and chowned during the build process, it's > permissions are replaced with those of root when bind mounted from the host. > Why this solve the issue? IMHO, the root cause is that: Kolla/docker consume much capacity in /var/lib/docker. But If we move the named volume to other place ( like /var/lib/nova ), it will consume that disk/folder capacity. I think the right solution should warn the end-user: you need configure a large partition for /var/lib/docker. -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Problem regarding named volume data location
If you really want some function like this, you may need this[0] > Create named local volumes that persist in the location(s) you want! [0] https://github.com/CWSpear/local-persist On Sat, Sep 3, 2016 at 1:04 AM, Jeffrey Zhang wrote: > > On Fri, Sep 2, 2016 at 11:48 PM, Paul Bourke > wrote: > >> In our Kilo based solution we were solving this using host bind mounts, >> e.g. -v /var/lib/nova:/var/lib/nova, where the directory on the left hand >> side can be mounted wherever you like. Two major issues with this approach >> are: >> >> 1) Kolla tasks have to be refactored in many places to replace >> "nova_data:/var/lib/kolla" with "/var/lib/nova:/var/lib/nova" (easily >> solvable) >> >> 2) This appears to be incompatible with the 'drop root' work done, as >> even though /var/lib/nova is created and chowned during the build process, >> it's permissions are replaced with those of root when bind mounted from the >> host. >> > > Why this solve the issue? > > IMHO, the root cause is that: Kolla/docker consume much capacity in > /var/lib/docker. But If we move the named volume to other place ( like > /var/lib/nova ), it will consume that disk/folder capacity. > > I think the right solution should warn the end-user: you need configure a > large partition for /var/lib/docker. > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [kolla] Requirement for bug when reno is present
release note just generate a bunch of html file. We can not use them for track bug/issue. For example, how to trace the backport/revert/re-open status for some issue/feature if the reno notes is the only thing we have? The reno is just a releasenote tool. It is not helpful for project management. On Tue, Aug 30, 2016 at 6:42 PM, Paul Bourke wrote: > Kolla, > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features in order to > track them as part of releases. Does/should reno supersede this? > > -Paul > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)
+1 On Thu, Sep 8, 2016 at 3:23 PM, Martin André wrote: > +1, nice work Christian. > > Martin > > On Thu, Sep 8, 2016 at 4:59 AM, Steven Dake (stdake) > wrote: > > Kolla core reviewer team, > > > > > > > > It is my pleasure to nominate Christian Berendt for the Kolla core team. > > > > > > > > Christian’s output over the last cycle has been fantastic – cracking the > top > > 10 reviewer list for the full cycle. His 30 day stats [1] place him in > > solid 7th position, and considering the size of the core review team we > > have, this is a great accomplishment. Christian also has solid 60 day > > review stats [2] place him in solid 7th position. But more importantly > his > > reviews are of high quality. He has great IRC participation as well as > > having implemented all kinds of bug fixes all over the code base. He > > clearly understands Kolla by the quality of his reviews. > > > > > > > > Consider this nomination a +1 vote from me. > > > > > > > > A +1 vote indicates you are in favor of Christian as a candidate, a 0 > vote > > indicates an abstain, and a -1 is a veto. Voting is open for 7 days > until > > September 15th, or a unanimous response is reached or a veto vote occurs. > > If a unanimous response is reached or a veto occurs, voting will close > > early. > > > > > > > > Regards, > > > > -steve > > > > > > > > [1] http://stackalytics.com/report/contribution/kolla/30 > > > > [2] http://stackalytics.com/report/contribution/kolla/60 > > > > > > > > > > > __ > > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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][elections][ptl] Kolla PTL Candidacy for Jeffrey Zhang
Hi Everyone, I'm excited to announce my candidacy for PTL for Kolla team during the Ocata cycle. Kolla is a fantastic project. It brings fresh new blood to OpenStack Deployment Management. Simplifying the lives of Operators when managing OpenStack is essential to OpenStack’s success and I personally believe Kolla as of Liberty 1.1.0 delivers on that promise. I also deployed several Kolla production environment for customers without any problem. I've been a core contributor to Kolla since Mitaka. I am full time on Kolla project and have been heavily involved with all of my waking hours[0][1]. Over the Newton development cycle, we have implemented numerous new features and improved stability and usability. The top features are: * Introduced the Bifrost and kolla-host to manage the bare metal provision and initialize the node before deploying OpenStack. * The introduction of far more services including Aodh, Bifrost, Ceilometer, Cloudkitty, Multipath, Rally, Sahara, Tempest, Watcher. * Implemented Dockerfile customization. * Launched the kolla-kubernetes project. * More robust CI jobs As a team, the Kolla Community tested 123 nodes for Kolla using osic[2]. The results validate Kolla works and scales to a majority of use cases today. The major code paths that enable this scalability have been in place since Liberty which gives a good indicator of Liberty and Mitaka scalability. As a Kolla core reviewer and PTL self-nominee, I find this result to be highly satisfying. One of Kolla’s many goals has been executed: Deploying OpenStack at 100+ node count fast and easily. The kolla community is diversely affiliated, a fantastic crew of contributors, and excellent leadership within the core reviewer team. For Ocata, I'd like the project focused on these objectives: * Focus on the needs of the Kolla team. * Optimize the speed of reconfiguration and upgrade. * Implement and integrate with more driver plugins for neutron and cinder. * Deliver 1.0.0 of kolla-kubernetes. * Implement different CI jobs to test diverse scenarios.I’d like to start out with some really hard CI problems such as testing real upgrades and validating ceph in the CI jobs per commit. * Support the implementation of a monitoring stack. Finally, I know it is important that PTL time is spent on the non-technical problem-solving such as mentoring potential core reviewers, scheduling the project progress, interacting with other OpenStack projects and many other activities a PTL undertakes. I’d like to work this cycle on scaling those activities across the core reviewer team. I will use my personal strengths and rely on the core reviewer team’s personal strengths to make Kolla Ocata the best release yet. Thank you for the considering me to serve as your Kolla PTL. Regards, Jeffrey Zhang [0] http://stackalytics.com/?release=all&module=kolla&metric=commits [1] http://stackalytics.com/?release=all&module=kolla&metric=marks [2] https://review.openstack.org/352101 __ 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] potential Ansible template issue you may meet
When using ansible template module, you may see the trailing newline
is stripped by blocks, like
# template.j2
a = {% if true %}1{% endfor %}
b = 2
the render will be like
a=1b=2
The newline character after `a=1` is stripped.
The root cause comes from jinja2's trim_blocks feature. Ansible
enabled this feature. If you want to disable it, just add `#jinja2:
trim_blocks: False` to the j2 template file. This is a feature in
Ansible, and I do not think they will fix/change this. But we need
take care of this when using the template module.
More info please check[0][1]
[0] https://github.com/ansible/ansible/issues/16344
[1] http://jinja.pocoo.org/docs/dev/api/#jinja2.Environment
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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][ptl] PTL Candidacy for Rocky
Hi everyone, I am excited to announce my candidacy for the Rocky cycle as Kolla PTL. Kolla is a fantastic project, which simplifies the lives of operators when managing OpenStack. Now, Kolla can containerize and deliver almost all OpenStack Big Tent projects. And more and more OpenStack environment are deployed by Kolla in the real world. And lots of developers and operators joined Kolla, too. I have been involved in OpenStack since Folsom cycle and I have been a core reviewer on Kolla since Liberty cycle. I have contributed lots of features and solved lots of critical issue in Kolla projects since then[0][1]. During the Ocata, Pike and Queens cycle I also served as the Kolla release liaison. I also have helped new developers to contribute to the project and operators to solve issues. For the Rocky cycle, I would like to focus on following objectives: * Focus on the needs of Kolla team. * Continue to encourage diversity in our Community. * Support check and diff mode in kolla-ansible. * Implement zero downtime for OpenStack services. * Continue to speed up the kolla-ansible deploy and reconfigure. * Make CI easier to understand and debug. * Push tag image to hub.docker.com site which is more stable than branch tag. * Deliver 1.0.0 of kolla-kubernetes. Finally, I know it is important that PTL time is spent on the non-technical problem-solving such as mentoring potential core reviewers, scheduling the project progress, interacting with other OpenStack projects and many other activities a PTL undertakes. I’d like to work this cycle on scaling those activities across the core reviewer team. Thank you for reading this and for considering this candidacy. As a community I am certain we can make Kolla better and better. Sincerely, Jeffrey4l [0] http://stackalytics.com/?release=all&module=kolla&metric=commits [1] http://stackalytics.com/?release=all&module=kolla&metric=marks -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
Re: [openstack-dev] [PTL][SIG][PTG]Team Photos
Kendall, I added the Kolla Team to 10:20-10:30 on Thursday On Thu, Feb 22, 2018 at 7:48 AM, Kendall Nelson wrote: > Hello Everyone! > > I just wanted to remind you all that you have till *Monday Feburary 26th* > to sign up if your team or group is interested in a team photo on the Croke > Park pitch! We still have slots available Tuesday afternoon and Thursday > morning. > > -Kendall (diablo_rojo) > > On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson > wrote: > >> This link might work better for everyone: >> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoT >> ypX66eNURsopQY/edit?usp=sharing >> >> -Kendall (diablo_rojo) >> >> >> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson >> wrote: >> >>> Hello PTLs and SIG Chairs! >>> >>> So here's the deal, we have 50 spots that are first come, first >>> served. We have slots available before and after lunch both Tuesday and >>> Thursday. >>> >>> The google sheet here[1] should be set up so you have access to edit, >>> but if you can't for some reason just reply directly to me and I can add >>> your team to the list (I need team/sig name and contact email). >>> >>> I will be locking the google sheet on *Monday February 26th so I need >>> to know if your team is interested by then. * >>> >>> See you soon! >>> >>> - Kendall Nelson (diablo_rojo) >>> >>> [1] https://docs.google.com/spreadsheets/d/ >>> 1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing >>> >>> >>> >>> > __ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
