Re: [openstack-dev] Designate Incubation Request (Approved)
On Sat, 2014-05-24 at 17:24 +, Hayes, Graham wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham With the +2/+A on [1] - Designate is now officially incubated :) Thanks to everyone for the support, especially everyone who has joined the project over the last year or so! Thanks, Kiall [1]: https://review.openstack.org/#/c/97609/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Several of the TC requested we have an openstack-infra managed DevStack gate enabled before they would cast their vote - I'm happy to say, we've got it :) With the merge of [1], Designate now has voting devstack / requirements / docs jobs. An example of the DevStack run is at [2]. Vote Designate @ [3] :) Thanks, Kiall [1]: https://review.openstack.org/#/c/98439/ [2]: https://review.openstack.org/#/c/98442/ [3]: https://review.openstack.org/#/c/97609/ On Sat, 2014-05-24 at 17:24 +, Hayes, Graham wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Zane Bitter wrote:
I think the problem is that we still have elements of the 'project'
terminology around from the bad old days of the pointless
core/core-but-don't-call-it-core/library/gating/supporting project
taxonomy, where project == repository. The result is that every time a
new project gets incubated, the reaction is always Oh man, you want a
new *program* too? That sounds really *heavyweight*. If people treated
the terms 'program' and 'project' as interchangeable and just referred
to repositories by another name ('repositories', perhaps?) then this
wouldn't keep coming up.
(IMHO the quickest way to effect this change in mindset would be to drop
the term 'program' and call the programs projects. In what meaningful
sense is e.g. Infra or Docs not a project?)
You're right that the confusion now comes from project terminology. We
replaced old projects by having granular code repositories on one
side and grouping them in programs. The issue is, we still use
project (generally to mean code repository now, but in some cases to
mean program). Personally I more and more use code repo instead of
project to avoid the confusion.
That said I disagree that we should just deprecate the term program
and use project for designating the grouping instead... I think that
would create more confusion that it solves. History in OpenStack proved
that when we reuse terms (core anyone ?) we end up with mess that
can't be easily untangled. I'd rather deprecate the use of the project
term now in favor of the new terminology. When I still use project
those days it is generally to say the OpenStack project.
In summary:
- The OpenStack project
- The Compute (Nova) program
- The openstack/nova git code repository
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little trees that orbit it (client and now specs repos). If we always expect that to be the case, I'm not really sure why we built this intermediate grouping. Programs were established to solve two problems. First one is the confusion around project types. We used to have project types[1] that were trying to reflect and include all code repositories that we wanted to make official. That kept on changing, was very confusing, and did not allow flexibility for each team in how they preferred to organize their code repositories. The second problem that solved was to recognize non-integrated-project efforts which were still essential to the production of OpenStack, like Infra or Docs. [1] https://wiki.openstack.org/wiki/ProjectTypes Programs just let us bless goals and teams and let them organize code however they want, with contribution to any code repo under that umbrella being considered official and ATC-status-granting. I would be a bit reluctant to come back to the projecttypes mess and create categories of programs (integrated projects on one side, and others). Back to the topic, the tension here is because DNS is seen as a network thing and therefore it sounds like it makes sense under Networking. But programs are not categories or themes. They are teams aligned on a mission statement. If the teams are different (Neutron and Designate) then it doesn't make sense to artificially merge them just because you think of networking as a theme. If the teams converge, yes it makes sense. If they don't, we should just create a new program. They are cheap and should reflect how we work, not the other way around. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On 05/29/2014 05:26 AM, Thierry Carrez wrote: Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little trees that orbit it (client and now specs repos). If we always expect that to be the case, I'm not really sure why we built this intermediate grouping. Programs were established to solve two problems. First one is the confusion around project types. We used to have project types[1] that were trying to reflect and include all code repositories that we wanted to make official. That kept on changing, was very confusing, and did not allow flexibility for each team in how they preferred to organize their code repositories. The second problem that solved was to recognize non-integrated-project efforts which were still essential to the production of OpenStack, like Infra or Docs. [1] https://wiki.openstack.org/wiki/ProjectTypes Programs just let us bless goals and teams and let them organize code however they want, with contribution to any code repo under that umbrella being considered official and ATC-status-granting. I would be a bit reluctant to come back to the projecttypes mess and create categories of programs (integrated projects on one side, and others). Back to the topic, the tension here is because DNS is seen as a network thing and therefore it sounds like it makes sense under Networking. But programs are not categories or themes. They are teams aligned on a mission statement. If the teams are different (Neutron and Designate) then it doesn't make sense to artificially merge them just because you think of networking as a theme. If the teams converge, yes it makes sense. If they don't, we should just create a new program. They are cheap and should reflect how we work, not the other way around. Ok, that's fare. My confusion might stem from the fact that in nova, novaclient really is being done by largely distinct subset of folks, and tends to have minimal overlap with nova itself. That might just be the size of the effort, and also will hopefully be addressed by the unified SDK/client getting off the ground. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Thu, 2014-05-29 at 11:26 +0200, Thierry Carrez wrote: Back to the topic, the tension here is because DNS is seen as a network thing and therefore it sounds like it makes sense under Networking. But programs are not categories or themes. They are teams aligned on a mission statement. If the teams are different (Neutron and Designate) then it doesn't make sense to artificially merge them just because you think of networking as a theme. If the teams converge, yes it makes sense. If they don't, we should just create a new program. They are cheap and should reflect how we work, not the other way around. +1 This is exactly how I feel about programs, and couldn't have said it better myself :) Thanks Thierry! Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Thu, 2014-05-29 at 08:00 +0930, Michael Davies wrote: On Thu, May 29, 2014 at 4:22 AM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. I also agree here - DNS isn't a program by itself in my opinion, it should be in a group of other Network Application Services. I disagree - but Thierry put it better than I could have ever said at [1], so I'll just refer to his email :) Thanks, Kiall [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-May/036213.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On 29/05/14 05:26, Thierry Carrez wrote:
Sean Dague wrote:
I honestly just think we might want to also use it as a time to rethink
our program concept. Because all our programs that include projects that
are part of the integrated release are 1 big source tree, and maybe a
couple of little trees that orbit it (client and now specs repos). If we
always expect that to be the case, I'm not really sure why we built this
intermediate grouping.
Programs were established to solve two problems. First one is the
confusion around project types. We used to have project types[1] that
were trying to reflect and include all code repositories that we wanted
to make official. That kept on changing, was very confusing, and did
not allow flexibility for each team in how they preferred to organize
their code repositories. The second problem that solved was to recognize
non-integrated-project efforts which were still essential to the
production of OpenStack, like Infra or Docs.
[1] https://wiki.openstack.org/wiki/ProjectTypes
Programs just let us bless goals and teams and let them organize code
however they want, with contribution to any code repo under that
umbrella being considered official and ATC-status-granting.
This is definitely how it *should* work.
I think the problem is that we still have elements of the 'project'
terminology around from the bad old days of the pointless
core/core-but-don't-call-it-core/library/gating/supporting project
taxonomy, where project == repository. The result is that every time a
new project gets incubated, the reaction is always Oh man, you want a
new *program* too? That sounds really *heavyweight*. If people treated
the terms 'program' and 'project' as interchangeable and just referred
to repositories by another name ('repositories', perhaps?) then this
wouldn't keep coming up.
(IMHO the quickest way to effect this change in mindset would be to drop
the term 'program' and call the programs projects. In what meaningful
sense is e.g. Infra or Docs not a project?)
I would be
a bit reluctant to come back to the projecttypes mess and create
categories of programs (integrated projects on one side, and others).
I agree, but why do we need different categories? Is anybody at all
confused about this? Are there people out there installing our custom
version of Gerrit and wondering why it won't boot VMs?
The categories existed largely because of the aforementioned strange
definition of 'project' and the need to tightly control the membership
of the TC. Now that the latter is no longer an issue, we could eliminate
the distinction between programs and projects without bringing the
categories back.
Back to the topic, the tension here is because DNS is seen as a
network thing and therefore it sounds like it makes sense under
Networking. But programs are not categories or themes. They are
teams aligned on a mission statement. If the teams are different
(Neutron and Designate) then it doesn't make sense to artificially merge
them just because you think of networking as a theme. If the teams
converge, yes it makes sense. If they don't, we should just create a new
program. They are cheap and should reflect how we work, not the other
way around.
+1
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Tue, 2014-05-27 at 17:42 -0700, Joe Gordon wrote: On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Does this make sense in Neutron? In my opinion it doesn't. DNSaaS is external to Neutron and is independent. It serves DNS requests that can come from the internet just as well as they can come from VMs in the cloud (but through the network external to the cloud). It can serve IPs for cloud resources just as well as it can serve IPs for resources outside the cloud. The services are separated by the external network (from Neutron's perspective). Neutron only provides very limited DNS functionality which forwards DNS queries to an external resolver to facilitate the ability for VMs to lookup DNS. It injects names and IPs for VMs on the same network but currently this needs some work with Neutron. I don't think it makes sense for Neutron to provide an external facing DNS service. Neutron is about moving network traffic within a cloud and between the cloud and external networks. My $0.02. Carl On Tue, May 27, 2014 at 6:42 PM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@hp.com wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application Based on http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst I have a few questions: * 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? * Can you expand on why this doesn't make sense in neutron when things like LBaaS do. * 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/) As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. -Sean On 05/28/2014 02:21 PM, Carl Baldwin wrote: Does this make sense in Neutron? In my opinion it doesn't. DNSaaS is external to Neutron and is independent. It serves DNS requests that can come from the internet just as well as they can come from VMs in the cloud (but through the network external to the cloud). It can serve IPs for cloud resources just as well as it can serve IPs for resources outside the cloud. The services are separated by the external network (from Neutron's perspective). Neutron only provides very limited DNS functionality which forwards DNS queries to an external resolver to facilitate the ability for VMs to lookup DNS. It injects names and IPs for VMs on the same network but currently this needs some work with Neutron. I don't think it makes sense for Neutron to provide an external facing DNS service. Neutron is about moving network traffic within a cloud and between the cloud and external networks. My $0.02. Carl On Tue, May 27, 2014 at 6:42 PM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@hp.com wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application Based on http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst I have a few questions: * 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? * Can you expand on why this doesn't make sense in neutron when things like LBaaS do. * 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/) As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On 28/05/14 14:52, Sean Dague wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. I agree, the whole program/project thing is confusing (as we've discovered this week, programs actually have code names which are... identical to the name of a project in the program) and IMHO unnecessary. Programs share a common core team, so it is inevitable that most incubated projects (including, I would think, Designate) will make sense in a separate program. (TripleO incorporating Tuskar is the only counterexample I can think of.) Let's just get rid of the 'project' terminology. Let programs organise whatever repos they have in whatever way they see fit, with the proviso that they consult with the TC on any change in scope. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Wed, May 28, 2014 at 1:52 PM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. +1 I think this is an example of something which makes sense in the Network program. We've already discussed having the Service VM project incubate in the Network program initially as well, and once LBaaS spins out in the future, it will land in the Network program as well. Thanks, Kyle -Sean On 05/28/2014 02:21 PM, Carl Baldwin wrote: Does this make sense in Neutron? In my opinion it doesn't. DNSaaS is external to Neutron and is independent. It serves DNS requests that can come from the internet just as well as they can come from VMs in the cloud (but through the network external to the cloud). It can serve IPs for cloud resources just as well as it can serve IPs for resources outside the cloud. The services are separated by the external network (from Neutron's perspective). Neutron only provides very limited DNS functionality which forwards DNS queries to an external resolver to facilitate the ability for VMs to lookup DNS. It injects names and IPs for VMs on the same network but currently this needs some work with Neutron. I don't think it makes sense for Neutron to provide an external facing DNS service. Neutron is about moving network traffic within a cloud and between the cloud and external networks. My $0.02. Carl On Tue, May 27, 2014 at 6:42 PM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@hp.com wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application Based on http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst I have a few questions: * 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? * Can you expand on why this doesn't make sense in neutron when things like LBaaS do. * 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/) As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
+1 This makes sense except that I'm not sure what the Network Program is. Is there already such a thing formally? Carl On Wed, May 28, 2014 at 12:52 PM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. -Sean On 05/28/2014 02:21 PM, Carl Baldwin wrote: Does this make sense in Neutron? In my opinion it doesn't. DNSaaS is external to Neutron and is independent. It serves DNS requests that can come from the internet just as well as they can come from VMs in the cloud (but through the network external to the cloud). It can serve IPs for cloud resources just as well as it can serve IPs for resources outside the cloud. The services are separated by the external network (from Neutron's perspective). Neutron only provides very limited DNS functionality which forwards DNS queries to an external resolver to facilitate the ability for VMs to lookup DNS. It injects names and IPs for VMs on the same network but currently this needs some work with Neutron. I don't think it makes sense for Neutron to provide an external facing DNS service. Neutron is about moving network traffic within a cloud and between the cloud and external networks. My $0.02. Carl On Tue, May 27, 2014 at 6:42 PM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@hp.com wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application Based on http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst I have a few questions: * 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? * Can you expand on why this doesn't make sense in neutron when things like LBaaS do. * 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/) As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
smime.p7m Description: S/MIME encrypted message ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Sorry - not sure what happened there - as I was saying: The Networking Program is Neutron. https://wiki.openstack.org/wiki/Programs Graham On 28/05/2014 21:29, Hayes, Graham graham.ha...@hp.com wrote: ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
That is what I was not sure about, if they are currently one in the same. Thanks for the link. Carl On May 28, 2014 2:47 PM, Hayes, Graham graham.ha...@hp.com wrote: Sorry - not sure what happened there - as I was saying: The Networking Program is Neutron. https://wiki.openstack.org/wiki/Programs Graham On 28/05/2014 21:29, Hayes, Graham graham.ha...@hp.com wrote: ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Thu, May 29, 2014 at 4:22 AM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. I also agree here - DNS isn't a program by itself in my opinion, it should be in a group of other Network Application Services. -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
Sean Dague s...@dague.net writes: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. One of the reasons we created programs was so that we wouldn't have to feel compelled to constrain our growth because of how it relates to our bureaucracy (specifically core). So I don't think we should limit the number of programs for that reason. To the task at hand -- Designate has its own group of people working on it and moreover is in an entirely different problem space than Neutron. Its PTL needs to be familiar with people and technology that are vastly different. I think DNSaaS makes sense as a new program, and I'm personally delighted to see the incubation request. -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On 05/28/2014 07:11 PM, James E. Blair wrote: Sean Dague s...@dague.net writes: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. One of the reasons we created programs was so that we wouldn't have to feel compelled to constrain our growth because of how it relates to our bureaucracy (specifically core). So I don't think we should limit the number of programs for that reason. To the task at hand -- Designate has its own group of people working on it and moreover is in an entirely different problem space than Neutron. Its PTL needs to be familiar with people and technology that are vastly different. I think DNSaaS makes sense as a new program, and I'm personally delighted to see the incubation request. I'm definitely very happy to see the incubation request. And, honestly, I'm fine with it as a new program. Cursory look shows that they are already more ahead on diversity and activity than 2 of our incubated projects. I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little trees that orbit it (client and now specs repos). If we always expect that to be the case, I'm not really sure why we built this intermediate grouping. Which is different from some of the programs that aren't part of the integrated release, which produce a collection of tools that happen when they happen. Anyway, probably a second conversation for the community. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham graham.ha...@hp.com wrote: Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application Based on http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rstI have a few questions: * 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? * Can you expand on why this doesn't make sense in neutron when things like LBaaS do. * 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/) As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Designate Incubation Request
Hi all, Designate would like to apply for incubation status in OpenStack. Our application is here: https://wiki.openstack.org/wiki/Designate/Incubation_Application As part of our application we would like to apply for a new program. Our application for the program is here: https://wiki.openstack.org/wiki/Designate/Program_Application Designate is a DNS as a Service project, providing both end users, developers, and administrators with an easy to use REST API to manage their DNS Zones and Records. Thanks, Graham ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
