[openstack-dev] [kolla]is it OK to modify python code in OpenStack project?

[Jeffrey Zhang]

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

[openstack-dev] [nimble] Project name collision

[Zhenguo Niu]

hi all,

Unfortunately, 'Nimble' is used by a company, We should rename the project
to avoid name collision.

There are already some names proposed, we will vote to choose a new name in
the next IRC team meeting this week, Dec 29.

Looking forward for new name proposals :)

Thanks!

-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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)

[Jeffrey Zhang]

​another issue we(kolla gate) meet is libvirtd got segment fault.
Here is the log from host messages file. But i do not get other issue in
nova.conf expect can not connect libvirt.

Dec 25 13:40:54 localhost kernel: libvirtd[5720]: segfault at 8 ip
7fa70379b823 sp 7fa6faa061c0 error 4 in libvirt.so.0.2000.0[
7fa703648000+353000]​

On Fri, Dec 23, 2016 at 10:00 PM, Neil Jerram  wrote:

> On Fri, Dec 23, 2016 at 1:37 PM Steve Gordon  wrote:
>
>> - Original Message -
>> > From: "Neil Jerram" 
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> >
>> > I appreciate that even libvirt 2.0.0 will be ancient history by now, to
>> its
>> > developers, but I am seeing further issues that look associated with the
>> > recent CentOS 7 transition from libvirt 1.2.7 to libvirt 2.0.0, and
>> would
>> > appreciate any comments on them that people may have.  I believe these
>> > issues are independent of those that have already been discussed on
>> other
>> > threads.
>> >
>> > First, this traceback in nova-compute.log:
>> >
>> > Traceback (most recent call last):
>> >   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> > 2156, in _build_resources
>> > yield resources
>> >   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> > 2009, in _build_and_run_instance
>> > block_device_info=block_device_info)
>> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 2534, in spawn
>> > block_device_info=block_device_info)
>> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 4620, in _create_domain_and_network
>> > xml, pause=pause, power_on=power_on)
>> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> line
>> > 4550, in _create_domain
>> > guest.launch(pause=pause)
>> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
>> line
>> > 142, in launch
>> > self._encoded_xml, errors='ignore')
>> >   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
>> 195,
>> > in __exit__
>> > six.reraise(self.type_, self.value, self.tb)
>> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
>> line
>> > 137, in launch
>> > return self._domain.createWithFlags(flags)
>> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186,
>> in
>> > doit
>> > result = proxy_call(self._autowrap, f, *args, **kwargs)
>> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144,
>> in
>> > proxy_call
>> > rv = execute(f, *args, **kwargs)
>> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125,
>> in
>> > execute
>> > six.reraise(c, e, tb)
>> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83,
>> in
>> > tworker
>> > rv = meth(*args, **kwargs)
>> >   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1065, in
>> > createWithFlags
>> > if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
>> failed',
>> > dom=self)
>> > libvirtError: Cannot find '' in path: No such file or directory
>> >
>> > which I believe is caused by the empty path attribute in this part of
>> the
>> > XML:
>> >
>> > 
>> >   
>> >   
>> >   
>> >   
>> >   
>> >   > > function='0x0'/>
>> > 
>> >
>> > which is in turn caused, I think, by
>> > https://github.com/openstack/nova/blob/master/nova/virt/
>> libvirt/designer.py#L61
>> >
>> > Is it plausible that libvirt 1.2.7 would have avoided trying to invoke a
>> > script with an empty path, whereas libvirt 2.0.0 does not?
>>
>> It seems someone filed this as https://bugs.launchpad.net/
>> nova/+bug/1649527 from a Nova POV. The Libvirt folks helped me narrow
>> this down to this commit being the first one that would have exhibited this
>> behavior:
>>
>> https://libvirt.org/git/?p=libvirt.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 

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[GHANSHYAM MANN]

Thanks Brian for bringing this up, same we been discussing last week on QA
channel and this patch[1] but I completely agree with Matthew opinion here.
There is no doubt that this change(4-valued) are much better and clear than
old one. This makes much defined and clear way of defining the image
visibility by/for operator/user.

