[openstack-dev] [Kolla][compute-kit plugins] Nova and neutron plugin bps

[Hui Kang]

Hi, Kolla core reviewers:
In one of the kolla work session, the discussion came across the
plugins for compute kit [1]. There are two bps I think that are
relevant to this topic regarding nova and neutron: nova-docker [3] and
neutron-OVN [2]. Could any kolla core help to take a look at these two
bps and provide some feedback? Thanks.

- Hui

[1] https://etherpad.openstack.org/p/kolla-newton-summit-plugin-planning
[2] https://blueprints.launchpad.net/kolla/+spec/ovn-controller-neutron
[3] https://blueprints.launchpad.net/kolla/+spec/nova-docker-container

__
OpenStack Development Mailing 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][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Hui Kang]

+1

- Hui

On Sat, Apr 30, 2016 at 10:50 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Fellow core reviewers,
>
> We had a fantastic turnout at our fishbowl kubernetes as an underlay for
> Kolla session.  The etherpad documents the folks interested and discussion
> at summit[1].
>
> This proposal is mostly based upon a combination of several discussions at
> open design meetings coupled with the kubernetes underlay discussion.
>
> The proposal (and what we are voting on) is as follows:
>
> Folks in the following list will be added to a kolla-k8s-core group.
>
>  This kolla-k8s-core group will be responsible for code reviews and code
> submissions to the kolla repository for the /kubernetes top level directory.
> Individuals in kolla-k8s-core that consistently approve (+2) or disapprove
> with a (-2) votes to TLD directories other then kubernetes will be handled
> on a case by case basis with several "training warnings" followed by removal
> of the kolla-k8s-core group.  The kolla-k8s-core group will be added as a
> subgroup of the kolla-core reviewer team, which means they in effect have
> all of the ACL access as the existing kolla repository.  I think it is
> better in this case to trust these individuals to the right thing and only
> approve changes for the kubernetes directory until proposed for the
> kolla-core reviewer group where they can gate changes to any part of the
> repository.
>
> 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)
>
>
> If you already are in the kolla-core review team, you won't be added to the
> kolla-k8s-core team as you will already have the necessary ACLs to do the
> job.  If you feel you would like to join this initial bootstrapping process,
> please add your name to the etherpad in [1].
>
> After 8 weeks (July 15h), folks that have not been actively reviewing or
> committing code will be removed from the kolla-k8s-core group.  We will use
> the governance repository metrics for team size [2] which is either 30
> reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months
> (in this case 2 commits) to the repository.  Folks that don't meet the
> qualifications are still welcome to commit to the repository and contribute
> code or documentation but will lose approval rights on patches.
>
> The kubernetes codebase will be maintained in the
> https://github.com/openstack/kolla repository under the kubernees top level
> directory.  Contributors that become active in the kolla repository itself
> will be proposed over time to the kolla-core group.  Only core-kolla members
> will be permitted to participate in policy decisions and voting thereof, so
> there is some minimal extra responsibility involved in joining the
> kolla-core ACL team for those folks wanting to move into the kolla core team
> over time.  The goal will be to over time entirely remove the kolla-k8s-core
> team and make one core reviewer team in the kolla-core ACL.
>
> Members in the kolla-k8s-core group will have the ability to +2 or –2 any
> change to the main kolla repository via ACLs, however, I propose we trust
> these folks to only +2/-2 changes related to the kubernetes directory in the
> kolla repository and remove folks that consistently break this agreement.
> Initial errors as folks learn the system will be tolerated and commits
> reverted as makes sense.
>
> I feel we made a couple errors with the creation of Kolla-mesos that I feel
> needs correction.  Our first error the kolla-mesos-core team made a lack of
> a diversely affiliated team membership developing the code base.  The above
> list has significant diversity.  The second error is that the repository was
> split in the first place.  This resulted in a separate ABI to the containers
> being implemented which was a sore spot for me personally.  We did our best
> to build both sides of the bridge here, but this time I'd like the bridge
> between these two interests and set of individuals to be fully built before
> beginning.  As such, I'd ask the existing k

[openstack-dev] [kolla][gate] Add a gating check job for precheck

[Hui Kang]

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

Re: [openstack-dev] [kolla][gate] Add a gating check job for precheck

[Hui Kang]

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) <std...@cisco.com> 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" <hkang.sun...@gmail.com> 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

Re: [openstack-dev] [kolla][gate] Add a gating check job for precheck

[Hui Kang]

