Re: [Openstack] POC for Pluggable Network Service
Hi Ryu, I appreciate your feedbacks to my design. And we welcome your contributes to this project. I created a new LaunchPad team ~nova-network-poc and invited your team ~midokura to it. Please approve this invitation, then you can commit to lp:~nova-network-poc/nova/network-service, which is the branch of lp:~ntt-pf-lab/nova/network-service. Thanks, Hisaharu Ishii (2011/04/01 11:34), Ishimoto, Ryu wrote: Hi Hisaharu, Great to see some action happening on the topic of network service! Thanks for creating this detailed spec! We, at Midokura, would love to contribute to this project. I took a look at the code and noticed a few things: - You have started the merging of flat, flat_dhcp and vlan plugins into one, which we think is a good decision. We can continue on with creating a new plugin ourselves. - Database models and APIs seem to have gone through some makeover with a use of DAO classes, which we also think is great. One thing we want to contribute is to remove the authentication code from db/sqlalchemy module altogether and move it to db/api.py. Please let us know how we can start making commits to this project. If it's ok that we commit directly to this branch, we will send you our public keys. Thanks, Ryu 2011/4/1 Dan Wendlandtd...@nicira.com I second the comment about a great spec. I look forward to poking at this and working with you to incorporate feedback. After a quick pass, I think the work we have done with the network-service should play well within your model. Dan 2011/3/31 Jay Pipesjaypi...@gmail.com Just wanted to say thank you for putting together an excellent spec document. Thanks, jay 2011/3/31 石井 久治ishii.hisah...@lab.ntt.co.jp: Hi Everyone, I have implemented a POC code for Pluggable Network Service at lp:~ntt-pf-lab/nova/network-service. And wrote the document of it http://wiki.openstack.org/NetworkServicePOC This document outlines the new network architecture for Nova that I would like to propose for the Diablo release. This is just a first draft, so I would love to get some feedbacks from the community to discuss and improve it. And hopefully attract some willing participants as well! Thanks, Hisaharu Ishii ___ 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 -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org cell: 650-906-2650 ~~~ ___ 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] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus
Gabe Westmaas wrote: Given this, what makes the most sense to me is to focus on stability for version 1.0 API excluding XML support. The bindings that are out there have strong support for the JSON data formats in v1.0. As suggested, I think we call the current mostly implemented 1.1 API experimental so as to give access to any features that we need that are only in 1.1. Makes sense for me as well. Since we know we won't reach 100%, we should definitely stop to work on feature gap bugs to concentrate on stability for what's already in. NB: It's sometimes difficult in bug triaging to determine which bugs would belong to this stability category: don't hesitate to mention stability for 1.0 API in the description somewhere (or ping me) so that their importance can be set accordingly. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] POC for Pluggable Network Service
Hi Hisaharu, Ah, sorry we actually already created our own branch: lp: ~midokura/nova/network-servicehttps://code.launchpad.net/~midokura/nova/network-service. We'll be committing our stuff there. Thanks! Ryu 2011/4/1 石井 久治 ishii.hisah...@lab.ntt.co.jp Hi Ryu, I appreciate your feedbacks to my design. And we welcome your contributes to this project. I created a new LaunchPad team ~nova-network-poc and invited your team ~midokura to it. Please approve this invitation, then you can commit to lp:~nova-network-poc/nova/network-service, which is the branch of lp:~ntt-pf-lab/nova/network-service. Thanks, Hisaharu Ishii (2011/04/01 11:34), Ishimoto, Ryu wrote: Hi Hisaharu, Great to see some action happening on the topic of network service! Thanks for creating this detailed spec! We, at Midokura, would love to contribute to this project. I took a look at the code and noticed a few things: - You have started the merging of flat, flat_dhcp and vlan plugins into one, which we think is a good decision. We can continue on with creating a new plugin ourselves. - Database models and APIs seem to have gone through some makeover with a use of DAO classes, which we also think is great. One thing we want to contribute is to remove the authentication code from db/sqlalchemy module altogether and move it to db/api.py. Please let us know how we can start making commits to this project. If it's ok that we commit directly to this branch, we will send you our public keys. Thanks, Ryu 2011/4/1 Dan Wendlandtd...@nicira.com I second the comment about a great spec. I look forward to poking at this and working with you to incorporate feedback. After a quick pass, I think the work we have done with the network-service should play well within your model. Dan 2011/3/31 Jay Pipesjaypi...@gmail.com Just wanted to say thank you for putting together an excellent spec document. Thanks, jay 2011/3/31 石井 久治ishii.hisah...@lab.ntt.co.jp: Hi Everyone, I have implemented a POC code for Pluggable Network Service at lp:~ntt-pf-lab/nova/network-service. And wrote the document of it http://wiki.openstack.org/NetworkServicePOC This document outlines the new network architecture for Nova that I would like to propose for the Diablo release. This is just a first draft, so I would love to get some feedbacks from the community to discuss and improve it. And hopefully attract some willing participants as well! Thanks, Hisaharu Ishii ___ 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 -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org cell: 650-906-2650 ~~~ ___ 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] Feature Freeze status
On Thu, 31 Mar 2011 10:02:34 +0200 Soren Hansen so...@openstack.org wrote: 2011/3/31 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: Sounds like the importance of blueprints is overrated. If you look at Linux kernel development (more than ten times developers and development speed, I guess), The Linux kernel development process uses a number of other approaches to deal with its volume. There a number of different staging trees. There are topic-based ones, like the one for people working on 'topic-based' is one of ways to manage a git tree so it's unrelated with this top but as you said, the patch acceptance load is distributed across a number of lieutenants. If there are more than 1,000 developers, you need to do that, I think. I expect OpenStack will need to do the similar with developers increased. You don't? you see that lots of developers can work well without something like blueprints. Just so we're clear: Linux has merge windows as well. New features simply do not get to go into mainline outside of these merge windows. Yeah, but you can propose new features (patches) any time. It's not uncommon for changes to take several kernel releases from being proposed until they're actually accepted into the tree. Also, noone promises that your stuff will get reviewed. Ever. We do. If you propose stuff in time, we promise it will at least be reviewed once before feature freeze. Hmm, that 'promise' works (and will work in the future)? I already saw the shortage of reviewing (and I even saw that a half-baked feature without enough reviewed was merged and reverted). I bet that we'll face more serious shortage of reviewing with developers increasing. In genera, developers prefer to write own code rather than reviewing. We can't change the nature. I think that there is no such 'promise' for reviewing in a large OSS. If your code can't get enough reviewers, your code might be not useful enough for the project. It's sorta evolutionary theory. The better code has the better chance to be merged quickly. The features are prioritized fairly. I don't think that openness and transparency are not related with blueprints. You can simply discuss, make a decision, etc on public mailing lists. That's merely transposing the exact same process, isn't it? If the goal is to have features described, whether you have to type it in one place or another shouldn't matter much. What does matter, though, is tracking. I think it's common consensus that mailing lists make *dreadful* bug trackers. I'm not sure I understand why it would be much better for tracking blueprints or whatever you'd call them in that context? Oops, I didn't mean that. I just meant that you can achieve openness and transparency without blueprints. I read some arguments in this thread, something like blueprints is a must for openness and transparency. ___ 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] Feature Freeze status
On Fri, Apr 1, 2011 at 8:41 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: I bet that we'll face more serious shortage of reviewing with developers increasing. In genera, developers prefer to write own code rather than reviewing. We can't change the nature. Yes, this is certainly true. I'm hoping that the PTL(s) will help give some stability to the current process. I think that there is no such 'promise' for reviewing in a large OSS. If your code can't get enough reviewers, your code might be not useful enough for the project. It's sorta evolutionary theory. The better code has the better chance to be merged quickly. The features are prioritized fairly. Hmm, I disagree. What is actually more likely is that the clique of developers that the proposing author is friendly/familiar will review their merge proposal before other ones. It's not really about good code versus bad code. Again, it's about prioritizing the reviews for folks that follow the procedures the community has agreed on. If the community wants to change the procedures that it has agreed on, it should do so at the next summit. I *think* that's what Vishy was saying and that I agree with. -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
[Openstack] heterogeneous instance types
I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes They could use some reviews in advance of the design summit. At our internal sprint review this week, we were able to launch in a multi-node configuration a 64-core 128GB virtual machine on our SGI UV100 (check out /proc/cpuinfo and /proc/meminfo below :-), a cg1.4xlarge with Nvidia S2050 GPU attached (currently using the gVirtuS driver), and a Tilera TileEmpower TilePro 64-core (8x8) system. We're going to start posting some of our results out on to the openstack wiki, but hopefully for Diablo, we will no longer need a homogeneous cloud infrastructure. Brian --- bespin:/tmp/openstack-demo # more nova/bin/nova.conf --verbose --nodaemon --dhcpbridge_flagfile=/tmp/openstack-demo/nova/bin/nova.conf --dhcpbridge=/tmp/openstack-demo/nova/bin/nova-dhcpbridge --cc_host=10.9.1.1 --s3_host=10.9.1.1 --ec2_url=http://10.9.1.1:8773/services/Cloud --rabbit_host=10.9.1.1 --sql_connection=mysql://root:nova@10.9.1.1/nova --auth_driver=nova.auth.dbdriver.DbDriver --network_manager=nova.network.manager.FlatDHCPManager --fixed_range=10.9.1.0/25 --network_size=128 --FAKE_subdomain=ec2 --libvirt_type=kvm --flat_network_dhcp_start=10.9.1.2 --images_path=/home/images --scheduler_driver=nova.scheduler.arch.ArchitectureScheduler --quota_cores=1024 --quota_gigabytes=1000 --connection_type=libvirt --cpu_arch=x86_64 --xpu_arch= --- bespin:/home/dkang # euca-describe-instances RESERVATION r-rkf0hucv admin default INSTANCEi-0002 ami-7664288410.9.1.310.9.1.3 running u1 (admin, uv) 0 m1.large2011-03-30T15:02:43Z nova RESERVATION r-zzp3rfgs admin default INSTANCEi-0006 ami-7664288410.9.1.710.9.1.7 running mykey (admin, uv) 0 sh1.8xlarge 2011-03-31T20:08:09Znova RESERVATION r-512w3my9 admin default INSTANCEi-0001 ami-7664288410.9.1.210.9.1.2 running u1 (admin, uv) 0 m1.large2011-03-30T15:02:21Z nova RESERVATION r-8puoktnr admin default INSTANCEi-0007 ami-7664288410.9.1.610.9.1.6 running mykey (admin, uv) 0 sh1.8xlarge 2011-03-31T20:10:59Znova bespin:/home/dkang # ssh -i mykey.priv ubuntu@10.9.1.6 Chop wood, carry water. $ tail -20 /proc/cpuinfo processor : 63 vendor_id : GenuineIntel cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.12.3 stepping: 3 cpu MHz : 1999.866 cache size : 4096 KB fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good pni cx16 popcnt hypervisor lahf_lm bogomips: 3999.73 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: $ cat /proc/meminfo MemTotal: 132294940 kB MemFree:129901280 kB Buffers: 300 kB Cached:16424 kB SwapCached:0 kB Active: 4620 kB Inactive: 13536 kB Active(anon): 1440 kB Inactive(anon):0 kB Active(file): 3180 kB Inactive(file):13536 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 1480 kB Mapped: 1652 kB Shmem: 0 kB Slab: 33188 kB SReclaimable: 8976 kB SUnreclaim:24212 kB KernelStack:7056 kB PageTables: 492 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:66147468 kB Committed_AS: 5060 kB VmallocTotal: 34359738367 kB VmallocUsed: 222800 kB VmallocChunk: 34359513032 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k:8168 kB DirectMap2M:134209536 kB $ uname -a Linux i-0007 2.6.35-22-virtual #35-Ubuntu SMP Sat Oct 16 23:19:29 UTC 2010 x86_64 GNU/Linux --- Brian Schott USC Information Sciences Institute http://www.east.isi.edu/~bschott ph: 703-812-3722 fx: 703-812-3712 ___ Mailing list: https://launchpad.net/~openstack Post to :
Re: [Openstack] Feature Freeze status
On Fri, Apr 1, 2011 at 9:19 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: Yeah, but discussion on the mailing list before the summit is useful (developers who can't attend the summit are able to discuss, I might not be able to make it too). True enough :) Didn't mean to suggest the discussion on the ML wasn't useful. It certainly has been! Cheers, 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
Re: [Openstack] Federated Identity Management (bursting and zones)
I was stewing on the suggestion of subject/verb/object tuples. There's a gotcha in the federated AuthZ situation: mapping Public and Private Objects in the tuples. Essentially, who owns the rights over the object if the object is externally managed (by, let's say, a service provider). My thoughts around how Federated AuthZ might work in Nova are updated here: http://wiki.openstack.org/ZonesOauth#Thoughts_on_Federated_AuthZ (and made some slight tweaks to map it to conventional RBAC schemes) Please burn/spindle/mutilate ... -S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Wednesday, March 30, 2011 7:29 PM To: Sandy Walsh Cc: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Federated Identity Management (bursting and zones) I think authz is simplest if we just give it the responsibility of mapping subjects, verbs, and objects. subjects are returned by authn. They can be users/projects/roles/groups/etc, but are basically opaque verbs are defined by the application: launch_instance, get_volume, get_container, etc. objects are the entities that actions are performed on. Then the authz system can just define how these three are mapped to create a pass/fail. There can be some magic in the rules to make this much easier: 1) the concept of an object_owner. This allows rules to match the stuff returned by authn to an owner field on the object 2) dividing groups of actions into certain roles or groups returned by authn. The obvious one here is admin, but other general roles could be defined as well. I'm not sure how we validate the roles returned by an external authn server. We don't really want Alice's admins to have full admin rights to our deploy. Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin Vish On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: From: Jay Pipes [jaypi...@gmail.com] Come to think of it, there's no reason that role A would need to have similar privileges in zones X and Y. More likely than not, they would have different privileges, and therefore a federated authz service wouldn't really make sense. I see your point, I was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] heterogeneous instance types
Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes Hey Brian, interesting work! I was wondering if you planned support for multiple hypervisor types in parallel. With the recent addition of LXC, it makes sense to run an IaaS that proposes two types of instances, say KVM and LXC, and routes requests to the appropriate subset of compute nodes. Currently we only support one type of compute node. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] heterogeneous instance types
On Apr 1, 2011, at 10:55 AM, Thierry Carrez wrote: Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes Hey Brian, interesting work! I was wondering if you planned support for multiple hypervisor types in parallel. With the recent addition of LXC, it makes sense to run an IaaS that proposes two types of instances, say KVM and LXC, and routes requests to the appropriate subset of compute nodes. Currently we only support one type of compute node. Hi Thierry: We didn't have this use case in mind when we did our initial implementation of heterogeneous instance types, but it's an interesting idea and should be pretty straightforward to implement (says the guy at ISI who probably contributed the least amount of code to the heterogeneous implementation...). Is there community interest in this type of functionality? Take care, Lorin - Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ 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] heterogeneous instance types
On Fri, 01 Apr 2011 16:55:36 +0200 Thierry Carrez thie...@openstack.org wrote: Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes Hey Brian, interesting work! I was wondering if you planned support for multiple hypervisor types in parallel. With the recent addition of LXC, it makes sense to run an IaaS that proposes two types of instances, say KVM and LXC, and routes requests to the appropriate subset of compute nodes. Currently we only support one type of compute node. Cheers, Hi, This sounds like an interesting idea and Im all for it. chuck ___ 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] heterogeneous instance types
That is a good idea if the networking service supports it. One of the things we've been thinking about is how to best to make the virt subsystem more modular. It really needs a better driver-style interface with plugins for non-libvirt virts, I think. Mikyung actually had to build a bare metal TFTP-boot image management system for the Tilera system because it doesn't currently support KVM or Xen. I could see some HPC folks interested in managing bare-metal XCAT or Perceus machines. Brian Schott bfsch...@gmail.com On Apr 1, 2011, at 10:55 AM, Thierry Carrez wrote: Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes Hey Brian, interesting work! I was wondering if you planned support for multiple hypervisor types in parallel. With the recent addition of LXC, it makes sense to run an IaaS that proposes two types of instances, say KVM and LXC, and routes requests to the appropriate subset of compute nodes. Currently we only support one type of compute node. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Federated Identity Management (bursting and zones)
Made a few notes on thoughts at the bottom. I won't replicate the notes here because it kind of requires reading through the link you supplied first. In short, I think we have some options for keeping AuthZ isolated to a given deployment and even a given service. I like this approach, because I want to minimize the number of contact points between different deployments. Vish On Apr 1, 2011, at 7:40 AM, Sandy Walsh wrote: I was stewing on the suggestion of subject/verb/object tuples. There's a gotcha in the federated AuthZ situation: mapping Public and Private Objects in the tuples. Essentially, who owns the rights over the object if the object is externally managed (by, let's say, a service provider). My thoughts around how Federated AuthZ might work in Nova are updated here: http://wiki.openstack.org/ZonesOauth#Thoughts_on_Federated_AuthZ (and made some slight tweaks to map it to conventional RBAC schemes) Please burn/spindle/mutilate ... -S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Wednesday, March 30, 2011 7:29 PM To: Sandy Walsh Cc: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Federated Identity Management (bursting and zones) I think authz is simplest if we just give it the responsibility of mapping subjects, verbs, and objects. subjects are returned by authn. They can be users/projects/roles/groups/etc, but are basically opaque verbs are defined by the application: launch_instance, get_volume, get_container, etc. objects are the entities that actions are performed on. Then the authz system can just define how these three are mapped to create a pass/fail. There can be some magic in the rules to make this much easier: 1) the concept of an object_owner. This allows rules to match the stuff returned by authn to an owner field on the object 2) dividing groups of actions into certain roles or groups returned by authn. The obvious one here is admin, but other general roles could be defined as well. I'm not sure how we validate the roles returned by an external authn server. We don't really want Alice's admins to have full admin rights to our deploy. Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin Vish On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: From: Jay Pipes [jaypi...@gmail.com] Come to think of it, there's no reason that role A would need to have similar privileges in zones X and Y. More likely than not, they would have different privileges, and therefore a federated authz service wouldn't really make sense. I see your point, I was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] Federated Identity Management (bursting and zones)
For those of you following along at home ... there was a big IRC discussion around this: http://paste.openstack.org/show/1075/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] Feature Freeze status
2011/4/1 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: On Thu, 31 Mar 2011 10:02:34 +0200 Soren Hansen so...@openstack.org wrote: 2011/3/31 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: Sounds like the importance of blueprints is overrated. If you look at Linux kernel development (more than ten times developers and development speed, I guess), The Linux kernel development process uses a number of other approaches to deal with its volume. There a number of different staging trees. There are topic-based ones, like the one for people working on 'topic-based' is one of ways to manage a git tree so it's unrelated with this top Um, no. I realise git has a concept of topic branches, but this is not what I'm referring to at all. David Miller, for instance, maintains git.kernel.org/.../davem/net-2.6.git which is where all the interesting networking related stuff goes on. Every once in a while, this gets merged into Linus' linux-2.6 tree. I expect OpenStack will need to do the similar with developers increased. You don't? Quite probably. When the time comes. Different scales of development community warrant different approaches. you see that lots of developers can work well without something like blueprints. Just so we're clear: Linux has merge windows as well. New features simply do not get to go into mainline outside of these merge windows. Yeah, but you can propose new features (patches) any time. Sure. You can do that in OpenStack, too. People just still expect to get stuff discussed/reviewed/merged outside of this window. That's what we're talking about. I don't believe our core development team is large enough to support splitting our efforts like this. When we're past feature freeze, we all need to focus on QA'ing what we've got already. There are plenty of bugs to fix. It's not uncommon for changes to take several kernel releases from being proposed until they're actually accepted into the tree. Also, noone promises that your stuff will get reviewed. Ever. We do. If you propose stuff in time, we promise it will at least be reviewed once before feature freeze. Hmm, that 'promise' works (and will work in the future)? If we want it to, it can. If noone does reviews and just everyone keeps working on their own snazzy, new features, it won't. That's really the core of this problem. I already saw the shortage of reviewing (and I even saw that a half-baked feature without enough reviewed was merged and reverted). Yes! EXACTLY! Because people who ought to be reviewing aren't. I bet that we'll face more serious shortage of reviewing with developers increasing. In genera, developers prefer to write own code rather than reviewing. We can't change the nature. Then people ought to grow up. Seriously. They should grow up and stop saying that they're going to review stuff, or they should start actually reviewing stuff. I think that there is no such 'promise' for reviewing in a large OSS. If your code can't get enough reviewers, your code might be not useful enough for the project. It's sorta evolutionary theory. The better code has the better chance to be merged quickly. The features are prioritized fairly. I think we have quite different definitions of fair. We're on a mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. We can't pretend to meet everyone's needs if we only accept patches that are fun to review or that we wrote ourselves. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.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
Re: [Openstack] Feature Freeze status
On Fri, 1 Apr 2011 22:02:02 +0200 Soren Hansen so...@openstack.org wrote: I already saw the shortage of reviewing (and I even saw that a half-baked feature without enough reviewed was merged and reverted). Yes! EXACTLY! Because people who ought to be reviewing aren't. I think that we need to admint that there isn't enough reviewing power for that 'promise'. Instead merge only patches that are reviewed well. If people get frustrated with the speed of merging patches, some developers start to review patches. I bet that we'll face more serious shortage of reviewing with developers increasing. In genera, developers prefer to write own code rather than reviewing. We can't change the nature. Then people ought to grow up. Seriously. They should grow up and stop saying that they're going to review stuff, or they should start actually reviewing stuff. I don't think that people grow up in the way that you expect. I feel that I listen to the shortage of reviewing discussion at every kernel summit. Even though there are more than 1,000 kernel developers. I think that there is no such 'promise' for reviewing in a large OSS. If your code can't get enough reviewers, your code might be not useful enough for the project. It's sorta evolutionary theory. The better code has the better chance to be merged quickly. The features are prioritized fairly. I think we have quite different definitions of fair. We're on a mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. We can't pretend to meet everyone's needs if we only accept patches that are fun to review or that we wrote ourselves. The majority of OpenStack developers are paid for OpenStack development, right? I don't think that we need to worry about such. Look at Linux kernel development. The mojority are professionals and understand what they need to do. ___ 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] heterogeneous instance types
Brian, nice spec! It's a great example of why I appreciate detailed blueprints. Although I think it's very interesting to store more information about instance types, I'd be more cautious in creating new columns if it's not strictly necessary. I'd prefer a metadata table, something similar to the instance_metadata table. In this way, each provider can adjust the attributes to their real needs or imagination :) - Ferdy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
