Open Stack

On Tue, 2014-05-27 at 17:42 -0700, Joe Gordon wrote:


> On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham <graham.hayes at hp.com>
> wrote:
> 
> * You mention nova's dns capabilities as not being adequate one of the
> incubation requirements is:

>   Project should not inadvertently duplicate functionality present in other
>   OpenStack projects. If they do, they should have a clear plan and timeframe
>   to prevent long-term scope duplication

>     So what is the plan for this?

Our current belief is that the DNS functionality in nova sees little to
no use, with replacement functionality (Designate) incubated, I would
personally like to see it deprecated and removed.

Additionally, as the functionality is driver based, we can likely
implement a driver that forwards requests to Designate during the
deprecation period.

> * Can you expand on why this doesn't make sense in neutron when things
> like LBaaS do.

LBaaS (and VPNaaS, FWaaS etc) certainly feel like a good fit inside
Neutron. Their core functionality revolves around "physically"
transporting or otherwise inspecting bits moving from one place to
another and their primary interfaces are Neutron ports, leading to a
desire for tight integration.

Designate, and authoritative DNS in general, is closer to a phone book.
We have no involvement in the transportation of bits, and behave much
closer to a specialized database than any traditional networking gear.

> * Your application doesn't cover all the items raised in the
> incubation requirements list. For example the QA requirement of
> Project must have a basic devstack-gate job set up which as far as I
> can tell isn't really there, although there appears to be a devstack
> based job run as third party which in at least once case didn't run on
> a merged patch (https://review.openstack.org/#/c/91115/)
> 
The application is based on the request template, which for better or
worse doesn't map directly to the the governance document :)

If there are other requirements beyond the devstack-gate one you
mentioned, please ask and we'll respond as best we can!

You're correct that we do not yet have a DevStack gate running directly
in the CI system, and that we do have a 3rd party Jenkins running
DevStack with Designate and some basic functional tests against our
repositories.

The 3rd party jobs were originally set up before DevStack supported
plugins (or at least, before we knew it did!), and were based on a fork
of DevStack which made using the official CI system difficult.

After DevStack gained plugin support, we converted our fork to a plugin,
and looked into getting the official CI system to run DevStack jobs with
our DevStack plugin. This again proved difficult, so the status quo was
left in place. We're looking forward to being able to merge our plugin
into DevStack so we can shutdown the 3rd party tests :)

Re the DevStack jobs not running on a merged patch, after the recent
Gerrit updates, the devstack job was failing for period of time due to
the change in how gerrit accepts reviews from 3rd party systems. This
was fixed recently, and all patches are again running through these
jobs.

Please keep the questions coming :)

Thanks,
Kiall