[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
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
[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] 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 08:00 +0930, Michael Davies wrote: > On Thu, May 29, 2014 at 4:22 AM, 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 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 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 Tue, 2014-05-27 at 17:42 -0700, Joe Gordon wrote: > On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham > 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-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 ..." to update what will be committed) # (use "git checkout -- ..." 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-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] [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] Oslo.exception being dropped??
Taking a total guess here... But, I reckon that it's usefulness now that oslo.* are being spun off into "real projects" means that the shared dependency is becoming a problem. e.g. oslo.config and oslo.messaging shouldn't both include it, so should a whole oslo.exception library be created for what is essentially 1 shared base exception class? I personally don't think so. Thanks, Kiall On 08/08/13 19:12, Joshua Harlow wrote: > Hi recently I was working with some cinder code and noticed that > oslo.exception is being dropped from it (and other projects). > > It seems connected back to this bug: > https://bugs.launchpad.net/oslo/+bug/1208734 > > https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L118 > > I'm just wondering if there is any more reason for why it is obsoleted, > is it being replaced? Was there just no one supporting it? Was it > decided that its not useful? > > Thanks much, > > Josh ___ 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 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
Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
So, From experimenting with, and looking at the WSME code - raising a status with `pecan.abort(404)` etc doesn't actually work. WSME sees that, and helpfully swaps it out for a HTTP 500 ;) The author of WSME even says there is currently no way to return a 404. So, ceilometer must be either not using anything but http 400 and http 500, or have replaced WSMEs error handling :/ I'll have to have a look a ceilometers API to see if they ran into/fixed the issue.. Thanks, Kiall On 06/08/13 07:56, Mike Perez wrote: > On Mon, Aug 5, 2013 at 11:03 AM, Mac Innes, Kiall <mailto:ki...@hp.com>> wrote: > > While the topic of WSME is open - Has anyone actually tried using it? > > > > > 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. > > > There was a whole thread about this a couple of months ago [1]. > > tl;dr Ceilometer is already using it. I have a rough patch for what > would be v3 of Cinder using Pecan/WSME for J if we decide we need a bump > [2]. Neutron will likely be using it when it switches to Pecan. > > For Cinder, WSME raises a 400 on type checking in the body as I need it > to. Everything else I have raised in the controller as needed. > > Thanks, > Mike Perez > > [1] - > http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html > [2] - > http://lists.openstack.org/pipermail/openstack-dev/2013-June/010857.html ___ 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 Gentle wrote: >> >On Mon, Aug 5, 2013 at 8:55 AM, John Garbutt 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
Re: [openstack-dev] Moniker renamed to Designate, and applies for Incubation.
On 16/06/13 22:34, Robert Collins wrote: > I thought the standard design pattern for that was zones. > say your cloud is cloud.example.com > so SRV for cloud.example.com would be keystone public > SRV for _compute._pub_endpoints.cloud.example.com -> compute public endpoint > SRV for _compute._priv_endpoints.cloud.example.com -> compute private > endpoint (and btw you can use split views to hide that from the > outside world) > > SRV for _network._pub_endpoints.cloud.example.com -> openstack network > public endpoint > etc. Pretty much - it's expected that SRV records will follow this pattern: _._.something, where .something doesn't have to be "provider.com", it could be "internal.provider.com", or "region-a.provider.com" etc. I would personally advocate for being "openstack-identity" + "openstack-identity-admin" + "openstack-identity-internal" etc rather then nesting unnecessarily. > > > E.g. known, solved thing, nothing to see here, move along. > > -Rob Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Moniker renamed to Designate, and applies for Incubation.
On 16/06/13 22:09, Mark Washenberger wrote: > On Sat, Jun 15, 2013 at 6:37 PM, Monty Taylor <mailto:mord...@inaugust.com>> wrote: > On 06/10/2013 10:49 AM, Mac Innes, Kiall wrote: > > > > Some interesting use cases are service discovery[1], replacing the > > traditional model of trust in browsers for HTTPS[2], authenticating > > email with DKIM[3], establishing SSH host key trust[4], aiding in the > > prevention of spam[5].. and many many more. Not all these > examples are > > practical today, but they do provide examples of DNS functions > which are > > outside the scope of OpenStack Networking. > > SO - As a huge supporter of using dns for things (since it's the world's > most scalable database), can I turn this around a little bit? > > Why don't we use DNS and/or a DNSaaS implementation to do the things in > the list that are above that are currently keystone's job in openstack? > Or, stated differently, why isn't this part of keystone, or keystone > part of this? > > I agree there is a very interesting overlap between DNSaaS for customer > service discovery and openstack service discovery. Even if you are > uncomfortable with the idea of mixing in service and customer data (I > kind of am!), reuse might still make a ton of sense in a TripleO type of > deployment context. > > I particularly like Monty's suggestion about using DNS to do some of the > service catalog functions that are currently Keystone's responsibility, > though I don't know enough about DNS to evaluate if this would be a good > choice in a technical sense. DNS has plenty of history as a "service catalog" of sorts, with things like XMPP, Kerberos making "simple" use of DNS for discovery and MS's Active Directory making heavy use of DNS for discovery. > I'd rather have us focus service discovery > (both catalog and DNS) into the same project outside of Keystone than > fold DNSaaS into/under Keystone--it honestly makes very little sense to > me to include service catalogs with identity and policy. Including > service catalogs in token responses has some very unfortunate side effects: > - service catalogs have to be small enough to fit into a single > response, sometimes even a single HTTP header if some service catalog > data ends up in pki tokens > - service catalog views are always restricted to a specific project, > since a token is in general valid only for a specific project > > These side effects make certain user experience stories really > difficult, for example, "List all instances I have permission to control > across project X, Y, and Z", which is needed when multiple projects are > sharing support/operations staff. > > I guess what I'm trying to say is, if we looked at the Designate > incubation request and determined that we need to refactor the > association between identity and catalog, that would be A Good Thing. > I hold off commenting any more on Keystone, as I'm way out of the loop on their plans :) Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Moniker renamed to Designate, and applies for Incubation.
On 16/06/13 19:50, Jay Pipes wrote: > On 06/16/2013 10:39 AM, Mac Innes, Kiall wrote: >> I'm assuming you're taking about using DNS for discovery of >> regions/services/endpoints etc. Essentially replacing the service >> catalog? If this is what's being discussed, then absolutely. That is >> what SRV records were designed for. > > Ah, but there's a catch. SRV records don't contain a number of pieces of > information that the service catalog supplies... > > The service type -- is it a compute service? an identity service? a > volume service? The only thing the SRV record gives you is "it's a > service"... you then have to do a further query (and assume some sort of > standard information discovery format) on the URI in order to determine > what it is. Since all of our endpoints are TCP/IP, there is no way to > use the protocol field of the SRV record to differentiate different > service types. You would still need some sort of service catalog being > served up from the URIs contained in the SRV record target field in > order for the OpenStack clients to make sense of anything. SRV records are typically well known / squatted names. For example: * XMPP federation: _xmpp-server._tcp.provider.com * Kerberos KDC discovery: _kerberos._udp.company.com * MS Active Directory site specific LDAP server: _ldap._tcp.$site._sites.company.com You'll notice that last one includes the notion of "sites" similar to OpenStack's regions. This is an MS convention, but shows a possible convention for handling multiple regions.. > > The endpoint interfaces -- unfortunately, Keystone's service catalog > implementation uses a (IMHO) silly concept of admin/public/internal > "interfaces" for each service endpoint. [1] There is no way to use a SRV > record to indicate to clients whether a URL should be considered an > admin URL, an internal URL, or a public URL. This comes back to providing the necessary conventions.. Maybe something along these lines: _compute._tcp.us-west.provider.com + _compute-admin._tcp.us-west.provider.com + _compute-internal.tcp.us-west.provider.com > Frankly, I think the entire > concept of endpoint interfaces should just be ditched in Keystone. The > concept is silly. If there is a separate "admin" interface that should > be physically or logically separate from some other interface, just make > it a separate service... or just use RBAC like any sane service would. Completely agree :) > > We could use a TXT record to inject some data about the type of service > a DNS record is, though. That way, we could write a blob of JSON into > the TXT record for the target domain name that would contain some > information about the service endpoints. Again, I think providing (and following) well known conventions can make this unnecessary for the most part. >> So - Should Keystone and Designate merge? I don't believe they should. >> Keystone is the OpenStack Identity service - It provides authentication >> and authorization services, which happens to include a list of services >> to which you are authorized to access. > > I don't believe they should merge, as I think Designate is targeted at > the tenant, not the underlying services needing a service catalog. > > What I think is a better idea is to write a Designate catalog driver for > Keystone, that itself could call a Designate endpoint to write the > afortementioned SRV and TXT records to whatever DNS backends that > Designate supports. +1 - Assuming some conventions are agreed upon.. > I think the entire service catalog module in Keystone should be > rewritten, starting from a new object model for the objects involved in > the service catalog: > > * Region -- this object isn't a first-class citizen in Keystone right > now, and its design suffers because of it. By Region I refer to a > generic area with no geographic connotation to it. > * Endpoint -- A URI publishing a service of some kind > * ServiceType -- the type of service available at an endpoint > > Once the object model is fully fleshed out, then the existing API which > returns a denormalized, inflexible, unfiltered list of all endpoints in > all regions, should be refactored to promote the natural regional > hierarchy that DNS naturally fits. > >> I'm not sure hosting $customer's DNS is an obvious fit within that scope. > > No, it definitely isn't. > > Best, > -jay > > [1] > https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#endpoints-v3endpoints > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Moniker renamed to Designate, and applies for Incubation.
On 16/06/13 05:06, Ryan Lane wrote: > > If you use OpenStack you have no choice but to use Keystone. This isn't > really the case with Designate, and I think it would be difficult for it > to be a required service. Maybe Keystone could have a driver that > interacts with Designate for global registry, if Designate is being used? Yea, I see Designate as something which is entirely optional to an OpenStack cloud. And, as a general purpose DNS service, hosting of the service catalog would require no changes on Designate's side. > > It really makes sense for this to be a standalone service that other > services interact with. It's very possible that some infrastructures may > choose to use Designate to manage their DNS without using any other > OpenStack service. > I absolutely agree, Designate has no hard dependencies on OpenStack services and frankly - I see no reason to introduce one. Isolated services with a clear and simple goal are always better IMHO than interdependent services with everything, even the kitchen sink, included! I actually think this shows through in Designate's architecture. Designate is made up of 4 small and discrete services: designate-api - A thin API service that provides the HTTP endpoint. This deserializes and validates the structure of incoming API calls, and forwards them to central. designate-central - The core of the service. All DB interactions, authorization etc happen here. designate-agent - An optional service that coordinates remote DNS servers. Say you decide to use BIND9, you'll need a way to write out the zonefiles on each DNS service as changes are made. With PowerDNS, or any other DB backed DNS service, this service can be skipped. designate-sink - Another optional service that hooks into the nova/quantum notifications and performs actions based on plugins. For example, you could write a plugin to create DNS records for instances as they boot. If Designate is incubated, I can see this service being deprecated and the relevant hooks being placed straight into Nova/Quantum rather than relying on the notification feed. So - What I'm getting at is, it's possible to use Designate is many different ways. Maybe you don't want to host DNS for $customer, but do want to maintain forward/reverse DNS for instances.. You can do that by running just central and sink[1]. Or maybe you only want to host $customers DNS, you just need the central and api services. Some people see this as complexity, but I see it as series of well defined and composable components that can hopefully be used in ways we never planned for! Thanks, Kiall [1]: Okay.. So some initial config would require the API.. but it wouldn't need to be exposed to customers, or even kept running after the initial config. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Moniker renamed to Designate, and applies for Incubation.
On 16/06/13 02:40, Monty Taylor wrote: > SO - As a huge supporter of using dns for things (since it's the world's > most scalable database), can I turn this around a little bit? > > Why don't we use DNS and/or a DNSaaS implementation to do the things in > the list that are above that are currently keystone's job in openstack? > Or, stated differently, why isn't this part of keystone, or keystone > part of this? It seems like some of the things that keystone needs to do > moving forward (global registry) have been working in the DNS for, well, > a long time... So - I have to admit, I've not been following keystones plans very closely! I'm assuming you're taking about using DNS for discovery of regions/services/endpoints etc. Essentially replacing the service catalog? If this is what's being discussed, then absolutely. That is what SRV records were designed for. So - Should Keystone and Designate merge? I don't believe they should. Keystone is the OpenStack Identity service - It provides authentication and authorization services, which happens to include a list of services to which you are authorized to access. I'm not sure hosting $customer's DNS is an obvious fit within that scope. Thoughts? Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
