Re: [openstack-dev] [kolla] Proposing Chason Chan (chason) as kolla-ansible core
+1 good job On Wed, Sep 26, 2018 at 9:30 AM zhubingbing wrote: > +1 > > > > > > At 2018-09-25 23:47:10, Eduardo Gonzalez wrote: > > Hi, > > I would like to propose Chason Chan to the kolla-ansible core team. > > Chason is been working on addition of Vitrage roles, rework VpnaaS > service, maintaining > documentation as well as fixing many bugs. > > Voting will be open for 14 days (until 9th of Oct). > > Kolla-ansible cores, please leave a vote. > Consider this mail my +1 vote > > Regards, > Eduardo > > > __ > OpenStack Development Mailing 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] ptl non candidacy
Hi all, I just wanna to say I am not running PTL for Stein cycle. I have been involved in Kolla project for almost 3 years. And recently my work changes a little, too. So I may not have much time in the community in the future. Kolla is a great project and the community is also awesome. I would encourage everyone in the community to consider for running. Thanks for your support :D. -- 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] Removing old / unused images
There are really lots of downstream consumers using kolla image. So when removing images, we need care about the downstream consumers. And follow our deprecation policy. i.e. deprecate at first cycle, and remove it at following cycle. If there is really some guys depends on these images, we should keep them. On Wed, Jun 27, 2018 at 5:39 PM Paul Bourke wrote: > Ok, thanks for the replies. Seems at least the non k8s images are in use > by tripleo and so will remain untouched. caoyuan has a similar patch > open to just remove the k8s related images so please have a look and > vote on that instead: https://review.openstack.org/#/c/576911/ > > I'm not sure we need a deprecation cycle on the k8s images given they > were directly related to kolla-k8s, that said, we need to remember there > are other consumers outside these projects so if people feel we should > keep them for a cycle please let me know. > > On 26/06/18 16:51, Andy Smith wrote: > > Also commented as tripleo is using qdrouterd. > > > > It's use in kolla-ansible > > > https://github.com/openstack/kolla-ansible/tree/master/ansible/roles/qdrouterd > > > > and bp > > > https://blueprints.launchpad.net/kolla/+spec/dispatch-router-messaging-component > > > > Thanks, > > Andy > > > > On Tue, Jun 26, 2018 at 10:52 AM Alex Schultz > <mailto:aschu...@redhat.com>> wrote: > > > > On Tue, Jun 26, 2018 at 8:05 AM, Paul Bourke > <mailto:paul.bou...@oracle.com>> wrote: > > > Hi all, > > > > > > At the weekly meeting a week or two ago, we mentioned removing > > some old / > > > unused images from Kolla in the interest of keeping the gate run > > times down, > > > as well as general code hygiene. > > > > > > The images I've determined that are either no longer relevant, or > > were > > > simply never made use of in kolla-ansible are the following: > > > > > > * almanach > > > * certmonger > > > * dind > > > * qdrouterd > > > * rsyslog > > > > > > * helm-repository > > > * kube > > > * kubernetes-entrypoint > > > * kubetoolbox > > > > > > If you still care about any of these or I've made an oversight, > > please have > > > a look at the patch [0] > > > > > > > I have commented as tripleo is using some of these. I would say that > > you shouldn't just remove these and there needs to be a proper > > deprecation policy. Just because you aren't using them in > > kolla-ansible doesn't mean someone isn't actually using them. > > > > Thanks, > > -Alex > > > > > Thanks! > > > -Paul > > > > > > [0] https://review.openstack.org/#/c/578111/ > > > > > > > > > __ > > > 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://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] Propose move the weekly meeting one hour earlier
The patch is already merged. The next weekly meeting will be at `date -d "1500 UTC"` on Wednesday. On Wed, Jun 13, 2018 at 3:38 PM Jeffrey Zhang wrote: > As we have more and more developer located in Asia and Europe timezone > rather > than Americas'. Current weekly meeting time is not proper. This was > discussed > at the last meeting and as a result, seems one hour earlier then now is > better > than now. > > So I propose to move the weekly meeting from UTC 16:00 to UTC 15:00 on > Wednesday. Feel free to vote on the patch[0] > > This patch will be opened until next weekly meeting, 20 June. > > [0] https://review.openstack.org/575011 > -- > 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
[openstack-dev] [kolla] Propose move the weekly meeting one hour earlier
As we have more and more developer located in Asia and Europe timezone rather than Americas'. Current weekly meeting time is not proper. This was discussed at the last meeting and as a result, seems one hour earlier then now is better than now. So I propose to move the weekly meeting from UTC 16:00 to UTC 15:00 on Wednesday. Feel free to vote on the patch[0] This patch will be opened until next weekly meeting, 20 June. [0] https://review.openstack.org/575011 -- 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 Steve Noyes for kolla-cli core reviewer
+1 On Fri, Jun 1, 2018 at 1:41 AM Mark Giles wrote: > > +1 > > On May 31, 2018 at 1:06:43 PM, Borne Mace (borne.m...@oracle.com) wrote: > > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli > core reviewer team. Consider this nomination as my personal +1. > > Steve has a long history with the kolla-cli and should be considered its > co-creator as probably half or more of the existing code was due to his > efforts. He has now been working diligently since it was pushed > upstream to improve the stability and testability of the cli and has the > second most commits on the project. > > The kolla core team consists of 19 people, and the kolla-cli team of 2, > for a total of 21. Steve therefore requires a minimum of 11 votes (so > just 10 more after my +1), with no veto -2 votes within a 7 day voting > window to end on June 6th. Voting will be closed immediately on a veto > or in the case of a unanimous vote. > > As I'm not sure how active all of the 19 kolla cores are, your attention > and timely vote is much appreciated. > > Thanks! > > -- Borne > > > __ > OpenStack Development Mailing 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] [stable][kolla] tagging newton EOL
have no idea about this too. and it looks as expected. Thanks tony On Thu, May 31, 2018 at 8:17 AM Tony Breeds wrote: > > On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote: > > hi stable team, > > > > Kolla project is ready for Newton EOL. Since kolla-ansible is split from > > kolla since ocata cycle, so there is not newton branch in kolla-ansible. > > please make following repo EOL > > > > openstack/kolla > > Okay I did this today but to be perfectly frank I suspect I've done it > wrong. > > There was already an existing tag for newton-eol pointing at > 3.0.3-20'ish so I tagged what was the HEAD of the existing newton branch > which was 3.0.0.0rc1-335'ish: > > About to delete the branch stable/newton from openstack/kolla (rev > 40e768ec2a370dc010be773af37e2ce417adda80) > > I'm not really sure about the history there. I apologise if I've made a > mistake. > > but at least as we have everything in git we can recover the branches > and retag if required. > > Yours Tony. > __ > OpenStack Development Mailing 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] [nova] nova aggregate and nova placement api aggregate
Recently, i am trying to implement a function which aggregate nova hypervisors rather than nova compute host. But seems nova only aggregate nova-compute host. On the other hand, since Ocata, nova depends on placement api which supports aggregating resource providers. But nova-scheduler doesn't use this feature now. So is there any better way to solve such issue? and is there any plan which make nova legacy aggregate and placement api aggregate cloud work together? -- 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] Problem when deploying Openstack with Kolla
seems there are some issue in you inventory file.
Could you compare your inventory file with the one in kolla-ansible code?
if you are still not fix it, try to provide you globals.yml file and
inventory file in ML.
On Tue, May 22, 2018 at 6:51 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> Hello OpenStackers,
> First of all, I am not sure if this is the right list to post this
> question. Therefore, please excuse me if I am sending an e-mail to the
> wrong place.
>
> So, I have been trying to use Kolla to deploy a POC environment of
> OpenStack. However, I have not been able to do so. Right now I am getting
> the following error:
>
> fatal: [localhost]: FAILED! => {"msg": "The conditional check
>> '(neutron_l3_agent.enabled | bool and neutron_l3_agent.host_in_groups |
>> bool) or (neutron_vpnaas_agent.enabled | bool and
>> neutron_vpnaas_agent.host_in_groups | bool)' failed. The error was:
>> error while evaluating conditional ((neutron_l3_agent.enabled | bool and
>> neutron_l3_agent.host_in_groups | bool) or (neutron_vpnaas_agent.enabled
>> | bool and neutron_vpnaas_agent.host_in_groups | bool)): Unable to look
>> up a name or access an attribute in template string ({{ inventory_hostname
>> in groups['neutron-vpnaas-agent'] }}).\nMake sure your variable name does
>> not contain invalid characters like '-': argument of type 'StrictUndefined'
>> is not iterable\n\nThe error appears to have been in
>> '/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml':
>> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
>> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
>> Setting sysctl values\n ^ here\n"}
>>
>
> It looks like an Ansible problem. I checked the file
> “/usr/local/share/kolla-ansible/ansible/roles/neutron/tasks/config.yml”
> at line 5, it has the following declaration:
>
>> neutron_l3_agent: "{{ neutron_services['neutron-l3-agent'] }}"
>>
>
> As far as I understand everything is ok with this variable declaration.
> There is the “neutron-l3-agent” parameter used to retrieve an element from
> “neutron_services” map, but that does look ok. Has anybody else experienced
> this problem before?
>
> I am using Kolla for OpenStack queens. I am using kolla with the following
> command.
>
>> kolla-ansible -i all-in-one bootstrap-servers && kolla-ansible -i
>> all-in-one prechecks && kolla-ansible -i all-in-one deploy
>>
>
> As you can see, it is a simple use case to deploy OpenStack in a single
> node. The command that is failing is the following.
>
>> kolla-ansible -i all-in-one deploy
>>
>
> --
> Rafael Weingärtner
>
> ______
> OpenStack Development Mailing 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] weekly meeting is cancelled May 23
Hi guys, we are canceling next Kolla weekly meeting on May 23th, due to the summit. It will be resumed at May 30th. -- 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 Mark Goddard (mgoddard) as kolla core member
Time is up. And welcome mgoddard to the team :D On Thu, May 3, 2018 at 5:47 PM, Goutham Pratapa <pratapagout...@gmail.com> wrote: > +1 for `mgoddard` > > On Thu, May 3, 2018 at 1:21 PM, duon...@vn.fujitsu.com < > duon...@vn.fujitsu.com> wrote: > >> +1 >> >> >> >> Sorry for my late reply, thank you for your contribution in Kolla. >> >> >> >> Regards, >> >> Duong >> >> >> >> *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com] >> *Sent:* Thursday, April 26, 2018 10:31 PM >> *To:* OpenStack Development Mailing List <openstack-dev@lists.openstack >> .org> >> *Subject:* [openstack-dev] [kolla][vote]Core nomination for Mark Goddard >> (mgoddard) as kolla core member >> >> >> >> Kolla core reviewer team, >> >> It is my pleasure to nominate >> >> >> >> mgoddard for kolla core team. >> >> >> >> Mark has been working both upstream and downstream with kolla and >> kolla-ansible for over two years, building bare metal compute clouds with >> ironic for HPC. He's been involved with OpenStack since 2014. He started >> the kayobe deployment project which complements kolla-ansible. He is >> also the most active non-core contributor for last 90 days[1] >> >> >> >> Consider this nomination a +1 vote from me >> >> A +1 vote indicates you are in favor of >> >> >> >> mgoddard as a candidate, a -1 >> is a >> >> >> >> veto. Voting is open for 7 days until >> >> May >> >> >> >> 4 >> >> th, or a unanimous >> response is reached or a veto vote occurs. >> >> [1] http://stackalytics.com/report/contribution/kolla-group/90 >> >> >> >> -- >> >> 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 >> >> > > > -- > Cheers !!! > 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-ansible] Configure OpenStack services to use Rabbit HA queues
Hi vladispay,
I guess you are talking rabbit_ha_queues options. It is already marked as
deprecated[0].
cfg.BoolOpt('rabbit_ha_queues',
default=False,
deprecated_group='DEFAULT',
help='Try to use HA queues in RabbitMQ (x-ha-policy: all). '
'If you change this option, you must wipe the RabbitMQ '
'database. In RabbitMQ 3.0, queue mirroring is no longer '
'controlled by the x-ha-policy argument when declaring a '
'queue. If you just want to make sure that all queues
(except '
'those with auto-generated names) are mirrored across all '
'nodes, run: '
"""\"rabbitmqctl set_policy HA '^(?!amq\.).*' """
"""'{"ha-mode": "all"}' \""""),
In kolla, we configure a global ha-mode policy through its definition.json
file in rabbitmq, please check[1]
[0] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_
drivers/impl_rabbit.py#L165-L176
[1] https://github.com/openstack/kolla-ansible/blob/
d2d9c6622888416ad2e748706fd237f8588e993a/ansible/roles/rabbitmq/templates/
definitions.json.j2#L20
On Sat, May 5, 2018 at 12:58 AM, <vladislav.belogru...@oracle.com> wrote:
> Hi,
>
> is there a reason we don't configure services for rabbitmq ha queues like
> it is suggested in [0] ?
> Rabbitmq itself has ha policy 'on' via one of its templates.
>
> Thanks,
> Vladislav Belogrudov
>
> [0] https://docs.openstack.org/ha-guide/shared-messaging.html#ra
> bbitmq-services
>
> __
> OpenStack Development Mailing 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] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate
Thanks hongbin In Kolla, one job is used to test multi OpenStack services. there are already two test scenarios. 1. without ceph 2. with ceph each scenario test a serial of OpenStack services. like nova, neutron, cinder etc. Zun or kuryr is not tested now. But i think it is OK to add a new scenario to test network related service, like zun and kuryr. for tempest testing, there is a WIP bp for this[0] [0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu <hongbin...@gmail.com> wrote: > Hi Kolla team, > > Recently, I saw there are users who tried to install Zun by using > Kolla-ansible and reported bugs to us whenever they ran into issues (e.g. > https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of > this usage pattern (Kolla + Zun) made me think that we need to have CI > coverage to verify the Zun deployment setup by Kolla. > > IMHO, the ideal CI workflow should be: > > * Create a VM with different distros (i.e. Ubuntu, CentOS). > * Use Kolla-ansible to stand up a Zun deployment. > * Run Zun's tempest test suit [1] against the deployment. > > My question for Kolla team is if it is reasonable to setup a Zuul job as > described above? or such CI jobs already exist? If not, how to create one? > > [1] https://github.com/openstack/zun-tempest-plugin > > Best regards, > Hongbin > > __ > OpenStack Development Mailing 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]Retire kolla-kubernetes project
Thanks all guys. Per the voting result, we will retire kolla-kubernetes project. On Tue, Apr 24, 2018 at 10:48 PM, Surya Singh <singh.surya64mn...@gmail.com> wrote: > +1 > > As we don't have active core team in Kolla-kubernetes since months, > unfortunately going for sunset is reasonable. > > Though happy to help in running OpenStack on kubernetes. > > --- > Thanks > Surya > > > > On Wed, Apr 18, 2018 at 7:21 AM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > > Since many of the contributors in the kolla-kubernetes project are moved > to > > other things. And there is no active contributor for months. On the > other > > hand, there is another comparable project, openstack-helm, in the > community. > > For less confusion and disruptive community resource, I propose to retire > > the kolla-kubernetes project. > > > > More discussion about this you can check the mail[0] and patch[1] > > > > please vote +1 to retire the repo, or -1 not to retire the repo. The vote > > will be open until everyone has voted, or for 1 week until April 25th, > 2018. > > > > [0] > > http://lists.openstack.org/pipermail/openstack-dev/2018- > March/128822.html > > [1] https://review.openstack.org/552531 > > > > -- > > 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-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member
Kolla core reviewer team, It is my pleasure to nominate mgoddard for kolla core team. Mark has been working both upstream and downstream with kolla and kolla-ansible for over two years, building bare metal compute clouds with ironic for HPC. He's been involved with OpenStack since 2014. He started the kayobe deployment project which complements kolla-ansible. He is also the most active non-core contributor for last 90 days[1] Consider this nomination a +1 vote from me A +1 vote indicates you are in favor of mgoddard as a candidate, a -1 is a veto. Voting is open for 7 days until May 4 th, or a unanimous response is reached or a veto vote occurs. [1] http://stackalytics.com/report/contribution/kolla-group/90 -- 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] kolla September ptg survey
Hi kollars The next PTG will be held at Denver Colorado on September 10-14, 2018[0]. We have to decide whether Kolla will participate. I personally think ptg is a great time for the team to gather together to resolve issues and make next roadmap. But it is not that easy for every to travel. So please take minutes to fill this form[1] before May 2nd. Then we cloud decide whether we should book a root at ptg. [0] https://www.openstack.org/ptg [1] https://goo.gl/forms/9ZHUw4GBUvggNl643 -- 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][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install
Recently, one of networking-odl package breaks kolla's gate[0]. The direct issue is ceilometer is added in networking-odl's requirements.txt file[1] Then when install network-odl with upper-contraints.txt file, it will raise error like $ pip install -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt ./networking-odl ... collecting networking-bgpvpn>=8.0.0 (from networking-odl==12.0.1.dev54) Downloading http://pypi.doubanio.com/packages/5a/e5/995be0d53d472f739a7a0bb6c9d9fecbc4936148651aaf56d39f3b65b1f1/networking_bgpvpn-8.0.0-py2-none-any.whl (172kB) 100% || 174kB 12.0MB/s Collecting ceilometer (from networking-odl==12.0.1.dev54) Could not find a version that satisfies the requirement ceilometer (from networking-odl==12.0.1.dev54) (from versions: ) No matching distribution found for ceilometer (from networking-odl==12.0.1.dev54) But if you just install the networking-odl's requirements.txt file, it works $ pip install -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt -r ./networking-odl/requirements.txt ... Obtaining ceilometer from git+ https://git.openstack.org/openstack/ceilometer@master#egg=ceilometer (from -r networking-odl/requirements.txt (line 21)) Cloning https://git.openstack.org/openstack/ceilometer (to revision master) to /home/jeffrey/.dotfiles/virtualenvs/test/src/ceilometer ... Is this expected? and how could we fix this? [0] https://bugs.launchpad.net/kolla/+bug/1764621 [1] https://github.com/openstack/networking-odl/blob/master/requirements.txt#L21 - - 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][vote]Retire kolla-kubernetes project
Since many of the contributors in the kolla-kubernetes project are moved to other things. And there is no active contributor for months. On the other hand, there is another comparable project, openstack-helm, in the community. For less confusion and disruptive community resource, I propose to retire the kolla-kubernetes project. More discussion about this you can check the mail[0] and patch[1] please vote +1 to retire the repo, or -1 not to retire the repo. The vote will be open until everyone has voted, or for 1 week until April 25th, 2018. [0] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html [1] https://review.openstack.org/552531 -- 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][stable][tc] Kolla deployment guide link is missing on docs.o.o
Thanks Andreas,
patch is pushed, please check https://review.openstack.org/#/c/561578/
On Mon, Apr 16, 2018 at 6:02 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2018-04-16 11:52, Jeffrey Zhang wrote:
> > Seems kolla deployment guide doc link is missing here[0]. But it exists
> > on pike[1] and ocata[2]
> >
> > How could we fix this?
>
> See https://docs.openstack.org/doc-contrib-guide/doc-index.html and sent
> a patch for openstack-manuals repository,
>
> Andreas
>
> > [0] https://docs.openstack.org/queens/deploy/
> > [1] https://docs.openstack.org/pike/deploy/
> > [2] https://docs.openstack.org/ocata/deploy/
> >
> > --
> > 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:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing 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][stable][tc] Kolla deployment guide link is missing on docs.o.o
Seems kolla deployment guide doc link is missing here[0]. But it exists on pike[1] and ocata[2] How could we fix this? [0] https://docs.openstack.org/queens/deploy/ [1] https://docs.openstack.org/pike/deploy/ [2] https://docs.openstack.org/ocata/deploy/ -- 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] [stable][kolla] tagging newton EOL
hi stable team, Kolla project is ready for Newton EOL. Since kolla-ansible is split from kolla since ocata cycle, so there is not newton branch in kolla-ansible. please make following repo EOL openstack/kolla Thanks a lot. -- 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] stable-policy tag has been removed in kolla
This has already happened[1] based on talks during Sydney summit[0]. But seems it is not noticed by some guys. Even though the tag is merged, we should still follow rule during backport patches to stable branches. The rules, I think, should be - do not break upgrade from y-1 or z-1 stream - API should be still backward compatible, and before removing any feature, we still need one more cycle to mark it as deprecated. and then remove it during next cycle. On the other hand, some bp-like patches like this[2] could be backported to stable branches. Since it won't break anything. [0] https://etherpad.openstack.org/p/SYD-stable-policy [1] https://review.openstack.org/#/c/519685/ [2] https://review.openstack.org/557729 -- 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] [tripleo] On moving start scripts out of Kolla images
effect that is changes the permissions of the files _on the host_. > While using kolla API we could simply add to our config.json: > > - path: /etc/pki/tls/certs/neutron.crt > owner: neutron:neutron > - path: /etc/pki/tls/private/neutron.key > owner: neutron:neutron > > > The other argument is that this removes the possibility for immutable > > infrastructure. The concern is, with the new approach, a rookie operator > > will modify one of the start scripts - resulting in uncertainty that what > > was first deployed matches what is currently running. But with the way > Kolla > > is now, an operator can still do this! They can restart containers with a > > custom entrypoint or additional bind mounts, they can exec in and change > > config files, etc. etc. Kolla containers have never been immutable and > we're > > bending over backwards to artificially try and make this the case. We > cant > > protect a bad or inexperienced operator from shooting themselves in the > > foot, there are better ways of doing so. If/when Docker or the upstream > > container world solves this problem, it would then make sense for Kolla > to > > follow suit. > > > > On the face of it, what the spec proposes is a simple change, it should > not > > radically pull the carpet out under people, or even change the way > > kolla-ansible works in the near term. If consumers such as tripleo or > other > > parties feel it would in fact do so please do let me know and we can > discuss > > and mitigate these problems. > > TripleO uses these scripts extensively, we certainly do not want to > see them go away from kolla images. > > Martin > > > Cheers, > > -Paul > > > > [0] https://review.openstack.org/#/c/550958/ > > [1] https://github.com/openstack/loci > > [2] > > https://github.com/openstack/kolla/blob/master/docker/base/ > set_configs.py > > [3] > > https://github.com/openstack/kolla-ansible/blob/master/ > ansible/roles/keystone/templates/keystone.json.j2 > > [4] > > http://eavesdrop.openstack.org/meetings/kolla/2018/kolla. > 2018-04-04-16.00.log.txt > > > > > __ > > OpenStack Development Mailing 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][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project
Thanks to all guys. The mail is a little off-topic. First of all, let us back to the topic of this mail. **kolla-kubernetes** The root issue for kolla-kubernetes is no active contributors. if more person is interested in this project, I would like to give more time to this project. But leave it in kolla governance may not good for its growth. Because it is a **totally different** technical stack with kolla-ansible. so migrate it to TC governance should the best solution. **for kolla and kolla-ansible split** kolla(container) is widely used by multi-project (TripleO, OSH). And I also heard some internal projects are using it too. kolla and kolla-ansible are well decoupled. The usage or the API kolla provides always stable and backward compatible. kolla images are also used in many produce environment through different deployment tools So kolla(container) is worth say "provide production-ready containers". This should not be negative, just because of kolla and kolla-ansible are under the same team governance. the team split would let people fouse on one thing and make it looks better. but we have two different teams, kolla-core team, and the kolla-ansible-core team already. anyone is welcome to join one of the team. But in fact, the members of these two teams are almost the same. if we split the team now, all we gain is making chaos and hard to manage. I think it may be proper time when the members of kolla-core team and the kolla-ansible-core team is different (50% maybe?). On Sun, Apr 1, 2018 at 7:16 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2018-03-31 22:07:03 + (+), Steven Dake (stdake) wrote: > [...] > > The problems raised in this thread (tension - tight coupling - > > second class citizens - stratification) was predicted early on - > > prior to Kolla 1.0. That prediction led to the creation of a > > technical solution - the Kolla API. This API permits anyone to > > reuse the containers as they see fit if they conform their > > implementation to the API. The API is not specifically tied to > > the Ansible deployment technology. Instead the API is tied to the > > varying requirements that various deployment teams have had in the > > past around generalized requirements for making container > > lifecycle management a reality while running OpenStack services > > and their dependencies inside containers. > [...] > > Thanks! That's where my fuzzy thought process was leading. Existence > of a stable API guarantee rather than treating the API as "whatever > kolla-ansible does" significantly increases the chances of other > projects being able to rely on kolla's images in the long term. > -- > Jeremy Stanley > > __ > OpenStack Development Mailing 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] [all][infra] Upcoming changes in ARA Zuul job reports
cool. kolla will try to implement it. On Fri, Mar 30, 2018 at 7:12 AM, Paul Belanger <pabelan...@redhat.com> wrote: > On Thu, Mar 29, 2018 at 06:14:06PM -0400, David Moreau Simard wrote: > > Hi, > > > > By default, all jobs currently benefit from the generation of a static > > ARA report located in the "ara" directory at the root of the log > > directory. > > Due to scalability concerns, these reports were only generated when a > > job failed and were not available on successful runs. > > > > I'm happy to announce that you can expect ARA reports to be available > > for every job from now on -- including the successful ones ! > > > > You'll notice a subtle but important change: the report directory will > > henceforth be named "ara-report" instead of "ara". > > > > Instead of generating and saving a HTML report, we'll now only save > > the ARA database in the "ara-report" directory. > > This is a special directory from the perspective of the > > logs.openstack.org server and ARA databases located in such > > directories will be loaded dynamically by a WSGI middleware. > > > > You don't need to do anything to benefit from this change -- it will > > be pushed to all jobs that inherit from the base job by default. > > > > However, if you happen to be using a "nested" installation of ARA and > > Ansible (i.e, OpenStack-Ansible, Kolla-Ansible, TripleO, etc.), this > > means that you can also leverage this feature. > > In order to do that, you'll want to create an "ara-report" directory > > and copy your ARA database inside before your logs are collected and > > uploaded. > > > I believe this is an important task we should also push on for the > projects you > listed above. The main reason to do this is simplify job uploads and > filesystemd > demands (thanks clarkb). > > Lets see if we can update these projects in the coming week or two! > > Great work. > > > To help you visualize: > > /ara-report <-- This is the default Zuul report > > /logs/ara <-- This wouldn't be loaded dynamically > > /logs/ara-report <-- This would be loaded dynamically > > /logs/some/directory/ara-report <-- This would be loaded > dynamically > > > > For more details on this feature of ARA, you can refer to the > documentation [1]. > > > > Let me know if you have any questions ! > > > > [1]: https://ara.readthedocs.io/en/latest/advanced.html > > > > David Moreau Simard > > Senior Software Engineer | OpenStack RDO > > > > dmsimard = [irc, github, twitter] > > > > > __ > > OpenStack Development Mailing 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][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project
There are two projects to solve the issue that run OpenStack on Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both leverage helm tool for orchestration. There is some different perspective at the beginning, which results in the two teams could not work together. But recently, the difference becomes too small. and there is also no active contributor in the kolla-kubernetes project. So I propose to retire kolla-kubernetes project. If you are still interested in running OpenStack on kubernetes, please refer to openstack-helm project. -- 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 pip packages vulnerable to CVE-2018-1000115
Hi Mathieu, Thanks for raising this issue. The patch is merged on all branches but not released[0].We will release the next release ASAP. But on the other hand, if you build an OpenStack cloud through kolla and be accessible through the internet, you'd better use an external network(interface) for internet access. There are lots of port enabled on the internal network. like MariaDB, Memcached. [0] https://review.openstack.org/#/q/I30acb41f1209c0d07eb58f4feec91bc53146dcea On Mon, Mar 26, 2018 at 10:36 PM, Mathieu Goessens < mathieu.goess...@imt-atlantique.fr> wrote: > Hi folks, > > I initially sent this mail privately, resending it to the list on request : > > Kolla-Ansible https://docs.openstack.org/kolla-ansible/ pip packages > (recommended in the doc) are vulnerable to CVE-2018-1000115. > > The patch have been commit, merged in stable/queens, stable/pike, > stable/ocata https://review.openstack.org/#/c/550686/. However, the pip > stable packages are still based on 5.0.1 which do not contain the fix > (6.0.0.0rc2 which contains the fix is available in pip, but won't be > installed by default because its a prerelease). > > While I understand that good security practices would recommend to > firewall etc, and that the fixes are available, I believe having > vulnerable packages in the default, recommend install, is an important > issue. > > Moreover, I would like to suggest issuing a Security Advisory when > updated packages would be available, because : > - pip/system won't propose upgrades by default, users may not be aware > they are vulnerable. > - users can actually being hit by CVE-2018-1000115 and participate to DDOS. > - DDOS traffic pattern observed in my cloud are not big burst ones, but > follow some classic daily pattern that could looks legitimate and so > could stay unnoticeable for a long time (see graph, > http://pix.toile-libre.org/?img=1522070903.png, mostly if not only DDOS > traffic in) > > - > How to verify : > > git clone https://github.com/openstack/kolla-ansible ; cd kolla-ansible > > git checkout tags/6.0.0.0rc2 ; git log | grep "Security memcached" > > git checkout tags/5.0.1 ; git log | grep "Security memcached" > > > wget > https://pypi.python.org/packages/cc/f2/27d9e75f2fe142b2a73c57023b055a > a9a50e49ba69d7da9c7808c4f25ac1/kolla-ansible-5.0.1.tar.gz#md5= > 6456618318b58d844ae57b47e34ee569 > > tar xvzf kolla-ansible-5.0.1.tar.gz > > cat kolla-ansible-5.0.1/ansible/roles/memcached/templates/ > memcached.json.j2 > > (compare with https://review.openstack.org/#/c/550686/ if needed) > > > Cheers, > -- > Mathieu Goessens > Research Engineer > IMT Atlantique > > > __ > OpenStack Development Mailing 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 caoyuan
Time is up. Welcome caoyuan join core team :D On Fri, Mar 16, 2018 at 2:57 PM, duon...@vn.fujitsu.com < duon...@vn.fujitsu.com> wrote: > +1 > > > > *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com] > *Sent:* Monday, March 12, 2018 9:07 AM > *To:* OpenStack Development Mailing List <openstack-dev@lists. > openstack.org> > *Subject:* [openstack-dev] [kolla][vote] core nomination for caoyuan > > > > Kolla core reviewer team, > > > > It is my pleasure to nominate caoyuan for kolla core team. > > > > caoyuan's output is fantastic over the last cycle. And he is the most > > active non-core contributor on Kolla project for last 180 days[1]. He > > focuses on configuration optimize and improve the pre-checks feature. > > > > Consider this nomination a +1 vote from me. > > > > A +1 vote indicates you are in favor of caoyuan as a candidate, a -1 > > is a veto. Voting is open for 7 days until Mar 12th, or a unanimous > > response is reached or a veto vote occurs. > > > > [1] http://stackalytics.com/report/contribution/kolla-group/180 > > -- > > 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
Re: [openstack-dev] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints
kolla install openstack packages through master tarball file on kolla
master branch[0]. like
pip install -c upper-constraints.txt neutron-master.tar.gz
On stable branch, kolla install through neutron tag tarball. so it should
work.
But i think there will be also some issue here. How about i want to install
neutron-12.0.1.tar.gz, whereas neutron===12.0.0 exist in the
upper-constraints.txt file?
[0] http://tarballs.openstack.org/neutron/neutron-master.tar.gz
On Fri, Mar 16, 2018 at 6:57 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2018-03-16 11:49, Jeffrey Zhang wrote:
> > Now it breaks the kolla's master branch jobs. And have to remove the
> > "horizon"
> > and "neutron" in the upper-constraints.txt file. check[1][2].
> >
> > i wanna know what's the correct way to install horizon develop
> > branch with upper-constraints.txt file?
> >
> >
> > [1] https://review.openstack.org/#/c/549456/4/docker/
> neutron/neutron-base/Dockerfile.j2
> > <https://review.openstack.org/#/c/549456/4/docker/neutron/
> neutron-base/Dockerfile.j2>
> > [2] https://review.openstack.org/#/c/549456/4/docker/
> horizon/Dockerfile.j2
> > <https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2>
>
> Sorry, that is too much magic for me to be able to help you.
>
> What are those doing? How do you install today? Please give me some
> instructions
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
--
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] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron
kolla install openstack packages through master tarball file on kolla
master branch[0].
On stable branch, kolla install through neutron tag tarball. But i think
there will be also
some issue here. How about i want to install neutron-12.0.1.tar.gz, whereas
neutron===12.0.0
exist in the upper-constraints.txt file?
[0] http://tarballs.openstack.org/neutron/neutron-master.tar.gz
On Fri, Mar 16, 2018 at 6:53 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2018-03-16 11:42, Thomas Morin wrote:
> > This is related to the topic in "[horizon][neutron] tools/tox_install
> > changes - breakage with constraints".
> >
> > proposes to remove these projects from upper-constraints (for a
> > different reason)
> > https://review.openstack.org/#/c/552865
> > <https://review.openstack.org/#/c/552865/> that adds other projects to
> > global-requirements, explicitly postpone their addition to
> > upper-constraints to a later step
> >
> > Perhaps neutron and horizon should be removed from upper-constraints for
> > now ? (ie restore https://review.openstack.org/#/c/553030 ?)
>
> Yes, that would be one option. but I like to understand whether that
> would be a temporary solution - or the end solution.
>
> Jeffrey, how exactly are you installing neutron? From git? From tarballs?
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing 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] [horizon][neutron][kolla] tools/tox_install changes - breakage with constraints
Now it breaks the kolla's master branch jobs. And have to remove the "horizon" and "neutron" in the upper-constraints.txt file. check[1][2]. i wanna know what's the correct way to install horizon develop branch with upper-constraints.txt file? [1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/ Dockerfile.j2 [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2 On Thu, Mar 15, 2018 at 9:28 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Thomas Morin's message of 2018-03-15 10:15:38 +0100: > > Hi Doug, > > > > Doug Hellmann, 2018-03-14 23:42: > > > We keep doing lots of infra-related work to make it "easy" to do > > > when it comes to > > > managing dependencies. There are three ways to address the issue > > > with horizon and neutron, and none of them involve adding features > > > to pbr. > > > > > > 1. Things that are being used like libraries need to release like > > >libraries. Real releases. With appropriate version numbers. So > > >that other things that depend on them can express valid > > > dependencies. > > > > > > 2. Extract the relevant code into libraries and release *those*. > > > > > > 3. Things that are not stable enough to be treated as a library > > >shouldn't be used that way. Move the things that use the > > > application > > >code as library code back into the repo with the thing that they > > >are tied to but that we don't want to (or can't) treat like a > > >library. > > > > What about the case where there is co-development of features across > > repos ? One specific case I have in mind is the Neutron stadium where > > We do that all the time with the Oslo libraries. It's not as easy as > having everything in one repo, but we manage. > > > we sometimes have features in neutron repo that are worked on as a pre- > > requisite for things that will be done in a neutron-* or networking-* > > project. Another is a case for instance where we need to add in project > > X a tempest test to validate the resolution of a bug for which the fix > > actually happened in project B (and where B is not a library). > > If the tempest test can't live in B because it uses part of X, then I > think X and B are really one thing and you're doing more work than you > need to be doing to keep them in separate libraries. > > > My intuition is that it is not illegitimate to expect this kind of > > development workflow to be feasible; but at the same time I read your > > suggestion above as meaning that it belongs to the real of "things we > > shouldn't be doing in the first place". The only way I can reconcile > > You read me correctly. > > We install a bunch of components from source for integration tests > in devstack-gate because we want the final releases to work together. > But those things only interact via REST APIs, and don't import each > other. The cases with neutron and horizon are different. Even the > *unit* tests of the add-ons require code from the "parent" app. That > indicates a level of coupling that is not being properly addressed by > the release model and code management practices for the parent apps. > > > the two would be to conclude we should collapse all the module in > > neutron-*/networking-* into neutron, but doing that would have quite a > > lot of side effects (yes, this is an understatement). > > That's not the only way to do it. The other way would be to properly > decompose the shared code into a library and then provide *stable > APIs* so code can be consumed by the add-on modules. That will make > evolving things a little more difficult because of the stability > requirement. So it's a trade off. I think the teams involved should > make that trade off (in one direction or another), instead of > building tools to continue to avoid dealing with it. > > So let's start by examining the root of the problem: Why are the things > that need to import neutron/horizon not part of the neutron/horizon > repositories in the first place? > > 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] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron
thanks Thomas, i will move my question into that topics. anyone who are interesting this issue, please reply in "[horizon][neutron] tools/tox_install changes - breakage with constraints". On Fri, Mar 16, 2018 at 6:42 PM, Thomas Morin <thomas.mo...@orange.com> wrote: > This is related to the topic in "[horizon][neutron] tools/tox_install > changes - breakage with constraints". > > proposes to remove these projects from upper-constraints (for a different > reason) > https://review.openstack.org/#/c/552865 that adds other projects to > global-requirements, explicitly postpone their addition to > upper-constraints to a later step > > Perhaps neutron and horizon should be removed from upper-constraints for > now ? (ie restore https://review.openstack.org/#/c/553030 ?) > > -Thomas > > > Jeffrey Zhang, 2018-03-16 18:31: > > recently, a new patch is merged[0]. It adds neutron and horizon itself into > upper-constraints.txt. But this will break installing horizon and neutron > with > upper-constraints.txt. > > Now it breaks the kolla's master branch patch. And have to remove the > "horizon" > and "neutron" in the files. check[1][2]. > > The easier way to re-produce this is > > git clone https://github.com/openstack/horizon.git > cd horizon > pip install -c https://git.openstack.org/cgit/openstack/requirements/ > plain/upper-constraints.txt . > > So the question is, is this expected? if so, what's the correct way to > install horizon develop > branch with upper-constraints.txt file? > > > [0] https://review.openstack.org/#/c/550475/ > [1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/ > Dockerfile.j2 > [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2 > > > -- > 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-dev] [requirements][kolla] new requirements change on upper-constraints.txt break horizon & neutron
recently, a new patch is merged[0]. It adds neutron and horizon itself into upper-constraints.txt. But this will break installing horizon and neutron with upper-constraints.txt. Now it breaks the kolla's master branch patch. And have to remove the "horizon" and "neutron" in the files. check[1][2]. The easier way to re-produce this is git clone https://github.com/openstack/horizon.git cd horizon pip install -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt . So the question is, is this expected? if so, what's the correct way to install horizon develop branch with upper-constraints.txt file? [0] https://review.openstack.org/#/c/550475/ [1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/Dockerfile.j2 [2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2 -- 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 caoyuan
sorry for a typo. The vote is open for 7 days until Mar 19th. On Mon, Mar 12, 2018 at 10:06 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > Kolla core reviewer team, > > It is my pleasure to nominate caoyuan for kolla core team. > > caoyuan's output is fantastic over the last cycle. And he is the most > active non-core contributor on Kolla project for last 180 days[1]. He > focuses on configuration optimize and improve the pre-checks feature. > > Consider this nomination a +1 vote from me. > > A +1 vote indicates you are in favor of caoyuan as a candidate, a -1 > is a veto. Voting is open for 7 days until Mar 12th, or a unanimous > response is reached or a veto vote occurs. > > [1] http://stackalytics.com/report/contribution/kolla-group/180 > -- > 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
[openstack-dev] [kolla][vote] core nomination for caoyuan
Kolla core reviewer team, It is my pleasure to nominate caoyuan for kolla core team. caoyuan's output is fantastic over the last cycle. And he is the most active non-core contributor on Kolla project for last 180 days[1]. He focuses on configuration optimize and improve the pre-checks feature. Consider this nomination a +1 vote from me. A +1 vote indicates you are in favor of caoyuan as a candidate, a -1 is a veto. Voting is open for 7 days until Mar 12th, or a unanimous response is reached or a veto vote occurs. [1] http://stackalytics.com/report/contribution/kolla-group/180 -- 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 jobs failed on pike branch due to package dependency
Here is what i tried[0]. - pin ceph version in ceph-* container to Jewel. - the clients (nova/gnocchi/cinder) container use ceph Luminous. I made some test locally with a env: nova + glance + gnocchi + ceph, seems it works. [0] https://review.openstack.org/549466 On Tue, Feb 27, 2018 at 12:53 AM, Michał Jastrzębski <inc...@gmail.com> wrote: > I'm for option 1 definitely. accidental ceph upgrade during routine > minor version upgrade is something we don't want. We will need big > warning about this version mismatch in release notes. > > On 26 February 2018 at 07:01, Eduardo Gonzalez <dabar...@gmail.com> wrote: > > I prefer option 1, breaking stable policy is not good for users. They > will > > be forced to upgrade a major ceph version during a minor upgrade, which > is > > not good and not excepted to be done ever. > > > > Regards > > > > > > 2018-02-26 9:51 GMT+01:00 Shake Chen <shake.c...@gmail.com>: > >> > >> I prefer to the option 2. > >> > >> On Mon, Feb 26, 2018 at 4:39 PM, Jeffrey Zhang <zhang.lei@gmail.com > > > >> wrote: > >>> > >>> Recently, the Ubuntu jobs on pike branch are red[0]. With some > debugging, > >>> i found it is caused by > >>> package dependency. > >>> > >>> > >>> *Background* > >>> > >>> Since we have no time to upgrade ceph from Jewel to Luminous at the end > >>> of pike cycle, we pinned > >>> Ceph to Jewel on pike branch. This works on CentOS, because ceph jewel > >>> and ceph luminous are on > >>> the different repos. > >>> > >>> But in Ubuntu Cloud Archive repo, it bump ceph to Luminous. Even though > >>> ceph luminous still exists > >>> on UCA. But since qemu 2.10 depends on ceph luminous, we have to ping > >>> qemu to 2.5 to use ceph Jewel[1]. > >>> And this works since then. > >>> > >>> > >>> *Now Issue* > >>> > >>> But recently, UCA changed the libvirt-daemon package dependency, and > >>> added following, > >>> > >>> Package: libvirt-daemon > >>> Version: 3.6.0-1ubuntu6.2~cloud0 > >>> ... > >>> Breaks: qemu (<< 1:2.10+dfsg-0ubuntu3.4~), qemu-kvm (<< > >>> 1:2.10+dfsg-0ubuntu3.4~) > >>> > >>> It requires qemu 2.10 now. So dependency is broken and nova-libvirt > >>> container is failed to build. > >>> > >>> > >>> *Possible Solution* > >>> > >>> I think there two possible ways now, but none of them is good. > >>> > >>> 1. install ceph Luminuous on nova-libvirt container and ceph Jewel in > >>> ceph-* container > >>> 2. Bump ceph from jewel to luminous. But this breaks the backport > policy, > >>> obviously. > >>> > >>> So any idea on this? > >>> > >>> [0] https://review.openstack.org/534149 > >>> [1] https://review.openstack.org/#/c/526931/ > >>> > >>> -- > >>> 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 > >>> > >> > >> > >> > >> -- > >> Shake Chen > >> > >> > >> > __ > >> OpenStack Development Mailing 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] Ubuntu jobs failed on pike branch due to package dependency
Recently, the Ubuntu jobs on pike branch are red[0]. With some debugging, i found it is caused by package dependency. *Background* Since we have no time to upgrade ceph from Jewel to Luminous at the end of pike cycle, we pinned Ceph to Jewel on pike branch. This works on CentOS, because ceph jewel and ceph luminous are on the different repos. But in Ubuntu Cloud Archive repo, it bump ceph to Luminous. Even though ceph luminous still exists on UCA. But since qemu 2.10 depends on ceph luminous, we have to ping qemu to 2.5 to use ceph Jewel[1]. And this works since then. *Now Issue* But recently, UCA changed the libvirt-daemon package dependency, and added following, Package: libvirt-daemon Version: 3.6.0-1ubuntu6.2~cloud0 ... Breaks: qemu (<< 1:2.10+dfsg-0ubuntu3.4~), qemu-kvm (<< 1:2.10+dfsg-0ubuntu3.4~) It requires qemu 2.10 now. So dependency is broken and nova-libvirt container is failed to build. *Possible Solution* I think there two possible ways now, but none of them is good. 1. install ceph Luminuous on nova-libvirt container and ceph Jewel in ceph-* container 2. Bump ceph from jewel to luminous. But this breaks the backport policy, obviously. So any idea on this? [0] https://review.openstack.org/534149 [1] https://review.openstack.org/#/c/526931/ -- 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]no meeting at Feb 28 because of PTG
Due to the PTG in Dublin, next meeting at Feb 28 is canceled. -- 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 <kennelso...@gmail.com> 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 <kennelso...@gmail.com> > 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 <kennelso...@gmail.com> >> 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
[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=kolla=commits [1] http://stackalytics.com/?release=all=kolla=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] [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 <paul.bou...@oracle.com> 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] 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] 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 <xinliang@linaro.org> wrote: > On 27 December 2017 at 20:25, Steven Dake (stdake) <std...@cisco.com> > 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 <xinliang@linaro.org> > wrote: > >> On 26 December 2017 at 15:38, Marcin Juszkiewicz > >> <marcin.juszkiew...@linaro.org> wrote: > >>> > >>> > >>> 26.12.2017 08:05 "Xinliang Liu" <xinliang@linaro.org> 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] 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 <pratapagout...@gmail.com> 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: > <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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] 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" <s...@yaple.net>写道： > 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 <paul.bou...@oracle.com> > 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
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 <paul.bou...@oracle.com> 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
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> 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] Proposal to add Marcin (hrw) to kolla images core team
+1 On Fri, Nov 3, 2017 at 9:46 AM, Xinliang Liu <xinliang@linaro.org> wrote: > +1, as I know hrw makes great contribution on ARM. > > On 2 November 2017 at 23:58, Michał Jastrzębski <inc...@gmail.com> 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] [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 <kennelso...@gmail.com> 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 <zhang.lei@gmail.com> > 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 <kennelso...@gmail.com> >> 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 <mriede...@gmail.com> >>> 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 <dansm...@redhat.com> >>>> - Melanie "Structured Settlement" Witt <melwi...@gmail.com> >>>> - Ed "Alternate Hosts" Leafe <e...@leafe.com> >>>> >>>> -- >>>> >>>> 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] [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 <kennelso...@gmail.com> 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 <mriede...@gmail.com> > 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 <dansm...@redhat.com> >> - Melanie "Structured Settlement" Witt <melwi...@gmail.com> >> - Ed "Alternate Hosts" Leafe <e...@leafe.com> >> >> -- >> >> 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] [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 <sam...@yaple.net> 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 <mna...@vexxhost.com> > wrote: > >> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <zhang.lei@gmail.com> >> 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] [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)" <vhosa...@cisco.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *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 <inc...@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *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
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 <eswar7...@gmail.com> 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] 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 <today.g...@163.com> 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] 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 <paul.bou...@oracle.com> 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][kolla-ansible] Proposing Surya (spsurya) for core
+1 nice jobs ;) On Wed, Jun 14, 2017 at 11:52 PM, Paul Bourke <paul.bou...@oracle.com> 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] [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 <kevin@pnnl.gov> 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 Bertrand Lallau for kolla and kolla-ansible core
+1 On Wed, May 3, 2017 at 12:31 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > +1 > > > -Original Message- > From: Michał Jastrzębski <inc...@gmail.com> > 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] [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, <hu.zhiji...@zte.com.cn> 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] 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 <sba...@redhat.com> wrote: > > > On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann <d...@doughellmann.com> > 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] Proposing duonghq for core
+1 from me On Wed, Mar 8, 2017 at 2:41 PM, Michał Jastrzębski <inc...@gmail.com> 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
[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] [networking-sfc] Stable/Ocata Version
roger. thanks all guys. On Tue, Mar 7, 2017 at 3:26 AM, Cathy Zhang <cathy.h.zh...@huawei.com> 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 <louis.fou...@huawei.com> > 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
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 <m...@mattfischer.com> 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] [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 <paul.bou...@oracle.com> 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] [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 <d...@doughellmann.com> 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] [neutron][sfc] stable/ocata version
great. thanks. On Tue, Mar 7, 2017 at 3:14 AM, Dariusz Śmigiel <smigiel.dari...@gmail.com> wrote: > 2017-03-06 11:27 GMT-06:00 Henry Fourie <louis.fou...@huawei.com>: > > 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] [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 <zhang.lei@gmail.com> 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
[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] [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 <gkot...@vmware.com> 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 <gkot...@vmware.com> > *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org> > *Date: *Sunday, March 5, 2017 at 9:36 AM > > *To: *OpenStack List <openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version > > > > Thanks! > > > > *From: *Jeffrey Zhang <zhang.lei@gmail.com> > *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org> > *Date: *Sunday, March 5, 2017 at 9:12 AM > *To: *OpenStack List <openstack-dev@lists.openstack.org> > *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 <gkot...@vmware.com> 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_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc=> > > ______ > OpenStack Development Mailing 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 <gkot...@vmware.com> 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] [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] [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 <louis.fou...@huawei.com> 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] [rally][ironic][release] How rally/ironic release version
@Dmitry, thanks. So ironic will use "openstack/releases" for release management? right? On Mon, Feb 13, 2017 at 11:19 PM, Dmitry Tantsur <dtant...@redhat.com> wrote: > We're still not done :( But we're very close! Please expect releases later > today or tomorrow. > > On 02/13/2017 04:09 PM, Jeffrey Zhang wrote: > >> loop ironic tag in subject. >> >> i do not see any release info in Ocata cycle in ironic[0] and >> ironic-inspector[1] project. >> >> >> [0] https://github.com/openstack/releases/blob/master/deliverabl >> es/ocata/ironic.yaml >> [1] https://github.com/openstack/releases/blob/master/deliverabl >> es/ocata/ironic-inspector.yaml >> >> On Mon, Feb 13, 2017 at 11:02 PM, Davanum Srinivas <dava...@gmail.com >> <mailto:dava...@gmail.com>> wrote: >> >> To add, please consider appointing a CPL to coordinate the update to >> the releases/ repo: >> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release >> _management >> <https://wiki.openstack.org/wiki/CrossProjectLiaisons#Releas >> e_management> >> >> Thanks, >> Dims >> >> On Mon, Feb 13, 2017 at 9:15 AM, Doug Hellmann <d...@doughellmann.com >> <mailto:d...@doughellmann.com>> wrote: >> > Excerpts from Andrey Kurilin's message of 2017-02-13 12:14:31 +0200: >> >> Hi Jeffrey, >> >> >> >> Rally team do not use "releases" repo at all, that is why >> information at >> >> [2] is outdated. >> >> Our release workflow is making a proper tag and pushing it via >> Gerrit. I >> >> find it more convenient. >> > >> > Please propose an update to openstack/releases to either update the >> > history information for Rally's releases or to delete the relevant >> file >> > entirely to avoid confusion. >> > >> > Doug >> > >> >> >> >> >> >> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang < >> zhang.lei@gmail.com >> <mailto:zhang.lei@gmail.com>> >> >> wrote: >> >> >> >> > Hey guys, >> >> > >> >> > I found rally already releases its 0.8.1 tag from[0][1]. But >> >> > I found nothing in openstack/releases project[2]. How rally >> >> > create tag? >> >> > >> >> > [0] http://tarballs.openstack.org/rally/ >> <http://tarballs.openstack.org/rally/> >> >> > [1] https://github.com/openstack/rally/releases >> <https://github.com/openstack/rally/releases> >> >> > [2] https://github.com/openstack/releases/blob/master/deliverabl >> es/_ >> <https://github.com/openstack/releases/blob/master/deliverables/_> >> >> > independent/rally.yaml#L45 >> >> > >> >> > -- >> >> > 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac >> k-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> > >> >> > >> >> >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.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> >> >> >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> >> __ >> OpenStack Development Mailing List (not for us
Re: [openstack-dev] [rally][ironic][release] How rally/ironic release version
loop ironic tag in subject. i do not see any release info in Ocata cycle in ironic[0] and ironic-inspector[1] project. [0] https://github.com/openstack/releases/blob/master/deliverables/ocata/ironic.yaml [1] https://github.com/openstack/releases/blob/master/deliverables/ocata/ironic-inspector.yaml On Mon, Feb 13, 2017 at 11:02 PM, Davanum Srinivas <dava...@gmail.com> wrote: > To add, please consider appointing a CPL to coordinate the update to > the releases/ repo: > https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management > > Thanks, > Dims > > On Mon, Feb 13, 2017 at 9:15 AM, Doug Hellmann <d...@doughellmann.com> > wrote: > > Excerpts from Andrey Kurilin's message of 2017-02-13 12:14:31 +0200: > >> Hi Jeffrey, > >> > >> Rally team do not use "releases" repo at all, that is why information at > >> [2] is outdated. > >> Our release workflow is making a proper tag and pushing it via Gerrit. I > >> find it more convenient. > > > > Please propose an update to openstack/releases to either update the > > history information for Rally's releases or to delete the relevant file > > entirely to avoid confusion. > > > > Doug > > > >> > >> > >> > >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com > > > >> wrote: > >> > >> > Hey guys, > >> > > >> > I found rally already releases its 0.8.1 tag from[0][1]. But > >> > I found nothing in openstack/releases project[2]. How rally > >> > create tag? > >> > > >> > [0] http://tarballs.openstack.org/rally/ > >> > [1] https://github.com/openstack/rally/releases > >> > [2] https://github.com/openstack/releases/blob/master/deliverables/_ > >> > independent/rally.yaml#L45 > >> > > >> > -- > >> > 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 > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing 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] [rally][release] How rally release version
@Andrey, thanks for the explanation. The issue is: how can i know which tag works with certain OpenStack branch? For example, which tag works with OpenStack Ocata release? There is no place recording this. I also found there are some other project do not use "project/releases" project. May they are using the same solution as rally. On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com> wrote: > Hi Jeffrey, > > Rally team do not use "releases" repo at all, that is why information at > [2] is outdated. > Our release workflow is making a proper tag and pushing it via Gerrit. I > find it more convenient. > > > > On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > >> Hey guys, >> >> I found rally already releases its 0.8.1 tag from[0][1]. But >> I found nothing in openstack/releases project[2]. How rally >> create tag? >> >> [0] http://tarballs.openstack.org/rally/ >> [1] https://github.com/openstack/rally/releases >> [2] https://github.com/openstack/releases/blob/master/ >> deliverables/_independent/rally.yaml#L45 >> >> -- >> 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 >> >> > > > -- > Best regards, > Andrey Kurilin. > > __ > OpenStack Development Mailing 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] [rally][release] How rally release version
Hey guys, I found rally already releases its 0.8.1 tag from[0][1]. But I found nothing in openstack/releases project[2]. How rally create tag? [0] http://tarballs.openstack.org/rally/ [1] https://github.com/openstack/rally/releases [2] https://github.com/openstack/releases/blob/master/deliverables/_independent/rally.yaml#L45 -- 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] [FFE][requirements][murano][murano-pkg-check]pdate constraint for murano-pkg-check to new release 0.3.0
upper-constraints.txt is enough. let merge the following patch in the next cycle. thanks tonyb. On Tue, Feb 7, 2017 at 1:46 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Tue, Feb 07, 2017 at 11:32:28AM +0800, Rong Zhu wrote: > > The Bot Gerrit link is: https://review.openstack.org/#/c/428200/ > > > > update constraint for murano-pkg-check to new release 0.3.0 Change-Id: > > I4d8cbf55525c90efd5d46f4659b57197f4c6f9f3 > > <https://review.openstack.org/#q,I4d8cbf55525c90efd5d46f4659b57 > 197f4c6f9f3,n,z> > > meta:version: 0.3.0 meta:diff-start: - meta:series: independent > > meta:release-type: release meta:pypi: yes meta:first: no > > meta:release:Author: zhurong <aaronzhu1...@gmail.com> > meta:release:Commit: > > zhurong <aaronzhu1...@gmail.com> meta:release:Change-Id: > > Ifa5de68fdf5f340e240a117563667ecd8903daff > > <https://review.openstack.org/#q,Ifa5de68fdf5f340e240a117563667 > ecd8903daff,n,z> > > meta:release:Code-Review+2: Doug Hellmann <d...@doughellmann.com> > > meta:release:Workflow+1: Doug Hellmann <d...@doughellmann.com> > > It's a upper-constraints.txt bump so I'm fine with granting an exception > for that. > > Howveer the follow-up patch to bump the minimum on global-requirements.txt > is > too disruptive to take. > > From my comment on the review: > We can't take this as it would require a re-release of python-muranoclient, > which inturn require a re-release of python-openstackclient which then > quickly > blows out: > > Package : murano-pkg-check [murano-pkg-check>=0.2.0] (used by 2 > projects) > Also affects : 2 projects > openstack/murano [] > openstack/python-muranoclient [] > Package : python-muranoclient [python-muranoclient>=0.8.2] (used by > 6 projects) > Also affects : 6 projects > openstack/congress[] > openstack/mistral [] > openstack/murano [] > openstack/murano-dashboard[] > openstack/openstackclient [] > openstack/python-openstackclient [] > Package : python-openstackclient [python-openstackclient>=3.3.0] > (used by 25 projects) > Also affects : 25 projects > openstack/ec2-api [] > openstack/freezer [] > openstack/heat[tc:approved-release] > openstack/kingbird[] > openstack/kolla [] > openstack/kolla-ansible [] > openstack/networking-bgpvpn [] > openstack/networking-midonet [] > openstack/networking-sfc [] > openstack/python-barbicanclient [] > openstack/python-heatclient [] > openstack/python-ironic-inspector-client [] > openstack/python-ironicclient [] > openstack/python-kingbirdclient [] > openstack/python-magnumclient [] > openstack/python-manilaclient [] > openstack/python-mistralclient[] > openstack/python-moganclient [] > openstack/python-neutronclient[] > openstack/python-saharaclient [] > openstack/python-searchlightclient[] > openstack/python-tripleoclient[] > openstack/python-troveclient [] > openstack/vmware-nsx [] > openstack/watcher [] > > The knock-on effects are just too far reaching for this to be granted in > Ocata. > > Yours Tony. > > __ > OpenStack Development Mailing 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] pip install kolla-ansible 4.0.0b3+ broken
This is caused by legacy issue during split kolla and kolla-ansible.
this[0] line should be changed to
version_info = pbr.version.VersionInfo('kolla-ansible')
A dirty quick fix is install kolla along with kolla-ansible with the same
version.
[0]
https://github.com/openstack/kolla-ansible/blob/161491edc55ca0530c3c444d11e1d7c5393b7d07/kolla/version.py#L15
On Mon, Feb 6, 2017 at 10:57 PM, Steven Dake (stdake) <std...@cisco.com>
wrote:
> Hey folks,
>
>
>
> Pip install kolla-ansible is busted. I’d take ownership of this bug
> myself, however, I am personally swamped. This is a DOA deliverable issue
> and as such is higher priority than “critical”. Can someone in the
> community take a look?
>
>
>
> https://bugs.launchpad.net/kolla-ansible/+bug/1662195
>
>
>
> TIA!
>
> -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] [vote][kolla] deprecation for Debian distro support
2 On Thu, Jan 19, 2017 at 7:53 PM, Mauricio Lima <mauricioli...@gmail.com> wrote: > 2 > > 2017-01-19 8:50 GMT-03:00 Steven Dake (stdake) <std...@cisco.com>: > >> My vote is for option 2 to deprecate Debian as there has been very little >> activity and operators seem uninterested in Debian as a platform. >> >> We could always add it back in at a later date if operators were to >> request it and the Debian team were interested in maintaining it. >> >> Regards >> -steve >> >> >> -Original Message- >> From: Christian Berendt <bere...@betacloud-solutions.de> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Date: Thursday, January 19, 2017 at 3:53 AM >> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack >> .org> >> Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro >> support >> >> As discussed in one of the last team meetings I want to propose the >> deprecation (this cycle) and removal (next cycle) of the Debian support in >> Kolla. >> >> More than 1 week ago I sent a pre warning mail to the >> openstack-operators mailing list, without any reply [0]. >> >> Kolla core reviewers, please vote now. The vote will be open for 7 >> days (26.01.2017). >> >> 1. Kolla needs support for Debian, it should not be deprecated >> >> 2. Kolla should deprecate support for Debian >> >> [0] http://lists.openstack.org/pipermail/openstack-operators/201 >> 7-January/012427.html >> >> -- >> Christian Berendt >> Chief Executive Officer (CEO) >> >> Mail: bere...@betacloud-solutions.de >> Web: https://www.betacloud-solutions.de >> >> Betacloud Solutions GmbH >> Teckstrasse 62 / 70190 Stuttgart / Deutschland >> >> Geschäftsführer: Christian Berendt >> Unternehmenssitz: Stuttgart >> Amtsgericht: Stuttgart, HRB 756139 >> >> >> >> __ >> 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 >> >> >> >> __ >> 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] Multi-Regions Support
t; module[9] that is responsible for contacting Keystone and creating a > new endpoint when we register a new OpenStack service. > > > 73 for _endpoint in cloud.keystone_client.endpoints.list(): > 74 if _endpoint.service_id == service.id and \ > 75 _endpoint.interface == interface: > 76endpoint = _endpoint > 77if endpoint.url != url: > 78 changed = True > 79 cloud.keystone_client.endpoints.update( > 80endpoint, url=url) > 81break > 82 else: > 83changed = True > 84cloud.keystone_client.endpoints.create( > 85 service=service.id, > 86 url=url, > 87 interface=interface, > 88 region=endpoint_region) > > > At some point, this module /create/ or /update/ a service endpoint. It > first tests if the service is already registered, and update the URL > if so (l. 74 to 81), or create the new endpoint in other cases (l. > 82). Unfortunately, the test (l. 74 to 75) only looks at the service > (e.g., glance) and the interface (e.g., public). This makes the test > wrong because we deploy the same service many times, but into > different regions. We have to add an extra condition to not only test > the service but also its region. > > > 74 if _endpoint.service_id == service.id and \ > 75 _endpoint.interface == interface and \ > 76 _endpoint.region == endpoint_region: > > > Finally, when we deployed OSRs, we override the value of > `keystone_admin_url', `keystone_internal_url' and `keystone_public_url' > to target Keystone in AR. We also have to change the > `[keystone_authtoken]' section of nova/neutron/glance conf[10] so that > it uses these variables instead of the canonical form with the > `kolla_internal_fqdn' variable[11]. In this regards, is it due to some > legacy code that configuration files use the `kolla_internal_fqdn' > variable instead of `keystone_*_url'? > > That's almost all. As you can see, handle multi-regions implies a very > small number of modifications if you call Kolla multiple times. > > So, thanks for the great job Kolla team! And waiting for your > feedback. > > > > [1] https://github.com/BeyondTheClouds/kolla/commit/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554 > [2] https://beyondtheclouds.github.io/ > [3] http://docs.openstack.org/arch-design/multi-site-architecture.html > [4] https://github.com/openstack/kolla/blob/11bfd9eb7518cc46ac441505a267f5 > cf974216ae/ansible/roles/keystone/tasks/register.yml > [5] https://github.com/BeyondTheClouds/kolla/commit/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554#diff- > 40be75c3a2237adfd1a05178f6f60006R1 > [6] https://github.com/BeyondTheClouds/kolla/commit/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554#diff- > 607e6e5925d0031dafa79eb80d198640R215 > [7] https://github.com/BeyondTheClouds/kolla/commit/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554#diff- > 6cbb63bb9c4843bcf8db4710e588475bR188 > [8] https://github.com/BeyondTheClouds/kolla/tree/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554/multi-regions > [9] https://github.com/BeyondTheClouds/kolla/commit/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554#diff- > ba10dd4575f65e03d50d586febdccbadR72 > [10] https://github.com/BeyondTheClouds/kolla/blob/ > 7e5f7e6c7936b7cc3136dfc082935e2995a65554/multi-regions/global.conf > [11] https://github.com/openstack/kolla/blob/ > 11bfd9eb7518cc46ac441505a267f5cf974216ae/ansible/roles/nova/ > templates/nova.conf.j2#L155 > > > -- > Ronan-A. Cherrueau > > __ > OpenStack Development Mailing 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][rdo] libvirt 2.0 process is failed during launching qemu progress
On Tue, Jan 3, 2017 at 6:23 AM, Clark Boylan <cboy...@sapwetik.org> wrote: > I don't have any answers but my first thought was maybe it is related to > https://bugs.launchpad.net/nova/+bug/1643911; however, that affects > libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of > that occurring on a non Xen hypervisor so maybe they are not related. > seems it is not related. > > Also noticed that you appear to have two redundant sets of system logs > in the Kolla centos job(s). See > http://logs.openstack.org/80/415880/1/check/gate-kolla- > dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/ > and > http://logs.openstack.org/80/415880/1/check/gate-kolla- > dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/. > yep. this is issue after split the kolla project into kolla-ansible and kolla. will fix it later. > > As for debugging this you may be able to install libvirt's debugging > symbols > (http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2. > 0.0-10.el7.x86_64.rpm), > capture a core dump, load into gdb and go from there. > I will try to install it and get more information. -- 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][rdo] libvirt 2.0 process is failed during launching qemu progress
On Tue, Jan 3, 2017 at 6:37 AM, Michał Jastrzębski <inc...@gmail.com> wrote: > XEN doesn't work well with nested kvm. We need to change nova config to > pure qemu without kvm. I thought we did that in gates? In the gate, kolla is using qemu all the time[0]. So this should be not related. [0] http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/kolla_configs/nova-compute/nova.conf.txt.gz -- 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] [legal-discuss] [kolla]is it OK to modify python code in OpenStack project?
Thanks all guys. Copy python code is really a bad idea. Now i have moved to re-use oslo.config iniparser[0][1], which works too. So we have no license issue, now. ;) [0] https://github.com/openstack/oslo.config/blob/master/oslo_config/iniparser.py [1] https://review.openstack.org/#/c/412101/5/ansible/action_plugins/merge_configs.py On Tue, Jan 3, 2017 at 1:04 AM, Van Lindberg <van.lindb...@rackspace.com> wrote: > Thierry is correct in his analysis. > > > If you really want to copy it - which I don't suggest - then copy it over > into your repo, rename both the module and the class, and make your code > use your derived work. > > > Put a header at the top that says something like "Based on Python's > ConfigParser.py. Original ConfigParser.py distributed under the Python > Software Foundation license. Additions and changes copyright [YOU] and > distributed under the Apache Software License, v2." > > > Do not modify the stdlib in-place (as it sounds like you are doing) - but > perhaps I just misunderstand. > > > -- > *From:* Thierry Carrez <thie...@openstack.org> > *Sent:* Monday, January 2, 2017 4:45 AM > *To:* legal-disc...@lists.openstack.org > *Subject:* Re: [legal-discuss] [kolla]is it OK to modify python code in > OpenStack project? > > Jeffrey Zhang wrote: > > Recently, Kolla project has requirement to modify[1] the python's > > ConfigParser.py code[0]. > > > > Python is using PSF license[3], which is GPL compatible. But OpenStack > > is using Apache License. > > > > Here is the diff view[2]. > > > > I want to make sure: is it OK to re-license ConfigParser.py? If not, what > > the solution? > > > > [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py > > [1] https://review.openstack.org/412101 > > [2] https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3 > 71/revisions?diff=split > > [3] https://docs.python.org/3/license.html > > I'm not a lawyer, but it sounds slightly tricky. > > The PSF license is Apache-compatible, which means that you can combine > PSF-licensed and Apache-licensed code (if you retain the original > licenses). But OpenStack code must be licensed under a license supported > by the Contributor License Agreement (CLA) which allows redistribution > by the OpenStack Foundation under ASLv2 (currently only ASLv2, the MIT > and both forms of the BSD license meet this requirement). > > So I don't think we can really bundle PSF-licensed code within OpenStack > code, and I think too much was copied from the original class so that > anyone can pretend it is original work. > > Three solutions that should work around the problem without requiring > lawyers to further investigate the issue: > > 1/ Do a clean room implementation (by someone not familiar with the > original code) > > 2/ Rewrite your code so that it takes a pure ConfigParser class output > and transforms it into what you need, rather than copying code over > > 3/ Publish your modified ConfigParser into its own 3rd-party PyPI > library (licensed under the PSF license) > > Of those, (2) is the one that introduces the less technical debt (no > code copy). > > -- > Thierry Carrez (ttx) > > ___ > legal-discuss mailing list > legal-disc...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > ___ > legal-discuss mailing list > legal-disc...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > -- 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][rdo] libvirt 2.0 process is failed during launching qemu progress
Checked more failed gate, here is the more info: 1. only rax-iad has such issue 2. the failed and successful gates have the same rpm installed. So the only difference between failed gate and successful gate is the xen hypervisor. On Sun, Jan 1, 2017 at 6:33 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Jeffrey, > > > > rax-iad uses xen as a base virtualization layer iiuc. Perhaps kvm on xen > is not a technical feature rax-iad supports or perhaps libvirt was modified > and now fails with xen? Whatever the case is, rax-iad has been a > semi-constant source of hassle with Kolla’s gate jobs; I think partly > because Kolla’s gate scripts need to special-case rax-iad in some way. > > > > Just one of many possibilities. > > > > Happy new year J > > > > Regards > > -steve > > > > > > *From: *Jeffrey Zhang <zhang.lei@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Saturday, December 31, 2016 at 6:22 AM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed > during launching qemu progress > > > > I checked more than ten error gates, all of them happened in rax-iad. > > > > On Sat, Dec 31, 2016 at 12:06 PM, Steven Dake (stdake) <std...@cisco.com> > wrote: > > Jeffrey, > > > > Have you detected any pattern to any specific cloud provider in the logs? > > > > Regards > > -steve > > > > > > *From: *Jeffrey Zhang <zhang.lei@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Friday, December 30, 2016 at 12:41 AM > *To: *OpenStack Development Mailing List <openstack-dev@lists. > openstack.org> > *Subject: *Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed > during launching qemu progress > > > > Found this nova bug[0] and another talk in openstack-dev[1]. > > > > The question is: why this happens now and then? sometimes the gate is OK. > and others not. > > > > [0] https://bugs.launchpad.net/nova/+bug/1649527 > > [1] http://lists.openstack.org/pipermail/openstack-dev/ > 2016-December/109401.html > > > > On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > > Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version. > > > > But in kolla's gate. the nova_libvirt container failed now and then. > > > > What i found is: > > > > 1. Simple start nova_libvirt container is OK. > > 2. When launching a new instance, libvirt is killed without any logs in > libvirtd.log file. > > 3. in system messages log, i found following line. > > Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip > 7f9fee072823 sp 7f9fe52dd1c0 error 4 in > libvirt.so.0.2000.0[7f9fedf1f000+353000] > > No idea why and how this happen. Any idea on this? > > > > -- > > 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 > > > > > > -- > > 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
Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress
I checked more than ten error gates, all of them happened in rax-iad. On Sat, Dec 31, 2016 at 12:06 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Jeffrey, > > > > Have you detected any pattern to any specific cloud provider in the logs? > > > > Regards > > -steve > > > > > > *From: *Jeffrey Zhang <zhang.lei@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Friday, December 30, 2016 at 12:41 AM > *To: *OpenStack Development Mailing List <openstack-dev@lists. > openstack.org> > *Subject: *Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed > during launching qemu progress > > > > Found this nova bug[0] and another talk in openstack-dev[1]. > > > > The question is: why this happens now and then? sometimes the gate is OK. > and others not. > > > > [0] https://bugs.launchpad.net/nova/+bug/1649527 > > [1] http://lists.openstack.org/pipermail/openstack-dev/ > 2016-December/109401.html > > > > On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > > Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version. > > > > But in kolla's gate. the nova_libvirt container failed now and then. > > > > What i found is: > > > > 1. Simple start nova_libvirt container is OK. > > 2. When launching a new instance, libvirt is killed without any logs in > libvirtd.log file. > > 3. in system messages log, i found following line. > > Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip > 7f9fee072823 sp 00007f9fe52dd1c0 error 4 in > libvirt.so.0.2000.0[7f9fedf1f000+353000] > > No idea why and how this happen. Any idea on this? > > > > -- > > 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 > > -- 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][rdo] libvirt 2.0 process is failed during launching qemu progress
Found this nova bug[0] and another talk in openstack-dev[1]. The question is: why this happens now and then? sometimes the gate is OK. and others not. [0] https://bugs.launchpad.net/nova/+bug/1649527 [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109401.html On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version. > > But in kolla's gate. the nova_libvirt container failed now and then. > > What i found is: > > 1. Simple start nova_libvirt container is OK. > 2. When launching a new instance, libvirt is killed without any logs in > libvirtd.log file. > 3. in system messages log, i found following line. > > Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip > 7f9fee072823 sp 7f9fe52dd1c0 error 4 in > libvirt.so.0.2000.0[7f9fedf1f000+353000] > > No idea why and how this happen. Any idea on this? > > > -- > 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
[openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress
Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version. But in kolla's gate. the nova_libvirt container failed now and then. What i found is: 1. Simple start nova_libvirt container is OK. 2. When launching a new instance, libvirt is killed without any logs in libvirtd.log file. 3. in system messages log, i found following line. Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip 7f9fee072823 sp 7f9fe52dd1c0 error 4 in libvirt.so.0.2000.0[7f9fedf1f000+353000] No idea why and how this happen. Any idea on 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
Re: [openstack-dev] [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?
not simple override the _read() method. I also copied some code from ConfigParser.py(more than 80%, i think). is that OK? is there any difference between override method and copy codes? On Tue, Dec 27, 2016 at 3:12 AM, Monty Taylor <mord...@inaugust.com> wrote: > On 12/26/2016 07:27 AM, Davanum Srinivas wrote: > > PSF is ok per (https://governance.openstack.org/tc/reference/licensing. > html) > > Though the overriding the _read() seems like something that could > > break easily > > Yah - you can't relicense it - but you can include it with the PSF > license. It might be worth adding a PSF license header to that file and > a note that the code is copied from [0] > > That said - I agree with dims, overriding the _read() method like that > seems prone to sadness. > > > On Mon, Dec 26, 2016 at 12:13 PM, Michał Jastrzębski <inc...@gmail.com> > wrote: > >> Added all and tc tags, as it might affect everyone really. > >> > >> On 25 December 2016 at 23:04, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > >>> Recently, Kolla project has requirement to modify[1] the python's > >>> ConfigParser.py code[0]. > >>> > >>> Python is using PSF license[3], which is GPL compatible. But OpenStack > >>> is using Apache License. > >>> > >>> Here is the diff view[2]. > >>> > >>> I want to make sure: is it OK to re-license ConfigParser.py? If not, > what > >>> the solution? > >>> > >>> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py > >>> [1] https://review.openstack.org/412101 > >>> [2] > >>> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3 > 71/revisions?diff=split > >>> [3] https://docs.python.org/3/license.html > >>> > >>> > >>> -- > >>> Regards, > >>> Jeffrey Zhang > >>> Blog: http://xcodest.me > >>> > >>> ___ > >>> legal-discuss mailing list > >>> legal-disc...@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > >>> > >> > >> ___ > >> legal-discuss mailing list > >> legal-disc...@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > > > > > > > > ___ > legal-discuss mailing list > legal-disc...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > -- 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]is it OK to modify python code in OpenStack project?
Recently, Kolla project has requirement to modify[1] the python's ConfigParser.py code[0]. Python is using PSF license[3], which is GPL compatible. But OpenStack is using Apache License. Here is the diff view[2]. I want to make sure: is it OK to re-license ConfigParser.py? If not, what the solution? [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py [1] https://review.openstack.org/412101 [2] https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revisions?diff=split [3] https://docs.python.org/3/license.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] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)
t.git;a=commit;h= >> 9c17d665fdc5f0ab74500a14c30627014c11b2c0 >> >> Michal Privoznik provided some additional context: >> >> "Previously, libvirt merely just appended 'script=' onto qemu cmd line >> according to what contained letting qemu execute the >> script. That was flawed from security POV (we don't want qemu to be >> allowed to execute anything) thus libvirt is executing the script now. >> However, we obviously forgot about this corner case." >> >> This actually apparently first appeared in v1.3.3-rc1~71, so it's not new >> in Libvirt 2.0.0 *but*: >> >> * The Ubuntu-based gate is apparently running v1.3.1 at the moment. >> * The RHEL 7.2 and aligned CentOS included v1.2.17. >> >> This is at least partially why this was not seen until recently, > > > Thanks for pinning all of that down! > > >> but it also seems like it might be specific to certain guest networking >> setup. > > > Yes, there are only a few networking backends that use type=ethernet>, I believe; mine is networking-calico, which uses > VIF_TYPE_TAP; I think (from code reading) that the others are 'ivs', > 'iovisor', 'midonet' and 'vrouter'. (Although another thing to keep in > mind here is that os-vif should soon be taking over this area of code - so > any fixes in nova/virt/libvirt may also be needed in os-vif.) > > > You mentioned you have multiple interfaces attached to the guest, which >> VIF types and associated Neutron plugins are you using? >> > > Note that the multiple interfaces issue is an additional one. The empty > path issue causes all VIF_TYPE_TAP tests to fail, whether with just a > single VM interface, or multiple VM interfaces. I fixed most of those by > patching my Nova locally (as in https://review.openstack.org/#/c/411936), > but am still seeing failures in tests with multiple interfaces, which I > haven't yet investigated further. > > Regards, > Neil > > > >> 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 > > -- 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][tc] Video Meetings - input requested
I do not want to kill the ad hoc video meeting. But we should keep a certain degree of openness. what i would like to see is an invitation in email or irc channel. some agenda which tell others want will be talked. And some decision made in the video meeting should be record in some way. on eth other hand, Kolla project and its team grows. We have kolla, kolla-ansible and kolla-k8s projects now. some time 1 hour may be very tight, especially for kolla-k8s project, which is always talked at last and may have no much time. I want to make some change for this in the next kolla meeting. the 1 hour meeting time will be split into 4 part 10-10-20-20, 10 min for announcement, 10 min for kolla, 20 min for kolla-ansible and 20 min for kolla-kubernetes. So if u want talk something in the meeting, feel free to add it in agenda list before the meeting[0] [0] https://wiki.openstack.org/wiki/Meetings/Kolla On Tue, Dec 13, 2016 at 1:51 PM, Swapnil Kulkarni <cools...@gmail.com> wrote: > > > On Dec 13, 2016 8:44 AM, "Michał Jastrzębski" <inc...@gmail.com> wrote: > > I think video meetings Jeffrey is referring to are just that- quickly as > hoc way to resolve some technical dispute or implementation. We did that > few times to quickly work out kolla k8s issues. Hangouts are much more > efficient way of discussions like that. > > My take on the issue is that we should use all tools available. Scheduling > of such meetings would defeat their purpose of resolving things *quickly*. > If something requires scheduling it should be done on our weekly meeting. > > Video meetings are thing in Kolla k8s for one more reason- we want to move > fast and scheduling meeting with proper heads up for every technical > dispute (couple of these every week) would seriously impede our ability to > deliver. Ocata is our goal! > > Tldr; ad hoc video meetings are good for quickly paced dev like in Kolla > k8s imho > > Cheers > Michał > > On Dec 12, 2016 12:36 PM, "Ed Leafe" <e...@leafe.com> wrote: > > On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > > > Some contributors in kolla have had unscheduled video meetings. This has > > resulted in complaints about inclusiveness. Some contributors can’t even > make > > the meeting we have, and another scheduled video meeting might produce a > > situation in which there is no any record of decisions made during the > video > > meeting. At least with IRC meetings there is always a log. > > Occasionally a quick Google hangout is necessary in Nova in order to > quickly settle an outstanding issue so we can continue to make progress. > When that happens, the link is posted in the #openstack-nova channel, and > anyone who is interested can join. So while it’s not logged like an IRC > meeting, it’s no excluding anyone, and we can quickly remove roadblocks > that are harder to do in IRC. > > > -- Ed Leafe > > > > > > > __ > OpenStack Development Mailing 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 > > > I think there is a mutual understanding where we have informal/ ad-hoc/ on > the fly meetings to discuss important things, like after design sessions in > the corridor, during lunch/dinner, etc etc. Video calls or hangouts is just > digital extension of it. > > Only recommendation I have is a digest either on etherpad or mailing list > where people who missed can get required details. > > Swapnil > > __________ > OpenStack Development Mailing 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][tc] Video Meetings - input requested
TC , Some contributors in kolla have had unscheduled video meetings. This has resulted in complaints about inclusiveness. Some contributors can’t even make the meeting we have, and another scheduled video meeting might produce a situation in which there is no any record of decisions made during the video meeting. At least with IRC meetings there is always a log. One solution is to schedule these meetings and have two 1 hour meetings per week. As the PTL while Michal is moving, I have trouble following these video meetings since English isn’t my native language. Can you offer any advice for our project? -- 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] balancing core team karma and collecting statements from kolla team.
First of all, kolla team != kolla core reviewer members. everyone is welcome to reply this email. Kolla ( including kolla, kolla-ansible and kolla-kubernetes projects ) is using launchpad for bug track and blueprint management as other OpenStack projects. As kolla become more mature, we have more developers and operators. So more bugs are filed. we have 200+ bugs[0] and 100+ bp[1] in kolla project. it is impossible to manage the states of the bugs and bp by few people. Here is the list of activities in kolla launchpad[2]. Only a few persons are busy on this. So hope more developers could work on this, including bug triage and confirmation. This is talked in the last meeting. We want to collect some information from kolla team. 1. Do u know how to manage bugs and bp on launchpad? 2. If 1) is yes, could u take the responsibility? 3. if 2) is yes, could u give your statement below about which project will you ? Here is the statement collected in the meeting, sdake: I am not interested in bug triage for any deliverable but kolla-kubernetes but know how to do bug triage jeffrey4l: I will take the triage work for kolla and kolla-ansible portdirect: I'm not that familiar with launchpad - srwilkers has given me a few pointers but I'm aware this a areanarea I need to get up to speed on berendt: I know how to do it, but do not do it at the moment, I try to spend some time on it wirehead: I know how to do triage, it wasn't really a critical effort for kolla-kubernetes, but I should start having time to at least pitch in there. duonghq: I can help in triaging, especially in kolla If you are not in kolla-drivers team, you can ask for one of core team to add you. [0] https://bugs.launchpad.net/kolla [1] https://blueprints.launchpad.net/kolla [2] https://launchpad.net/kolla/+topcontributors -- 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-Kubernetes tagging -> on the road to 1.0.0
thanks Steve for making this clear. btw, could we have an expected release date for next minor version? On Thu, Dec 8, 2016 at 10:36 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Hey folks, > > > > Jeffrey delegated to me to determine the tagging structure for > kolla-kubernetes. I was under the mistaken impression we need to tag 1.0.0 > with the milestone tags (such as 1.0.0.0b2/1.0.0.0b3) for > kolla-kubernetes. That is not the case. We will be tagging 0.4.0 next, > then 0.5.0, then 0.6.0, until we have something reliable that does the job > as suggested by Doug Hellman. For full context read the logs here: > > > > http://eavesdrop.openstack.org/irclogs/%23openstack- > release/%23openstack-release.2016-12-07.log.html#t2016-12-07T20:25:00 > > __ > OpenStack Development Mailing 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 to add zhubingbing to core team
zhubingbing, Congratulations, the vote passed with ( 10 votes, without a veto ). I've added you to the appropriate group in Gerrit. I'll give you some training on the policies for core reviewers. PS: Since Michal is out on vacation recently, I will take the PTL duty for a while. On Fri, Dec 2, 2016 at 11:05 AM, Swapnil Kulkarni <cools...@gmail.com> wrote: > On Tue, Nov 29, 2016 at 9:51 PM, Michał Jastrzębski <inc...@gmail.com> > wrote: > > Hello team! > > > > I'd like to propose to add zhubingbing to kolla (and kolla-ansible) > > core teams. He did great job reviewing code during last couple of > > months. > > > > Consider this proposal +1 from me, voting will be open for 1 week > > (until Dec 6) or if we get unanimous agreement (or veto) before. > > > > 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 > > +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] [Openstack] OpenStack Ocata B1 for Ubuntu 16.04 LTS
Cool. And Kolla has upgrade ubuntu repo to b1 in master branch. btw, if there is any way or help doc for proposing a new package into ubuntu-cloud-archive? like kolla. On Fri, Dec 2, 2016 at 12:53 AM, Corey Bryant <corey.bry...@canonical.com> wrote: > Hi All, > > > The Ubuntu OpenStack team is pleased to announce the general availability > of the OpenStack Ocata B1 milestone in Ubuntu 16.04 LTS via the Ubuntu > Cloud Archive. > > > Ubuntu 16.04 LTS > > > > > You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on > Ubuntu 16.04 installations by running the following commands: > > > echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu > xenial-updates/ocata main" | sudo tee /etc/apt/sources.list.d/ocata- > uca.list > > sudo apt install -y ubuntu-cloud-keyring > > sudo apt update > > > The Ubuntu Cloud Archive for Ocata includes updates for: cinder, glance, > horizon, keystone, manila, networking-ovn, neutron, neutron-fwaas, > neutron-lbaas, neutron-dynamic-routing, nova, openstack-trove, and swift > (2.11.0). > > > You can check out the full list of packages and versions at [0]. > > > Branch Package Builds > > --- > > > If you want to try out the latest updates to stable branches, we are > delivering continuously integrated packages on each upstream commit via the > following PPA’s: > > >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 > >sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata > > > 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/ocata_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] propose to remove COPY_ONCE feature
@sdake we can keep COPY_ONCE and COPY_ALWAY in docker images. But in kolla-ansible side, only implement COPY_ALWAY. And does kolla-k8s will only implement COPY_ONCE? @Gerard COPY_ALWAYS only affect the configuration file, like /etc/nova/nova.conf. others are still immutable. @Paul For the end-user, either COPY_ONCE or COPY_ALWAYS is transparent. When he running kolla-ansible, there is no big difference. On Thu, Dec 1, 2016 at 6:29 PM, Paul Bourke <paul.bou...@oracle.com> wrote: > While I would be interested to know how many people actually do use > COPY_ONCE, I think if I was in charge of a production deployment I would > use COPY_ONCE. > > > On 01/12/16 02:27, Jeffrey Zhang wrote: > >> Kolla has a config_strategy option during deployment. it supports >> COPY_ONCE and >> COPY_ALWAYS. which means whether copy the configuration files defined in >> config.json again during starting containers. >> >> COPY_ALWAYS: copy all configuration files always during every start ( >> default >> value now ) >> COPY_ONCE: copy only once for the first start, then it >>won't copy even the configuration is changed >> >> COPY_ALWAYS is more common for most users. change configuration, then >> restart >> containers and it works. but COPY_ONCE is not. after changing the >> configuration, >> should remove the container and start it again. >> >> for COPY_ONCE, the pro is keeping immutability of the container. the con >> is >> making thing difficult. no matter for kolla code or end-user. >> >> I am curiosity does end-user really care about the immutability cause by >> configuration file? how many user really need such a feature? >> >> So I propose to remove COPY_ONCE. >> >> any idea is welcome ;) >> >> -- >> 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
[openstack-dev] [kolla] propose to remove COPY_ONCE feature
Kolla has a config_strategy option during deployment. it supports COPY_ONCE and COPY_ALWAYS. which means whether copy the configuration files defined in config.json again during starting containers. COPY_ALWAYS: copy all configuration files always during every start ( default value now ) COPY_ONCE: copy only once for the first start, then it won't copy even the configuration is changed COPY_ALWAYS is more common for most users. change configuration, then restart containers and it works. but COPY_ONCE is not. after changing the configuration, should remove the container and start it again. for COPY_ONCE, the pro is keeping immutability of the container. the con is making thing difficult. no matter for kolla code or end-user. I am curiosity does end-user really care about the immutability cause by configuration file? how many user really need such a feature? So I propose to remove COPY_ONCE. any idea is welcome ;) -- 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] migrate from heka to fluentd
Heka is deprecated, and its alternative has been talked many times. Finally, Kolla team reach an agreement on this. kolla-ansible implementation will migrate from Heka to Fluentd. ( kolla-kubernetes is using Fluentd ) Fluentd will be a good choice, which is maturity enough and part of CNCF[1]. it will not be easy to do this migrate. And this cycle is not long enough, too. Anyone who take this, please provide a stake of patch sets and make sure the last one work for all services. Then it will be considered to merge. otherwise, this bp will be moved to Pike cycle. [0] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation [1] https://www.cncf.io/ -- 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
