[openstack-dev] [Designate] DNS Services PTL Candidacy
Hi all, I'd like to announce my candidacy for the DNS Services Program PTL position. I've been involved in Designate since day one, as the both original author and as pseudo-PTL pre-incubation. Designate and the DNS Services program have come a long way since the project was first introduced to StackForge under my lead, and while we're far from done, I feel I'm more than capable and best positioned to bring the project through to fruition. Additionally, I manage the team at HP running the largest known public and production deployment of Designate for HP Cloud - Giving me the operational experience necessary to guide the project towards meeting real world operational requirements. Thanks - Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects
Hi all, While requesting a openstack/designate-dashboard project from the TC/ Infra - The topic of why Designate panels, as an incubated project, can't be merged into openstack/horizon was raised. In the openstack/governance review[1], Russell asked: Hm, I think we should discuss this with the horizon team, then. We are telling projects that incubation is a key time for integrating with other projects. I would expect merging horizon integration into horizon itself to be a part of that. With this in mind - I'd like to start a conversation with the Horizon, Tempest and DevStack teams around merging of code to support Incubated projects - What are the drawbacks?, Why is this currently frowned upon by the various teams? And - What do each of the parties believe is the Right Way forward? Thanks, Kiall [1]: https://review.openstack.org/#/c/119549/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects
-Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 09 September 2014 15:13 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote: Hi all, While requesting a openstack/designate-dashboard project from the TC/ Infra – The topic of why Designate panels, as an incubated project, can’t be merged into openstack/horizon was raised. In the openstack/governance review[1], Russell asked: Hm, I think we should discuss this with the horizon team, then. We are telling projects that incubation is a key time for integrating with other projects. I would expect merging horizon integration into horizon itself to be a part of that. With this in mind – I’d like to start a conversation with the Horizon, Tempest and DevStack teams around merging of code to support Incubated projects – What are the drawbacks?, Why is this currently frowned upon by the various teams? And – What do each of the parties believe is the Right Way forward? I though the Devstack and Tempest cases were pretty clear, once things are incubated they are fair game to get added in. Devstack is usually the right starting point, as that makes it easy for everyone to have access to the code, and makes the testability by other systems viable. I currently don't see any designate changes that are passing Jenkins that need to be addressed, is there something that got missed? -Sean From previous discussions with Tempest team members, we had been informed this was not the case - this could have been miscommunication. For DevStack, I never even asked - After two Not till you're integrated's, I made the assumption DevStack would be the same. I'll get our DevStack part's submitted for review ASAP if that's not the case! The Horizon integration though, the spark for this conversation, still stands. Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gate proposal - drop Postgresql configurations in the gate
On Thu, 2014-06-12 at 11:36 -0400, Sean Dague wrote: If someone can point me to a case where we've actually found this kind of bug with tempest / devstack, that would be great. I've just *never* seen it. I was the one that did most of the fixing for pg support in Nova, and have helped other projects as well, so I'm relatively familiar with the kinds of fails we can discover. The ones that Julien pointed really aren't likely to be exposed in our current system. Which is why I think we're mostly just burning cycles on the existing approach for no gain. -Sean I don't have links handy - but Designate has hit a couple of bugs that prevented our database migrations from succeeding on PostgreSQL - Maybe a new re-usable test slave type for exercising database migrations + database interface code against? These would be much quicker to run than a full devstack/tempest gate.. 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 (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] [openstack-tc] Designate Incubation Request
On Mon, 2014-06-09 at 07:25 -0400, Sean Dague wrote: On 06/06/2014 12:06 PM, Mac Innes, Kiall wrote: 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/ I'm seeing in [2] api logs that something was run (at least 1 API request was processed), but it's hard to see where that is in the console logs. Pointers? -Sean Hey Sean, Yes - on Saturday, after sending this email on Friday, I noticed the exercises were not running - devstack-gate has them disabled by default. We landed a patch to the job this morning to allow us to run them, and have a series of patches in the check/gate queues to enable the exercises for all patches. An example of the output is at [1] - this will be enabled for all patches once [2] lands. Thanks, Kiall [1]: http://logs.openstack.org/88/98788/6/check/gate-designate-devstack-dsvm/98b5704/console.html [2]: https://review.openstack.org/#/c/98788/ ___ 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
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 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] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit
Yep - I know I'll join in :) Thanks, Kiall On Tue, 2014-04-29 at 14:09 -0600, Carl Baldwin wrote: The design summit discussion topic I submitted [1] for my DNS blueprints [2][3][4] and this one [5] just missed the cut for the design session schedule. It stung a little to be turned down but I totally understand the time and resource constraints that drove the decision. I feel this is an important subject to discuss because the end result will be a better cloud user experience overall. The design summit could be a great time to bring together interested parties from Neutron, Nova, and Designate to discuss the integration that I propose in these blueprints. DNS for IPv6 in Neutron is also something I would like to discuss. Mostly, I'd like to get a good sense for where this is at currently with the current Neutron dns implementation (dnsmasq) and how it will fit in. I've created an etherpad to help us coordinate [6]. If you are interested, please go there and help me flesh it out. Carl Baldwin Neutron L3 Subteam [1] http://summit.openstack.org/cfp/details/403 [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate ___ 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] [neutron][Designate] A question about DNSaaS?
On Fri, 2014-03-14 at 08:44 +, Yuzhou (C) wrote: Hi stackers, Are there any plans about DNSaaS on the neutron roadmap? As far as I known, Designate provides DNSaaS services for OpenStack. Why DNSaaS is Independent service , not a network service like LBaas or VPNaaS? Thanks, Zhou Yu I personally see DNSaaS as being outside the scope of Neutron. VPNaaS and LBaaS are, at their core, about moving bits from A - B. DNSaaS is different, as it plays no part in how bits are moved from A - B. Neutron's 1 line intro is: Neutron is an OpenStack project to provide networking as a service between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova). I'm not sure I could squeeze authoritative DNS into that scope without changing it :) Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introduction: Rich Megginson - Designate project
Hi Rich - Welcome! We're mostly all on the #openstack-dns IRC channel, drop by and say hello ;) Thanks, Kiall On Wed, 2014-01-15 at 18:24 -0700, Rich Megginson wrote: Hello. My name is Rich Megginson. I am a Red Hat employee interested in working on Designate (DNSaaS), primarily in the areas of integration with IPA DNS, DNSSEC, and authentication (Keystone). I've signed up for the openstack/launchpad/gerrit accounts. Be seeing you (online). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: This is a digitally signed message part ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Designate DNSaaS installation issue
Hi Nick, Several fixes to the migrations for PostgreSQL have now merged, and we've setup some automated tests to verify the migrations continue to function on SQLite / MySQL / PostgreSQL.. So - Hopefully that's the end of PostgreSQL issues :) Thanks, Kiall On Sun, 2014-01-12 at 08:26 +0200, Nick Maslov wrote: Thanks Kiall! -- Nick Maslov Sent with Airmail On January 9, 2014 at 5:26:07 PM, Mac Innes, Kiall (ki...@hp.com) wrote: Hi Nick, I'll get psql re-tested this week, I expect it's something simple causing the failure, but it's been a while since I've tested with PostgreSQL. I've filed bug #1267509 [1] on your behalf to track the issue, you can hit the This affects me too link at the top of the page to get notified of progress. [1]: https://bugs.launchpad.net/designate/+bug/1267509 Thanks, Kiall On Mon, 2014-01-06 at 12:49 +0200, Nick Maslov wrote: Hi Simon, Say, are there any news on this issue? Or - you can point me to a place in the code, where this check is - and I will ask local python devs to help me with it. Cheers, NM -- Nick Maslov Sent with Airmail On January 1, 2014 at 11:20:11 AM, Nick Maslov (azp...@gmail.com) wrote: Hi Simon, Thanks a lot, will wait for updated version. Well, we decided to hit the Postgres road with this installation. And already had a lot of issues on that path, starting with small things like this to inability of Postgres to easily perform HA. Happy NY! -- Nick Maslov Sent with Airmail On December 31, 2013 at 5:27:10 PM, Simon McCartney (si...@mccartney.ie) wrote: Hi Nick, I don't think we've tested against Postgres recently, let me see if we can get a Postgres test environment setup tweak the SQLA to keep Postgres happy. (fwiw, we're using Percona/Galera MySQL clusters in production with Designate) Simon. On Tuesday, December 31, 2013, Nick Maslov wrote: Hi, I`m installing Designate as per this doc. When I try to use this command: designate-manage database-sync It fails with following: 2013-12-31 12:20:39 DEBUG [migrate.versioning.util] Disposing SQLAlchemy engine Engine(postgres://designate:pa %24w0rd@pg01-001/designate) 2013-12-31 12:20:39 ERROR [cliff.app] Postgresql ENUM type requires a name. ERROR: Postgresql ENUM type requires a name. I`m using PostgreSQL as backend for Designate. Can someone point me in the right direction, and maybe point to Designate developers? Thanks, NM -- Nick Maslov Sent with Airmail -- Simon McCartney E: si...@mccartney.ie M: +44 7710 836 915 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack - signature.asc, 853 bytes signature.asc Description: This is a digitally signed message part ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Designate DNSaaS installation issue
Hi Nick, I'll get psql re-tested this week, I expect it's something simple causing the failure, but it's been a while since I've tested with PostgreSQL. I've filed bug #1267509 [1] on your behalf to track the issue, you can hit the This affects me too link at the top of the page to get notified of progress. [1]: https://bugs.launchpad.net/designate/+bug/1267509 Thanks, Kiall On Mon, 2014-01-06 at 12:49 +0200, Nick Maslov wrote: Hi Simon, Say, are there any news on this issue? Or - you can point me to a place in the code, where this check is - and I will ask local python devs to help me with it. Cheers, NM -- Nick Maslov Sent with Airmail On January 1, 2014 at 11:20:11 AM, Nick Maslov (azp...@gmail.com) wrote: Hi Simon, Thanks a lot, will wait for updated version. Well, we decided to hit the Postgres road with this installation. And already had a lot of issues on that path, starting with small things like this to inability of Postgres to easily perform HA. Happy NY! -- Nick Maslov Sent with Airmail On December 31, 2013 at 5:27:10 PM, Simon McCartney (si...@mccartney.ie) wrote: Hi Nick, I don't think we've tested against Postgres recently, let me see if we can get a Postgres test environment setup tweak the SQLA to keep Postgres happy. (fwiw, we're using Percona/Galera MySQL clusters in production with Designate) Simon. On Tuesday, December 31, 2013, Nick Maslov wrote: Hi, I`m installing Designate as per this doc. When I try to use this command: designate-manage database-sync It fails with following: 2013-12-31 12:20:39DEBUG [migrate.versioning.util] Disposing SQLAlchemy engine Engine(postgres://designate:pa %24w0rd@pg01-001/designate) 2013-12-31 12:20:39ERROR [cliff.app] Postgresql ENUM type requires a name. ERROR: Postgresql ENUM type requires a name. I`m using PostgreSQL as backend for Designate. Can someone point me in the right direction, and maybe point to Designate developers? Thanks, NM -- Nick Maslov Sent with Airmail -- Simon McCartney E: si...@mccartney.ie M: +44 7710 836 915 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack signature.asc Description: This is a digitally signed message part ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Designate DNSaaS and Horizon
Hey Jason/Andriy, That fork is very outdated :) Before we had a chance to complete it and turn it into a real plugin, another team at HP began working on a Horizon plug-in for our new Horizon based console. At the time, deadlines were tight, so we discussed open-sourcing the plugin once their team had some spare cycles - I'll check in with them again. Thanks, Kiall On 05/01/14 14:21, Andriy Yurchuk wrote: Hi Jason, Take a look at this http://lists.openstack.org/pipermail/openstack/2013-August/000778.html There is fork of Horizon with basic support for Designate but it does not look like it's being developed further. --- Regards, Andriy Yurchuk On Dec 31, 2013, at 5:34 PM, ja...@chatinara.com wrote: Hi, Is there a Horizon plugin or something to manage Designate yet? I did some quick searching but can't seem to find anything on github or launchpad about it. If there is, can someone point me in the right direction? Thanks! jason ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Designate /DnsaaS
Hey Cláudio, Yes and No .. There is a fork of Horizon[1] where we have really basic integration (Create, List, Delete domains - No support for records etc) Once we get this a little more complete, We we're going to figure out how to make it an actual horizon plugin rather than a fork :) Thanks, Kiall [1]: https://github.com/moniker-dns/horizon/ On 23/08/13 13:04, claudio wrote: Hello guys I appreciate your help with DESIGNATE and your patience. Is there any plugin to integrate designate in Horizon? Cheers Cláudio Marques clau...@onesource.pt http://www.onesource.pt/ *De:*Simon McCartney [mailto:si...@mccartney.ie] *Enviada:* 22 de agosto de 2013 18:37 *Para:* clau...@onesource.pt *Assunto:* Re: [Openstack] Designate /DnsaaA Do you mean in conjunction with the notifications sink (where records are created or deleted in response to instance create/delete events) in which case the domain to be used is set in the designate.conf file, and is global, not currently configurable per tenant. On 22 August 2013 17:05, clau...@onesource.pt mailto:clau...@onesource.pt wrote: Hi Stackers Is there anyone that have some experience with designate? I can create domains servers and records but I am a bit stuck. How can allocate a domain to a specific Tenant/project? Can anyone help-me in this? Thank's Cheers Claudio Marques clau...@onesource.pt mailto:clau...@onesource.pt http://www.onesource.pt/ ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org mailto:openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Simon McCartney E: si...@mccartney.ie mailto:si...@mccartney.ie M: +44 7710 836915 ___ Claudio, Hey, maybe I am not understanding your question, but whatever tenant you are using to create domains and domain records, that is the one allocated to that tenant. Regards, Patrick ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org mailto:openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] Osl and dangerous code merging
On 21/08/13 16:07, Doug Hellmann wrote: IIUC, git sub-modules point to a specific revision of the external repository, right? So would projects still have to explicitly update to newer versions of the incubator code by changing that sub-module reference? Normally - Yes. With Gerrit - Maybe. Gerrit supports auto-updating submodule pointers in other gerrit hosted repos. But.. There are gottchas. The big one being, I don't think it's something that can be gated on.. Even if Gerrit was to make it *really easy* and testable .. I'd vote against any attempt to bring submodules into our repositories. I can use them, and have used them successfully with teams in the past. But it wasn't worth it. Training every new person in, and dealing with the inevitable mistakes was just too much effort. With a team the size of OpenStack's, this will be totally unmanageable IMO. Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Osl and dangerous code merging
On 21/08/13 19:48, Boris Pavlovic wrote: So why submodules are terrible and oslo-sync is good?=) I think the biggest mistake people make with submodules, which oslo's sync avoids, is dropping commits / Going backwards / Switching branches on submodule - or worse - pointing at a detached commit. Olso's sync results in a diff.. Here's what happens when you switch a submodule: $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: cookbooks (new commits) $ git diff diff --git a/cookbooks b/cookbooks index e9e667f..3c3156a 16 --- a/cookbooks +++ b/cookbooks @@ -1 +1 @@ -Subproject commit e9e667f51283abb2e2f174c68adaec683098bcd1 +Subproject commit 3c3156ac0c67ee2334b52fd8e2d298d3433b4281 And WORSE! That submodule is now pointing to a detached commit. Getting developers - the hundreds of developers involved in OpenStack - to understand and appreciate this issue, and about 50 other issues, is not time spent well. Time that will need to be spent over and over again as OpenStack gains more and more developers. Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] Designate/DNSaaS question
Hi David, The getting started guide walks through an install into a virtualenv, which will isolate the dependencies from any other services. So - Following this on your existing controller should be safe. Generally speaking, our dependencies are fairly close to the current havana deps, So, I wouldn't recommend installing from .deb's alongside an earlier version of OpenStack. At HP, we deploy onto dedicated servers where the dependencies won't conflict. We do plan on cutting a formal release in or around the time of the Havana release (October), at which point it'll be easier to maintain a compatible set of .deb's. In the meantime, you can install Designate using the PPA/.deb's inside an instance on top of nova, or you can install into a virtualenv on the controller node by following the getting started guide. Let me know if you have any questions! Thanks, Kiall On 16/08/13 11:13, David Palma wrote: Hi Stackers I am looking forward to install Designate in order to get familiarized with DnsaaS on openstack. I noticed that there are some installations guides available such as: http://designate.readthedocs.org/en/latest/getting-started.html and http://timsimmons.me/getting-started-with-openstack-and-designate Has anyone already worked with Designate? Should I install it on my controller node or should I install it on a separate machine in order to prevent possible conflicts with Openstack services running on the controller node? Can anyone enlighten me ? Thanks in advance, David Palma ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [keystone] Pagination
So, Are we saying that UIs built on OpenStack APIs shouldn't be able to show traditional pagination controls? Or am I missing how this should work with marker/limit? e.g. for 11 pages of content, something like: 1 2 3 .. 10 11 Thanks, Kiall On 13/08/13 22:45, Jay Pipes wrote: On 08/13/2013 05:04 PM, Gabriel Hurley wrote: I have been one of the earliest, loudest, and most consistent PITA's about pagination, so I probably oughta speak up. I would like to state three facts: 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface. 2. Pagination doesn't scale. 3. OpenStack's APIs have historically had useless filtering capabilities. In a world where pagination is a must-have feature we need to have page number + limit pagination in order to build a reasonable UI. Ironically though, I'm in favor of ditching pagination altogether. It's the lowest-common denominator, used because we as a community haven't buckled down and built meaningful ways for our users to get to the data they really want. Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level solutions: Problem 1: I know what I want and I need to find it. Solution: filtering/search systems. This is a good place to start. Glance has excellent filtering/search capabilities -- built in to the API from early on in the Essex timeframe, and only expanded over the last few releases. Pagination solutions should build on a solid filtering/search functionality in the API, where there is a consistent sort key and direction (either hard-coded or user-determined, doesn't matter). Limit/offset pagination solutions (forward and backwards paging, random skip-to-a-page) are inefficient from a SQL query perspective and should be a last resort, IMO, compared to limit/marker. With some smart session-storage of a page's markers, backwards paging with limit/marker APIs is certainly possible -- just store the previous page's marker. Problem 2: I don't know what I want, and it may or may not exist. Solution: tailored discovery mechanisms. This should not be a use case that we spend much time on. Frankly, this use case can be summarized as the window shopper scenario. Providing a quality search/filtering mechanism, including the *API* itself providing REST-ful discovery of the filters and search criteria the API supports, is way more important... Problem 3: I need to know something about *all* the data in my system. Solution: reporting systems. Sure, no disagreement there. We've got the better part of none of that. I disagree. Some of the APIs have support for a good bit of search/filtering. We just need to bring all the projects up to search speed, Captain. Best, -jay p.s. I very often go to the second and third pages of Google searches. :) But I never skip to the 127th page of results. But I'd like to solve these issues. I have lots of thoughts on all of those, and I think the UX and design communities can offer a lot in terms of the usability of the solutions we come up with. Even more, I think this would be an awesome working group session at the next summit to talk about nothing other than how can we get rid of pagination? As a parting thought, what percentage of the time do you click to the second page of results in Google? All the best, - Gabriel ___ 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] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On 06/08/13 21:56, Jonathan LaCour wrote: James Slagle james.sla...@gmail.com wrote: WSME + pecan is being used in Tuskar: https://github.com/tuskar/tuskar (OpenStack management API) We encountered the same issue discussed here. A solution we settled on for now was to use a custom Renderer class that could handle different response codes. You set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. If there is anything I can do on the Pecan side, let me know! Happy to build in new functionality to make this easier, in general. It does seem to make sense to be fixed on the WSME side, though. Best -- - Jonathan Nah - this is entirely on the WSME side :) WSME translate all exceptions that don't extend their ClientExcption to HTTP 500, and anything that does to HTTP 400. Beyond that, you only have the default status code to work with - 401, 404, 503 etc are all off limits with stock WSME. Literally you have a default code for successful requests, and 400 or 500. Nothing else. It seems like Ceilometer has worked there way around it using the _lookup method for 404's (but I can't find how they return any other status codes..), and libra + tuskar have replaced the WSME error handling for something entirely custom. We're not massively interested in replacing WSME's error handling with something custom, so our plan is to just use Pecan and ignore WSME for the Designate v2 API. When it's ready, hopefully the switch won't be too painful! Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On 05/08/13 16:09, John Garbutt wrote: On 5 August 2013 15:15, Anne Gentleannegen...@justwriteclick.com wrote: On Mon, Aug 5, 2013 at 8:55 AM, John Garbuttj...@johngarbutt.com wrote: Given we seem to be leaning towards WSME: http://lists.openstack.org/pipermail/openstack-dev/2013-August/012954.html Could we not try to make WSME give us the documentation we need? Not sure if its feasible, but it seems like there is a good start to that already available: https://wsme.readthedocs.org/en/latest/document.html John, this looks interesting, but I have reservations. Do you know if you can suppress the SOAP and ExtDirect entries? Sorry no idea, but we certainly would have to. While the topic of WSME is open - Has anyone actually tried using it? IMO it's just not ready. Simple things like returning a 404 are not currently supported[1]. I would be very cautious about assuming WSME can support anything we need when the absolute fundamentals of building a REST API are totally MIA. Thanks, Kiall [1]: https://bitbucket.org/cdevienne/wsme/issue/10/returning-404-or-basically-any-status-code ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] need to pin jsonschema version for glance?
On 17/07/13 19:51, Matthew Treinish wrote: I think that setting a requirement of =1.3.0 is fine it should get us around this. Watch out! There was a mis-release of 2.0 under the version 1.4.0. The OpenStack mirror still has this release, ever after it was pulled from pypi. openstack/requirements[1] now uses this pin jsonschema=1.0.0,!=1.4.0,2 Thanks, Kiall [1]: https://github.com/openstack/requirements/blob/master/requirements.txt#L23 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] AMQP Version upgrade plans?
If you have a recent version of kombu, and amqp[1] rather than amqplib installed, things will just start using AMQP 0.9.1. Ubuntu doesn't package a new enough Kombu, and they don't package amqp at all.. Not sure about other distro's. Thanks, Kiall [1]: https://pypi.python.org/pypi/amqp On 24/06/13 19:12, Sunjeet Singh wrote: OpenStack currently uses AMQP 0.8. Are there any plans to upgrade? Thank you, Sunjeet ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