Hi, Lei and Steve,
I think what Lei said makes sense. When I look at the other proposed
gate jobs [1], the function can be tested against the service.
However, for the precheck roles, it depends on the deployment. If the
deployment task could not pass the precheck phase, the job should be
stopped.

So I agree that adding precheck to deployment gate task, rather than
as a dedicated gate job. Any comment? Thanks.

- Hui


[1] https://etherpad.openstack.org/p/kolla-newton-summit-kolla-functional-gating

On Tue, May 3, 2016 at 12:50 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote:
> 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 <hkang.sun...@gmail.com> 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) <std...@cisco.com>
>> 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" <hkang.sun...@gmail.com> 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
>

__
OpenStack Development Mailing 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

[Hui Kang]

This commit fixes the tag:
https://github.com/openstack/kolla/commit/e2fa75fce6f90de8b2766070bb65d0b80bcad8c8

But I think fixing the tag in dockerfile of base container image is better

- Hui

On Tue, May 3, 2016 at 12:12 PM, Jeffrey Zhang  wrote:
> 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
>

__
OpenStack Development Mailing 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

[Hui Kang]

FYI, I filed a bug about this issue
https://bugs.launchpad.net/kolla/+bug/1579583

- Hui

On Mon, May 9, 2016 at 10:42 AM, Steven Dake (stdake)  wrote:
>
>
> On 5/8/16, 7:55 AM, "Monty Taylor"  wrote:
>
>>On 05/08/2016 03:45 AM, 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.
>>>
>>
>>We will be changing our images this cycle to Xenial from Trusty. I do
>>not believe we have any intention of installing backported wily kernels
>>in our trusty images, as what we want to test on them is Trusty.
>>
>>However, the Xenial transition should be happening soon enough - so
>>things that need a newer kernel this release can happily just require
>>Xenial images for testing.
>>
>>I think the question of why/how kolla grew a dependency on a newer
>>kernel than what trusty has is worth checking. As of right now, trusty
>>kernels are the newest thing supported in the gate.
>
> Monty,
>
> One of our dependencies, Docker, only works with the btrfs storage driver
> on Trusty.  All other storage drivers for Trusty are DOA on Trusty without
> kernel recompiles.  CentOS 7 works well with all storage drivers, although
> overlayfs is a little flakey when building images because of  the yum OVL
> plugin.  We recommend in the docs to upgrade the kernel to Willy howver
> Xenail should work as well.
>
> What comes out of this is a recommendation to use BTRFS as the storage
> backend when using Trusty.  We should be documenting that anyway.
>
> 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

Re: [openstack-dev] [kolla] CentOS binary and source gate failed due to the rabbitmq

[Hui Kang]

The ubuntu gate deploy failed too; that is awkward.

http://logs.openstack.org/05/314205/1/check/gate-kolla-dsvm-deploy-ubuntu-source/766ee43/console.html#_2016-05-09_16_58_39_411

- Hui

On Mon, May 9, 2016 at 1:48 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote:
> 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 <hkang.sun...@gmail.com> 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 <zhang.lei@gmail.com>
>> 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
>

__
OpenStack Development Mailing 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

[Hui Kang]

Hi, Jeffrey,
Then the precheck should check for backend overlay fs on Ubuntu
trusty, rather than the kernel version.

In fact, the deploy gate job did success with kernel 3.13 [1]. The
existing checking for kernel 4.2 causes false alarm.

- Hui

[1] 
http://logs.openstack.org/06/313706/1/check/gate-kolla-dsvm-deploy-ubuntu-source/22c0d4d/console.html.gz#_2016-05-06_21_46_54_503

On Sun, May 8, 2016 at 4:57 AM, Jeffrey Zhang  wrote:
> 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
>

__
OpenStack Development Mailing 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

[Hui Kang]

On Sun, May 8, 2016 at 10:55 AM, Monty Taylor  wrote:
> On 05/08/2016 03:45 AM, 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.
>>
>
> We will be changing our images this cycle to Xenial from Trusty. I do not
> believe we have any intention of installing backported wily kernels in our
> trusty images, as what we want to test on them is Trusty.
>
> However, the Xenial transition should be happening soon enough - so things
> that need a newer kernel this release can happily just require Xenial images
> for testing.

Sounds great.

>
> I think the question of why/how kolla grew a dependency on a newer kernel
> than what trusty has is worth checking. As of right now, trusty kernels are
> the newest thing supported in the gate.

