Re: [Wg-openstack] Meeting Minutes 2015-12-16

[Bob Ball <bob.ball@xxxxxxxxxx>]

And - guess what - this has broken the CI again on Friday but I only just found 
out :)

Seems that a new python novaclient was released on Friday, which deprecates 
novaclient v1_1 but pyrax (which does the uploading to swift) only uses 
novaclient v1_1.

Have disabled the CI for now.  Not sure what the solution is, but I currently 
suspect it's likely to need either some significant work in our CI to remove 
the pyrax dependency, or for Rackspace to fix pyrax. Have raised an issue 
(https://github.com/rackspace/pyrax/issues/593)

Thanks,

Bob

> -----Original Message-----
> From: wg-openstack-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:wg-openstack-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Bob Ball
> Sent: 17 December 2015 14:41
> To: Stefano Stabellini; wg-openstack@xxxxxxxxxxxxxxxxxxxx; Stefano
> Stabellini; Lars Kurth
> Subject: Re: [Wg-openstack] Meeting Minutes 2015-12-16
> 
> Regarding the CI failure below, I wanted to share some links to further
> explain the issue.
> 
> > During the last few months we had a few CI-loop failures, some of them
> > are due to broken upstream, but a couple of them are due to the Xen
> > Project CI-loop being unable to upload logs.
> 
> When we run jobs, they include a custom 'builder' which is executed at the
> end of the job [1].  This builder creates an environment, and then installs a
> package 'osci' which has the swift upload capability built in.
> 
> > Possible fix: install scripts at image creation time?
> 
> The simplest fix may be to move this code to the
> prepare_node_devstack_xen script[2].  This script is run after devstack is
> prepared and therefore I think a failure here would probably cause the
> image to fail (which is good, since we would just use the image created the
> previous day)
> 
> > Install packages depending on the original install time version rather
> > than the last?
> 
> I believe this might be tricky unless we get a list of the 'latest version' of
> packages and generate a requirements.txt file with fixed versions in,
> depending on the versions available at the time the node was created
> 
> > There might be other ways to fix this.
> 
> The other proposal (and the 'right way') is to use zuul-swift-upload[3] but to
> extend this and swift's middleware to allow setting of both content-type
> and critically the content encoding in a similar way to the existing OSCI
> upload[4].  Adding support for the HTML would be a very nice addition as it
> does make the log files look more user friendly.
> 
> > ACTION: Anybody could help on this?
> 
> [1] https://github.com/citrix-openstack/os-ext-
> testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_j
> ob_builder/config/macros.yaml.erb#L231
> [2] https://github.com/citrix-openstack/os-ext-
> testing/blob/master/nodepool-scripts/prepare_node_devstack_xen.sh
> [3] https://github.com/citrix-openstack/os-ext-
> testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_j
> ob_builder/config/macros.yaml.erb#L143
> [4] https://github.com/citrix-openstack/openstack-citrix-
> ci/blob/master/osci/swift_upload.py#L24
> 
> _______________________________________________
> Wg-openstack mailing list
> Wg-openstack@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-openstack

_______________________________________________
Wg-openstack mailing list
Wg-openstack@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-openstack