On Fri, Feb 20, 2015, at 11:24 AM, Philipp Marek wrote:
> Hi all,
> this is a reflection of the discussion I just had on #openstack-infra;
> it's 
> about (re-)using the central CI infrastructure for our Open-Source DRBD 
> driver too.
> The current status is:
>  * The DRBD driver is already in Cinder, so DRBD-replicated Cinder
>  storage
>    using iSCSI to the hypervisors does work out-of-the-box.
>  * The Nova-parts didn't make it in for Kilo; we'll try to get them into
>  L.
>  * I've got a lib/backends/drbd for devstack, that together with a
>  matching 
>    local.conf can set up a node - at least for a limited set of 
>    distributions (as DRBD needs a kernel module, Ubuntu/Debian via DKMS
>    are 
>    the easy way).
>    [Please note that package installation is not yet done in this script 
>    yet - I'm not sure whether I can/may/should simply add an 
>    apt-repository.]
> Now, clarkb told me about two caveats:
>   «Yup, so the two things I will start with is that multinode testing is 
>    still really rudimentary, we only just got tempest sort of working
>    with 
>    it. So I might suggest running on a single node first to get the
>    general 
>    thing working.
You can follow the current state of multinode work at
>    The other thing is that we don't have the zuul code to vote with 
>    a different account deployed/merged yet. So initially you could run
>    your 
>    job but it wouldn't vote against, say, cinder.»
The stack that adds the necessary zuul stuff ends with
> Cinder has a deadline for CI: March 19th; upon relaying that fact (resp. 
> nearly correct date) clarkb said
>   «thats about 3 weeks... probably at least for the zuul thing.»
> So, actually it's nearly 4 weeks, let's hope that it all works out.
> Actually, the multi-node testing will only be needed when we get the Nova 
> parts in, because then it would make sense to test (Nova) via both iSCSI 
> and the DRBD transport; for Cinder CI a single-node setup is sufficient.
> My remaining questions are:
>  * Is it possible to have our driver tested via the common
>  infrastructure?
I think it should be, initially just reporting against your devstack
plugin while things get sorted out then once zuul has the appropriate
bits reporting like a third party test account but running upstream.
>  * Is it okay to setup another apt-repository during the devstack run,
>    to install the needed packages? I'm not sure whether our servers
>    would simply be accessible, some firewall or filtering proxy could
>    break such things easily.
It is not ok in a gating job to do that but that isn't your intention so
should be fine. That said, isn't drbd available in existing apt/yum
repos? What special sauce do you need to pull in?
>  * Apart from the cinder-backend script in devstack (which I'll have to 
>    finish first, see eg. package installation), is any other information 
>    needed from us?
Other than following this thread and writing that devstack plugin
probably not.
Hope this helps,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to