Re: [Openstack] [Keystone] PKI
If you're open to levarging other OSS projects, http://www.ejbca.org/architecture.html us a great one to look at, assuming you need a PKI implementation available. I believe it is at least worth a look. On Tue, May 15, 2012 at 1:30 PM, Razique Mahroua wrote: > great topic :) > > > Joseph Heck > 15 mai 2012 21:06 > Coming out of the Keystone meeting from today ( > http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-15-18.02.html), > I thought it worth mentioning that adam young has been doing some > tremendous lifting in terms of looking at adding in PKI support to > Keystone. The writeup and details are on the OpenStack wiki at > http://wiki.openstack.org/PKI > > I rather suspect there's a lot of interest in this topic, so I wanted to > make sure the broader community knew about the effort, what we were > thinking, and were we are. > > If you're interested in discussing, the keystone meeting is on Tuesday > mornings at 18:00 UTC > > -joe > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > -- > Nuage & Co - Razique Mahroua > razique.mahr...@gmail.com > > > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > ___ 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] OpenStack Academic Alliance|Circle|Initiative #unconference
I see very little under Mendeley on OpenStack. Linking these two up may help in this area. Also, anyone have ins at Internet2? Seems like it would be a good fit. verba volant, scripta manent Sent from my cloud edge device On 2011-10-13, at 5:49 AM, Prem Sankar G wrote: > Hi, > This is a great idea. I feel this would create a good Openstack ecosystem. > Count me in as co-ordinator. > Regards, > Prem > > On Tue, Oct 11, 2011 at 9:34 PM, Stefano Maffulli > wrote: > hello folks, > > a group of people interested in academia met in Boston during the > unconference. I was there to take notes and facilitate this community > run initiative. Here is what we agreed so far. I'm sharing it on the > list to gather more ideas. > > /stef > > OpenStack Academic Initiative > > Mission: > > * provide a place for all research academics efforts can be >advertised and found, about and around OpenStack (not generic >about IaaS or PaaS) > * a list of papers published and ongoing research > * a list of conferences about cloud > * maintain a list of ideas for the companies to sponsor research >like a "market" > * a place for the companies to say what they need and research can >execute > * undergrad level, gsoc-style, time starved but there are >many of them. it's important to be easy for them to >contribute > * masters level, more in depth work, empirical studies >like performance evaluation > * phd level, exploratory type of research > * handle the funding, hr tasks, mentoring: who's going to manage >this? > * mentoring is intense and time consuming, but crucial for >the success of research > * provide resources, like hardware for tests, for researchers > * advertise this initiative among researchers > * Example: setup OpenStack tracks at a couple of relevant >conference > > > Next steps: Identify the group responsible for this initiative and > define action items, deadlines and deliverables. > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp ___ 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] API Spec
I'm a huge fan of Peter Coad in the area of software architecture. One of the largest hurdles to overcome is the separation between code & design. The larger the gap, the more they diverge and the greater the inconsistencies become. Many tools (like xdoclet, Together, etc.) have focused on keeping the code and design better in sync. There are some projects that do a very good job of having core documentation in the code (Cocoon) and others that have had it much more separated (Jini / River). The one thing that I have seen more common in having far separated design docs, is that most current ones have reference systems that are taken as the correct implementation and still override the docs. As we don't have a "reference implementation" to point to, I think keeping the core spec in the code is better, but it will require more adherence to a design pattern that can pull quality documentation from the code base. Leveling that documentation is hard though, but seems to be quite worth it. Thor HW On Sat, Aug 27, 2011 at 6:44 PM, George Reese wrote: > I don't necessarily agree with that approach. I'm not sure if that's the way > AWS does things or not, but you will note that the AWS APIs are very > fragmented across projects. > I think there are several principles that may at times be in conflict that > need to be in place: > * Any GA feature should be exposed via API at the time of its GA-ness. > * There needs to be a "gatekeeper" (possibly the wrong word) ensuring that > the APIs are self-consistent > > > And the understanding should exist that modeling something for functionality > may not be the same as the way it is modeled in the API. In fact, the > underlying model will likely be refactored many times by the API must be > timeless (but evolvable). > -George > On Aug 28, 2011, at 2:29 AM, Jonathan Bryce wrote: > > This is on the agenda for Tuesday's policy board meeting (in > #openstack-meeting 1 hour before the weekly OpenStack team meeting for those > interested). Sounds like a potentially acceptable solution is to set some > cross-project API standards and then push the remainder of the API > definition and implementation into each project. Then the API can progress > with the underlying project's features as the developers see fit. > Jonathan. > > On Aug 27, 2011, at 4:16 PM, Tim Bell wrote: > > I have an api, diablo nova v1.1. > > What we are talking about is if it covers 100% functionality. > > I can start my deployment testing with v1.1. The limiting factor is not > v1.1 vs v1.x for most sites. It is packaging, user exits and integration, > not whether feature X is in the latest API. > > Tim. > > - Reply message - > From: "George Reese" > To: "Tim Bell" > Cc: "openstack@lists.launchpad.net" > Subject: [Openstack] API Spec > Date: Sat, Aug 27, 2011 20:47 > > > > A cloud platform simply isn't functional without an API. It is a core > requirement. > > No API, no cloud. > > -George > > On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: > >> I'm also a non-API expert but getting a stable open cloud engine with a >> reasonable API would seem to be a good target before we look to enhance it. >> >> There are lots of potential users of Nova (including Rackspace) who would >> like to get Nova into production. An API will fully exploits all of the >> underlying functionality should be discussed/planned in the longer term but >> let's get Diablo out and deployable first. >> >> Tim Bell >> CERN >> >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > -- > George Reese - Chief Technology Officer, enStratus > e: george.re...@enstratus.com t: @GeorgeReese p: +1.207.956.0217 f: > +1.612.338.5041 > enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus > - http://www.enstratus.com > To schedule a meeting with me: http://tungle.me/GeorgeReese > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- > George Reese - Chief Technology Officer, enStratus > e: george.re...@enstratus.com t: @GeorgeReese p: +1.207.956.0217 f: > +1.612.338.5041 > enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus > - http://www.enstratus.com > To schedule a meeting with me: http://tungle.me/GeorgeReese > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@list
Re: [Openstack] API Spec
That sounds fair. I listened to Linus talk about a similar thing when in the early days they tried to pack in features, and only later started to try and constrain what got into the "core". There was some interesting debate about the new features as they often didn't know how they would be best used and grow until after people started using them. As such they looked to try and maintain backwards compatibility as best they could until people had enough warning to migrate (measured in years). Sounds like a similar dilemma to me. Thor HW On Mon, Aug 22, 2011 at 9:49 PM, Jorge Williams wrote: > > I say we up the version number when we can't ensure backward compatibility. > As to how long older versions should be supported. Hard to say. It depends > on a lot of factors, and at the end of the day it may come up to how popular > a version is and how willing and able operators and client devs are to > upgrading. > > -jOrGe W. > > > On Aug 22, 2011, at 8:49 PM, Thor Wolpert wrote: > >> I agree the Specs shouldn't change often ... but just to use your >> examples, they where all simplifications of larger specs that took >> years to create. >> >> If an API changes and is deprecated, how long does backwards >> compatibility stay in place? >> >> Thanks, >> Thor W >> >> On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake wrote: >>> +1 >>> >>> >>> >>> >>> On Aug 22, 2011, at 5:06 PM, Jay Pipes wrote: >>> >>>> ++ >>>> >>>> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams >>>> wrote: >>>>> Hi Vish, >>>>> I don't have a problem moving the spec out of docs manuals and into >>>>> another >>>>> project even the nova repo. But, I do have a number of issues with the >>>>> approach that you're proposing. First, I think that fundamentally there >>>>> should be a decoupling of the spec and the implementation. If you have >>>>> the >>>>> spec generated from the code than essentially the spec is whatever the >>>>> code >>>>> does. It's very difficult to interoperate with specs that are generated >>>>> this >>>>> way as the specs tend to be very brittle and opaque (since you have to >>>>> study >>>>> the code). If you introduce a bug in the code that bug filters it's way >>>>> all >>>>> the way to the spec (this was a big problem with SOAP and CORBA). It's >>>>> difficult to detect errors because you cant validate. By keeping the >>>>> implementation and the spec separate you can validate one against the >>>>> other. >>>>> >>>>> Second, I don't think that the core OpenStack API should change with every >>>>> OpenStack release. There are a number of efforts to provide multiple >>>>> implementation of an existing OpenStack API. We should encourage this, >>>>> but >>>>> it becomes difficult if the core spec is in constant flux. Certainly you >>>>> can use the extension mechanism to bring functionality out to market >>>>> quickly, but the process of deciding what goes into the core should be >>>>> more >>>>> deliberate. Really good specs, shouldn't need to change very often, think >>>>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for >>>>> our >>>>> spec and we need to also encourage other implementors to write >>>>> implementations for it. These efforts become very difficult if the spec is >>>>> in constant flux. >>>>> -jOrGe W. >>>>> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote: >>>>> >>>>> Hey Everyone, >>>>> We discussed at the Diablo design summit having API spec changes be >>>>> proposed >>>>> along with code changes and reviewed according to the merge process that >>>>> we >>>>> use for code. This has been impossible up until now because the canonical >>>>> spec has been in the openstack-manuals project. >>>>> My suggestion is that we move the openstack-compute spec into the nova >>>>> source tree. During a six-month release we can propose changes to the >>>>> spec >>>>> by proposing along with the code that changes it. In the final freeze for >>>>> the release, we can incremen
Re: [Openstack] API Spec
I agree the Specs shouldn't change often ... but just to use your examples, they where all simplifications of larger specs that took years to create. If an API changes and is deprecated, how long does backwards compatibility stay in place? Thanks, Thor W On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake wrote: > +1 > > > > > On Aug 22, 2011, at 5:06 PM, Jay Pipes wrote: > >> ++ >> >> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams >> wrote: >>> Hi Vish, >>> I don't have a problem moving the spec out of docs manuals and into another >>> project even the nova repo. But, I do have a number of issues with the >>> approach that you're proposing. First, I think that fundamentally there >>> should be a decoupling of the spec and the implementation. If you have the >>> spec generated from the code than essentially the spec is whatever the code >>> does. It's very difficult to interoperate with specs that are generated this >>> way as the specs tend to be very brittle and opaque (since you have to study >>> the code). If you introduce a bug in the code that bug filters it's way all >>> the way to the spec (this was a big problem with SOAP and CORBA). It's >>> difficult to detect errors because you cant validate. By keeping the >>> implementation and the spec separate you can validate one against the other. >>> >>> Second, I don't think that the core OpenStack API should change with every >>> OpenStack release. There are a number of efforts to provide multiple >>> implementation of an existing OpenStack API. We should encourage this, but >>> it becomes difficult if the core spec is in constant flux. Certainly you >>> can use the extension mechanism to bring functionality out to market >>> quickly, but the process of deciding what goes into the core should be more >>> deliberate. Really good specs, shouldn't need to change very often, think >>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our >>> spec and we need to also encourage other implementors to write >>> implementations for it. These efforts become very difficult if the spec is >>> in constant flux. >>> -jOrGe W. >>> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote: >>> >>> Hey Everyone, >>> We discussed at the Diablo design summit having API spec changes be proposed >>> along with code changes and reviewed according to the merge process that we >>> use for code. This has been impossible up until now because the canonical >>> spec has been in the openstack-manuals project. >>> My suggestion is that we move the openstack-compute spec into the nova >>> source tree. During a six-month release we can propose changes to the spec >>> by proposing along with the code that changes it. In the final freeze for >>> the release, we can increment the spec version number and copy the current >>> version of the spec into openstack-manuals and that will be the locked down >>> spec for that release. >>> This means that openstack 1.1 will be the official spec for diablo, at which >>> point we will start working on a new api (we can call it 1.2 but it might be >>> best to use a temporary name like 'latest') during the essex release cycle, >>> then at essex release we lock the spec down and it becomes the new version >>> of the openstack api. >>> Ultimately I would like the spec to be generated from the code, but as a >>> first pass, we should at least be able to edit the future version of the >>> spec as we make changes. I've proposed the current version of the spec >>> here: >>> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506 >>> Are there any issues with this approach? >>> Vish >>> >>> This email may include confidential information. If you received it in >>> error, please delete it. >>> ___ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > ___ 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] about vlan and switch
That was a great explanation, thanks! There is also a limit of 12 bits in the 802.1Q protocol, effectively setting the max to 4096 vlans I so look forward to having that kind of problem :)! On Wed, Jul 20, 2011 at 9:26 PM, Jeff Kramer wrote: > As I understand it, you can setup the tags in the switch first if you > want, but you don't need to. You will create VLAN tags in the Nova > database as you create networks with 'nova-manage network create ...', > and those will be assigned to users on a first-come first-serve basis. > When a user creates their first node nova assigns them an unused > network which has a unique VLAN tag. This tag is passed to > nova-compute when your instance is started, and it feeds that VLAN tag > into KVM which uses it for all network traffic in a way that's > transparent to the guest OS. When the guest talks to the network it > uses that VLAN tag, which the nova-network node is also listening on. > > As long as your switch supports host-tagged VLANs (802.1Q), you don't > have to create the tags in the switch before you use them. You could > setup all your VLANs before, someone else may have more experience > with that. > > One wrinkle is that many switches have a set number of tagged VLANs > they can support, for instance the HP V1810-24G switch that I'm using > supports 64 tagged VLANs, which means my Nova cluster can only have 64 > different networks (or 64 different users). The next model up > supports 256, etc. I assume that if you go over this number your > network traffic will start dropping and weird things will happen. > > Your switch's management IPs should probably be in an address space > that doesn't conflict with what you're assigning with nova. If you're > using 10.x.x.x for Nova you could put the switch on 192.168.x.x. You > probably shouldn't be touching the switch from a Nova guest, since the > time you'll want to be fiddling with it will be when your Nova cluster > is crashing or otherwise broken. > > > On Wed, Jul 20, 2011 at 10:43 PM, tianyi wang wrote: > > Hi, all > > > > > > If use VLAN mode, it's need setting VLAN in switch's NOS first? > > And then the setting VLAN in nova controller node? > > > > Now, the switch's IP is 192.168.0.234 and the gateway ip address is > > 192.168.0.1 ( in switch web management interface), should I change the > > switch IP and gateway to 10.0.0.x ? > > > > In VLAN mode, what's the relationship tween the controller node's VLAN > > management and switch's NOS VLAN management? > > > > thanks > > > > > > alex > > > > ___ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Jeff Kramer > jeffkra...@gmail.com > http://www.jeffkramer.org/ > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > ___ 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] OpenStack Identity: Keystone API Proposal
Any thoughts on pulling in OpenDS or OpenLDAP? A plus for OpenDS is it'a already integrated with OpenAM and could supply federated logins if so desired. I have that need. On Sat, Jul 16, 2011 at 3:56 PM, Ziad Sawalha wrote: > Whatever name a container for global objects has - or if one or more even > exist – is only relevant to a specific implementation and not canonical. It > fits better as a configuration than as a core part of the API or code. Even > in the same LDAP system, an operator may have their own unique > implementation. Take, as an example, Active Directory with it's default > setup. Some enterprises may use the BuiltIn container where 'global' > entities live. Others may use the Users container. And some may create their > own containers or OU. Some may want to map role assignments to group > membership in certain groups (ex. If a user is a member of Domain Admins, > have Keystone report them as having the keystone:admin role). > > I posit that a construct like a 'global' tenant is artificial and not > driven from a generic, canonical use case. It is actually not a tenant. > And by adopting it we assume the risk of a collision with a backend that > defines a 'global' tenant with a different semantic and we don't get much > return for that risk. > > I agree we should provide an out-of-the-box reference implementation, but > we should keep Keystone acting as a metasystem that allows mapping the > OpenStack use cases back to any operator implementation. > > Look for an an LDAP implementation to come very soon … and we should pick > the thread back up with more concrete examples? > > Kind regards, > Z > > > From: Thor Wolpert > Date: Wed, 13 Jul 2011 17:17:03 -0700 > To: Ziad Sawalha > Cc: Jay Pipes , Bryan Taylor , > "openstack@lists.launchpad.net" > Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal > > If they had called it "global" or some other container name, would you be > happier with that? If you're trying to leverage some LDAP style framework, > then you'd always want users in some container instead of at the raw root. > > Maybe some guidance or default schema would help those groups out? > > > On Wed, Jul 13, 2011 at 2:12 PM, Ziad Sawalha > wrote: > >> And some current Nova users have created 'dummy' tenants to house global >> users. That's ugly and hard to maintain, so we wanted to avoid 'dummy' >> tenant solutions if possible. Given we're creating the spec right here and >> now, we can do that :-) >> >> >> >> On 7/13/11 12:14 PM, "Jay Pipes" wrote: >> >> >On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor >> >wrote: >> >> How is this different in effect than letting swift or nova be tenants? >> >>Each >> >> tenant gets to define users, roles, and groups, right? >> > >> >A service can have multiple tenants. For instance, an installation of >> >Nova might have a RAX tenant and a RAX-INTERNAL tenant, both of which >> >can create users and roles separately. Keystone can manage these sets >> >of users independently, but when the Nova service requests information >> >from Keystone, supplying the tenant and user, which depending on the >> >information stored in Keystone, could return different role/group >> >infomation. >> > >> >-jay >> > >> >___ >> >Mailing list: https://launchpad.net/~openstack >> >Post to : openstack@lists.launchpad.net >> >Unsubscribe : https://launchpad.net/~openstack >> >More help : https://help.launchpad.net/ListHelp >> >> This email may include confidential information. If you received it in >> error, please delete it. >> >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > This email may include confidential information. If you received it in > error, please delete it. > ___ 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] OpenStack Identity: Keystone API Proposal
If they had called it "global" or some other container name, would you be happier with that? If you're trying to leverage some LDAP style framework, then you'd always want users in some container instead of at the raw root. Maybe some guidance or default schema would help those groups out? On Wed, Jul 13, 2011 at 2:12 PM, Ziad Sawalha wrote: > And some current Nova users have created 'dummy' tenants to house global > users. That's ugly and hard to maintain, so we wanted to avoid 'dummy' > tenant solutions if possible. Given we're creating the spec right here and > now, we can do that :-) > > > > On 7/13/11 12:14 PM, "Jay Pipes" wrote: > > >On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor > >wrote: > >> How is this different in effect than letting swift or nova be tenants? > >>Each > >> tenant gets to define users, roles, and groups, right? > > > >A service can have multiple tenants. For instance, an installation of > >Nova might have a RAX tenant and a RAX-INTERNAL tenant, both of which > >can create users and roles separately. Keystone can manage these sets > >of users independently, but when the Nova service requests information > >from Keystone, supplying the tenant and user, which depending on the > >information stored in Keystone, could return different role/group > >infomation. > > > >-jay > > > >___ > >Mailing list: https://launchpad.net/~openstack > >Post to : openstack@lists.launchpad.net > >Unsubscribe : https://launchpad.net/~openstack > >More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in > error, please delete it. > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
