date:20180517

[openstack-dev] [devstack][python/pip][octavia] pip failure during octavia/ocata image build by devstack

2018-05-17 Thread rezroo

Hello - I'm trying to install a working local.conf devstack ocata on a 
new server, and some python packages have changed so I end up with this 
error during the build of octavia image:


   2018-05-18 01:00:26.276 |   Found existing installation: Jinja2 2.8
   2018-05-18 01:00:26.280 | Uninstalling Jinja2-2.8:
   2018-05-18 01:00:26.280 |   Successfully uninstalled Jinja2-2.8
   2018-05-18 01:00:26.839 |   Found existing installation: PyYAML 3.11
   2018-05-18 01:00:26.969 | Cannot uninstall 'PyYAML'. It is a
   distutils installed project and thus we cannot accurately determine
   which files belong to it which would lead to only a partial uninstall.

   2018-05-18 02:05:44.768 | Unmount
   /tmp/dib_build.2fbBBePD/mnt/var/cache/apt/archives
   2018-05-18 02:05:44.796 | Unmount /tmp/dib_build.2fbBBePD/mnt/tmp/pip
   2018-05-18 02:05:44.820 | Unmount
   /tmp/dib_build.2fbBBePD/mnt/tmp/in_target.d
   2018-05-18 02:05:44.844 | Unmount /tmp/dib_build.2fbBBePD/mnt/tmp/ccache
   2018-05-18 02:05:44.868 | Unmount /tmp/dib_build.2fbBBePD/mnt/sys
   2018-05-18 02:05:44.896 | Unmount /tmp/dib_build.2fbBBePD/mnt/proc
   2018-05-18 02:05:44.920 | Unmount /tmp/dib_build.2fbBBePD/mnt/dev/pts
   2018-05-18 02:05:44.947 | Unmount /tmp/dib_build.2fbBBePD/mnt/dev
   2018-05-18 02:05:50.668 |
   +/opt/stack/octavia/devstack/plugin.sh:build_octavia_worker_image:1
   exit_trap
   2018-05-18 02:05:50.679 | +./devstack/stack.sh:exit_trap:494
   local r=1
   2018-05-18 02:05:50.690 |
   ++./devstack/stack.sh:exit_trap:495 jobs -p
   2018-05-18 02:05:50.700 | +./devstack/stack.sh:exit_trap:495
   jobs=
   2018-05-18 02:05:50.710 | +./devstack/stack.sh:exit_trap:498
   [[ -n '' ]]
   2018-05-18 02:05:50.720 | +./devstack/stack.sh:exit_trap:504
   kill_spinner
   2018-05-18 02:05:50.731 | +./devstack/stack.sh:kill_spinner:390 
   '[' '!' -z '' ']'
   2018-05-18 02:05:50.741 | +./devstack/stack.sh:exit_trap:506
   [[ 1 -ne 0 ]]
   2018-05-18 02:05:50.751 | +./devstack/stack.sh:exit_trap:507
   echo 'Error on exit'
   2018-05-18 02:05:50.751 | Error on exit
   2018-05-18 02:05:50.761 | +./devstack/stack.sh:exit_trap:508
   generate-subunit 1526608058 1092 fail
   2018-05-18 02:05:51.148 | +./devstack/stack.sh:exit_trap:509
   [[ -z /tmp ]]
   2018-05-18 02:05:51.157 | +./devstack/stack.sh:exit_trap:512
   /home/stack/devstack/tools/worlddump.py -d /tmp

I've tried pip uninstalling PyYAML and pip installing it before running 
stack.sh, but the error comes back.


   $ sudo pip uninstall PyYAML
   The directory '/home/stack/.cache/pip/http' or its parent directory
   is not owned by the current user and the cache has been disabled.
   Please check the permissions and owner of that directory. If
   executing pip with sudo, you may want sudo's -H flag.
   Uninstalling PyYAML-3.12:
   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/INSTALLER
   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/METADATA
   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/RECORD
   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/WHEEL
   /usr/local/lib/python2.7/dist-packages/PyYAML-3.12.dist-info/top_level.txt
  /usr/local/lib/python2.7/dist-packages/_yaml.so
   Proceed (y/n)? y
  Successfully uninstalled PyYAML-3.12

I've posted my question to the pip folks and they think it's an 
openstack issue: https://github.com/pypa/pip/issues/4805


Is there a workaround here?


__
OpenStack Development Mailing 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] [tc] [all] TC Report 18-20

2018-05-17 Thread Rochelle Grober


