Re: [Openstack] Review days for nova-core members
Good points Ken. I think we should leave the nova-core as the default selection. This lets those go to the nova-core mailing list, and sets it up so someone/anyone can add reviewers as those requests come in. I just tried out the "Claim Review" button on a merge proposal. It looks like using it removed the nova-core assignment and replaced it with me. I feel I could now add another reviewer (or more) and have them chime in. Maybe we could generate a daily report of unclaimed branches and send it to the list or to someone who had authority to assign people? -todd[1] On Mon, Feb 21, 2011 at 6:52 PM, Ken Pepple wrote: > On Feb 21, 2011, at 1:34 PM, Andy Smith wrote: >> Sure, we just need to remove it automatically selecting "Nova Core" and >> likewise as a reviewer for you so that people are forced to explicitly add a >> reviewer. > > > sorry to come in late in the discussion, but i believe this is a bad idea. > > imho, this raises another barrier between potential developers wanting to > contribute and actually contributing. specifically, it assumes that a newbie > to the project "knows" a nova-core member. > > they don't -- i am not sure the nova-core list is even publicly posted. > > just in my own case, it took me several days of signing contracts, figuring > out the toolset/standards, revising the patches, adding myself to wikis and > hanging out of IRC before i could get single line of code into nova. at any > of those points, i could have simply said *** (expletive deleted) … > > bottom line, we should be making it easier for people to contribute not > harder :) > > having said that, i understand what you are trying to do. > so, as a counter proposal, can we implement a round-robin or smart routing > (based on file names or modules) reviewer assignment ? > failing that, could we assign everything to ttx (sorry) and he can assign > reviewers ? > failing that, could we give them a list of potential reviewers (with some > good instructions) to choose from ? > > please correct me if i misconstrued your proposal > /k > ___ > 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] Queue Service, next steps
Ditto erl > cpp. On Tue, Feb 22, 2011 at 3:57 AM, Vishvananda Ishaya wrote: > +1 for Erlang from me. I'm hoping to never have to see C++ templates again :) > > On Feb 21, 2011, at 10:58 PM, Devin Carlen wrote: > >> It's been discussed a fair amount already, but I think this is a good list >> of pros for erlang: >> >> - less code to do the same thing (dramatically less in a lot of cases) >> >> - more robust development environment (far fewer sharp edges in erlang >> compared to c++) >> >> - this is exactly the type of project where erlang shines >> >> - lends itself towards more hands in the source code pie since there are >> fewer correct ways to do things in erlang >> >> >> Both are good choices but erlang has gained a ton of momentum in recent >> years for the reasons listed above. >> >> >> Personally I'd love to see us choose erlang for this project. I think it's >> a great fit. >> >> >> >> - Devin >> >> >> >> On Feb 21, 2011, at 10:51 PM, Eric Day wrote: >> >>> While Erlang is a dependency most folks usually don't have installed >>> by default, it is a fairly simple and predictable dependency. All >>> major distros have it, and if they don't or are too outdated, the >>> packages from the Erlang website are straightforward to install. >>> >>> Any dependency (C/C++ compilers, autotools, Erlang) will always have >>> its quirks, but I think either choice would be fine in the long run. >>> >>> The advantages for choosing Erlang right now are speed of development, >>> code safety, and trivial multi-core/machine use. The advantages for >>> C++ are runtime efficiency and familiarity. I'm pretty split and don't >>> think there is an incorrect choice here, but it feels like more folks >>> are leaning towards C++. >>> >>> -Eric >>> >>> On Mon, Feb 21, 2011 at 02:47:21PM -0600, John Purrier wrote: I agree with this. Unless there are significant, obvious advantages to Erlang I would suggest we stick with C/C++. John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Tim Bell Sent: Monday, February 21, 2011 2:08 PM To: Eric Day; openstack@lists.launchpad.net Subject: Re: [Openstack] Queue Service, next steps Please bear in mind the long term maintainability of the openstack package. One of the attractive features at the moment is that there are not significant pre-reqs to set up the environment and most mass market environments can support it. Using C++ would not significantly change this situation, whereas using Erlang may create some more difficulty further down the line. Anything that makes porting/rebuilding more difficult needs to be carefully thought through. 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 >>> >>> ___ >>> 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] documentation of flags, introducing of a naming convention for flags
The separation of flag definitions into the modules that consume them is a good practice, IMO. This is especially true with a system as configurable/pluggable as nova, as you don't want flags for unused modules polluting your help output, etc. It also goes most of the way into creating the logical boundaries you'd need to speak to when documenting configurations. -todd[1] 2011/2/22 Brian Schott : > +1 > > We are also struggling with the various and sundry deployment options. > Getting bit by the multiple mechanisms to install and launch openstack. > > --- > Brian Schott, Project Leader > USC Information Sciences Institute > http://www.east.isi.edu/~bschott > ph: 703-812-3722 fx: 703-812-3712 > > > > On Feb 22, 2011, at 10:07 AM, Diego Parrilla Santamaría wrote: > >> I have counted 160 configuration parameters in Nova, and only about 15 >> are documented. This is clearly one of the areas of improvement in the >> project. >> >> I have been fighting with Nova Bexar in not-so-standard configurations >> and deployments and believe me, I would appreciate more information >> about what they do. >> >> Something that took me a lot of time to figure out was what are >> 'common' flags for all the components in nova, and what are 'specific' >> flags for each component. If you are setting up an environment with >> specialized nodes >> (compute,network,volume,api,objectstore,scheduler...) this is a must >> if you want to have more than a couple of servers running Nova. >> >> Diego >> - >> Diego Parrilla >> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog >> +34 649 94 43 29 >> >> >> >> >> On Tue, Feb 22, 2011 at 3:29 PM, Jay Pipes wrote: >>> >>> Just use optparse/argparse. paste.deploy handles configuration files >>> already, which is where most "flags" should really be... gflags adds >>> unneeded complexity for no real gains, IMHO. Swift and Glance do just >>> fine without gflags, as do the vast majority of Python projects. As >>> for documentation of program options, the most common practice in the >>> open source world is to document configuration options in the example >>> configuration files that ship with your project, and document command >>> line options "inline" to show up in --help output. >>> >>> >>> On Tue, Feb 22, 2011 at 1:37 AM, Christian Berendt >>> wrote: Hi. At the moment we're using a lot of flags spread all over the code. a) we should create a useful documentation including all flags b) we should introduce a naming convention for new flags and we should rename existing flags example: all flags related to default values are starting with "default_", all flags related to a path are starting with "path_". Looks like most of the flags have good names at the moment, but I think we should write it down in the wiki or the developer documentation to reduce the possibility of bad names in the future. c) if it's possible we should collect all flags in one file At the moment the flags are defined in the files where they are used. I think it would be nice to have on file, for example nova/flags.py, including all flags used all over the code. Bye, Christian. -- Christian Berendt Linux / Unix Consultant & Developer Tel.: +49-171-5542175 Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 ___ 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 > > ___ 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] Novatools ...
I'd like to go on record as saying that anything related to nova or openstack that doesn't allow you to configure which public API you're consuming shouldn't bear the name nova or openstack. If you look at http://nova.openstack.org/ you see "API Compatibility" in bold as one of our design guidelines. This agnosticism should apply to clients as well. If I use something called 'nova' or 'openstack', I expect it to run against my installation regardless of my particular configuration is. It is now (with paste.deploy) trivial to run one API (ec2) and not the other (cloudservers). If we're writing a tool that only uses the cloudservers api, it clearly doesn't run against any openstack installation, so shouldn't have the names nova or openstack associated with it. I'm glad novatools exists and we're getting a library that consumes one of our APIs, but lets not call it 'nova' or 'os'. We could in fact just keep calling it 'cloudservers' as that is the API it exercises. -todd[1] On Thu, Feb 24, 2011 at 7:17 PM, John Purrier wrote: > Sounds good. > > John > > -Original Message- > From: Eric Day [mailto:e...@oddments.org] > Sent: Thursday, February 24, 2011 6:17 PM > To: John Purrier > Cc: 'Devin Carlen'; 'Jay Pipes'; 'Josh Kearney'; so...@openstack.org; 'Andy > Smith'; openstack@lists.launchpad.net; 'Rick Clark'; 'John Purrier' > Subject: Re: [Openstack] Novatools ... > > Hi John, > > I think the "super tool" should be named openstack, I don't think > anyone was proposing we call that nova. Each individual project can > use whatever name it likes, for example: > > nova create instance > glance describe images > openstack create cluster > > The last one would use the nova/glance/network APIs/tools to actually > do the work, it's just a thin wrapper around service specific tools. > > -Eric > > On Thu, Feb 24, 2011 at 05:49:43PM -0600, John Purrier wrote: >> I guess I will be the odd man out, but using the project name for compute > as >> the command line tool name makes no sense. As we add more projects and >> services it makes less sense to drive them from a tool called 'nova'. For >> example, today swift has a tool called st to manipulate its rest api. Are > we >> saying that it is logical to run 'nova list container'? >> >> I would prefer to use 'openstack' and then let people alias it to > something >> shorter. >> >> I do like the idea of having an interactive shell, as well as direct api >> calls in the tool. >> >> /nitpick >> >> John >> >> -Original Message- >> From: openstack-bounces+john=openstack@lists.launchpad.net >> [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On > Behalf >> Of Devin Carlen >> Sent: Thursday, February 24, 2011 4:34 PM >> To: Jay Pipes >> Cc: Josh Kearney; so...@openstack.org; Andy Smith; >> openstack@lists.launchpad.net; John Purrier; Rick Clark >> Subject: Re: [Openstack] Novatools ... >> >> This is a bit nitpicky but I'd rather see it called just "nova", as in: >> >> nova describe images >> >> Who has strong opinions? >> >> On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: >> >> > On Thu, Feb 24, 2011 at 4:06 PM, Eric Day wrote: >> >> On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: >> >>> I just don't want to end up with: >> >>> >> >>> os-describe-images >> >>> os-describe-image-attribute >> >>> os-describe-instances >> >>> os-describe-groups >> >>> os-describe-zones >> >>> os-describe-keypairs >> >>> os-describe-volumes >> >>> os-describe-snapshots >> >>> >> >>> The above is asinine, IMO. >> >> >> >> Completely agree. :) >> > >> > Cool. Was starting to lose my mind thinking people *really* wanted to >> > duplicate the eucatools mess... >> > >> >>> If you want to have an os-compute and an os-network CLI tool, cool, >> >>> but I think that: >> >>> >> >>> os-compute describe images >> >>> os-compute describe image-attribute >> >>> os-compute describe instances >> >>> os-compute describe groups >> >>> etc... >> >>> >> >>> is far more workable than 15 separate CLI tools that do essentially >> >>> identical things. >> >> >> >> Yup, agree. Also keep in mind that some operations may be duplicates >> >> across services, just with a different context. For example, >> >> in a deployment where you use glance backed by swift for nova, >> >> os-compute describe image may be the same as os-image describe >> >> or os-object describe (swift), but the os-compute is in >> >> the context of instances so it could have more metadata. This will >> >> mirror the dependency tree we see between services (especially as >> >> they are split out). >> > >> > ++ >> > >> >> We want to make sure there are tools so services can stand alone as >> >> needed (for example, os-image if you run glance standalone). Services >> >> that combine other services (like nova) should aggregate these into >> >> context-specific commands so you don't *need* to use the underlying >> >> service tools for most things. This allows you to control nova use >> >> one tool. :) >>
Re: [Openstack] server affinity
I like prefixed names that are grouped in with user metadata. On Wed, Mar 2, 2011 at 1:30 PM, Eric Day wrote: > On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote: >> Wait, are we all in agreement that we need user-defined metadata and >> service-specific metadata? I do agree that the data store isn't conducive to >> adding arbitrary metadata due to the rigidness of our DB, but how often are >> we going to be adding new attributes? >> >> I guess my main question is where is the line between a new metadata >> attribute and an instance-specific property? I suppose you could say then >> I'm all for your third and final example. > > The line is no core code in nova will ever look at user-metadata. If it > does need to, it should either be service-metadata or simply an object > property. There is a need for some deployments to define metadata > that can be used in the pluggable scheduler (as Justin mentioned, > things like GPU tags), but this should not be in the same namespace as > user-metadata or count against the user-metadata quota. Do we want to > require deployments to alter the DB schema, provide a service-metadata > table, or use reserved prefixes in the same table as user-metadata? > > I'm split between the last two. > > -Eric > >> >> -Original Message- >> From: "Eric Day" >> Sent: Wednesday, March 2, 2011 12:43pm >> To: "Mark Washenberger" >> Cc: "openstack@lists.launchpad.net" >> Subject: Re: [Openstack] server affinity >> >> Well said Jorge. I think we're all in agreement that we need a way >> to add both user-defined metadata and service-specific metadata (and >> possibly deployment-specific metadata). I think Justin was working >> on the metadata mechanisms assuming it would support both based on >> prefix. If we don't want to overload metadata and use prefixes to >> differentiate between users, providers, and so forth, we should add >> another collection to resources. For example: >> >> metadata = [ >> "user:comment": "This is Eric's dev server" >> "openstack:affinity_id": "rack4.dc2.east.rackspace.com"] >> >> Would become: >> >> user_metadata = ["comment": "This is Eric's dev server"] >> service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"] >> >> Or don't use metadata for service metadata at all and put directly >> in the instance object/record: >> >> instance.id = 100 >> instance.network = 42 >> instance.affinity_id = rack4.dc2.east.rackspace.com >> # instance.metadata is user-defined metadata only. >> instance.metadata = ["comment": "This is Eric's dev server"] >> >> Now the arguments stated by many folks is that "service_metadata" >> is really instance properties or instance attributes and should >> instead be part of the instance object/record directly (like size, >> flavor id, etc. are). I don't disagree, but unfortunately there is >> a little more overhead since we're using a structured data store, >> and this requires an alter table for every change at this point. It's >> more difficult to introduce, test, and remove service attributes. If >> we want deployments to be able to define service-specific metadata >> and use that in pluggable schedulers, a DB schema change is not a >> very elegant way to support this. >> >> So the questions are: >> >> Do we need to support variable service metadata? If so, where should >> it go? >> >> If in a key/value list, should existing instance properties be moved >> into this format as well? >> >> If in a key/value list, should it just be a prefix in a general >> metadata list (and user metadata has a 'user' prefix)? >> >> -Eric >> >> On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote: >> > > [W]e >> > > shouldn't be overloading that functionality by performing some action >> > > based on >> > > user-defined metadata. >> > >> > That is exactly what I've been trying to say, but you have stated it much >> > more succinctly. Thanks! >> > >> > My specific concern is with quotas. If the current osapi metadata is >> > overloaded with api functionality, then it muddies the concept of quotas. >> > Admins who run nova probably don't want the server affinity feature to >> > count against the general metadata quota. >> > >> > Because of this, I don't think server affinity should be part of the >> > metadata (specifically defined as the metadata attribute in >> > nova.compute.api.API::create). >> > >> > This doesn't really have any effect on which of Jorge's options we choose, >> > though, so /unhijack. >> > >> > "Jorge Williams" said: >> > >> > > Metadata in the OpenStack Compute/Cloud Servers API is meant to >> > > describe user >> > > defined properties. That's it. So in that case, I agree with Brian >> > > that we >> > > shouldn't be overloading that functionality by performing some action >> > > based on >> > > user-defined metadata. >> > > >> > > Speaking more generally though, any attribute that you associate with a >> > > resource >> > > can be thought of as metadata as well
Re: [Openstack] Queue Service Implementation Thoughts
With this switch to python, does it make sense to revisit the concept of openstack-common for things like logging, flag parsing, etc? What components would you like to just be able to drop in from nova, glance, or swift? -todd[1] On Tue, Mar 8, 2011 at 4:05 PM, Eric Day wrote: > Hi everyone, > > I added a sqlite backend to the prototype and ran some tests. Initially > things were very slow, but after some further testing I was able > to figure out where the time was being spent. In order to do this I > added a very simple binary protocol interface to insert only. These > tests are with a single server process and multiple client processes > (so don't compare to previous email numbers that were two process). The > numbers given are requests/second. > > echo (no parsing) - 17k > > binary - 13k > binary+insert msg into dict - 11k > binary+insert msg into sqlite - 8.7k > > wsgi - 4.9k > wsgi+webob - 3.5k > wsgi+webob+insert msg into dict - 3.4k > wsgi+webob+insert msg into sqlite - 2.8k > > wsgi+webob+routes - 1.9k > wsgi+webob+routes+insert msg into dict - 1.8k > wsgi+webob+routes+insert msg into sqlite - 1.5k > > This shows that without wsgi/webob/routes, the performance is pretty > decent). This would be the case when using an efficient binary protocol > or perhaps a more efficient HTTP parser. > > Next, it shows WSGI adds significant overhead. The webob and routes > modules also add a fair amount. > > I'm going to rework the current code in the prototype into a proper > project in the burrow trunk with modular front-ends and back-ends so > we can easily test new options. I'll stick with the current wsgi code > for now just to get things functioning and we can look at optimizing > later. For the proxy-server communication, we'll definitely need to > use something more efficient than stock wsgi modules in the long run. > > No red flags yet with Python, and we're in the ballpark for efficiency > with a binary protocol. A quick test with other servers showed > rabbitmq at about 9k messages/sec (binary protocol, Erlang server) > and Gearman at about 13k messages/sec (binary protocol, C server). > > -Eric > > On Mon, Mar 07, 2011 at 01:32:55PM -0800, Eric Day wrote: >> I ran the tests again to verify: >> >> 500k requests - 10 processes each running 50k requests. >> >> time req/s cs us sy id >> 2 thread/proc >> echo c++ 7.19 69541 142182 23 77 0 >> echo erlang 9.53 52465 105871 39 61 0 >> echo python 9.58 52192 108420 42 58 0 >> 2 thread/proc >> wsgi python 58.74 8512 18132 86 14 0 >> webob python 78.75 6349 13678 89 11 0 >> webmachine* 63.50 7874 11834 89 11 0 >> openstack 20.48 24414 49897 68 32 0 >> >> cs/us/sys/id are from vmstat while running the tests. >> >> * webmachine degrades over time with long-lived, multi-request >> connections. This number was estimated with 1000 requests per >> connection. At 50k requests per connection, the rate dropped to >> 2582 req/s. >> >> As you can see I was able to reproduce the same numbers. If >> anyone would like to do the same, you can grab lp:burrow for the >> "openstack" Erlang application (compile and run ./start), webmachine >> is at https://github.com/basho/webmachine (you need to create a demo >> app and make sure you set nodelay for the socket options), and I've >> attached the python server and client (start 10 client processes when >> testing). Find me on irc (eday in #openstack) if you have questions. >> >> If we hit performance issues with this type of application, we'll >> probably hit them around the same time with both Erlang and Python >> (then we'll look to C/C++). Since most OpenStack developers are a lot >> more comfortable with Python, I suggest we make the switch. Please >> response with thoughts on this. I'll add a sqlite backend to the >> Python prototype and run some performance tests against that to see >> if any red flags come up. >> >> -Eric >> >> On Sat, Mar 05, 2011 at 10:39:18PM -0700, ksan...@doubleclix.net wrote: >> > Eric, >> > Thanks for your experimentation and analysis. Somewhat illustrates >> > the >> > point about premature optimization. First cut, have to agree with you >> > and >> > conclude that python implementation is effective, overall. As you >> > said,if >> > we find performance bottlenecks, especially as the payload size >> > increases >> > (as well as if we require any complex processing at the http server >> > layer) >> > we can optimize specific areas. >> > Just for sure, might be better for someone else to recheck. That way >> > we have done our due diligence. >> > Cheers >> > >> > >> > Original Message >> > Subject: [Openstack] Queue Service Implementation Thoughts >> > From: Eric Day >> > Date: Sat, March 05, 2011 4:07 pm >> > To: openstack@lists.launchpad.net >> > >> > Hi everyone, >> > >> > When deciding to move forward with Erlang, I first tried o
Re: [Openstack] Feature Freeze status
Open == Accessible. Open != Verbose. I'm willing to discuss more at the design summit, but my biggest concern is that we let the most people possible can contribute. This includes those who work behind closed doors on their own pet projects. This thread started specifically in response to a few branches that didn't hinder anyone else's work, but also didn't have blueprints. So what? Blueprints should only be required for coordination when doing large work that can conflict with others'. Code should be the only artifact required to contribute, as that will keep contribution more accessible. If these proposers had run afoul of any other work in progress where the other branch _did_ have a blueprint, we could have just said "Sorry, you'll have to rebase after this other thing goes in, and coordinate better in the future," at which point they could have kept working to get their patch to land or walk away without getting it approved. Reviews are open so people working on branches that have blueprints can complain if a "rogue" branch gets proposed that would interfere with their plans. I really feel like we're making a problem where none exists. You can certainly craft a scenario where a lack of coordination causes a problem in a branch like this, but we don't have actual evidence it will happen. If it does, we can just push back against the proposer to fix things. Whats the problem with that? -todd[1] On Mon, Mar 28, 2011 at 1:53 PM, Jay Pipes wrote: > On Mon, Mar 28, 2011 at 1:38 PM, Justin Santa Barbara > wrote: >> No objection to a discussion during the summit, but I've been able to watch >> all of these branches and others evolve here: >> https://code.launchpad.net/nova >> For example, when I wanted to add VNC support because my system wouldn't >> boot, it was easy for me to look at the vnc_console branch and get the >> libvirt XML magic from there. If I was feeling brave, I could have grabbed >> the whole branch and merged it into my tree. That feels _very_ open to me. > > Rubbish. Open development means knowing the general directions and > specifications that people are working on by open discussions, open > blueprints/specs, and active communication between teams. I can go to > github and see how many people "forked this" (ugh.). That doesn't give > me any clue as to what people are attempting to do with the code in > the long term. > > The problem we've been having revolves around the fact that we have > dozens of developers working on Nova, with no real guidance as to the > long-term direction of the project, and teams just doing whatever the > heck they want to, without ML discussion and blueprints, and then > expecting people to just merge branches a few days before feature > freeze. > >> Just another benefit of bazaar being a centralized version >> control system, I guess > > I don't know what the heck you are talking about. > > -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 > ___ 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 Mon, Mar 28, 2011 at 2:54 PM, Jay Pipes wrote: > On Mon, Mar 28, 2011 at 2:32 PM, Todd Willey wrote: >> Open == Accessible. Open != Verbose. I'm willing to discuss more at >> the design summit, but my biggest concern is that we let the most >> people possible can contribute. This includes those who work behind >> closed doors on their own pet projects. > > It's not about letting people contribute. It's an open source project. > Anyone can contribute. Anyone can work on a fork of their > PetProjectStack. I'd say that forking is a form of consumption, and not contribution. I'd really like to make contribution as easy as possible to avoid forking. > > But when it comes to merge proposal time, and especially the backlog > that always shows up around Feature Freeze, I couldn't care less about > PetProjectStack unless it has a blueprint or bug tied to it that lets > me know the patch fixes something or adds something to the project > that has been debated and discussed. Can't you know what it fixes or adds by reading the merge proposal? I think it is reasonable to make merge proposals be detailed enough to answer any questions that a blueprint would have answered. Thats what the "Needs Information" status is for. The whole MP process is for debating and discussing. I actually prefer the linear discussion of a MP, as opposed to a BP, so I can see what changes based on feedback, and see new revisions that actually fix what is wrong. Compare that to a BP where you only have a text blob that is maintained by the proposer, isn't generally updated after questions are raised on mailing list or summit, and isn't displayed inline with the code. > >> This thread started specifically in response to a few branches that >> didn't hinder anyone else's work, but also didn't have blueprints. > > Not true. There were only a few branches that didn't have bugs or > blueprints assigned to them. Those branches are what Thierry and > myself were talking about. > >> So >> what? Blueprints should only be required for coordination when doing >> large work that can conflict with others'. Code should be the only >> artifact required to contribute, as that will keep contribution more >> accessible. > > IMHO, this doesn't work for projects with dozens of developers and > many teams all working towards a unified goal (you know, that whole > "this release is about X" thing?). It works spectacularly well for > projects with developers all working on their own forks of stuff that > want to do their own hacks but don't care about the direction of the > project as a whole. In other words, the blueprint/discussion process > is designed to bring unity to the project's direction and goals. it's > about *process*, not code. I agree with John's post that the PTL should solve some of the problems we have with a unified vision. I don't see developers working on their own interests being at odds with the direction of the project as a whole. Of course if someone clearly doesn't care about the direction of the stack as a whole, we would do right to reject their patches that would stray from our vision. I think that isn't likely though, as our developers are our users. Service providers and users have their own needs to tend to as well as the overall scope of the project. We're always going to be getting MPs for things that aren't in the scope of our release vision, but we should accept them as long as they don't go against that vision or other goals of the project. Clearly blueprints are about process and not about code. Merge proposals are a hybrid of code and process. Blueprints are about managing expectations, whereas merge proposals are about managing code. I think if you are working on a self-contained change you don't need to manage the expectations of people working on other parts of the system because you're not going to interfere, and their expectations about how they should write code can go unchanged. You do, however, need to have a process required to get your changes accepted into the code, and need to outline your reasoning and implementation goals. > >> If these proposers had run afoul of any other work in >> progress where the other branch _did_ have a blueprint, we could have >> just said "Sorry, you'll have to rebase after this other thing goes >> in, and coordinate better in the future," at which point they could >> have kept working to get their patch to land or walk away without >> getting it approved. Reviews are open so people working on branches >> that have blueprints can complain if a "rogue" branch gets proposed >> that would i
Re: [Openstack] Feature Freeze status
On Mon, Mar 28, 2011 at 7:42 PM, Ewan Mellor wrote: >> -Original Message- >> From: Todd Willey >> Sent: 28 March 2011 21:11 >> To: Jay Pipes >> Cc: openstack@lists.launchpad.net >> Subject: Re: [Openstack] Feature Freeze status >> >> [Snip] >> >> Clearly blueprints are about process and not about code. Merge >> proposals are a hybrid of code and process. Blueprints are about >> managing expectations, whereas merge proposals are about managing >> code. I think if you are working on a self-contained change you don't >> need to manage the expectations of people working on other parts of >> the system because you're not going to interfere, and their >> expectations about how they should write code can go unchanged. You >> do, however, need to have a process required to get your changes >> accepted into the code, and need to outline your reasoning and >> implementation goals. > > I think that this paragraph is a great exposition of why I (and others) > disagree with you. Blueprints are not about managing expectations. > Blueprints are about telling other people what you're working on. This is > important, because I don't think that anyone is in a position to judge > whether they are "working on a self-contained change" or whether they're "not > going to interfere" _unless_ they are telling people what they are working on. > Blueprints are great for the reason you and Rick have stated. They let all types of people who are interested in monitoring the development and planning their own development and implementation plan more effectively. I think of unplanned features as an extra gift on top of all of this that we should accept gratefully. I'm not saying we can know before propose-time if a feature is isolated. But, if at the end it turns out it is in fact isolated, then I see no reason we shouldn't welcome it with a minimum of drama. > For example, there have been many occasions when we (Citrix) have said "oh, > we don't need to work on that, because Rackspace have it covered" or "we'd > best mention this to Rackspace, because they're working on something else > that is _bound_ to conflict". There have also been times when we've said "it > sure would have been great to know about that in advance, and save ourselves > half-a-dozen trunk merges". > > Blueprints are important because they save other people wasting their time. > That's either because they get to avoid duplicating your effort, or because > they want to work in the same code and get to schedule around you so that the > merge conflicts aren't insane. Maybe, if you're really lucky, they might > actually have some good ideas and can make suggestions to you. > I understand that working without blueprints is more often the more painful way to do things. I'm not saying it's good, I'm only saying that there are cases where it is _acceptable_. Breaking things, making major design decisions without discussion, and ignoring our platform goals should get things rejected. Always. We can also still offer feedback and suggestions in a MP, so I think the window of time that people have to be really lucky is non-zero even in the absence of a BP. With core review days and targeting specific reviewers by name we should continue to move this out of the realm of luck and into a process designed to get the right people providing that meaningful feedback. > Blueprints should be regarded in the same way as docstrings. Sure, you can > write the code faster without docstrings, and the code will work just as > well, but it will take everyone else twice as long to figure out what it was > you are trying to do. Blueprints are the same, just at a different phase in > the process. You can definitely write the code without writing the blueprint > first, but everyone else would sure appreciate it if you put half-an-hour > into the blueprint. That way, we'll know what it is you're trying to do. > I, too, appreciate people taking their time to write blueprints. I also appreciate people who take time to write code, even if it doesn't come with a blueprint. People who take their creative energy to contribute to something I love earn enough favor that my default state is to try and accept their contribution without imposing additional barriers to entry. Maybe a patch comes in that it isn't reasonable to merge, but we never know unless we actually look at it with the mindset of trying to accept it. I still expect that people give blueprint-level details in merge proposals so that we can follow the code with an understanding of what you're trying to accomplish, otherwise we&
Re: [Openstack] Feature Freeze status
On Tue, Mar 29, 2011 at 8:54 AM, Ewan Mellor wrote: >> -Original Message- >> From: Todd Willey [mailto:t...@ansolabs.com] >> Sent: 29 March 2011 04:08 >> To: Ewan Mellor >> Cc: Jay Pipes; openstack@lists.launchpad.net >> Subject: Re: [Openstack] Feature Freeze status >> >> On Mon, Mar 28, 2011 at 7:42 PM, Ewan Mellor >> wrote: >> >> -Original Message- >> >> From: Todd Willey >> >> Sent: 28 March 2011 21:11 >> >> To: Jay Pipes >> >> Cc: openstack@lists.launchpad.net >> >> Subject: Re: [Openstack] Feature Freeze status >> >> >> >> [Snip] >> >> >> >> Clearly blueprints are about process and not about code. Merge >> >> proposals are a hybrid of code and process. Blueprints are about >> >> managing expectations, whereas merge proposals are about managing >> >> code. I think if you are working on a self-contained change you >> don't >> >> need to manage the expectations of people working on other parts of >> >> the system because you're not going to interfere, and their >> >> expectations about how they should write code can go unchanged. You >> >> do, however, need to have a process required to get your changes >> >> accepted into the code, and need to outline your reasoning and >> >> implementation goals. >> > >> > I think that this paragraph is a great exposition of why I (and >> others) disagree with you. Blueprints are not about managing >> expectations. Blueprints are about telling other people what you're >> working on. This is important, because I don't think that anyone is in >> a position to judge whether they are "working on a self-contained >> change" or whether they're "not going to interfere" _unless_ they are >> telling people what they are working on. >> > >> >> Blueprints are great for the reason you and Rick have stated. They >> let all types of people who are interested in monitoring the >> development and planning their own development and implementation plan >> more effectively. I think of unplanned features as an extra gift on >> top of all of this that we should accept gratefully. I'm not saying >> we can know before propose-time if a feature is isolated. But, if at >> the end it turns out it is in fact isolated, then I see no reason we >> shouldn't welcome it with a minimum of drama. > > I don't agree. Unplanned features aren't an extra gift -- they're extra work > for everyone. > > Thierry is trying to stabilize a release and get it out on time. He can't do > that if people come along saying "here's an extra gift that you now need to > give time to review". We're already short on resources, and Thierry needs to > prioritize based on the capacity that we collectively have. For example, > Citrix has bumped a number of features to Diablo, because it was clear that > we wouldn't get everything reviewed and merged and stabilized in time unless > we deferred low priority work. Unplanned features just put all that in > jeopardy. > > If someone comes along with a random branch as a "gift", then it's not > unreasonable for us to say "Thank you for that, we'll take it in the next > unstable period in a couple of months. In the meantime, please write a brief > blueprint so that we don't forget about it." > Well then lets recruit more -core members, keep tweaking the review process, and work with the release windows. I would say those things are more a cause of the problem than someone sharing code. What is the point of timed releases if we punt stuff without blueprints regardless of landing during an open window? Code that comes in before freezes should be reviewed for the release it was in the window for. > A blueprint doesn't have to be burdensome. Big features need a long time at > the planning stage, but for other things there's no reason why the blueprint > should take more than half-an-hour. I don't think it's unreasonable to ask > anybody to spend half-an-hour writing down what their new shiny thing is, how > it works, and how to test it. > Not all features take a long time to plan and implement. Some are quite tiny. Some are conceived and implemented near the end of the release cycle. Size, scope, and timing can change how valuable a blueprint is as the odds that a patch requires coordination tends toward zero. The information that you point to (what their new shiny thing is, how it works, and how to test it) certainly remains valuable regardless of size, scope an timing, but that information can also live in a merge proposal. -todd[1] > Cheers, > > Ewan. > > ___ 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 Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez wrote: > Todd Willey wrote: >> Not all features take a long time to plan and implement. Some are >> quite tiny. Some are conceived and implemented near the end of the >> release cycle. Size, scope, and timing can change how valuable a >> blueprint is as the odds that a patch requires coordination tends >> toward zero. The information that you point to (what their new shiny >> thing is, how it works, and how to test it) certainly remains valuable >> regardless of size, scope an timing, but that information can also >> live in a merge proposal. > > We have always had some tolerance so far for small unplanned features > that land in time. I still think those should have linked blueprints > (since I still fail to see the cost associated), even if that means > creating them retroactively. Then it is reasonable to ask people in a merge proposal discussion to file a blueprint, and give them guidance on how to do so. > > What I want to avoid is large unplanned features, which hurt project > external visibility and tend to generate duplicate work and last-minute > objections. I also want to avoid unplanned features landing *outside the > merge window*. This whole thread started because a set of unplanned > features were proposed after FeatureFreeze and required exceptions. At FFE time why don't we branch and change so proposals default to the next release then? I understand that you don't want people focusing on features instead of bugs, but I doubt that situation will arise. It could, however, save us from some late proposals. I don't want to have to do more work on my end in tracking branches and remembering dates, I'd rather just push my stuff to launchpad and have it show up in the list of pending proposals. > > I think we outlined the cost of not filing blueprints... Could you > outline the cost of filing them ? They aren't standard practice in the open source world. My main concern is the amount of indignation that was exhibited for a practice that is the standard operating procedure in most open source projects. If we keep that attitude we're going to drive away developers, and I feel like we should be doing all we can to be welcoming. We're apache licensed, people don't have to share their work. They can either close up or fork. The best way to avoid that and encourage them to be open is to take contributions in a way that feels natural for developers who are making the changes and are willing to share their work. if we need more information let's ask nicely, not turn a merge proposal into a protest. Most importantly, I think this: http://wiki.openstack.org/SpecsSubmissionDeadline sets the wrong precedent. I understand that it is great for large features, things that require changes to every hypervisor layer, or some other change that has ripple effects. We need to deal with the case that people have new ideas all the time, not just every three months. If someone conceives of a new feature after this freeze, they shouldn't have to wait nearly six months to see it released if it is small, doesn't break anything, and doesn't duplicate work or invalidate ideas others are working on. You can check those criteria during a merge review. I'm not in the mindset that every patch is going to be self-contained. It makes sense to occasionally postpone things until they can be part of the next cycle. I want there to be a practice of cheerfully reviewing changes to see if they can land or not, instead of trying to default everything to invalid. We have reviews for a reason, lets let them work the way they should. You've done a great job of determining which things were valid for FFE, and comments on the proposals have discussed why it was so late in coming. It seems like our process is already working, so I feel like this whole thread is mostly pointless, other than as a catalyst for people to express their various attitudes toward different aspects of our processes and how they are used. > > -- > 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] Feature Freeze status
On Wed, Mar 30, 2011 at 6:41 PM, Jay Pipes wrote: > On Wed, Mar 30, 2011 at 6:17 PM, Todd Willey wrote: >> On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez >> wrote: >>> Todd Willey wrote: >>>> Not all features take a long time to plan and implement. Some are >>>> quite tiny. Some are conceived and implemented near the end of the >>>> release cycle. Size, scope, and timing can change how valuable a >>>> blueprint is as the odds that a patch requires coordination tends >>>> toward zero. The information that you point to (what their new shiny >>>> thing is, how it works, and how to test it) certainly remains valuable >>>> regardless of size, scope an timing, but that information can also >>>> live in a merge proposal. >>> >>> We have always had some tolerance so far for small unplanned features >>> that land in time. I still think those should have linked blueprints >>> (since I still fail to see the cost associated), even if that means >>> creating them retroactively. >> >> Then it is reasonable to ask people in a merge proposal discussion to >> file a blueprint, and give them guidance on how to do so. >> >>> >>> What I want to avoid is large unplanned features, which hurt project >>> external visibility and tend to generate duplicate work and last-minute >>> objections. I also want to avoid unplanned features landing *outside the >>> merge window*. This whole thread started because a set of unplanned >>> features were proposed after FeatureFreeze and required exceptions. >> >> At FFE time why don't we branch and change so proposals default to the >> next release then? I understand that you don't want people focusing >> on features instead of bugs, but I doubt that situation will arise. >> It could, however, save us from some late proposals. I don't want to >> have to do more work on my end in tracking branches and remembering >> dates, I'd rather just push my stuff to launchpad and have it show up >> in the list of pending proposals. >> >>> >>> I think we outlined the cost of not filing blueprints... Could you >>> outline the cost of filing them ? >> >> They aren't standard practice in the open source world. My main >> concern is the amount of indignation that was exhibited for a practice >> that is the standard operating procedure in most open source projects. >> If we keep that attitude we're going to drive away developers, and I >> feel like we should be doing all we can to be welcoming. >> >> We're apache licensed, people don't have to share their work. They >> can either close up or fork. The best way to avoid that and encourage >> them to be open is to take contributions in a way that feels natural >> for developers who are making the changes and are willing to share >> their work. if we need more information let's ask nicely, not turn a >> merge proposal into a protest. > > Sorry, have to respond here. You have a view of "the open source > world" that seems to correspond only to the "hackers itching an itch" > view. While this view is valid, it's not the only "open source world" > even though it might be near and dear to some of our hearts. > I don't think the methods used to submit code have anything to do with what the motivations of the contributors are. > You also bring up that we are licensed under the Apache license. I'll > therefore bring up this, which outlines the "the open source world" > that the Apache foundation and its contributors belong to: Not sure how valid this is since applying the apache license doesn't make you a part of the apache foundation. > > http://ostatic.com/blog/guest-post-the-apache-software-foundations-open-source-approach > > From the article: > > "For the Apache Software Foundation, open source is more about an open > development methodology (ODM). This is characterized by six main > traits and, regardless of the strength of the technology and vision, > all Apache TLPs have to prove themselves in these key areas: > > • a deep level of user engagement: if you don't have users then > there is no point having a project. > • transparency: being open about what the community is undertaking > and the way decisions are made. > • collaboration: the ability of working within a diverse group of > people, something that the Internet has obviously made easier. > • agility: once work begins and there is a serious engagement with > users, ideas and plans may need
Re: [Openstack] Creating a forum
I think between the list and the Launchpad Questions section we have it covered. Maybe we could just make the Launchpad Questions section mentioned more prevalently in docs? -todd[1] On Mon, May 2, 2011 at 4:12 PM, Jordan Rinke wrote: > I had a number of discussions with various people at the summit about > creating a forum for openstack (forum.openstack.org) and everyone seemed to > think it was a good idea especially for user support and discussions for > people who are not likely to use a mailing list. So I have 2 questions... > > 1. Is anyone against creating a forum? > 2. Does anyone have a specific forum software they suggest we use? > > Once I have it all configured, we will need to determine the categories and > get moderators etc for each category. Stephen Spector will be the keeper of > the kingdom in that regard so if you would like to help out just let him know. > > > ___ > 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] Do we need SSL on nova-api ports?
We should be able to do it with a wsgi middleware and either include it or not in the paste config file. In a heavily load-balanced environment you'll probably want to terminate SSL before it gets proxied to the actual api servers, but it would be nice to support the simple case where the api server could have ssl. Middleware seems like a better, more reusable solution than a flag. -todd[1] On Mon, May 2, 2011 at 7:42 PM, Vishvananda Ishaya wrote: > Can we do this with a flag (or two) and just keep regular http if the flag is > not set? > > Vish > > On May 2, 2011, at 4:34 PM, Eldar Nugaev wrote: > >> Hi all. >> >> So what is the decision? >> I see three decisions: >> >> #1 Replace existed plain http to ssl >> #2 Add additional ports for ssl (save plain http) >> #3 Do nothing >> >> Eldar >> >> On Tue, Apr 26, 2011 at 11:27 AM, Dirk-Willem van Gulik >> wrote: >>> >>> On 25 Apr 2011, at 19:47, Kirill Shileev wrote: >>> Recently, playing with libcloud against a private openstack installation we realized that 8773 and 8774 ports listened by openstack-nova-api expect plain HTTP. This is something that is rarely allowed in production installations. . Other option would be making this configurable, although not sure why and where the plain HTTP might be justified. Any thoughts, comments? >>> >>> An important side effect of slapping SSL with client/server certs on pretty >>> much all connection is that it makes all sort of governance and validation >>> jobs much easier from an organisational point of view. With more 'reuse' of >>> existing process and validation. >>> >>> The attack footprint/exposed estate now splits in three clean realms: >>> issuing of client cert, security of the TCP and SSL layer - and a specific >>> model for what happens within that connection. With the latter bound by the >>> previous two. Furthermore client validation can be done with narly a secret >>> in sight. >>> >>> So for those reasons alone - SSLis good. >>> >>> Dw. >>> ___ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> >> >> -- >> Eldar >> Skype: eldar.nugaev >> >> ___ >> 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] Do we need SSL on nova-api ports?
On Tue, May 3, 2011 at 5:39 AM, Dirk-Willem van Gulik wrote: > > On 3 May 2011, at 10:31, Soren Hansen wrote: > >> 2011/5/3 Todd Willey : >>> In a heavily load-balanced environment you'll probably want to terminate >>> SSL before it gets >>> proxied to the actual api servers, >> >> Why is that? It seems like a win to distribute as much processing as >> possible, including SSL termination? > > Because most load balancing vendors are either 1) convinced that they need to > go up the stack and have gradually made it impossible to do blind socket LB - > and insist on looking at headers and what not, or 2) is soo far out of touch > and old that blind socket forwarding is not overly practical as the outdated > means to inform the LB what to blindly forward where is just too painful. > I was thinking of hardware acceleration. > But yes - a bright vendor/standard would indeed do a clever pass through to > the distributed boxes for at least the initial exchange; optionally > facilitate session sharing and/or providing it in-line and after the exchange > it could be informed of the session key and then do a bit more than just > blind forwarding. > > Dw. > > ___ 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] Separation of IRC Channels
I think we should finalize a plan for the forum before we start changing IRC. I'd hate to become unresponsive on many fronts at once, and I think growing just one of those communities will be hard enough. On Tue, May 3, 2011 at 8:23 PM, Devin Carlen wrote: > +1 to not splitting everything up. > > On May 3, 2011, at 5:03 PM, Eric Day wrote: > >> I would vote for no separation yet, but I understand everyone has >> a different threshold. If we do separate, +1 on #openstack-dev, >> #openstack- seems a bit excessive. >> >> -Eric >> >> On Tue, May 03, 2011 at 07:34:30PM -0400, Jay Pipes wrote: >>> On Tue, May 3, 2011 at 7:16 PM, Ken Pepple >>> wrote: Do we have to break out all the projects into their own development channels ? Can't we just have a #openstack-dev to cover them all ? There are a lot of cross-project discussions (especially between nova/glance, but I think NaaS will also cross quite a few projects). >>> >>> +1 >>> >>> -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 >> >> ___ >> 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] euca-describe-images help?
Looks like the directories need to be named base 16. See nova/images/local.py line 60 (in trunk). On Mon, May 9, 2011 at 6:34 PM, Yang, Fred wrote: > Hi, > > > > I am installing nova from the latest source trunk following > http://wiki.openstack.org/InstallFromSource as a newbie and is having > euca-describe-images issue, can someone enlighten me? The environment is > single node installation with Ubuntu 10.10 > > > > fred@stocky1:~/openstack/nova$ ls -R images > > images: > > aki-lucid ami-tiny ari-lucid > > > > images/aki-lucid: > > image info.json > > > > images/ami-tiny: > > image info.json > > > > images/ari-lucid: > > image info.json > > > > fred@stocky1:~/openstack/nova$ euca-describe-images > > > > where the ./bin/nova-api window gets following messages > > 2011-05-09 15:04:04,437 DEBUG nova.api [-] action: DescribeImages from > (pid=15607) __call__ /home/fred/openstack/nova/nova/api/ec2/__init__.py:214 > > 2011-05-09 15:04:04,437 DEBUG nova.api [-] arg: ExecutableBy.1 > val: self from (pid=15607) __call__ > /home/fred/openstack/nova/nova/api/ec2/__init__.py:216 > > 2011-05-09 15:04:04,440 ERROR nova.image.local [-] aki-lucid is not in > correct directory naming format > > 2011-05-09 15:04:04,440 ERROR nova.image.local [-] ami-tiny is not in > correct directory naming format > > 2011-05-09 15:04:04,441 ERROR nova.image.local [-] ari-lucid is not in > correct directory naming format > > 2011-05-09 15:04:04,441 DEBUG nova.api.request [-] ?> xmlns="http://ec2.amazonaws.com/doc/2009-11-30/";>4WE2DMZ2ZNE4D7BSSYD5 > from (pid=15607) _render_response > /home/fred/openstack/nova/nova/api/ec2/apirequest.py:171 > > 2011-05-09 15:04:04,441 INFO nova.api [4WE2DMZ2ZNE4D7BSSYD5 fredy Ras] > 0.28957s 192.168.0.14 GET /services/Cloud/ CloudController:DescribeImages > 200 [Boto/1.9b (linux2)] text/plain text/xml > > > > Is the images path incorrect? I have also tried execute command by step > into ~/images > > > > Thanks, > > -Fred > > > > > > ___ > 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] [Glance] New Glance API changes .. feedback needed
Would adding new fields into a response bump the minor version number and not the major? In that case, knowing the exact version would be nice. In all honesty though, I'm for integer version numbers for APIs anyway, so every set of changes bumps the revno, and you always have good documentation specific to exactly what you are querying against and tool authors don't get lost sifting through fine print. On Tue, May 10, 2011 at 6:52 PM, Jay Pipes wrote: > Hey all, > > We've been working to improve the Glance API. The first step to > improving the API, however, is to add versioning to it. > > We've gotten a lot of the work done on this versioning of the API (see > https://code.launchpad.net/~jaypipes/glance/api-version/+merge/60130). > > However, there is an issue that remains unresolved that we would like > some community input on. > > We have a choice of using the following two API URIs: > > /v1/images > /v1.0/images > > I coded the latter (/v1.0/images) because I was copying the way that > swauth and Nova's OpenStack API do it, but Brian Waldon brought up the > fact that major versions of APIs should never break clients written to > that major version of the API, so there is no real reason to specify > the minor version in the URLs. > > I would prefer the shorter /v1/images API, myself. > > What do others think? > > Feedback appreciated. > > -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 > ___ 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 API, Reservation ID's and Num Instances ...
I'm for zone-generated ids. If we take user input it is one more thing to sanitize and scope accordingly. As the number is essentially disposable, I don't know why they would care to provide one anyway, it just seems like changing who is responsible for making a uuid. On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh wrote: > Actually, I'm cool with it either way. > > I'm not really sure of the value in letting users generate their own > Reservation ID though. What would the typical motivation be? > > That said, anyone else have preferences (PUT + user defined reservation ID's) > vs. (POST + zone generated ID's)? > > -S > > > From: Brian Lamar [brian.la...@rackspace.com] > Sent: Tuesday, May 24, 2011 11:30 AM > To: Sandy Walsh > Cc: openstack@lists.launchpad.net > Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... > > Only a small scream on PUT /zones/server/ > > PUT would work in my mind if we allowed users to create their own > ReservationIDs, but since (I assume) we're generating them it would make more > sense to me to use POST on /zones/server. > > -Original Message- > From: "Sandy Walsh" > Sent: Monday, May 23, 2011 5:54pm > To: "openstack@lists.launchpad.net" > Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... > > Thanks to all for the input. I don't think we've really come to any > conclusions for the near term. > > Unless someone screams, we will be proceeding along the following lines: > > 1. Adding PUT /zones/server/ to create an instance that will return a > Reservation ID (a UUID). It will also accept a num-instances parameter. > (I'll refactor with the existing code to keep the duplication to a minimum) > > 2. python-novaclient will be extended to take an optional reservation ID for > GET /servers, which will be used to list instances across zones based on > Reservation ID > > None of this should affect the existing OS API or EC2 API functionality. > > We can have Feats of Strength later to decide how this should live on in an > OS API 2.0 world. > > /me listens for the screams ... > > -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. > > > ___ > 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 for Brian Lamar to join Nova-Core
+1 On Tue, May 31, 2011 at 3:16 PM, Vishvananda Ishaya wrote: > While I was checking branch merges, I noticed that Brian Lamar (blamar), is > not listed as a nova-core developer. This is most definitely a travesty, as > he has been one of the most prolific coders/reviewers over the past few > months. So I'm proposing that he is added as a nova-core member. > > Vish > ___ > 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] SQLAlchemy migration number conflicts
Agreed. Wholeheartedly. On Wed, Jun 1, 2011 at 3:47 PM, Trey Morris wrote: > I like vish's idea. instead of 999, maybe it should be anything over 9000. > -tr3buchet > > On Wed, Jun 1, 2011 at 1:47 PM, Brian Schott wrote: >> >> That's not crazy, but I'd recommend a range of numbers 900-999? There >> have been cases where larger branches have multiple migrate files. >> Brian Schott >> bfsch...@gmail.com >> >> >> On Jun 1, 2011, at 1:56 PM, Vishvananda Ishaya wrote: >> >> This might be a little crazy, but how about numbering new migrations 999 >> and having tarmac rename the file before merging. Then all we need is a >> little logic in the migrate code to allow 999 for testing purposes. >> >> Vish >> >> On Jun 1, 2011 9:33 AM, "Brian Schott" wrote: >> > I was getting migrate errors because gaps are not allowed in the >> > migration numbers. Maybe this could be changed so that folks could use >> > arbitrarily large numbers in their branches until ready to propose for >> > merge. That would help minimize conflicts and manual bzr rename on our >> > local >> > branches when merging from trunk. >> > >> > The reservation numbers need to be monotonically increasing at trunk >> > merge because suppose migration 12 gets reserved but doesn't submit any >> > code >> > changes, then migration 13 comes in and gets approved and merged, then >> > migration 12 merges code and breaks migration 13. You can't revert back to >> > migration 11 because the new migration 12 is in the way. >> > >> > Brian Schott >> > bfsch...@gmail.com >> > >> > >> > >> > On Jun 1, 2011, at 11:12 AM, Ed Leafe wrote: >> > >> >> Another option is to have a migration reservation page in the wiki. It >> >> would contain a table with a sequence of numbers in the first column, and >> >> a >> >> blank cell in the right column. When you need to add a migration, fill >> >> your >> >> branch name next to the first available number, and that number's yours. >> >> If >> >> there's a conflict, it will be clear who needs to change their number. >> >> >> >> It's a manual process, sure, but this isn't a process that's repeated >> >> all that often. >> >> >> >> >> >> >> >> -- Ed Leafe >> >> >> >> >> >> >> >> >> >> ___ >> >> 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] Swift+Keystone error
Needs
account_autocreate = true
in proxy-server.conf
I'm assuming your keystone baseURL points the public url of swift to
http://127.0.0.1:/v1/AUTH_%tennant_id%
I'm running trunk on swift and keystone w/o problems (though it was
broken for a bit on trunk keystone).
-todd[1]
On Tue, Jun 21, 2011 at 8:22 PM, Jesse Andrews wrote:
> Todd was doing some work on keystone
> https://github.com/rackspace/keystone/commit/722fcd8ebef3fe1268ace5c05e014f6a945abfab
> It still needs some work and might not be at the right place.
> Jesse
> On Jun 21, 2011, at 4:31 PM, Tres Henry wrote:
>
> Trying to get a Swift+Keystone dev environment setup and having some issues.
> I'm running Swift 1.4.2 and have it pointing at Keystone 0.9 (on the same
> VM) according to the instructions at https://github.com/rackspace/keystone,
> however, Swift is reporting 500s from Keystone (Auth GET
> failed: http://127.0.0.1:8080/v1.0 500 Internal Server Error) and the
> Keystone log says:
>
> eventlet.wsgi.server: DEBUG Traceback (most recent call last):
> File "/usr/lib/python2.6/dist-packages/eventlet/wsgi.py", line 336, in
> handle_one_response
> result = self.application(self.environ, start_response)
> File "/home/tres/nova/keystone/keystone/frontends/legacy_token_auth.py",
> line 74, in __call__
> new_request.body = json.dumps(params)
> File "/usr/lib/pymodules/python2.6/webob/request.py", line 1173, in
> __setattr__
> object.__setattr__(self, attr, value)
> File "/usr/lib/pymodules/python2.6/webob/request.py", line 498, in
> _body__set
> raise ValueError("%s requests cannot have body" % self.method)
> ValueError: GET requests cannot have body
> (this was specifically when trying "swift -A http://127.0.0.1:8080/v1.0 -U
> joeuser -K secrete post container"
> Here's some relevant configs if it helps:
> -- keystone.conf --
>
> [DEFAULT]
> # Show more verbose log output (sets INFO log level output)
> verbose = True
> # Show debugging output in logs (sets DEBUG log level output)
> debug = True
> # Which backend store should Keystone use by default.
> # Default: 'sqlite'
> # Available choices are 'sqlite' [future will include LDAP, PAM, etc]
> default_store = sqlite
> # Log to this file. Make sure you do not set the same log
> # file for both the API and registry servers!
> #log_file = /var/log/keystone.log
> log_file = keystone.log
> # SQLAlchemy connection string for the reference implementation
> # registry server. Any valid SQLAlchemy connection string is fine.
> #
> See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine
> sql_connection = sqlite:///../keystone/keystone.db
> # Period in seconds after which SQLAlchemy should reestablish its connection
> # to the database.
> sql_idle_timeout = 30
> #Dictionary Maps every service to a header.Missing services would get header
> X_(SERVICE_NAME) Key => Service Name, Value => Header Name
> service-header-mappings = {'nova' : 'X-Server-Management-Url' , 'swift' :
> 'X-Storage-Url', 'cdn' : 'X-CDN-Management-Url'}
> # Address to bind the API server
> #TODO Properties defined within app not available via pipeline.Till then
> server props stay outside.
> server_bind_host = 0.0.0.0
> # Port the bind the API server to
> server_bind_port = 8080
> [app:admin]
> paste.app_factory = keystone.server:admin_app_factory
> # Address to bind the Admin API server
> bind_host = 0.0.0.0
> # Port the bind the Admin API server to
> bind_port = 8081
> [app:server]
> paste.app_factory = keystone.server:app_factory
> [pipeline:keystone-legacy-auth]
> pipeline =
> legacy_auth
> server
> [filter:legacy_auth]
> paste.filter_factory = keystone.frontends.legacy_token_auth:filter_factory
>
> -- proxy-server.conf --
>
> [DEFAULT]
> bind_port =
> user = root
> log_facility = LOG_LOCAL1
> [pipeline:main]
> pipeline = catch_errors healthcheck cache keystone proxy-server
> [app:proxy-server]
> use = egg:swift#proxy
> allow_account_management = true
> [filter:keystone]
> use = egg:keystone#tokenauth
> auth_protocol = http
> auth_host = 127.0.0.1
> auth_port = 8081
> admin_token = 999888777666
> delay_auth_decision = 0
> service_protocol = http
> service_host = 127.0.0.1
> service_port = 8100
> service_pass = dTpw
> [filter:healthcheck]
> use = egg:swift#healthcheck
> [filter:cache]
> use = egg:swift#memcache
> [filter:catch_errors]
> use = egg:swift#catch_errors
>
>
> ___
> 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
Re: [Openstack] Default ports for services
I'd prefer to keep it convenient to develop and demo on a single
machine. I don't think there is any added inconvenience during
deployment if the ports are not the standard http ports.
On Fri, Jun 24, 2011 at 12:15 PM, Jay Pipes wrote:
> Hi!
>
> As I stated on our Skype chat about this the other day, I think that
> the default port for HTTP services should be 80, with 8080 used for
> administrative endpoints. Unless there's a good reason to have a
> specific port assigned to what is essentially just an HTTP service, I
> don't think we should stray from the standard.
>
> That said, I recognize that Glance's API and registry servers are at
> 9292 and 9191 respectively. I believe it was a mistake to do that, and
> I would support switching those both back to 80.
>
> -jay
>
> On Wed, Jun 22, 2011 at 9:52 PM, Ziad Sawalha
> wrote:
>> Where's the best place to keep track of default ports for services to avoid
>> conflicts? A wiki page on wiki.openstack.org?
>> We had a discussion while working on Keystone about default ports for
>> OpenStack services (https://github.com/rackspace/keystone/issues/31). We
>> want OpenStack to work 'out-of-the-box' without built-in port conflicts, so
>> we should coordinate which ports new services start on.
>> At a minimum, we need that for Keystone as it isn't discoverable. Other
>> services can be discovered using the service catalog that Keystone returns
>> as part of an auth request (Sample response below at end of email).
>> Here's a list of ports we talked about on
>> https://github.com/rackspace/keystone/issues/31
>>
>> 80: Swift proxy server (swift/etc/proxy-server.conf-sample)
>> 6000: Swift object server
>> 6001: Swift container server
>> 6002: Swift account server
>> 6080: Nova VNC proxy
>> 8001: Nova direct API
>> 8080: Swift proxy server (swift/bin/swift-proxy-server)
>> 3306: MySQL
>> 5672: AMPQ (RabbitMQ)
>> 9292: Glance API
>> 9191: Glance Registry
>> 5900...590?: qemu-system for VNC
>>
>> We've moved Keystone to 5000/5001 (for Service and Admin API, respectively).
>>
>>
>> Sample Response with service catalog:
>>
>> {
>> "auth":{
>> "token":{
>> "id":"asdasdasd-adsasdads-asdasdasd-adsadsasd",
>> "expires":"2010-11-01T03:32:15-05:00"
>> },
>> "serviceCatalog":{
>> "nova":[
>> {
>> "region":"NorthAmerica",
>> "publicURL":"https://service1-public:9000/v1/blah-blah";,
>> "internalURL":"https://service1-internal:9001/v1/blah-blah";
>> },
>> {
>> "region":"Europe",
>> "publicURL":"https://service1-public-eu/v1/blah-blah";,
>> "internalURL":"https://service1-internal-eu/v1/blah-blah";
>> }
>> ],
>> "swift":[
>> {
>> "region":"regionOne",
>> "publicURL":"https://service2-public-dat/v1/blah-blah";
>> }
>> ]
>> }
>> }
>> }
>>
>> ___
>> 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] Default ports for services
On Sat, Jun 25, 2011 at 11:47 AM, Jay Pipes wrote: > On Fri, Jun 24, 2011 at 10:10 AM, Todd Willey wrote: >> I'd prefer to keep it convenient to develop and demo on a single >> machine. I don't think there is any added inconvenience during >> deployment if the ports are not the standard http ports. > > Can you explain why having the *default* port be 80/8080 for HTTP > services would hinder that? Unless I'm mistaken, spinning up servers > on different ports is as simple as specifying a set of test config > files that have ports set for an all-on-one-machine setup? > > Just curious... > > -jay > I'm just trying to avoid having to either remember a command line flag for every service I launch, or remember to not check in config files that specify port numbers that I've changed in source directories. If we go to a 80/8080 setup I'll just end up writing scripts that wrap all the services, but I imagine that if I'm doing that to make things easier, people who want to evaluate OpenStack on a single box are going to find things unnecessarily complicated. ___ 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] Default ports for services
I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production. On Sun, Jun 26, 2011 at 12:50 PM, Bryan Taylor wrote: > If we use something other than 80 for http and/or 443 for https, then > clients will have to know magic numbers for the port and firewall > obstacles will annoy them. I don't see HTTP as something we just happen to > have chosen. We should prefer convention over configuration, and embrace > the conventions of HTTP. > > On 6/26/11 11:13 AM, "Jay Pipes" wrote: > >>On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen wrote: >>> 2011/6/25 Jay Pipes : Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? >>> >>> I've heard this sort of argument before, and I've never quite >>>understood it. >>> >>> Yes, our API happens to be built on top of HTTP, but why must that >>> bleed into the choice of port number? I think of port 80 not so much >>> as "the HTTP port", but rather "the www port" (and 8080 as the >>> unprivileged www port). >>> >>> Say we had come up with our own basic, generic protocol, on top of >>> which we'd built the Glance API, Nova API, Swift API, etc... Would you >>> want them to have assigned a single port as well, just because their >>> API's all were encapsulated in the same generic protocol? >> >>If we develop APIs on top of other protocols, I'd expect them to be >>different ports. >> >>All I'm saying is that our services (except for Burrow, which has >>non-HTTP choices) are HTTP services, and since 80 is the default port >>for HTTP, I think it's natural for our services to run on 80. I hear >>the other arguments, though. Just offering my opinion. :) >> >>-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 > > > ___ > 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 Common
One thing that might be added would be dynamic module and class loading. This has implications for flags/options and help output as well. It is something nova does, and I suspect keystone and others will need to do as well. On Mon, Jul 25, 2011 at 2:59 PM, Devin Carlen wrote: > If by mini-projects you mean small and separate projects, then I don't think > that makes sense. > > All we need for this is a single project that contains submodules that don't > contain unnecessary dependencies on other submodules within the common > project. So lots of bite size pieces that can be used or not used. > > Devin > > On Jul 25, 2011, at 10:20 AM, Glen Campbell wrote: > >> Would it better to break it down even further? I.e., instead of trying to >> put ALL the common code into one project, create mini projects for >> common-logging, common-configuration, etc. That would permit other >> projects to adopt what they need, when they need it, rather than trying to >> integrate the entire common project at once. >> >> For example, we're working on converting Glance to use the >> logging/notification mechanism defined by Nova. The first step in the >> project was, however, "cut and paste notification code" from one to the >> other. That's disturbing to me, because it doubles the amount of effort >> required to implement changes to the notification system in the future. It >> would be much better IMHO to have a refactored common-logging module that >> could be included by multiple projects, with a standard interface each >> project could rely upon. >> >> There's no requirement, then, to implement common-rpc when you integrate >> common-logging, which lowers the barrier to entry for each project. >> >> >> >> >> >> >> On 7/25/11 12:11 PM, "Brian Lamar" wrote: >> >>> All, >>> >>> I love the idea of having an openstack-common project. However, the >>> prospect of creating such a project is daunting and quite difficult. >>> >>> It's my belief that standardizing/collecting common logic into a single >>> module will be beneficial to our current code-base and allow for future >>> projects to be created more quickly/easily. >>> >>> Currently the behemoth in the room is OpenStack Compute (aka Nova). The >>> Compute project contains much more code than all other OpenStack projects >>> (combined), and rightly so...virtualization is a pretty darn complex >>> thing to do in a flexible way. This might be why other projects have been >>> spawned to take away some of the logic from a single massive project and >>> place that logic into smaller, more focused projects. >>> >>> However, I would argue that the barrier of entry is too high for this >>> strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >>> suffer from the lack of a single cohesive strategy in the following areas: >>> >>> -Logging >>> -Configuration >>> -WSGI >>> -RPC >>> -Database >>> -Testing >>> -Deployment/Distribution of code >>> >>> These are the building blocks which most projects will require, yet every >>> project has to create their own implementations? Sure, it's not going to >>> be easy, and maybe some categories I've labeled won't make the final cut, >>> but I would like to start a conversation with the community as to the >>> feasibility of such an endeavor. >>> >>> This is not the first time such a project has been brought up. Much >>> earlier in the year, a number of people suggested moving "lazy loading" >>> code into a common project. I would like to think that project died due >>> to complexity rather than the community rejecting the idea. >>> >>> To create a common library of this nature requires a bit of pushing aside >>> one's partisan blinders and the abandonment of ideological >>> entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >>> argparse flame-war. >>> >>> TLDR: No >>> >>> * - Shamelessly stolen from The West Wing (tm) >>> >>> >>> >>> >>> ___ >>> 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 > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpa
Re: [Openstack] Review Spam
Strictly speaking I think gerrit is the canonical one and github is a mirror of that. On Fri, Sep 23, 2011 at 1:53 PM, Lorin Hochstein wrote: > Vish: > The description at https://github.com/openstack/nova still says "GitHub > Mirror of OpenStack Compute (Nova)". Is it now the case that the GitHub repo > is the canonical one and that the Launchpad repo is a mirror? > > Lorin > -- > Lorin Hochstein, Computer Scientist > USC Information Sciences Institute > 703.812.3710 > http://www.east.isi.edu/~lorin > > > > On Sep 23, 2011, at 11:04 AM, Vishvananda Ishaya wrote: > > Hey Nova-Core, > A couple of apologies: > 1) Sorry about not communicating more about the Gerrit move. Somehow I > assumed that everyone already knew we were moving as soon as diablo was > finalized, but I never made an official announcement. I will try to stay on > top of these things in the future. > 2) Sorry about the review spam earlier. I was trying to bring in an old > branch and keep the commit history. It seems that in the new world of > gerrit, we're going to end up squashing everything in to one commit anyway > so that is not the right way to go. > There is a lesson learned though for moving existing branches over. If you > are not worried about keeping commit history in your local repository, you > probably will have an easier time if you just squash everything using the > second method on the bottom of the page here: > http://wiki.openstack.org/MigrateMergePropFromLaunchpadToGerrit > > Good luck migrating branches. > Vish > > PS: We have re-enabled the pep8 check which disappeared for a while > recently, so don't forget to check your branches. > ___ > 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] virtio for VM NICs
This probably goes back to when there were problems with certain kernels that would lock up when attaching volumes with virtio enabled. There still may be issues with Windows images that don't have the right drivers installed. -todd[1] On Thu, Oct 27, 2011 at 9:33 PM, Yun Mao wrote: > Is there a reason that libvirt_use_virtio_for_bridges is not set to > True by default? Without virtio the network performance in kvm is > ridiculously slow.. Thanks, > > Yun > > ___ > 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 add Johannes Erdfelt to nova-core
Plus one On Nov 9, 2011 9:25 AM, "Brian Waldon" wrote: > I'd like to nominate Johannes for nova-core, as he has definitely been > doing a good number of reviews lately. > ___ > 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 for Lorin Hochstein to join nova-core
+1 On Tue, Nov 29, 2011 at 1:03 PM, Vishvananda Ishaya wrote: > Lorin has been a great contributor to Nova for a long time and has been > participating heavily in reviews over the past couple of months. I think he > would be a great addition to nova-core. > > Vish > ___ > 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 Foundation] OpenStack Foundation
On Thu, Jan 5, 2012 at 5:19 PM, Mark McLoughlin wrote: > Hi Mark, > > On Thu, 2012-01-05 at 15:16 -0500, m...@openstack.org wrote: >> As Jim mentioned, I'm going to focus on establishing the foundation >> this year and am really excited to be able to dedicate the time and >> attention it deserves, alongside Jonathan, Stef, and many others. >> I've found myself spread a bit too thin the past few months, as I'm >> sure we all have in the crazy whirlwind of the OpenStack universe. >> >> To kick things off I've created a Foundation page on the wiki and >> published a "Foundation Mission" draft for comment > > Nicely done on the Foundation Mission. It covers a lot of ground > concisely. Great start. Really. > > At first glance, one thing that seems missing is "OpenStack is a > self-governing meritocracy". Compare with the GNOME Charter, "How the > ASF works" and the Document Foundation Manifesto. > > There's lots of ways we could reflect this principle of meritocracy - > e.g. to highlight that the foundation is not an entity separated from > its members, but rather its members are the foundation. Members are > empowered beyond the points you list; they are empowered to > fundamentally shift the direction of the foundation itself. Influence in > the foundation is based solely on what one is doing to drive the project > forward. etc. > > Another thing I wouldn't be too keen on is the overly negative "defend > the trademark" references. I'd go for "determining the appropriate use > of the trademark". The trademark is an asset of the foundation that > needs to be fairly shared amongst the foundation membership, not some > precious jewel to be locked in a basement and jealously guarded. > > But, again ... great start. > > In some ways the mission statement is fundamental to the foundation, but > in other ways it won't nearly have as much impact on the success of the > foundation as its structure, governance and culture. For that reason, > I'd tend to say "the mission statement looks fine, let's get on to the > meaty stuff". > > RAX have a lot to be commended for and will be worthy of high praise > indeed if this is done right. The feedback below is purely my little bit > to help make that happen. > >> as well a a rough timeline for the next couple of months: >> http://wiki.openstack.org/Governance/Foundation >> >> The first thing you'll notice is that I tried to keep it simple and >> stay out of the questions of HOW the foundation will achieve the >> mission, because I think it's good to start with an idea of the >> purpose before debating the many ways in which a foundation could be >> structured to achieve it (as several people pointed out on the list). >> So much of the HOW is too be discussed, debated, and ultimately >> determined, but if you look at the timeline you'll see that in about a >> month our goal is t have a draft structure to review with everyone. >> I'm hopeful that we can rally around the Mission between now and then >> and get it finalized. > > Having to wait another month before any discussion of the structure is > very disappointing. > > It sounds like there are "numerous other" RAX employees who have the > privilege of some insight into the ongoing drafting. That may have been > intended to convey RAX's commitment to establishing the foundation, but > it comes across to me like there's a party going on that the rest of us > aren't invited to. > > I assume some basic principles for the structure of the foundation have > been settled on in the months since the announcement. I really don't see > why those principles can't be shared and debated on in advance of the > full blown verbiage. > >> Jonathan and I will host a webinar in the next week or so as an >> additional method of gathering feedback. We are also thinking an in >> person meeting in February in Santa Clara might be helpful, and can >> add other forums. > > IMHO, the mailing list is the one forum available to us which enables a > truly open debate. > > I think the emphasis should be on encouraging that debate here on the > mailing list for all to see, archived for posterity. > > The previous thread here that I contributed to felt a little like > Thierry and I chatting alone in a giant cavern. > > That concerns me for two reasons - (1) the silence of all those > excellent RAX OpenStack developers suggests that those folks are either > afraid to publicly speak their mind on these matters, or they are > ambivalent about them and (2) there are obviously many other discussions > happening away from the transparency of this mailing list. Speaking for myself: I'm more interested in driving the code base forward than the foundation. The foundation bits are in the hands of trustworthy people that are very approachable. Knowing I can ask about it at any time, and that it is moving forward without having to constantly bird-dog it makes me happy and able to be productive in other ways. I don't think there is going to be any publicly holding
Re: [Openstack] [OpenStack Foundation] OpenStack Foundation
On Fri, Jan 6, 2012 at 5:26 AM, Mark McLoughlin wrote: > Hi Todd, > > On Thu, 2012-01-05 at 18:29 -0500, Todd Willey wrote: >> On Thu, Jan 5, 2012 at 5:19 PM, Mark McLoughlin wrote: >> > >> > The previous thread here that I contributed to felt a little like >> > Thierry and I chatting alone in a giant cavern. >> > >> > That concerns me for two reasons - (1) the silence of all those >> > excellent RAX OpenStack developers suggests that those folks are either >> > afraid to publicly speak their mind on these matters, or they are >> > ambivalent about them and (2) there are obviously many other discussions >> > happening away from the transparency of this mailing list. >> >> Speaking for myself: I'm more interested in driving the code base >> forward than the foundation. >> >> The foundation bits are in the hands of trustworthy people that are >> very approachable. Knowing I can ask about it at any time, and that >> it is moving forward without having to constantly bird-dog it makes me >> happy and able to be productive in other ways. > > So, generally speaking, RAX hackers are regularly talking (in-person, on > private mail, irc, phone?) to the folks working on establishing the > foundation and are reassured by what they are hearing back? Sorry, the point I was trying to get across is that I don't necessarily need to be in discussions to feel confident. I don't think I've ever had a conversation about it, but I know they'll be responsive when pinged, and the people involved have been active in responding to this thread in the last couple of days. > > I'm reassured that you're reassured (genuinely), but I'd be more > reassured if such questions and assurances were happening on this list > where I too could be directly reassured by the assurances given ... if > you follow me :-) I follow you. I just wanted to point out that the reason I'm not asking on the list is that I'm not asking at all, because I haven't felt any concerns I needed to voice (yet). I think the early stages are likely to be very political and getting founding members to feel good about their positions in the new foundation. Once the discussions are less strategic and more tactical about how we actually implement very specific parts of our mission, I'll likely be more active. I assume other developers are in the same boat as we often make better tacticians than politicians. > >> I don't think there is going to be any publicly holding back from >> developers once there are more substantial bits that we have opinions >> on, and we'll register them on the list the same way as everyone else. >> Looking at the foundation archives, I'm not sure how you construed >> silence on behalf of RAX developers more than anyone else in the first >> place. It is very low volume so you have a poor sample to begin with, >> and a lot of what is there is in fact from Rackspace employees. > > Ok, cool. I'm really looking forward to hearing the thoughts of more > developers on this stuff. > > Thanks for the perspective Todd. > > Cheers, > Mark. > ___ 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] cloudpipe stuff
I'd like to point out a change I have waiting for reviews in Nova, in case it has any impact: https://review.openstack.org/#change,2593 This is a user-launchable image that can connect from a VLAN to a floating address as it is launched. It serves much the same function as a cloudpipe, but can be launched and terminated by users, so it needs to use the same toolchain (ie, nova). Maybe this can stay in nova, and quantum can be in charge of the times you want always-on vpns (either soft- or hardware), but we also should support having no VPN at all for the bastion/ssh case. -todd[1] On Sat, Jan 7, 2012 at 3:50 AM, Dan Wendlandt wrote: > Context for openstack-mailing list: > > This is a thread from the netstack list about integrating VPN capability > with Quantum. Wanted larger community feedback. > > - > > Hi Debo, > > Based on our discussion Tuesday, it sounds like some nova folks don't see > nova cloudpipe as a path worth investing in long-term, in which case I agree > that it doesn't make sense for the Quantum team to integrate with it. I'd > like to get a more general nod on that from the rest of the community > though, particularly the nova devs, so I am CC'ing the wider openstack list. > > > Creating a pluggable VPN API + service either as a standalone-service or as > a "sub-service" of Quantum has always been the long-term plan, so if there > is no short-term nova plan, jumping to that directly makes sense. Finishing > this in Essex seems ambitious to me, but given its importance to achieve > "nova-network parity" for Quantum I'd love to see it happen. If we could > have a "proposed" API (perhaps as a Quantum extension) and at least one > open-source implementation (as well as any proprietary implementations) in > time for the main essex release I think we would be in great shape. > > Thanks! > > Dan > > > On Wed, Jan 4, 2012 at 11:17 PM, Debo Dutta (dedutta) > wrote: >> >> Hi >> >> >> >> After some offline discussions with Dan and Soren it was felt that we need >> to have this discussion on the ML. >> >> >> >> Context: goal of the CP is to enable auth-ed access to a network managed >> by Nova /Quantum and not publicly accessible from the Internet. >> >> >> >> There are 2 ways to do CP: >> >> · Tweaks in Nova and Quantum rework to get CP to work. Nova-manage >> will spin up the CP VM but on a specific Quantum network. We could get this >> into E3. >> >> · Soren felt that a clean solution should be independent of Nova >> and be inside Quantum since the fact that we spin a CP VM is an artifact of >> the way the legacy CP was implemented and that may not be the ideal way >> going forward. From that perspective the above workaround planned would be a >> distraction and potentially would need to be refactored. >> >> >> >> If we choose the 2nd route, then we will need to coverge on the quantum >> API for VPN service. The design will incorporate a pluggable driver for the >> following scenarios a) HW VPN devices b) VM based soft VPNs like openvpn. >> >> >> >> Question to the elite netstack group: >> >> · Does anyone have a strong preference for the tweak that was >> planned >> >> · For the 2nd route (i.e. API + pluggable modules), the API could >> be as simple as >> >> o VPN.connect(args)/VPN.disconnect() >> >> o VPN.config(VPNConfig) >> >> § Split tunneling configuring options …. >> >> o Network.attach_vpn_instance(VPN) and detach >> >> o Network.enable_vpn … instantiates a VPN instance and attaches to the >> network >> >> o VPN object could be either SoftVPN or HardVPN >> >> >> >> I asked Soren if the CP tweak is critical for Quantum to be the default >> manager and his opinion is a “no” and he favors a solution that is more >> flexible and generic. I think if we choose the 2nd route, we should still >> have a working VPN solution by E, maybe as an addon and not part of E3. >> >> >> >> Thoughts? Opinions? Flames? >> >> >> >> Regards >> >> Debo >> >> > > > > > -- > ~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com > twitter: danwendlandt > ~~~ > > > ___ > 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
