[dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors

Ian Wienand iwienand at redhat.com
Mon Dec 17 03:16:26 UTC 2018


On Fri, Dec 14, 2018 at 11:32:00PM +0000, Jeremy Stanley wrote:
> On 2018-12-14 17:20:05 -0500 (-0500), Mike Bayer wrote:
> [...]
> > OK, so first step is...identify some zuul jobs?    I have CI for
> > sqlalchemy, alembic, dogpile-cache that each would benefit from db
> > /cache-centric builds.
> 
> I mean, if there's a job which was failing immediately after the
> release in our CI system and we think that's a reasonable
> integration test to perform, we could work out a way to have it
> install dogpile from the master branch source instead of a released
> package.

I would suggest we use the nodepool-functional-py35-src jobs.  These
jobs are failing [1]

These jobs install a devstack environment, then nodepool,
openstacksdk, diskimage-builder and glean from git; then they build an
image with dib, upload it to the devstack cloud and ensure it boots
and communicates.

This means openstacksdk (and hence dogpile) is being used by nodepool
against a real-life cloud doing very real-life things like creating
servers, listing them and connecting all the various bits up.

Connecting to dogpile's gerrit as 3rd party CI is possible.  But I'd
suggest we KISS to start with.  As mentioned above, cloning from
github master during the job is a good place to start, as I'm not sure
at this point if devstack correctly handles installing non-openstack
dependencies from Zuul checkouts during test runs.

Reviews:

 https://review.openstack.org/625467 Add github dogpile.cache to project list
 https://review.openstack.org/625457 [wip] Add dogpile.cache master to the -src tests

-i

[1] http://logs.openstack.org/55/624855/3/check/nodepool-functional-py35-src/c63c515/controller/logs/screen-nodepool-builder.txt.gz#_Dec_13_14_46_10_332628



More information about the openstack-discuss mailing list