Thierry Carrez [mailto:thie...@openstack.org]
> 
> Graham Hayes wrote:
> > Any additional background on why we allowed LCOO to operate like this
> > would help a lot.
> 
The group was started back when OPNFV was first getting involved with 
OpenStack.  Many of the members came from that community.  They had a "vision" 
that the members would have to commit to provide developers to address the 
feature gaps the group was concerned with.  There was some interaction between 
them and the Product WG, and I at least attempted to get them to meet and talk 
with the Large Deployment Team(?) (an ops group that met at the Ops midcycles 
and discussed their issues, workarounds, gaps, etc.)

Are they still active?  Is anyone aware of any docs/code/bugfixes/features that 
came out of the group?

--Rocky

> We can't prevent any group of organizations to work in any way they prefer -
> - we can, however, deny them the right to be called an OpenStack
> workgroup if they fail at openly collaborating. We can raise the topic, but in
> the end it is a User Committee decision though, since the LCOO is a User
> Committee-blessed working group.
> 
> Source: https://governance.openstack.org/uc/
> 
> --
> Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] [Forum] [all] [Stable] OpenStack is "mature" -- time to get serious on Maintainers -- Session etherpad and food for thought for discussion

2018-05-17 Thread Rochelle Grober

Folks,

TL;DR
The last session related to extended releases is: OpenStack is "mature" -- time
to get serious on Maintainers
It will be in room 220 at 11:00-11:40
The etherpad for the last session in the series on Extended releases is here:
https://etherpad.openstack.org/p/YVR-openstack-maintainers-maint-pt3

There are links to info on other communities’ maintainer
process/role/responsibilities also, as reference material on how other have
made it work (or not).

The nitty gritty details:

The upcoming Forum is filled with sessions that are focused on issues needed to
improve and maintain the sustainability of OpenStack projects for the long
term. We have discussion on reducing technical debt, extended releases, fast
forward installs, bringing Ops and User communities closer together, etc. The
community is showing it is now invested in activities that are often part of
“Sustaining Engineering” teams (corporate speak) or “Maintainers (OSS speak).
We are doing this; we are thinking about the moving parts to do this; let’s
think about the contributors who want to do these and bring some clarity to
their roles and the processes they need to be successful. I am hoping you read
this and keep these ideas in mind as you participate in the various Forum
sessions. Then you can bring the ideas generated during all these discussions
to the Maintainers session near the end of the Summit to brainstorm how to
visualize and define this new(ish) component of our technical community.

So, who has been doing the maintenance work so far? Mostly (mostly) unsung
heroes like the Stable Release team, Release team, Oslo team, project liaisons
and the community goals champions (yes, moving to py3 is a
sustaining/maintenance type of activity). And some operators (Hi, mnaser!).
We need to lean on their experience and what we think the community will need
to reduce that technical debt to outline what the common tasks of maintainers
should be, what else might fall in their purview, and how to partner with them
to better serve them.

With API lower limits, new tool versions, placement, py3, and even projects
reaching “code complete” or “maintenance mode,” there is a lot of work for
maintainers to do (I really don’t like that term, but is there one that fits
OpenStack’s community?). It would be great if we could find a way to share the
load such that we can have part time contributors here. We know that operators
know how to cherrypick, test in there clouds, do bug fixes. How do we pair
with them to get fixes upstreamed without requiring them to be full on
developers? We have a bunch of alumni who have stopped being “cores” and
sometimes even developers, but who love our community and might be willing and
able to put in a few hours a week, maybe reviewing small patches, providing
help with user/ops submitted patch requests, or whatever. They were trusted
with +2 and +W in the past, so we should at least be able to trust they know
what they know. We would need some way to identify them to Cores, since they
would be sort of 1.5 on the voting scale, but……

So, burn out is high in other communities for maintainers. We need to find a
way to make sustaining the stable parts of OpenStack sustainable.

Hope you can make the talk, or add to the etherpad, or both. The etherpad is
very musch still a work in progress (trying to organize it to make sense). If
you want to jump in now, go for it, otherwise it should be in reasonable shape
for use at the session. I hope we get a good mix of community and a good
collection of those who are already doing the job without title.

Thanks and see you next week.
--rocky

华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
Rochelle Grober
Sr. Staff Architect, Open Source
Office Phone:408-330-5472
Email:rochelle.gro...@huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI,
which
is intended only for the person or entity whose address is listed above. Any
use of the
information contained herein in any way (including, but not limited to, total
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender by
phone or email immediately and delete it!

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

40 matches

Mail list logo