Upgrade procedure defined in all referenced ML/spec looks fine for
redefining the visibility for images with or without members to
shared/private. Operator feedback/acceptance for this change makes it
acceptable.

But operator/users creating images with visibility as "private"
*explicitly*, this changes is going to break them:

- Images with member already added in that would not works
as Tempest tests does [2].

- They cannot add member as they used to do that.

First one is being something tested by Tempest and which is valid tests as
per current behaviour of API

There might be lot of operators will be doing the same and going to be
broken after this. We really need to think about this change as API
backward incompatible pov where upgrade Cloud with new visibility
definition is all ok but it break the way of usage(Image of Private
visibility explicitly with added members).

After looking into glance API versioning mechanism, it seems /v2 points to
latest version irrespective of version includes backward compatible or
incompatible changes. I mean users cannot lock API on old version (say they
want only v2.2). How glance introduced backward incompatible changes?

I am not sure why it is not done like api-wg suggested microversion way
(like nova). I know glance API versioning is much older but when there are
some better improvement coming like this community image change, I feel it
should be done with backward compatible way in microversion.

Tempest testing the old behaviour is something very valid here and we
should not change that to introduced backward incompatible changes which
going to break cloud.

.. [1] https://review.openstack.org/#/c/412731/

.. [2]
https://github.com/openstack/tempest/blob/master/tempest/api/image/v2/test_images.py#L339

​-gmann

On Fri, Dec 23, 2016 at 5:51 AM, Matthew Treinish 
wrote:

> On Thu, Dec 22, 2016 at 02:57:20PM -0500, Brian Rosmaita wrote:
> > Something has come up with a tempest test for Glance and the community
> > images implementation, and I think it could use some mailing list
> > discussion, as everyone might not be aware of the patch where the
> > discussion is happening now [1].
> >
> > First, the Glance background, to get everyone on the same page:
> >
> > As part of implementing community images [2], the 'visibility' field of
> > an image is going from being 2-valued to being 4-valued.  Up to now, the
> > only values have been 'private' and 'public', which meant that shared
> > images were 'private', which was inaccurate and confusing (and bugs were
> > filed with Glance about shared images not having visibility 'shared'
> > [3a,b]).
> >
> > With the new visibility enum, the Images API v2 will behave as follows:
> >
> > * An image with visibility == 'private' is not shared, and is not
> > shareable until its visibility is changed to 'shared'.
> >
> > * An image must have visibility == 'shared' in order to do member
> > operations or be accessible to image members.
> >
> > * The default visibility of a freshly-created image is 'shared'.  This
> > may seem weird, but a freshly-created image has no members, so it's
> > effectively private, behaving exactly as a freshly-created image does,
> > pre-Ocata.  It's also ready to immediately accept a member-create call,
> > as freshly-created images are pre-Ocata.  So from a workflow
> > perspective, this change is backward compatible.
> >
> > * After much discussion [4], including discussion with operators and an
> > operator's survey [5], we decided that the correct migration of
> > 'visibility' values for existing images when a cloud is updated would
> > be: public images stay 'public', private images with members become
> > 'shared', and private images without images stay 'private'.  (Thus, if
> > you have a 'private' image, you'll have to change it to 'shared' before
> > you can add members.  On the other hand, now it's *really* private.)
> >
> > * You can specify a visibility at the time of image-creation, as you can
> > now.  But if you specify 'private', what you get is *really* private.
> > This either introduces a minor backward incompatibility, or it fixes a
> > bug, depending on how you look at it.  The key thing is, if you *don't*
> > specify a visibility, an image with the default visibility will behave
> > exactly as it does now, from the perspective of being able to make API
> > calls on it (e.g., adding members).
> >
> > Thanks for reading this far.  (There's a much more detailed discussion
> > in the spec; see the "Other end user impact" section. [2])  Here's the
> > point of this email:
> >
> > The community images