The dependency is on docker's backend fs. Please see my reply to
Jeffrey. Thanks.

- Hui

>
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [kolla] CentOS binary and source gate failed due to the rabbitmq

[Hui Kang]

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

[openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Hui Kang]

Hi,
I see that the minimum kernel version required for ubuntu 14.04 is 4.2
[1]. The precheck job failed on gate because those ubuntu VMs have
kernel version 3.13.

Shall we add kernel upgrade command (i.e., apt-get install
linux-image-generic-lts-wily) in the precheck role?

- Hui

[1] 
http://docs.openstack.org/developer/kolla/quickstart.html#installing-dependencies
[2] 
http://logs.openstack.org/19/313819/1/check/gate-kolla-dsvm-deploy-ubuntu-source/f49ad57/console.html#_2016-05-08_02_31_50_295

__
OpenStack Development Mailing 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

[Hui Kang]

Robert,
Thanks for you reply. Is there any way to change the VM image on the gate?

BTW, I do see some kolla deploy gate job successes on kernel 3.13 [1].
Is there any reason kolla needs to check 4.2 on ubuntu 14.04?

- Hui

[1] 
http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-ubuntu-source/90ff270/console.html#_2016-05-07_12_42_12_253

On Sat, May 7, 2016 at 11:14 PM, Robert Collins
 wrote:
> That won't get you running the new kernel; for that you need to change
> the image itself.
>
> -Rob
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Kolla] How to use template-override to build image?

[Hui Kang]

Hi,
There seems no doc or example about how to customize the Dockerfile
with template override.
For example, if I want to run ./tools/build.py --template-only
--template-override ./heat-extend.j2 heat, what is the correct format
for heat-extend.j2?

When the content of heat-extend.j2 is

{% set heat_base_packages = heat_base_packages + ['vim', 'emacs'] %}

The above command gives the error "jinja2.exceptions.UndefinedError:
'heat_base_packages' is undefined".
Thanks in advance.

- Hui

__
OpenStack Development Mailing 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

[Hui Kang]

Hi, Jeffrey and Nate,
Thanks for the links. I will update my PS.

- Hui

On Tue, Jun 28, 2016 at 12:15 PM, Nate Johnston <openstackn...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 11:47:58PM +0800, Jeffrey Zhang wrote:
>> On Tue, Jun 28, 2016 at 9:23 PM, Hui Kang <hkang.sun...@gmail.com> wrote:
>>
>> > Do you mind giving some example of such reno release note? Thanks.
>>
>> like this https://review.openstack.org/#/c/235398/ .
>
> The instructions are also very good:
>
> http://docs.openstack.org/developer/reno/usage.html
>
> --N.
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [kolla] Usage of Reno - all devs please read

[Hui Kang]

Hi, Steven
Do you mind giving some example of such reno release note? Thanks.

- Hui

On Tue, Jun 28, 2016 at 8:46 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> We have had reno in place since the end of Mitaka, yet folks aren't using it
> very often.  I am guilty myself of not thinking of it when reviewing
> changes.
>
> Core reviewers:
> Please –1 any review of significant work that doesn't include a reno release
> note.
>
> Developers:
> If you have made significant changes to the code base (things like
> Ceilometer come to mind) please submit release notes for them.  Note release
> notes should generally be submitted with the work in question, but in this
> case, lets just get the notes in the codebase.
>
> A release note takes 5 minutes to write – it doesn't have to be long and
> complicated.
>
> 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

[openstack-dev] [rally] Support executing multi scenarios in a single task file

[Hui Kang]

Hi, OpenStack Developers,
I came across this rally spec [1]. The spec mentions defining and
executing multiple scenarios
in a single rally task file. However, as this was written about 8month
ago, may I know if this
feature is implemented in rally? If not, is there any related patch?
Thanks in advance.

- Hui

[1] 
https://github.com/openstack/rally/blob/master/doc/specs/in-progress/new_rally_input_task_format.rst

__
OpenStack Development Mailing 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][elections][ptl] Kolla PTL Candidacy for Jeffrey Zhang

[Hui Kang]

+1 for Jeffrey Zhang
- Jeffrey is full time on Kolla
- Steven is doing excellent job, but I would like to see some change.

Thanks.

- Hui

On Mon, Sep 12, 2016 at 3:18 AM, Jeffrey Zhang  wrote:
> 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=kolla=commits
> [1] http://stackalytics.com/?release=all=kolla=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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev