Re: [Openstack] Is It Safe to Use The OpenStack Packages Distributed in Ubuntu 12.04 Official Repository?
>> - Reply message - >> From: "Ji Zhang" >> To: "openstack@lists.launchpad.net" >> Subject: [Openstack] Is It Safe to Use The OpenStack Packages Distributed in >> Ubuntu 12.04 Official Repository? >> Date: Mon, Aug 20, 2012 04:58 >> >> >> >> Hi, >> >> I'm to deploy OpenStack Essex in production environment. According to >> the official manual, I should either install it manually or use >> dodai-deploy. After briefly browsing these methods, it seems that both >> of them are using the packages distributed in official repository >> (i.e. apt-get install keystone), not building from source like >> DevStack does. >> >> So my question is, as is said in the title, are these packages >> production ready? Or should I checkout the stable/essex branch of each >> project and build it by myself? >> >> Thanks. >> > >On Mon, Aug 20, 2012 at 08:53:23AM +0200, Ruzicka, Marek wrote: > Hi, > > Guys around will probably disagree,but I have spent last 5-6weeks > creating POC using repos is ubuntu, and I have to say it is not > production rdy yet. > > Versions in repos are about 2months old if I'm not mistaken...too > old for such fast paced project. > > Marek Ruzicka > System Engineer (storage) > T-Systems Slovakia s.r.o. > > Sent from my mobile, please excuse typos. Hi, Hmm, I do disagree with this stance. There are 3 issues being mingled together, but do have overlap. 1. Is it 'safe' for production. - All distributions commit to an assurance level of software they ship. This differs between distributions, and the level of the assurance. However, you can be pretty sure - that any major distro will be taking great care of their openstack packages. - In relation to Ubuntu, by using the distribution packages you can be assured that: - Security updates will be included promptly, usually on the day the embargo is lifted. - Assurance that the software has been tested in given scenarios with the dependencies and libraries that are shipped. Any distribution will tell you that a project such as this, the core software is only half of the complexity, the dependencies carry significant burden. - Safe upgrade for security and bug fixes for the release, and reasonably easy transition between major versions. A git checkout, doesn't promise safe upgrade. - With these factors taken into account, unless significant investment into controlling these issues on your own deployment, i'd consider it *un-safe* to use anything other than a distributions packages. 2. How current are the packages? - As mentioned in Marek's email, the packages are about 2 months old. Originally, 12.04 released with Essex Final and some local distro patches. The patches were incorporated upstream, and many others contributed fixes. For this reason, we undertook the process of a Stable Release Update. Due to the level of upstream CI, Ubuntu CI and further extended testing, we were able to release a snapshot, which seems to have proved to have been regression free (!). This is a testament to the amount of pre-release work that went into this update. - We are currently preparing the next update, based on Essex Stable, which will undergo the same level of care, and should hit a mirror near you in a timely manner. - For a *stable* release of both upstream, and the distribution platform.. I would consider 2 months between updates to be pretty good. Some distributions refuse this model for stable updates. 3. Is it 'production ready': - Marek seemed to think this was /too/ old. I'd like specific issues to be outlined, regarding the stable tree and our last update, which render the distribution packages unsuitable for production usage. If this cannot be done, please re-consider this statement. - To add to this, Canonical run a two-region hybrid cloud, which is purely based on the 12.04/Precise packages. I'd also like to take this opportunity to mention the effort that is going on for Folsom on 12.04. However, i'll cover this in a separate mail. -- Kind Regards, Dave Walker Engineering Manager, Ubuntu Server Infrastructure signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] PEP8 checks
On Mon, Jul 02, 2012 at 08:28:04AM -0400, Monty Taylor wrote: > > > On 07/02/2012 06:46 AM, John Garbutt wrote: > > Hi, > > > > I noticed I can now run the pep8 tests like this (taken from Jenkins job): > > tox -v -epep8 > > ... > > pep8: commands succeeded > > congratulations :) > > > > But the old way to run tests seems to fail: > > ./run-tests.sh -p > > ... > > File > > "/home/johngar/openstack/nova/.venv/local/lib/python2.7/site-packages/pep8.py", > > line 1220, in check_logical > > for result in self.run_check(check, argument_names): > > TypeError: 'NoneType' object is not iterable > > > > Is this expected? > > Did I just miss an email about this change? > > I cannot reproduce this on my system. Can you run > "bash -x run_tests.sh -p" and pastebin the output? Also, > tools/with_venv.sh pep8 --version just to be sure. > Hi, The issue is that as of a recent change to upstream pep8 [1], the additional pep8 rules in tools/hacking.py need to be changed from returns to yields.. :( [1] https://github.com/jcrocholl/pep8/commit/b9f72b16011aac981ce9e3a47fd0ffb1d3d2e085 Kind Regards, Dave Walker Engineering Manager, Ubuntu Server Infrastructure signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: Redux (Dubstep Remix)
Hi Jesse and Andy, Thanks muchly for outlining the reasoning and the direction. The vocal nature of this is more re-assuring. It seems like the it was a wise decision to start a fresh, based on the experiences of keystone v1. Initial impressions seem to be quite pleasing, thanks to all those who were involved. Kind Regards, Dave Walker Engineering Manager, Ubuntu Server Infrastructure On Tue, Feb 14, 2012 at 06:20:24PM -0800, Jesse Andrews wrote: > The major lessons of keystone: > > While keystone served as an effective proof of concept for unified > authentication (before keystone each component had its own > users/passwords), it didn't get enough attention from other developers and > integration with other core projects. > > The pain caused by not having shared authentication caused it to grow up > too fast. Keystone was in incubation during Diablo and is scheduled for > official core at the Essex release. > > Going forward when something is added to core we need to make sure it has > the project wide support necessary to present a consistent openstack during > the transition and afterwards. > > As an example, before quantum becomes a core project we are documenting > what becomes of Nova network and existing APIs. Glance integration into > nova was a good example where the image list API call proxies to glance. > > Additional if the code is vastly different, it is harder to get existing > contributors to participate. > > The original keystone team had a hard task and didn't get enough time and > help due to circumstances (some within their control and some not) > > Jesse > > > On Feb 14, 2012 5:53 PM, "Andy Smith" wrote: > > > > Hey there Joshua, > > > > Good question! `redux` started due to a variety of frustrations with the > previous design that arose from decisions made early in the original > development and were deemed infeasible to resolve in an evolutionary way. > > > > My team and the teams we work with closely felt we were in a good > position to re-imagine some of those decisions while still providing a > service that was functional (since we rely on it heavily for day to day > work) and robust. > > > > There will certainly be bugs introduced by this move, but we have an > extremely strong vested interest in fixing them rapidly and feel that the > new code base will greatly improve our ability to do so. > > > > --andy > > > > > > On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow > wrote: > >> > >> Great! > >> > >> A question I never understood, why was a redux needed? > >> Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo. > >> Was there some kind of “learnings/oops moment” that happened that we can > all benefit from (and not repeat?). > >> > >> Sorry if this is a repeat... > >> > >> > >> On 2/14/12 4:38 PM, "Andy Smith" wrote: > >> > >>> tl;dr proposal to merge keystone redux: same API, same client, new > service. Please review and ask questions! > >>> > >>> FRIENDS, ROMANS > >>> > >>> We are gathered here today to celebrate the commencement of Keystone > (redux) to fill the role of Keystone (henceforth known as legacy). It is > with great pride that we propose this stand-up-fellow of a refactor to join > the ranks of the other OpenStack projects. > >>> > >>> There will be differences, both in how you develop and how you use it, > though we've tried to keep those to a minimum (it has the same API, client, > and migration paths from existing deploys) > >>> > >>> You will notice that the code is organized rather differently in most > cases, though still in line with the general form of OpenStack projects, > and we use the standard tools and procedures you may be familiar with from > work on a project like Nova. (Your wrists will be shattered if you attempt > to use double quotes where single quotes might better suffice.) > >>> > >>> The bulk of the work put into `redux` has been to reduce the complexity > of and provide a more easily extensible version of `legacy` while still > providing the features that the other projects require. We think we have > been successful in this, and we hope you'll agree. > >>> > >>> Read on for more specifics. > >>> > >>> MERGE PROPOSAL: > >>> > >>> Please voice your comments & votes on the merge proposal: > >>> > >>> * > https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z > >>>
Re: [Openstack] Gating on deployment and integration tests for stable/diablo
Hi, Thanks for the update James. The Ubuntu project has also been setting up per-commit testing for both stable/* and trunk, where the cloud setup is achieved by juju using per-commit packages. I would quite like for this test run to initially be a post-commit blame alert requiring manual resolution, when confidence is provided around the validity of the test runs - i'm aiming to push for this to be an additional gate for stable/*. Thanks. Kind Regards, Dave Walker On Thu, Dec 08, 2011 at 02:12:24PM -0800, James E. Blair wrote: > Hi, > > A lot of people would like to see us with more commit gating jobs that > test functionality across the full range of core OpenStack projects. > We've made some progress in that direction, and I think we can start > some limited testing by turning on a gating job for the stable/diablo > branch of several projects. > > We have a job on Jenkins that creates a new VM, runs devstack on it, and > then exercise.sh: > > https://jenkins.openstack.org/job/dev-gate-integration-tests-devstack-vm/ > > It will eventually run the tempest test suite once it's ready. It is > triggered by gerrit changes to the following projects and branches: > > openstack/nova stable/diablo > openstack/glancestable/diablo > openstack/keyston stable/diablo > openstack/openstack-ci master > openstack/python-novaclient master > openstack-dev/devstack stable/diablo > > A change to any of those projects (on those branches) currently triggers > this job, in silent mode, which means it runs on the change before it's > merged into gerrit, but does not vote, and so can not reject the change. > This configuration has been running for a couple of weeks now. > > In general, it usually works, but we have seen a few failures, typically > either a failure to deploy a VM from the cloud provider or a part of the > install or setup process that hits the network and encounters a failure. > We'll continue to work on stabilizing it (volunteers welcome!) In the > mean time, it's fairly easy to retrigger the test in either jenkins or > gerrit. > > There are still a number of issues involved in turning this on for > trunk, not only related to stability and determinism, but also to > coordinating simultaneous changes to multiple projects. However, I > think this is reasonably stable and workable for the stable/diablo > branch. It will allow us to get some experience with a cross-project > integration test gating job without risking slowing down trunk > development too much. And it just might catch a bug. > > So unless anyone objects, I'd like to disable "silent mode" and make > this an actual gating job for stable/diablo. > > -Jim > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Stable branch reviews
On Thu, Nov 10, 2011 at 08:02:23AM -0800, James E. Blair wrote: > > > But wait! Vish +2ed a stable branch patch yesterday: > > > > https://review.openstack.org/328 > > > > James, help a poor confused soul out here, would you? :) > > > > Right, that makes sense. Only folks that understand the stable branch > > policy[1] should be allowed to +2 on the stable branch. > > > > Basically, a stable branch reviewer should only +2 if: > > > > - It fixes a significant issue, seen, or potentially seen, by someone > > during real life use > > > > - The fix, or equivalent, must be in master already > > > > - The fix was either a fairly trivial cherry-pick that looks > > equally correct for the stable branch, or that the fix has > > sufficient technical review (e.g. a +1 from another stable > > reviewer if it's fairly straightforward, or one or more +1s from > > folks on core it it's really gnarly) > > > > - If this reviewer proposed the patch originally, another stable > > branch reviewer should have +1ed it > > > > All we need is an understanding of the policy and reasonable judgement, > > it's not rocket science. I'd encourage folks to apply to the team for > > membership after reviewing a few patches. > > It sounds like the best way to implement this policy is to give > openstack-stable-maint exclusive approval authority on stable branches, > and then make sure people understand those rules when adding them to > that team. If that's the consensus, I can make the change. Hi, Thanks for helping to add clarification to this. From our perspective, I have confidence that ~*-core members know the difference between trunk and stable policy. Therefore for the short term, it makes sense to have more eyes - especially those which are likely to have good knowledge of the internals. Therefore, I am happy for ~*-core to still have +2 access; especially if it helps seed the maint team. Going forward, it probably will make sense to have a distinction, but I feel it might be quite early for that to be a requirement. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] ANN: (Unofficial) OpenStack Diablo packages for Ubuntu Oneiric
Inline also. On Tue, Oct 25, 2011 at 06:34:28PM +0100, Kiall Mac Innes wrote: > See inline. > > On Oct 25, 2011 10:24 a.m., "Dave Walker" wrote: > > > > Hi Kiall, > > > > This is great news that you are working on resolving Diablo issues on > > Oneiric. > > > > I'd like to question what gave you the impression Ubuntu were not > > working on post-release fixes for Oneiric? > > One of the names involved in lots of the Ubuntu cloud packages, and > OpenStack, mentioned it was unlikely Oneiric would see a fully working > stack.. > Can you point me to this discussion? It sound awfully like there has been some confusion.. Who was it that said this? > > > > I think it would be great if you were keen to work on the real archive > > packages, we'd certainly appreciate any additional hands. > > I actually tried that first, but became frustrated at bzr and > bzr-builddeb... I ended up switching back to my faithful git and > git-buildpackage! > > I was simply more interested in getting the packages working, rather than > learning another sparsely documented tool (I've done that once with > git-buildpkg, and bzr-builddeb seemed to have even less > documentation). $ bzr bd -S ; cd ../ ; dput *.change (or pbuilder/sbuild) -S means source package (more details below) > > > > > Nova has already had one update, waiting to migrate from the -proposed > > to the -updates pocket: > > https://launchpad.net/ubuntu/oneiric/+source/nova/2011.3-0ubuntu6.1 > > > > Keystone sql path fix is now in -proposed, and pending verification > > before moving to updates. > > > > Please do raise bugs for each specific issue that needs to be > > resolved, and myself (or my team) will gladly assist if necessary - > > including sponsoring of uploads. > > I'm happy to give bzr and bzr-builddeb another chance, if you can point me > to some documentation ;) TBH, a simple debdiff attached to the bug report might also be suitable. However, if you do want to look at doc's - perhaps this will help? http://developer.ubuntu.com/packaging/html/fixing-a-bug.html Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] ANN: (Unofficial) OpenStack Diablo packages for Ubuntu Oneiric
On Fri, Oct 21, 2011 at 08:58:16PM +0100, Kiall Mac Innes wrote: > Hiya, > > I've gone ahead and updated the OpenStack Ubuntu Oneiric packages to the > latest diablo/stable branches, Since it seems Ububtu won't be fixing > keystone any time soon :( > > So far, I have nova+glance+keystone+python-novaclient done .. dashboard up > next. Feedback is welcome :) > Hi Kiall, This is great news that you are working on resolving Diablo issues on Oneiric. I'd like to question what gave you the impression Ubuntu were not working on post-release fixes for Oneiric? I think it would be great if you were keen to work on the real archive packages, we'd certainly appreciate any additional hands. Nova has already had one update, waiting to migrate from the -proposed to the -updates pocket: https://launchpad.net/ubuntu/oneiric/+source/nova/2011.3-0ubuntu6.1 Keystone sql path fix is now in -proposed, and pending verification before moving to updates. Please do raise bugs for each specific issue that needs to be resolved, and myself (or my team) will gladly assist if necessary - including sponsoring of uploads. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Git repository for packaging
On Thu, Oct 20, 2011 at 03:06:53PM +0800, Thomas Goirand wrote: > Hi, > > I've found my way through https://github.com/openstack, and I'm happy to > see that mostly everything is there now. However, I've found still missing: > > - python-novaclient > - the debian folder for packaging files (there's no branch for that either) > > Is there any plan to fix this? I'm not sure this is a core project as yet. Currently it's developed on https://github.com/rackspace/python-novaclient . > > Also, I've seen numerous patches in debian/patches in the Ubuntu > package. Why aren't these sent to the "upstream" github diablo branch? > Seriously? All the patches have been submitted or landed in trunk. diablo-stable only opened for business yesterday. Some have landed which were the same patches that markmc identified. Give us a chance, please. You are also welcome to propose these patches if it is blocking you. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [RFC] Stable branch
On Wed, Oct 12, 2011 at 04:58:58PM +0100, Mark McLoughlin wrote: > Hey, > > I've posted a proposal for how the stable branch could work here: > > http://wiki.openstack.org/StableBranch Hi Mark, Firstly, apologies for not replying to this sooner. Next, I'd like to thank you for taking the initiative in getting this moving. Generally, the whole proposal on the wiki page is pretty sane. I do have two comments. "The stable branch will only be maintained until the next release is out." - Does this explicitly need stating? If contributors want to continue to propose changes to this for a longer term, is this a problem? I see it that the branch will naturally stop being maintained as contributors lose interest? "Security patches".. This procedure needs better expansion, with how the stable team work with new (has it arrived yet?), security team. In addition, i've reviewed there proposals you have pushed to Gerrit.. and jenkins seems to be doing the right thing! It seems to be working \o/. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova trunk will require a new dependency: kombu
On Wed, Aug 31, 2011 at 08:36:27PM +, Chris Behrens wrote: > > This email wasn't sent sooner, because there was an assumption that since > glance already depended on kombu.. and that nova depends on glance... that > kombu is already a required dependency for nova. However, this must not be > completely true because we just got a merge failure because of kombu not > installed for this: > Thanks for resolving this, and letting us know! Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Where to find the Debian packaging for nova/swift/glance
On Tue, Aug 23, 2011 at 09:09:46AM -0700, Monty Taylor wrote: > Hi Thomas! > > Packaging for nova is _currently_ (like, this morning) on launchpad - as > is all of nova dev. (this will be changing soon) However, we do not keep > packaging in the upstream source tree. > > However, I'm working on rolling out an all new and improved packaging > tooling that should make it easier for you to collaborate with us > (git-buildpackage is certainly involved- as are builds for debian hosts) > > Gimme, like, 4 more hours and I'll have something to point you at as far > as that goes. > > However, in the mean time, packaging can be found at: > > lp:~openstack-ubuntu-packagers/nova/ubuntu > > Monty Hi Monty, This change has come to a complete surprise to us, when was this planned and what work is going into this? Having spent quite some time ensuring we had good collaboration on the packaging, with agreed processes - this seems to be different to what we were expecting. Please can you confirm the current plan, or point me to the blueprint or wiki page where this was planned so I can catch up. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu Cloud Days
On 06/07/11 21:11, Thomas Goirand wrote: >> Thanks a lot Thierry and Soren! It's a pleasure to have you at UCD. May >> I ask you to please pick your preferred time slot at >> https://wiki.ubuntu.com/UbuntuCloudDays/Timetable as soon as possible. >> If unsure what you'll be presenting, just write TBD. Thanks > May I ask why you decided to make an Ubuntu event in the middle of > Debconf11? > > Thomas Hi Thomas, Thanks for raising this. I don't think it was intentional to schedule a Ubuntu online event during Debconf11. This is one of the many online events held through the Ubuntu development cycle. Some of the others include Ubuntu User Days, Ubuntu Developer Week and Ubuntu Open Week. Whilst unfortunate, I think it is inevitable that some of these events will clash with other events. Note, that I wasn't able to attend the Openstack Summit this time, because it clashed with Ubuntu release week. The good news is that the sessions are logged for later usage, and they are held suitably regularly enough that others, who wanted to, but could not attend this specific one; are able to attend. Kind Regards, Dave Walker ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: Bug#631834: python-novaclient and simh: error when trying to install together
On 06/07/11 21:09, Thomas Goirand wrote: > > Seems that this issue solved itself, as the latest upload of simh in > Debian fixes the conflicting files. I don't know the status in Ubuntu. > > Has the "st" issue of swift conflicting with suckless-tools been > addressed already? > > Thomas Hi Thomas, Ubuntu is still carrying simh 3.8.1-2, which means that it isn't yet resolved in Ubuntu. At the time of writing, it seems the 3.8.1-3 package which contains the fix hasn't yet been published in Debian. As this package is untouched in Ubuntu, it will be automatically sync'd across when it is published. Thanks! Kind Regards, Dave Walker ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Project Alignment
On 16/05/11 21:06, Brian Lamar wrote: Dave, While I'm not Vish, I have been working on/around authentication for the past couple weeks and I'll provide my thoughts. EC2 and OpenStack Nova APIs should not be affected by the authentication work going on. The Keystone project is the only candidate I'm aware of, and it seems like it is, or soon will be, a good candidate for integration into the stack. Migration to a separate authentication service is going to be tricky, but the goal is to do it as seamlessly as possible. "Near stable" should be able to be promised. This is the phased approach myself and Brian Waldon have been playing around with: http://wiki.openstack.org/Nova/AuthManagerSpec Keystone should be able to provide the features of IAM. I'm not able to find the PTL meeting logs, perhaps a #startmeeting was never issued for it? I was eavesdropping at the time but can't find the logs, perhaps someone can find them or send them out. The meeting I'm refering to was right after this: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-10-21.01.log.html Thanks Vish and Brian for your replies, it makes more sense now. I did find the meeting in my IRC logs here: http://pb.daviey.com/U0db/ Thanks again. Kind Regards, Dave Walker ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Project Alignment
On 16/05/11 21:06, Brian Lamar wrote: Dave, While I'm not Vish, I have been working on/around authentication for the past couple weeks and I'll provide my thoughts. EC2 and OpenStack Nova APIs should not be affected by the authentication work going on. The Keystone project is the only candidate I'm aware of, and it seems like it is, or soon will be, a good candidate for integration into the stack. Migration to a separate authentication service is going to be tricky, but the goal is to do it as seamlessly as possible. "Near stable" should be able to be promised. This is the phased approach myself and Brian Waldon have been playing around with: http://wiki.openstack.org/Nova/AuthManagerSpec Keystone should be able to provide the features of IAM. I'm not able to find the PTL meeting logs, perhaps a #startmeeting was never issued for it? I was eavesdropping at the time but can't find the logs, perhaps someone can find them or send them out. The meeting I'm refering to was right after this: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-10-21.01.log.html Thanks Vish and Brian for your replies, it makes more sense now. I did find the meeting in my IRC logs here: http://pb.daviey.com/U0db/ Kind Regards, Dave Walker ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Project Alignment
On 16/05/11 18:11, Vishvananda Ishaya wrote: Hello Everyone, The PTLs had a quick meeting the other day to try and align some things between the projects. In order for openstack to be successful, it is very important that we create a consistent user experience for users and administrators. We realize that it is hard to find agreement between all developers on implementation details, so we focused less on the idea of code-sharing and more on the idea of bringing the user-experience into alignment. If we are going to be successful in this effort, we all need to realize that we should value doing things the same way over doing things the best way. We have a few actions that we are taking to help move in this direction. 1. Consistent Auth -- all of the projects are working on integrating the keystone project so that we have one auth system. For nova, this means that we may lose some of the rbac features we provide for the ec2 api, but by the diablo release we expect to have equivalent features and a migration plan for cactus deployments. Hi Vish, This is really useful to know, thank you for the highlevel outline. I didn't quite understand the "Consistent Auth", and what it means for ec2 api for the Diablo release. Would you be able to confirm the extent / roadmap of the ec2 api breakage expected? Are you expecting the base ec2 api functionality to be near stable throughout the transition, or are you expecting large breakage? In regards to the loss of RBAC, is this expected to be transitional; and be fixable in time for Diabalo release? Essentially, can you clarify "equivalent features". The blueprint[0] or specification on the wiki[1] doesn't seem to mention "ec2' anywhere, can you confirm where this was discussed? I'd also like to check if consideration on how this might impact possible future implementation of comparative feature of AWS Identity and Access Management (IAM)[2] support in both ec2 and openstack API was discussed? Additionally, are the logs of the PTL's meeting available anywhere? Thanks. [0] https://blueprints.launchpad.net/nova/+spec/integrate-nova-authn [1] http://wiki.openstack.org/openstack-authn [2] http://aws.amazon.com/documentation/iam/ Kind Regards, Dave Walker ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
