On Tue, 2014-05-27 at 17:42 -0700, Joe Gordon wrote:
> On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham <[email protected]> > 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
