Re: [Openstack] Future of Launchpad OpenStack mailing list (this list)
On Thu, Sep 13, 2012 at 5:40 PM, Stefano Maffulli stef...@openstack.orgwrote: On 09/13/2012 01:45 AM, Thierry Carrez wrote: That would be option B2 (single user/general list, named openstack): openst...@lists.openstack.org openstack-annou...@lists.openstack.org openstack-...@lists.openstack.org I think it's the clearest to avoid cross-posting... Reminder: here were the other options: Option A1 (separate operators, general named openstack-general): openstack-gene...@lists.openstack.org openstack-operat...@lists.openstack.org openstack-annou...@lists.openstack.org openstack-...@lists.openstack.org Option A2 (separate operators, general just named openstack): openst...@lists.openstack.org openstack-operat...@lists.openstack.org openstack-annou...@lists.openstack.org openstack-...@lists.openstack.org Option B1 (single user/general list, named openstack-user): openstack-u...@lists.openstack.org openstack-annou...@lists.openstack.org openstack-...@lists.openstack.org All lovely options, if we started with mailing lists today. Unfortunately we already have the list openstack-operators *and* we have the general list to move to a new host. I'd rather not move *two* lists, annoying two large sets of people and losing many of them in the process. Sometimes (and I believe this is one of the cases) you have to live with 'technical debt'. The viable options are A1 or A2 or A3* (s/openstack-general/openstack-users/) or Option C (dev, announce and operators as user/general list --no renames, no moving stuff around, just a new description) openstack-operat...@lists.openstack.org openstack-annou...@lists.openstack.org openstack-...@lists.openstack.org Given no option Bs, the simplicity of option C is most appealing to me. d Option Z (keep current situation): forget about this, we have to move out of LP for lists. I would go with option C but if that's not an option then let's create a new list (B1 nomenclature for the new list gets my vote) and leave -operators as is. /stef ___ 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] Quantum PTL election - please check Voters list
On Thu, Sep 6, 2012 at 9:03 AM, Dan Wendlandt d...@nicira.com wrote: I must admit even I was unaware of the requirement to be a individual foundation member in order to vote in PTL elections (I personally happen to be a member already). There are definitely at least a few people on the list below that I feel should be able to vote but can't, including two core members, Sumit and Aaron. The summary for the elections process that I saw sent to the list (see below) said nothing about foundation membership, and said that the process is mostly the same used in past PTL/PPB elections, which clearly did not have a foundation requirement because the foundation didn't exist. This is not the end of the world, but I'm guessing both Gary and I would both feel better if people had a chance to revisit their foundation status. Is there anything we can do about this? I hope so! I'm still reading this thread, but I've recommended that we give ATCs a chance to register as Foundation members now, and then accept them as valid voters... d ___ 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-dev] Nova PTL candidacy
/me waits for http://vishfacts.com/ ... On Thu, Sep 6, 2012 at 10:54 AM, Matt Joyce matt.jo...@cloudscaling.com wrote: Vish doesn't sleep. He waits. On Thu, Sep 6, 2012 at 10:32 AM, Blake Yeager blake.yea...@gmail.com wrote: He also lives vicariously through himself. On Thu, Sep 6, 2012 at 10:12 AM, Ravi Jagannathan reagul.2...@gmail.com wrote: +1 . Plus he has a cool name. On Thu, Sep 6, 2012 at 10:58 AM, Sam Su susltd...@gmail.com wrote: +1 On Wed, Sep 5, 2012 at 12:19 AM, Michael Still michael.st...@canonical.com wrote: On 09/05/2012 06:03 AM, Matt Joyce wrote: Vish is also a pretty cool guy and doesn't afraid of anything. Vish does a great job -- many hours a day of code review and mentoring, puts up with criticism much more calmly than I think many would, and is a pleasure to work with. Mikal ___ 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 ___ 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] Quantum committers: Do you want to vote?!
New subject line, to catch the attention of those who might have dozed off during this thread... See the announcement below! Thanks, Thierry! d On Thu, Sep 6, 2012 at 1:29 PM, Thierry Carrez thie...@openstack.org wrote: Thierry Carrez wrote: We (the election officials) are still checking if we'll be able to get a new Foundation membership dump tomorrow in time for setting up the final election voters list. OK, this is now confirmed. All election officials and the two candidates to the Quantum PTL election agree to extend the cut-off date for the Foundation individual membership criteria for that election to today Thursday, 23:59 PST. That leaves about 10 hours for Quantum committers mentioned in the voters list under the not a foundation member yet section to join the Foundation as an Individual Member if they want to participate to the Quantum PTL election: http://openstack.org/join Regards, -- Thierry Carrez (ttx) Election Official ___ 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-dev] Glance PTL Candidacy
On Mon, Sep 3, 2012 at 10:02 PM, Brian Waldon bcwal...@gmail.com wrote: Good news, everyone! I'd like to officially announce my candidacy for the Project Technical Lead of Glance for the Grizzly release cycle. Since I am the current Glance PTL, I have had a chance to figure out what being a PTL means for me: - provide general direction for the project - facilitate discussion around important topics - be the subject-matter expert of the project - be available to the community - work with other PTLs to help provide a cohesive OpenStack story - provide feedback on blueprints and code reviews On top of all that, I've focused on designing and implementing a new OpenStack Images API and completely rewriting the python Glance client. During Grizzly, I plan to continue work on the v2 Images API, but mostly focus on internal code refactoring. Thanks! Brian Waldon As an election official, I confirm that you are eligible to this position. d ___ 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-dev] Nova PTL candidacy
On Tue, Sep 4, 2012 at 12:58 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, I'm writing to announce my candidacy for the Project Technical Lead of Nova for the Grizzly Release cycle. Qualifications -- I was part of the original Anso Labs Team that created Nova at NASA[1]. I have more commits to nova than any other contributor[2] and the second most in the past 12 months[3]. I am the most active reviewer for nova commits[4] I have been the Nova PTL since the position waw created[5]. Folsom Accomplishments -- A lot was achieved in Nova during this cycle. I have to give most of the credit to the active contributors we had. I don't have space to cover everything that we achieved during the release but here are some key points: * Split the volume code into its own project and helped it get under way. * Versioned the rpc apis * Improved api testing and xml support * Moved instances to using exclusively UUIDs * Improved our state management and minimized race conditions * Cleaned up the quota management to make it more robust Grizzly Plan While there is a great deal to be determined at the design summit, I think there are a few key things that we need to focus on over the next cycle. * Spreadi * No DB compute: We did a huge amount of preparation during folsom to allow us to remove database access from the compute nodes. This will dramatically improve the security profile of nova and allow us to scale * Better quantum integration: We are very close to a seamless integration with quantum where a provider could be using quantum on the backend and end-users wouldn't even have to know. * Upgrade consistency: Now that we have rpc versioning, we should be able to take steps to allow for the possibility of live upgrades * Better support for custom backends: we need to solidify the driver interfaces so custom backends can potentially live out-of-tree. This will allow the management Vish [1] https://github.com/openstack/nova/commit/f04c6ab2d082ce8fe48ec58cb5c7cc64ed2a282b [2] http://www.ohloh.net/p/novacc/contributors?query=sort=commits [3] http://www.ohloh.net/p/novacc/contributors [4] http://173.203.107.207/~soren/stats/nova-30days.json [5] https://lists.launchpad.net/openstack/msg01674.html As an election official, I confirm that you are eligible to this position. d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fwd: [openstack-dev] Running for Quantum PTL
-- Forwarded message -- From: Duncan McGreggor dun...@dreamhost.com Date: Mon, Sep 3, 2012 at 12:40 AM Subject: Re: [openstack-dev] Running for Quantum PTL To: OpenStack Development Mailing List openstack-...@lists.openstack.org On Sun, Sep 2, 2012 at 2:10 PM, Dan Wendlandt d...@nicira.com wrote: Hi folks, I'm really excited about what we've done with Quantum so far and I am even more pumped about where we can take things in the future. As a result, no surprise, I'm running to continue on as the Quantum PTL. I've been a leader of the Quantum project since it was started during the Diablo release, and I was the PTL elected when we became an official incubated project in Essex. If anyone has concerns with the way the project has been running so far, I'd love to hear from you and discuss that feedback. So far, my main goals as PTL have been: - Moving project toward core release in Folsom with a core L2/L3 networking feature set. - Acting as a core developer and reviewing, contributing features and reviewing change-sets. - Growing the number of people contributing to to the project from a development, testing, and documentation perspective. - Helping people in the OpenStack community understand what Quantum is and why it can be useful, though activity on the mailing list and presenting at conferences. . - Making sure existing contributions are able to achieve their and their company's goals within Quantum and OpenStack as a whole. - Interfacing with those outside the community (vendors, media, etc.) to answer their questions on Quantum and help promote OpenStack in general. Moving forward in Grizzly, here are some thoughts of what I'm looking to have the team focus on during Grizzly: - continue to grow the number of people regularly contributing high quality community code reviews to the Quantum project - improve system test coverage for core quantum feature set - Improve documentation, both admin and developer. - identify and fix transition hurdles of people looking to move from nova-network to quantum - improve HA/Scale of some existing sub-systems, including DHCP/L3 (this includes a mechanism similar to nova-network multi_host flag) - add additional core quantum plugins from vendors new to the community. - explore internal architectures and external APIs for higher-level services. This will likely focus on L3/L4 packet filtering and Load-balancing, based on initial community input. Note: obviously we will tackle other issues in Grizzly as well, so don't worry if something you're looking to do is not on this list. We'll have the chance to discuss additional priorities in the time running up to the summit and at the summit itself. Thanks, Dan As an election official, I confirm that you are eligible to this position. d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nominations now open for OpenStack Project Technical Leads
Hey everyone! It's that time again :-) Anyone who would like to be a candidate for the forth-coming elections for the OpenStack Project Technical Leads may now submit their names! Valid candidates must currently be an Active Technical Contributor (within the 6 months prior to 23:59 PST August 29, 2012). The project for which they are running as PTL must be one of: Nova, Swift, Glance, Keystone, Horizon, Quantum, or Cinder. To submit your name for the ballot, please send an email to the OpenStack mail list with the following information included: To: openstack@lists.launchpad.net Subject: PROJECT_NAME PTL candidacy Body: Ideally, a description of your platform/what you aim to accomplish (and how!), your technical/leadership credentials, experience, etc. -- in short, anything that will be useful for voters to assess your qualifications as a technical lead for the OpenStack project of your passion. Timeline: Now: kickoff! Today through 5 Sep: * collect names of candidates who have submitted an email indicating their intent to run for election * verification of eligibility of candidate; confirmation sent by election officials to the openstack mail list * for each project, election officials will identify the list of valid voters (Active Technical Contributors; see the TechnicalCommittee wiki link below for more info) * verify the that the Active Technical Contributors are members of the OpenStack Foundation 6 Sep: Set up the online polls with the information gathered above. 7 Sep - 13 Sep: Hold the online elections (a separate announcement for this will be forthcoming). For more information (background and process), please see the following: * http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee * http://wiki.openstack.org/Governance/TCElectionsFall2012 * http://wiki.openstack.org/Projects Let us know if there's anything more we can do to make this process as transparent as possible! Thanks, and happy running ;-) d ___ 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] Individual Nominations for Foundation Board of Directors
On Thu, Jul 26, 2012 at 1:15 PM, Stefano Maffulli stef...@openstack.org wrote: On 07/26/2012 08:37 AM, Rick Clark wrote: Who is the election official, running this election. Nomination should be an open process, similar to the core dev process. Speaking of that process, it's broken and needs to be fixed ASAP, since we'll have the PTL elections soon. The current nomination process, especially, is broken: it requires way too much manual processing and more than manipulation, it allows mistakes (like in the past election, where I forgot to include one candidate to the list). This is how we ran it last time: http://wiki.openstack.org/Governance/ElectionsSpring2012 Want to help fix it? Yes! Let's define a better process and build the tools to automate it all. David Mertz of the Python Software Foundation is currently working on fixing lots of the same problems that we -- in the OpenStack community -- are now facing or will be soon. Count me in :-) I'll start pulling information and resources together for this, and when I've landed from my travels, I'll send an update to this thread with links. d ___ 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] Please vote for the name of the G release
I the future, I'd like to suggest Condorcet voting for future polls. It's a more comprehensive voting mechanism than the polling done on Launchpad. It's also easy to use (both in creating polls and in voting on favorites). Here's an example set of results (favorite programming language poll): http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_540fe382529392ba Here's the poll, if you'd like to vote :-) http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/vote.pl?id=E_540fe382529392ba d On Thu, Jul 5, 2012 at 4:03 AM, Thierry Carrez thie...@openstack.org wrote: The public polls to determine the name of the OpenStack G release (due in Spring 2013) are now open. All members of the openstack group in Launchpad can vote, and membership to that group is open[1]. The polls will close Tuesday, July 10, 21:45 UTC. Due to the Bear Flag Revolt, there are actually two polls you need to participate in: First, you need to decide whether we should amend our naming rules and just call it Grizzly, or keep our rules and go with the result of the second poll. You can do that here: https://launchpad.net/~openstack/+poll/g-stands-for-grizzly Then you can select the name the G release should have in case we choose to keep our current rules: https://launchpad.net/~openstack/+poll/g-release-naming Happy voting! [1] https://launchpad.net/~openstack -- 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] Please vote for the name of the G release
On Wed, Jul 11, 2012 at 10:46 AM, Thierry Carrez thie...@openstack.org wrote: Duncan McGreggor wrote: I the future, I'd like to suggest Condorcet voting for future polls. It's a more comprehensive voting mechanism than the polling done on Launchpad. It's also easy to use (both in creating polls and in voting on favorites). It's also extremely easy to game if you don't provide a set of voters email addresses. We want all the community involved in picking the name (so all the ~openstack group in Launchpad) but we don't have all email addresses, and we don't want some group to stuff the ballot and let Greenville win. The only way to game the Launchpad poll system is to create a thousand Launchpad IDs : it sounds like a high-enough barrier of entry to fraud. CIVS poll stuffing is just a click away. Basically Launchpad polls are in the sweet spot between convenience, accuracy and fraud-resistance. Fair point ;-) You just don't know what the Bear Revolt crew was ready to do to let Grizzly win :) *laughs* Not the BEAR REVOLT!!! d ___ 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-operators] New mailing list server
On Thu, Jul 5, 2012 at 5:06 PM, Stefano Maffulli stef...@openstack.org wrote: Thanks to Duncan McGreggor, James E. Blair and Antony Messerly, we now have a new mailing list server. Don't forget Barry Warsaw! He helped us find a last-minute corrupted pickle file issue right at the very end of our maintenance window :-) The new mailing list server has better looking archives and info pages for the individual lists, integrated with the look-and-feel of other openstack.org websites. [snip] And for this awesomeness, we can thank Stefano himself! Thanks, team! d ___ 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] cfg usage - option registration, global objects
+1 :-) d On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger mark.washenber...@rackspace.com wrote: Hi Mark, Please forgive the top-posting! I always get way too wordy with inline replies. Regarding configuration, I think there is another option I'd like us to adopt. We should implement the code as in your option #1, but then implement convenience factories that give the appearance of option #3 or #2, or both, you pick. From your examples it might look something like this: class Connection(object): def __init__(self, broker_hostname, broker_port): self.cnx = self.connect(broker_hostname, broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) def connection_from_global_conf(): return Connection(CONF.broker_hostname, CONF.broker_port) I think its pretty necessary that we don't do option #3 directly. There are some important use cases to consider, like migrating from one rpc implementation to another where you might want an adapter that can relay messages from one to the other. Also, cells with kombu at least requires that one process be able to talk to multiple brokers. Regarding incubation, I suppose I am confused. At what point during incubation do other projects start to use the shared library? I would imagine the answer to be after incubation but it sounds like there are several projects very eager to adopt rpc as soon as it lands in openstack common, even before incubation is complete. If incubation happens before the calcifying effects of shared use set in, then it sounds like a great place to address the other rpc-specific concerns we've talked about. Otherwise I guess we're stuck where I thought we were, where the bar needs to be set pretty high to initially land in os-common. Mark McLoughlin mar...@redhat.com said: Hi Mark, On Thu, 2012-05-31 at 10:48 -0400, Mark Washenberger wrote: Jay Pipes jaypi...@gmail.com said: On 05/29/2012 04:04 AM, Mark McLoughlin wrote: Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. Unfortunately, what this leads to is interdependencies between the openstack-common-rpc code and the openstack-common-cfg code. :( Now, if someone wants to use the openstack RPC code in their own project, they have to switch their way of configuring stuff to use global config objects. Tight coupling means less adherence to the do one thing and do it well mantra of *nix utilities and libraries and in general isn't good software design. I personally would consider a rigid connection between the rpc library and the configuration to be inappropriate in the context of openstack common. This is a fairly general design question for openstack-common. If the behaviour of any given API should be dependent on the configuration of the service (i.e. in nova.conf, glance-api.conf, keystone.conf), then how should we design the API to handle that? Three options: 1) The API knows nothing about cfg: class Connection(object): def __init__(self, broker_hostname, broker_port): self.cnx = self.connect(broker_hostname, broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) 2) The API is passed a ConfigOpts instance: class Connection(object): def __init__(self, conf): self.cnx = self.connect(conf.broker_hostname, conf.broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) 3) The API uses the global config object class Connection(object): def __init__(self): self.cnx = self.connect(CONF.broker_hostname, CONF.broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) I see (1) as having value if we want the API to be usable outside OpenStack. That might be worthwhile long term, but openstack-common's goal is to provide APIs shared between OpenStack projects. (2) and (3) have the huge benefit of configuration consistency - the same configuration keys, defaults, etc. shared across projects. (2) has value if there are cases where we want to use a non-global cfg object. Quantum might have this use case if it continues parsing plugin configuration separately from its main configuration. We'll see. (3) has value if all use cases are using a global object. I can see us getting to a point where we support both (2) and (3). I'm dubious of the value of (1) in the medium term, but maybe we might find a compelling use case for it. I'm also very happy to contribute modifications that would eliminate that connection. There are a few other reasons
Re: [Openstack] cfg usage - option registration, global objects
On Thu, May 31, 2012 at 11:26 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger mark.washenber...@rackspace.com wrote: Jay Pipes jaypi...@gmail.com said: On 05/29/2012 04:04 AM, Mark McLoughlin wrote: Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. Unfortunately, what this leads to is interdependencies between the openstack-common-rpc code and the openstack-common-cfg code. :( Now, if someone wants to use the openstack RPC code in their own project, they have to switch their way of configuring stuff to use global config objects. Tight coupling means less adherence to the do one thing and do it well mantra of *nix utilities and libraries and in general isn't good software design. I personally would consider a rigid connection between the rpc library and the configuration to be inappropriate in the context of openstack common. I'm also very happy to contribute modifications that would eliminate that connection. There are a few other reasons I'm concerned about nova's rpc implementation becoming the de facto standard. It has grown up organically and as such has some significant issues we should probably address before we create a precedent that other projects must adopt it to be good community members. From a brief scan, it seems to me that a restructured implementation of rpc that lands in common should * not be tied up with eventlet on the consumer side * let the consumer code decide when to ack a message (although maybe the concept of acking doesn't exist for all implementations?) * not depend on a global singleton _RPC_IMPL * leave out/refactor some unused or non-general aspects, such as multicall, fanout_cast_to_server, notify, and fanout_cast (not so sure about that last one) It would also be useful if it had a way to subscribe to notification messages. From what I can tell, notifications don't work with any of the consumers in the existing drivers because those consumers all want to dispatch to a method invocation, but notifications aren't structured appropriately for that. I would like to abstract the messaging layer out of the existing nova RPC library and then build a compatible RPC layer on top of it. Notifications and other simple messages (such as meter data for ceilometer) would use the lower layer, and communication that truly works like RPC could use the higher level API. We should be able to build an agnostic RPC layer that uses the messaging driver, instead of having the two concepts bound up together. A very hearty +1. d ___ 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] cfg usage - option registration, global objects
On Thu, May 31, 2012 at 4:21 PM, Mark McLoughlin mar...@redhat.com wrote: Hi Mark, On Thu, 2012-05-31 at 10:48 -0400, Mark Washenberger wrote: Jay Pipes jaypi...@gmail.com said: On 05/29/2012 04:04 AM, Mark McLoughlin wrote: Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. Unfortunately, what this leads to is interdependencies between the openstack-common-rpc code and the openstack-common-cfg code. :( Now, if someone wants to use the openstack RPC code in their own project, they have to switch their way of configuring stuff to use global config objects. Tight coupling means less adherence to the do one thing and do it well mantra of *nix utilities and libraries and in general isn't good software design. I personally would consider a rigid connection between the rpc library and the configuration to be inappropriate in the context of openstack common. This is a fairly general design question for openstack-common. If the behaviour of any given API should be dependent on the configuration of the service (i.e. in nova.conf, glance-api.conf, keystone.conf), then how should we design the API to handle that? Three options: 1) The API knows nothing about cfg: class Connection(object): def __init__(self, broker_hostname, broker_port): self.cnx = self.connect(broker_hostname, broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) 2) The API is passed a ConfigOpts instance: class Connection(object): def __init__(self, conf): self.cnx = self.connect(conf.broker_hostname, conf.broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) 3) The API uses the global config object class Connection(object): def __init__(self): self.cnx = self.connect(CONF.broker_hostname, CONF.broker_port) def cast(self, topic, msg): self.cnx.cast(topic, msg) I see (1) as having value if we want the API to be usable outside OpenStack. That might be worthwhile long term, but openstack-common's goal is to provide APIs shared between OpenStack projects. (2) and (3) have the huge benefit of configuration consistency - the same configuration keys, defaults, etc. shared across projects. (2) has value if there are cases where we want to use a non-global cfg object. Quantum might have this use case if it continues parsing plugin configuration separately from its main configuration. We'll see. (3) has value if all use cases are using a global object. Also note that a configuration registry (per my previous email) can satisfy both approaches outlined in 2) and 3). d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: [Infra] administration of new mailinglists
On Wed, May 30, 2012 at 10:11 AM, Thierry Carrez thie...@openstack.org wrote: Stefano Maffulli wrote: On Tue 29 May 2012 10:36:05 AM PDT, James E. Blair wrote: Someone pointed out that since the security announcements _haven't_ been going to the announce list, but the main mailing list instead, that they are concerned that people may have missed them. That seems like a very important and valid concern to me. Same here, I'm concerned that important information is sent out through the wrong channel, not reaching the relevant people. I think the -announce list can be used as a reference channel, from where given posts can be highlighted in Twitter, blogposts, weekly newsletter, etc. To punt and say people will see it on G+ or Twitter or whatever (as stated elsewhere in this thread) isn't good enough for a project of this size. What user should they follow? What hashtag should they search for? Fundamentally, the same problems will show up That's because, fundamentally, sending out a message to the relevant people is a complex problem. Even if you setup the announce- list, you still have to make sure that people will subscribe to it, and make sure the announcers will use it properly. I assumed that since the list existed formally but nobody cared to use it, it was not needed. In addition to mentioning the list on getting started pages, if you keep on pointing to the -announce archived posts when tweeting about something, some people will realize subscribing to the source will give them earlier access to the information. If they care enough, they will subscribe. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? Release team. Security team. Sounds good enough for me. If those teams want to take care of it, I don't have a problem, as long as they're happy with such a tool. [...] We clearly have two different use cases in mind. Since now it's clear that the announce list is for the release and security team, I remove my objection to have a list for announcements. I think we should also formally announce things like elections and election results on that (reference) channel. Obviously the news would be echoed in a lot of other channels, like the OpenStack blog/newsletter. All good points. +1 d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Thierry Carrez thie...@openstack.org Date: Sat, May 26, 2012 at 2:38 PM Subject: Re: administration of new mailinglists To: Monty Taylor mord...@inaugust.com Cc: Stefano Maffulli stef...@openstack.org, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com Monty Taylor wrote: On 05/25/2012 03:27 AM, Thierry Carrez wrote: Stefano Maffulli wrote: On 05/23/2012 05:58 PM, Stefano Maffulli wrote: http://etherpad.openstack.org/newmlist-layout re-reading this list, I think it's not clear to me what purpose the 'old' list on launchpad will serve. How shall we re-purpose it? If we keep it, do we need to keep also operators (in what would they differ?) The current list (the General list) is the default discussion list about everything openstack. We have decided to move the development discussions (focused on the next release of OpenStack) out of this list and on its own list. That doesn't suddenly make it empty. It's still the list for discussing everything openstack, with a focus on the latest stable release. I think we should keep it, because it is certainly the biggest openstack list out there, with 2072 subscribers. tl;dr - I could not possible disagree more strongly. There should be one place for mailing lists. If we are running our own mailman properly already, this list should move there. I think the 2072 subscribers will be able to figure out it. That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) Alternatively we can have a more classic: openstack-announce@l.o.o - Important announcements openstack-users@l.o.o - discussion about using openstack, present-lookin openstack-dev@l.o.o - development discussions - forward-looking We would rename operators to users and encourage current subscribers to join it. Two questions: how do you merge the old archives with the operators archive ? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? -- 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
[Openstack] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Stefano Maffulli stef...@openstack.org Date: Tue, May 29, 2012 at 11:13 AM Subject: Re: administration of new mailinglists To: Thierry Carrez thie...@openstack.org Cc: Monty Taylor mord...@inaugust.com, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com On 05/26/2012 11:38 AM, Thierry Carrez wrote: That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. I don't think there is an easy way to migrate over 2000 users from one place to another but I also think that we should have one place for all the lists, ideally. Moving those subscribers will not be an easy task, so I would consider that a project in itself. We should move this discussion to the public list. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) I like this setup, so we don't have to change names/addresses. We can keep openstack@ on LP until we have the new l.o.o up and running. Migrating will be complicate. We would rename operators to users and encourage current subscribers to join it. I don't see the value in renaming the list. Why would you want to create this pain for the current subscribers? Two questions: how do you merge the old archives with the operators archive ? which old archives? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? You'll have to work very hard to convince me that an announce list is worth the trouble :) 'Tradition' is not a good argument. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? I'll start enumerating why I don't think such list is needed by community managers: - more lists, more policies, more complexity for newcomers, things that they need to learn. - more lists, more policies, more complexity to manage (moderators, spam masters, etc) - the announce list has not been used for over 8 months, nobody noticed - multiplying contact points for people increases the need for cross-posting, more messages - an announce is fundamentally a one-way communication, no need to have 'discussions' around it, mailing list is the wrong tool *today* (it made sense in the 90s) - an announce sent to a mailman list is fundamentally shouting in the wind: there might be people listening, you'll never know if they heard something. A *segmented* (developers, operators, business folks) newsletter is the best way to send out announcements. /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Monty Taylor mord...@inaugust.com Date: Tue, May 29, 2012 at 11:24 AM Subject: Re: administration of new mailinglists To: Stefano Maffulli stef...@openstack.org Cc: Thierry Carrez thie...@openstack.org, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com On 05/29/2012 11:13 AM, Stefano Maffulli wrote: On 05/26/2012 11:38 AM, Thierry Carrez wrote: That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. I don't think there is an easy way to migrate over 2000 users from one place to another but I also think that we should have one place for all the lists, ideally. Moving those subscribers will not be an easy task, so I would consider that a project in itself. We should move this discussion to the public list. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) I like this setup, so we don't have to change names/addresses. We can keep openstack@ on LP until we have the new l.o.o up and running. Migrating will be complicate. We would rename operators to users and encourage current subscribers to join it. I don't see the value in renaming the list. Why would you want to create this pain for the current subscribers? Two questions: how do you merge the old archives with the operators archive ? which old archives? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? You'll have to work very hard to convince me that an announce list is worth the trouble :) 'Tradition' is not a good argument. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? I'll start enumerating why I don't think such list is needed by community managers: - more lists, more policies, more complexity for newcomers, things that they need to learn. - more lists, more policies, more complexity to manage (moderators, spam masters, etc) - the announce list has not been used for over 8 months, nobody noticed - multiplying contact points for people increases the need for cross-posting, more messages - an announce is fundamentally a one-way communication, no need to have 'discussions' around it, mailing list is the wrong tool *today* (it made sense in the 90s) - an announce sent to a mailman list is fundamentally shouting in the wind: there might be people listening, you'll never know if they heard something. A *segmented* (developers, operators, business folks) newsletter is the best way to send out announcements. I agree with this about the announce list. Announcements these days are usually done via some combination of blog/rss/twitter. ___ 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] cfg usage - option registration, global objects
On Tue, May 29, 2012 at 4:04 AM, Mark McLoughlin mar...@redhat.com wrote: Hey, I had the chance to discuss the global conf issue with a good number of folks at the design summit and the conclusion I came away with was that opinions range from meh, it's fairly inelegant but I don't care much either way to I actually like the simplicity to we use global conf, it works and we're not changing. Indeed, at the common configuration patterns, there was very little in the way of opinion expressed at all: http://etherpad.openstack.org/FolsomCommonConfigPatterns Given that my goal here is to establish a common pattern used by all projects, that both Nova and Keystone uses global conf and there isn't a huge amount of interest in moving away from it, I'm proposing adding support for it to openstack-common: https://blueprints.launchpad.net/openstack-common/+spec/cfg-global-object Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. Though not a fan of global objects, I've used (and still do use) them to simplify things. 99% of my usage of them in other projects are for configuration, as one might expect. I've avoided this in the past through passing parameters, but that often ends up quite messy and rather cumbersome to trace when debugging. More often than not, even when passed, configuration ends up getting used in contexts that are almost global anyway. If I do use a global object, I am deeply loathe to do it without the following: * ample documentation - how to use it, when not to use it, what one needs to do first, etc. * an API for it - no direct use of an object itself I have used zope.components to address the last point (the first one being addressed by good discipline ;-) ). It's simple to use: from zope.component import getGlobalSiteManager, getUtility from zope.interface import Interface class IConfig(Interface): A marker interface for configuration instances. gsm = getGlobalSiteManager() gsm.registerUtility(some_config_object, IConfig) That's done once, often in the __init__.py of a subpackage. All child modules and/or subpackages should need that configuration to be declared. Any code that doesn't need such configuration should be in a sibling (or higher) subpackage. Any time you need the config object: config = getUtility(IConfig) Note that you can register any object using this approach (including imported modules). The use of a marker interface may seem like overkill, but it provides a very natural place for documentation. Also, I usually wrap these calls in convenience functions in my projects, making use as simple, self-documenting, and maintainable as possible. More benefits to this approach (and why I chose to use it): I've got several projects (non-OpenStack) that have one or more other projects as their base -- the base project defines a configuration setup that is used in part or completely by the projects which depend upon it. zope.components let's me use a global registry to look up a config by interface, and this means that as long as a child project registers its config before the parent/base project code does, the base project code will be referencing the child projects configs. This does require strong import discipline, and careful subpackage organization, but I've found it a wonderful compromise for the global configuration problem. Note that the Pyramid project also uses the zope.components capabilities for configuration registry, so you might want to check out their code for potential use-cases. Hope this is helpful, d I've posted patches to openstack-common, Nova, Glance and Keystone: https://review.openstack.org/#/q/status:open+branch:master+topic:bp/cfg-global-object,n,z Cheers, Mark. On Tue, 2012-03-06 at 10:10 +, Mark McLoughlin wrote: Hey, The original cfg design[1] assumed certain usage patterns that I hoped would be adopted by all projects using it. In gerrit, we're debating a set of patch to make keystone use these patterns: https://review.openstack.org/4547 I thought it was best to move some of that discussion here since I'm hoping we can get some rough consensus across projects. I really think it will be beneficial if we can share common idioms and patterns across projects, rather than just using the same library in different ways. [snip] Thread archived here: https://lists.launchpad.net/openstack/msg08329.html ___ 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 :
Re: [Openstack] [Infra] Mailing-list split
On Thu, May 10, 2012 at 3:28 PM, James E. Blair cor...@inaugust.com wrote: Duncan McGreggor dun...@dreamhost.com writes: I want to wait on creating openstack-dev until we've got Exim setup properly. Someone else will need to do that. I'm not sure if the mailman Ubuntu package updates Exim properly, and I wouldn't know where to look to check :-/ Take a look at this: https://review.openstack.org/#/c/7319/ It's merged now! Thanks, guys :-) Once it's merged, you (or anyone else) can make changes to the mailman config by proposing patches to that repo. Nice. I'm asking you about this on IRC right now :-) The Exim config will automatically handle new lists (no aliases or any config changes need to happen after running the newlist command). That change enables VERP, but has Exim generate the VERP addresses for efficiency. We need to talk about migrating data: * from the old host to the new one * from LP archives (don't know if that's possible) Do you have access to the old host? I believe Stef knows who to ask to get archives from LP. We need to figure out DNS, and see what we can do about testing the lists/Exim with just the IP address/temp CNAME/etc ... Let me know if you want a temporary alternate A/CNAME record. You'll notice the exim/mailman config has that as a parameter, so it'll be easy for us to change it back. Yeah, let's to a temporary CNAME (actually, maybe A is better? lists.openstack.org points elsewhere...). How about stagelists.openstack.org? We will be able to set the reverse dns for the IP correctly. And when it comes time for the move, we can set the ttl to 300 and make the change for the A record. Nice! Thanks, Jim! d -Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Infra] Mailing-list split
Oh, one more thing: On Thu, May 10, 2012 at 3:28 PM, James E. Blair cor...@inaugust.com wrote: Duncan McGreggor dun...@dreamhost.com writes: [snip] We need to talk about migrating data: * from the old host to the new one * from LP archives (don't know if that's possible) Do you have access to the old host? I believe Stef knows who to ask to get archives from LP. Yeah, Stef and Ant are working on that. I'm thinking we shouldn't copy the archives until we've actually made the switch, so that we don't miss any messages that might have made it to the old lists in the interim... d ___ 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] Mailing-list split
On Fri, Apr 27, 2012 at 9:44 AM, Duncan McGreggor dun...@dreamhost.com wrote: On Fri, Apr 27, 2012 at 8:46 AM, Monty Taylor mord...@inaugust.com wrote: Hey everyone! On 04/27/2012 05:04 AM, Thierry Carrez wrote: To avoid Launchpad list slowness, we would run the new openstack-dev list off lists.openstack.org. Given the potential hassle of dealing with spam and delivery issues on mission-critical MLs, we are looking into the possibility of outsourcing the maintenance of lists.openstack.org to a group with established expertise running mailman instances. Please let us know ASAP if you could offer such services. We are not married to mailman either -- if an alternative service offers good performance and better integration (like OpenID-based subscription to integrate with our SSO), we would definitely consider it. Just to be clear - I definitely think that mailing lists are an important part of dev infrastructure and would love for this to be a fully integrated part of all of the rest of our tools. However, the current set of active infrastructure team members have huge todo lists at the moment. So the biggest home run from my perspective would be if someone out there had time or resources and wanted to join us on the infra team to manage this on our existing resources (turns out we have plenty of servers for running this, and even a decent amount of expertise, just missing manpower). The existing team would be more than happy to be involved, and it would help avoid get-hit-by-a-truck issues. We're a pretty friendly bunch, I promise. Any takers? Anybody want to pony up somebody with some bandwidth to admin a mailman? Respond back here or just find us in #openstack-infra and we'll get you plugged in and stuff. Thanks! Monty Count me in, Monty. I've been managing mailman lists for about 12 years now (and, incidentally, Barry and I are bruthas from anutha mutha), so I'd be quite comfortable handling those responsibilities. I can couple it with the python.org SIG mail list that I manage, so there'd be zero context switching. d Hey folks, quick update for ya... Here are some Etherpads for this effort: * http://etherpad.openstack.org/openstack-dev-ml-prefixes * http://etherpad.openstack.org/lists-changes * http://etherpad.openstack.org/mailmain-install-and-notes * http://etherpad.openstack.org/mailmain-migration-notes Mailman is installed, with the site-wide mailman list set up. James Blair has been working on the Exim set up, and I'll be following up on his changes when I get some time this weekend. It would be great to migrate our old mail list data: * from the old host to the new one * from LP archives (don't know if that's possible) Some of us know folks who maintain launchpad (and mailman, for that matter), so we'll be reaching out to folks at Canonical to see what we can do here. James Blair also has a good plan for DNS, setting a hostname set up for testing, and then rolling over once we're ready to go live. ttx had some good input on making sure the list description had the necessary info about tagging subjects in list emails. Stef had some ideas about customizing the look and feel. That's all in the notes linked above. There have been other conversations in various places, and I'll gather those up and send out another email. More soon, d ___ 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] Mailing-list split
Re-sending to the list... On Fri, May 4, 2012 at 6:07 PM, Stefano Maffulli stef...@openstack.org wrote: On Fri 04 May 2012 12:38:16 PM PDT, Duncan McGreggor wrote: Oh, gmane is fine, I just said the first thing that came into my head. Now that I think about it, I'm a Emacs/Gnus guy, so I guess if I did have an opinion, it would probably be go gmane. :) they're all suboptimal but so much better than pipermail... or not... the situation is just bad. Lets wait for MM3 or something else. I can't find the openstack list on gmane: is there an archive there now? We'll subscribe to gmane (which can also add us to mail-archive.com) as soon as the lists are in their new locations. We need to talk about migrating data: * from the old host to the new one * from LP archives (don't know if that's possible) we can migrate data from LP archives (we can ask them for the mbox). I wonder if we need to do that though. It'd be nice to offer folks as a download, so they can search mail archives off-line. I've certainly done that in the past. d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone client, user belongs to many tenants?
Hey guys, Just wanted to say that I'm deep, deep into some Keystone right now (auth'ing against DreamHost's existing infrastructure and granting access to tenants, etc.) and this email just saved me about a week of work :-) Thanks! d On Thu, May 10, 2012 at 10:25 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Thu, May 10, 2012 at 9:00 AM, Lorin Hochstein lo...@nimbisservices.com wrote: Are there any documented examples out there of how to use roles? I still have a hard time building a mental model of how the system works. In particular: Do I need to create a new role for every user-tenant pair? Or can I reuse the same role? You can recycle roles. Role names are also unique. A member role is frequently used in the docs, where you can grant membership to a user on a specific tenant. Creating and granting this role to two users on different tenants using keystoneclient looks something like: # create two tenants $ keystone tenant-create --name=Tenant A tenant-id-a $ keystone tenant-create --name=Tenant B tenant-id-b # create two users $ keystone user-create --name=User A user-id-a $ keystone user-create --name=User B user-id-b # create a membership role $ keystone role-create --name=member role-id # (Neither user can access either tenant at this point.) # grant User A membership on Tenant A $ keystone user-role-add --role_id=role-id --tenant_id=tenant-id-a --user_id=user-id-a # User A is now a member of Tenant A. # (User B still has access to nothing at this point.) # grant User B membership on Tenant B $ keystone user-role-add --role_id=role-id --tenant_id=tenant-id-b --user_id=user-id-b # User B is now a member of Tenant B, but not Tenant A. # (and User A is still a member of Tenant A, but not Tenant B.) Where are the semantics of roles specified? What I mean is, what determines what a role allows a user to do with a specific service? Right now, that's entirely managed by each service's policy.json -- keystone does nothing but provide the role names to each OpenStack service. This will change a bit during folsom, with the introduction of RBAC (bp https://blueprints.launchpad.net/keystone/+spec/rbac-keystone). The contents of each service's policy.json will be centrally managed in keystone, and the meaning of the roles a user has (the user's set of capabilities in the current authentication context) will be provided to OpenStack services -- so service's will no longer need to understand role names. The examples I see always create a magical admin role, but how does, say, nova, know that this role is associated with admin privileges? Is it because the label is admin? Today, this is configurable via Nova's policy.json: https://github.com/openstack/nova/blob/master/etc/nova/policy.json What if I want to create a role that allows users in a tenant to have regular access to nova, but not to swift? How do I do that? Do I need to create a novaUser role? Where do I describe what a novaUser role means? In nova? In keystone? How? See above; not sure about swift's status, though. Pointer to an example here would be really helpful, would love to add this to the docs. Let me know if you find the above useful; or feel free to revise and submit :) Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On May 10, 2012, at 3:50 AM, Dolph Mathews wrote: +1 The second way to accomplish this is exactly what keystone currently supports (explicit role grants), which didn't change between diablo and essex at all. The first method (using global unscopedness) was dropped because its just as confusing as you describe it. -Dolph Mathews On May 10, 2012, at 2:35 AM, Joseph Heck he...@mac.com wrote: Guang, I think you need to re-read the code. The association between a user and tenant is what the role represents, and its inaccurate to assert that a user is aligned only with a single tenant ever, that is not the case. A role is no longer global, specifically to avoid the tremendous confusion and inaccuracy of implementation about how to apply a role that relates a tenant and user along with a potential global role concept that was in the earliest implementations of Keystone. The current implementation is simpler and far more specific and clear in it's implementation. -joe On May 9, 2012, at 10:22 PM, Yee, Guang wrote: I think this use case underscores one of the key differences between the fat Keystone (Diablo - E3) and KSL (Essex final). In fat Keystone, users and tenants are loosely coupled. They are bind together by role assignments. In KSL, users and tenants are tightly coupled, and IMHO very inflexible. Maybe the following example would further clarify this … Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, roles Commissioner and Minority Owner, and service MLB. And you want Bud Selid to have
Re: [Openstack] [Nova] [Ops] Blueprints for Folsom
On Mon, May 7, 2012 at 7:16 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello everyone, The number of blueprints for nova has gotten entirely out-of-hand. I've obsoleted about 40 blueprints and there are still about 150 blueprints for nova. Many of these are old, or represent features that are cool ideas, but haven't had any activity in a long time. I've attempted to target all of the relevant blueprints to Folsom. You can see the progress here: https://blueprints.launchpad.net/nova/folsom I would like to get our nova blueprints cleaned up as much as possible. In one week, I am going to mark all blueprints that are not targeted to folsom Obsolete. This will allow us to start over from a clean slate. So here is what I need from everyone: 1. If you see a blueprint on the main nova list that is not targeted to folsom that should stay around, please let me know ASAP or it will get deleted: https://blueprints.launchpad.net/nova 2. Operational Support Team, there are a bunch of blueprints that are not targeted to folsom, so please either target them or mark them obsolete by next week. Yeah, I've been fishing for takers on the ops list, and no one has volunteered. I'll move them out of the Ops Support Team until folks want to take them on, so that they don't show up for project tracking in folsom. d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] heads up regarding keystone dev venv on an Ubuntu VM (VirtualBox)
Hey folks, We're really pressed for time right now, so there are certain rabbit holes we can't dive down, but I wanted to bring this up in case it hasn't been seen yet. On Mac OS X 10.6 and 10.7, when running a 12.04 Ubuntu VM and setting up the dev env for Keystone, we get some madness. 10.6: VirtualBox instance aborts, leaving no traces of issue in system logs (that I could see) 10.7: VB dies, OS X kernel panics The second time, I watched carefully, and it happened as python-memcached was getting installed via pip in the .venv. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up after I removed .venv and changed tools/install_venv.py to enable system site-package use. d ___ 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] heads up regarding keystone dev venv on an Ubuntu VM (VirtualBox)
Updates: * Doug Hellmann narrowed this down to the network access that was happening with pip * Mark McClain further narrowed it down to VirtualBox's networking: with a NATed interface, big probs -- with a bridged interface, things go well. I haven't taken the time to check this on my own system, since I've got a working solution right now, but when I need to rebuild, I will check. Mark also mentioned that VBox networking sometimes does some weird stuff (rewriting headers or something) and that might be contributing to the problem. Hope this helps, d On Fri, May 4, 2012 at 12:40 PM, Duncan McGreggor dun...@dreamhost.com wrote: Hey folks, We're really pressed for time right now, so there are certain rabbit holes we can't dive down, but I wanted to bring this up in case it hasn't been seen yet. On Mac OS X 10.6 and 10.7, when running a 12.04 Ubuntu VM and setting up the dev env for Keystone, we get some madness. 10.6: VirtualBox instance aborts, leaving no traces of issue in system logs (that I could see) 10.7: VB dies, OS X kernel panics The second time, I watched carefully, and it happened as python-memcached was getting installed via pip in the .venv. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up after I removed .venv and changed tools/install_venv.py to enable system site-package use. d ___ 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] heads up regarding keystone dev venv on an Ubuntu VM (VirtualBox)
Nope, sadly :-( Straight-up VirtualBox is where we were having troubles. (Although Mark is using Vagrant for some other stuff). d On Fri, May 4, 2012 at 4:24 PM, Lorin Hochstein lo...@nimbisservices.com wrote: Duncan: Are you using Vagrant? I saw a recent Vagrant update (1.0.3) that dealt with a networking issue with Ubuntu 12.04, but it was DNS-related: https://github.com/mitchellh/vagrant/commit/6f5a9d13f3afb64c3efacb7a0873226d68bba10a https://github.com/mitchellh/vagrant/commit/93d0821220dbe483bd1d129969ac18d914901bb4 Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On May 4, 2012, at 12:59 PM, Duncan McGreggor wrote: Updates: * Doug Hellmann narrowed this down to the network access that was happening with pip * Mark McClain further narrowed it down to VirtualBox's networking: with a NATed interface, big probs -- with a bridged interface, things go well. I haven't taken the time to check this on my own system, since I've got a working solution right now, but when I need to rebuild, I will check. Mark also mentioned that VBox networking sometimes does some weird stuff (rewriting headers or something) and that might be contributing to the problem. Hope this helps, d On Fri, May 4, 2012 at 12:40 PM, Duncan McGreggor dun...@dreamhost.com wrote: Hey folks, We're really pressed for time right now, so there are certain rabbit holes we can't dive down, but I wanted to bring this up in case it hasn't been seen yet. On Mac OS X 10.6 and 10.7, when running a 12.04 Ubuntu VM and setting up the dev env for Keystone, we get some madness. 10.6: VirtualBox instance aborts, leaving no traces of issue in system logs (that I could see) 10.7: VB dies, OS X kernel panics The second time, I watched carefully, and it happened as python-memcached was getting installed via pip in the .venv. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up after I removed .venv and changed tools/install_venv.py to enable system site-package use. d ___ 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] heads up regarding keystone dev venv on an Ubuntu VM (VirtualBox)
(Adding Sean at tummy, in case this is useful info for him.) Nice detective work, Jeremy! d On Fri, May 4, 2012 at 8:27 PM, Jeremy Hanmer jeremy.han...@dreamhost.com wrote: After quite a bit of experimentation, I've noticed that the crash is triggered by pip when accessing ftp://tummy.com specifically. After doing some network dumps, it's apparent that after the connection is initiated we receive an ICMP Host Administratively Prohibited message. My assumption is that this message is seen by VirtualBox, who then tears down the NAT session but fails to pass the ICMP message along to the guest (hard to verify because of how quickly the guest gets killed off). When the guest tries to transfer the first bit of data over the NAT link, I'm guessing it causes something along the lines of a null pointer deref. I'll throw in some of the debug info I've got but the problem is trivial to reproduce: simply run pftp tummy.com, log in anonymously, and try an ls. Process: VirtualBoxVM [16548] Path: /Applications/VirtualBox.app/Contents/MacOS/VirtualBoxVM Identifier: VirtualBoxVM Version: ??? (???) Code Type: X86-64 (Native) Parent Process: VBoxSVC [16535] Date/Time: 2012-05-04 17:14:19.640 -0700 OS Version: Mac OS X 10.7.3 (11D50b) Report Version: 9 Crashed Thread: 22 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0010 On May 4, 2012, at 2:31 PM, Duncan McGreggor wrote: Update: Jeremy Hanmer said that it looks like it's a port lookup that's failing and taking cfprefsd with it. He's gone over my head, but I'm sure that's meaningful to someone out there ;-) d On Fri, May 4, 2012 at 12:59 PM, Duncan McGreggor dun...@dreamhost.com wrote: Updates: * Doug Hellmann narrowed this down to the network access that was happening with pip * Mark McClain further narrowed it down to VirtualBox's networking: with a NATed interface, big probs -- with a bridged interface, things go well. I haven't taken the time to check this on my own system, since I've got a working solution right now, but when I need to rebuild, I will check. Mark also mentioned that VBox networking sometimes does some weird stuff (rewriting headers or something) and that might be contributing to the problem. Hope this helps, d On Fri, May 4, 2012 at 12:40 PM, Duncan McGreggor dun...@dreamhost.com wrote: Hey folks, We're really pressed for time right now, so there are certain rabbit holes we can't dive down, but I wanted to bring this up in case it hasn't been seen yet. On Mac OS X 10.6 and 10.7, when running a 12.04 Ubuntu VM and setting up the dev env for Keystone, we get some madness. 10.6: VirtualBox instance aborts, leaving no traces of issue in system logs (that I could see) 10.7: VB dies, OS X kernel panics The second time, I watched carefully, and it happened as python-memcached was getting installed via pip in the .venv. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up after I removed .venv and changed tools/install_venv.py to enable system site-package use. d ___ 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] [offtopic] Occasion to learn from Ubuntu Developer Summit how to enable remote participation
On Thu, May 3, 2012 at 8:44 PM, Stefano Maffulli stef...@openstack.org wrote: Hello folks, The Ubuntu IS team is setting up their famous infrastructure for UDS on Sunday from 9am-6pm. This may be a good chance for people that are already in the San Francisco/Oakland to learn a few tricks from the experts. If you're interested in learning how they deploy their network infrastructure and enable remote participation let me or Jorge Castro know. I couldn't agree with you more on this! I attended abotu 6 UDS from 2008 to 2011, -- elmo and crew REALLY rock out the infrastructure and support for an event that is super-intense, super-focused, and one of the most amazing aspects of the core development community in Ubuntu. There's often a significant amount of remote participation -- and not just listening! I mean remote folks, being engaged in the discussions, planning, architecting, etc., right there on IRC while discussions are being broadcast. Good stuff! Wish I was there with you guys right now! Let us know how it goes... d ___ 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 Client Followup
On Tue, May 1, 2012 at 7:55 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: There are a couple of ways to handle that: 1. A separate openstackadmin CLI that looks for commands using a different plugin namespace, and therefore only loads the admin commands. 2. Prefix admin-related commands in the unified cli with admin (so openstack admin create network or whatever). +1 on this proposition. d ___ 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 Client Followup
You make some fair points. But consider the large class of cloud users that will never need to bring up OpenStack from scratch, but rather maintain them. These users will need to be able to easily identify the commands that pertain to their daily maintenance, troubleshooting, and reporting tasks. Design of a CLI tool for different audiences is just as important as visual interface design. However, anticipating that now, before we have solid usage data, may be premature. In order to eventually deliver improved organization of CLI commands and a good usability experience for all classes of users, I'd ask that we at least leave room in the design of these tools such that improving the command organization later will be a trivial task. d On Wed, May 2, 2012 at 9:14 AM, Dolph Mathews dolph.math...@gmail.com wrote: I disagree with all three... the line between admin and not admin is going to get very blurry in the long run. Example: I may be a regular user, but I've been granted what is normally an admin capability on tenant X. Does that make me an admin? Do I now need to use two different clients? I also don't think it should be the client's *responsibility* to understand what capabilities are required for any given command (ultimately making *assumptions* about what the service will allow the user to do), as it's the remote service that's ultimately going to enforce it's own policies. It may be a decent feature to warn the user something is probably not going to work (or better yet, the ability to ask the remote service if something will succeed before we attempt it), but the client shouldn't prevent the user from trying -- especially by suppressing/isolating features. Horizon is going to face the same challenge (hiding/showing capability-relevant UI). tl;dr: openstackclient should be uniformly featured across all OpenStack API's (service, admin or otherwise) -Dolph On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: There are a couple of ways to handle that: 1. A separate openstackadmin CLI that looks for commands using a different plugin namespace, and therefore only loads the admin commands. 2. Prefix admin-related commands in the unified cli with admin (so openstack admin create network or whatever). 3. Separate admin apps for each project. I think we should avoid 3, since that goes against the spirit of this project. I like #2, but #1 would be easy to implement and could share 99% of the code from the basic openstackclient. On Tue, May 1, 2012 at 4:59 PM, Matt Joyce m...@nycresistor.com wrote: How does this blueprint play into this client. Is it a separate admin only client or just a subset of this guy? https://blueprints.launchpad.net/nova/+spec/admin-cli -matt On Tue, May 1, 2012 at 12:28 PM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 1, 2012 at 2:11 PM, Adam Spiers aspi...@suse.com wrote: As of my recent patch, --help is contextual in nova: I hadn't seen that yet... and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites using python-openstack! The continued existence of the project-specific commands is really up to the projects themselves. I think it would be great to converge them on things like this, but trying to get them all to work the same is what led us to openstackclient due to backward compatibility and all. My guess would be that the existing client binaries would live through the 'G' release even if we decided to deprecate them now. I agree with Dolph - there is a precedent from other well-known programs (git, hg, svn are the first ones I can think of) for --help to behave differently depending on whether or not it was preceded by a subcommand. So my vote is that we should definitely aim to adhere to this pattern. How about detailing it in the HIG and once we get a command or two implemented with argument parsing we give it a shot? dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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:
Re: [Openstack] [Openstack-operators] OpenStack Client Followup
On Wed, May 2, 2012 at 1:56 PM, Matt Joyce m...@nycresistor.com wrote: I disagree pretty strongly with the idea of an admin binary. I think many of us do; I (and I believe Doug) were simply preferring 1) a single binary with 2) division of commands. Fundamentally my consternation with the idea comes from what I see as such a clear and final delineation in what I expect will be a very complex ACL set in the future. I can't see there being something as simple as an admin and a user in any orchestration environment. There will be more roles than that. Agreed. The client shouldn't be making any presumptions when it comes to ACLs. Agreed. We shouldn't be drawing lines in the sand. And I guess more to the point we shouldn't be solving problems we don't have. For now I would be happy to just throw a permission denied when it happens. We can solve the problem when it becomes defined ( later ). Creating a whole second binary seems like a nuclear solution to a problem we don't even really have. So, I think if you re-read my email, you'll see that we're essentially of the same view. 1) I don't think a separate binary is a good idea 2) I don't think we should solve problems before we have data on them but in addition, 3) I think we should anticipate a future need of defining things such as ACLs. Organizing the CLI's commands via a subcommand like Doug proposed could be part of a solution like that. I doesn't have to be, but it could be. Making sure that we don't limit our options in the future would be a good thing :-) d The APIs are handling the permission checks after all. -Matt On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor dun...@dreamhost.com wrote: You make some fair points. But consider the large class of cloud users that will never need to bring up OpenStack from scratch, but rather maintain them. These users will need to be able to easily identify the commands that pertain to their daily maintenance, troubleshooting, and reporting tasks. Design of a CLI tool for different audiences is just as important as visual interface design. However, anticipating that now, before we have solid usage data, may be premature. In order to eventually deliver improved organization of CLI commands and a good usability experience for all classes of users, I'd ask that we at least leave room in the design of these tools such that improving the command organization later will be a trivial task. d On Wed, May 2, 2012 at 9:14 AM, Dolph Mathews dolph.math...@gmail.com wrote: I disagree with all three... the line between admin and not admin is going to get very blurry in the long run. Example: I may be a regular user, but I've been granted what is normally an admin capability on tenant X. Does that make me an admin? Do I now need to use two different clients? I also don't think it should be the client's *responsibility* to understand what capabilities are required for any given command (ultimately making *assumptions* about what the service will allow the user to do), as it's the remote service that's ultimately going to enforce it's own policies. It may be a decent feature to warn the user something is probably not going to work (or better yet, the ability to ask the remote service if something will succeed before we attempt it), but the client shouldn't prevent the user from trying -- especially by suppressing/isolating features. Horizon is going to face the same challenge (hiding/showing capability-relevant UI). tl;dr: openstackclient should be uniformly featured across all OpenStack API's (service, admin or otherwise) -Dolph On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: There are a couple of ways to handle that: 1. A separate openstackadmin CLI that looks for commands using a different plugin namespace, and therefore only loads the admin commands. 2. Prefix admin-related commands in the unified cli with admin (so openstack admin create network or whatever). 3. Separate admin apps for each project. I think we should avoid 3, since that goes against the spirit of this project. I like #2, but #1 would be easy to implement and could share 99% of the code from the basic openstackclient. On Tue, May 1, 2012 at 4:59 PM, Matt Joyce m...@nycresistor.com wrote: How does this blueprint play into this client. Is it a separate admin only client or just a subset of this guy? https://blueprints.launchpad.net/nova/+spec/admin-cli -matt On Tue, May 1, 2012 at 12:28 PM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 1, 2012 at 2:11 PM, Adam Spiers aspi...@suse.com wrote: As of my recent patch, --help is contextual in nova: I hadn't seen that yet... and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites
Re: [Openstack] [Openstack-operators] Question Regarding Swift Distribution Statistics
cc'ing openstack list On Wed, May 2, 2012 at 4:45 PM, Richard Raseley rich...@raseley.com wrote: I am trying to figure out the best way to see view the distribution of a file or files across my test swift setup. I want to basically upload a file or files to containers and then be able to run a command or script that will tell me See, these files *are* actually distributed over these particular zones / nodes. Is there anything built into Swift like this? Thank you in advance for your answers. ___ Openstack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ 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-operators] Mailing-list split
On Mon, Apr 30, 2012 at 2:01 PM, Everett Toews everett.to...@cybera.ca wrote: Hi Stefano, I was replying to Duncan's email, not Thierry's. I'm all for the new openstack-dev list. It was Duncan's proposal that the other lists be split as so. 1. openstack-dev = Dev 2. openstack = Ops 3. openstack-operators = DevOps To be clear, my proposal is to see how the devops community feels about this, before deciding it's a good idea, without their input. I am questioning the necessity to have both lists 2 and 3. My proposal boils down to the question, does the DevOps community really need its own list? As soon as it's clear that *everyone* feels this way, we should do it. Until then, we should not make decisions that impact the community (e.g., taking something away that may be valueable to some) without getting their feedback and finding some way transition in a way that keeps everyone happy. I'm willing to wait until the next Summit to see what the traffic numbers are like on the openstack and openstack-operators lists before any decisions are made around merging them or keeping them separate. Agreed. However, I still think it's worthwhile to ask the question above. Agreed. d ___ 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] Mailing-list split
On Fri, Apr 27, 2012 at 8:46 AM, Monty Taylor mord...@inaugust.com wrote: Hey everyone! On 04/27/2012 05:04 AM, Thierry Carrez wrote: To avoid Launchpad list slowness, we would run the new openstack-dev list off lists.openstack.org. Given the potential hassle of dealing with spam and delivery issues on mission-critical MLs, we are looking into the possibility of outsourcing the maintenance of lists.openstack.org to a group with established expertise running mailman instances. Please let us know ASAP if you could offer such services. We are not married to mailman either -- if an alternative service offers good performance and better integration (like OpenID-based subscription to integrate with our SSO), we would definitely consider it. Just to be clear - I definitely think that mailing lists are an important part of dev infrastructure and would love for this to be a fully integrated part of all of the rest of our tools. However, the current set of active infrastructure team members have huge todo lists at the moment. So the biggest home run from my perspective would be if someone out there had time or resources and wanted to join us on the infra team to manage this on our existing resources (turns out we have plenty of servers for running this, and even a decent amount of expertise, just missing manpower). The existing team would be more than happy to be involved, and it would help avoid get-hit-by-a-truck issues. We're a pretty friendly bunch, I promise. Any takers? Anybody want to pony up somebody with some bandwidth to admin a mailman? Respond back here or just find us in #openstack-infra and we'll get you plugged in and stuff. Thanks! Monty Count me in, Monty. I've been managing mailman lists for about 12 years now (and, incidentally, Barry and I are bruthas from anutha mutha), so I'd be quite comfortable handling those responsibilities. I can couple it with the python.org SIG mail list that I manage, so there'd be zero context switching. d ___ 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] Mailing-list split
On Fri, Apr 27, 2012 at 3:52 PM, Everett Toews everett.to...@cybera.ca wrote: I like this idea but what happens to the openstack-operators list in this scenario? I don't think we'd want to have the openstack and openstack-operators list going along in parallel since it sounds like they would overlap. I propose that the members of the openstack-operators list would be (automatically or manually) migrated to the openstack list. Then the openstack-operators list would be set to read-only or maybe even removed completely to avoid confusion. Comments? Feedback? Hrm. One of the things that came out of the Design Summit discussions around DevOps was that the OpenStack DevOps sub-community doesn't really feel like it has a voice. As a result, I'd be loathe to remove that venue for discussion right now, even if it's only of symbolic value. That being said, I propose that something along the following lines could happen: * intense dev work, collaboration, etc., happening on openstack-dev@ * general usage of openstack questions by folks who are not code contributors, but standing up OpenStack itself, happening on openstack@ * conversations around DevOps in particular (the wide spectrum of definitions that comprise DevOps in various people's minds) happening in openstack-operators@ In helping jump-start (or re-jump-start) the OpenStack DevOps community, I'd really like to have a dedicated place for announcements, questions, etc. Even if we spent some time pointing folks to more detailed, technical resources. In hallway conversations at the summit (and in various emails and phone calls since then), people who consider themselves DevOps have expressed concern over the possibility that the operators list would go away. They are overwhelmed by the volume of traffic on the openstack list, and don't have the time to devise a solution for creating appropriate filters, etc. That objection may simply go away with the new mail list split. But if openstack-operators has become a property valuable to community members, we shouldn't just get rid of it because it doesn't make logical sense. We should make sure that folks are ready to transition to another location for their DevOps needs. And that might take a cycle to sort out... d ___ 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] post-summit editing of etherpads
A side note: On the DevOpsTeam session etherpad, I've added a new section for post-event additions, comments, etc., hopefully encouraging responsible after-the-fact contributions :-) d On Thu, Apr 26, 2012 at 7:43 PM, Adam Spiers aspi...@suse.com wrote: Hi all, Thanks for an awesome design summit! I've been reviewing the etherpads: http://wiki.openstack.org/FolsomSummitEtherpads and have noticed a few instances of accidental post-summit corruption of etherpad contents, which is not surprising considering there is no difference between view mode and edit mode, and any changes are automatically recorded. Unfortunately there doesn't seem to be a mechanism for freezing the contents to protect against this, although it's possible to click the Save icon at the right of the blue formatting bar, and it will mark the current state as a saved revision retrievable via the 'Saved revisions' or 'Time Slider' tabs at the top. Perhaps it would be worth the session leaders doing this after (optionally ;-) sanity-checking the content? Also, part of the etherpads list was accidentally copy'n'pasted into itself - I just removed the duplicate chunk, taking care not to remove anything which wasn't duplicated. Cheers, Adam ___ 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] New OpenStack Releases in Ubuntu 12.04LTS
Robbie, this is just as awesome as AWESOME and has as much mass as MAAS. With this support, you may have solved one of DreamHost's long-standing logistical issues around our cloud efforts. Thanks, Ubuntu and Canonical! d On Mon, Apr 23, 2012 at 11:02 AM, Robbie Williamson rob...@ubuntu.com wrote: For those of you who may have missed this announcement. Canonical has created the Ubuntu Cloud archive. Starting with the Folsum release, users will be able to elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloud archive for at least 18 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). We will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. In order to allow for a relatively easy upgrade, and still adhere to Ubuntu processes and policy, we have elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. We will enable update paths for each OpenStack release. e.g. Enabling “precise-folsum” in the archive will provide access to all OpenStack Folsum packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release. More information on this can be found here: https://wiki.ubuntu.com/ServerTeam/CloudArchive -- Robbie Williamson rob...@ubuntu.com robbiew[irc.freenode.net] Don't make me angry...you wouldn't like me when I'm angry. -Bruce Banner ___ 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] Remote participation from Design Summit (and conference)
On Wed, Apr 11, 2012 at 8:13 PM, Duncan McGreggor dun...@dreamhost.com wrote: The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Looks like for the conference rooms c and d will be combined, so I've created and registered a new IRC channel for that one: #osds-seacliff-c-d Most of the action will be happening in there as well as: #osds-ballroom #osds-seacliff-a-b #osds-bayview-b And then a session or two in: #osds-marina For the sessions I attend, I plan on having my laptop and being on IRC. Stef, any word on whether WebEx will be continued for the conference sessions? d ___ 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] Remote participation from Design Summit (and conference)
On Mon, Apr 16, 2012 at 3:15 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Thu, Apr 12, 2012 at 10:11 AM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 23:13 -0400, Duncan McGreggor wrote: The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b A reminder for those at home: I'm going to be camped out in Seacliff A/B all day today in the DevOps track, with the IRC channel open. Ping me (oubiwann) with a question (if you use my name, an alert will pop up, and I'll see it easier -- I'm also going to be taking notes). See you there! d ___ 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-operators] WebEx Sessions Expired... (was: Remote participation from Design Summit)
Hey all, I caught up with Stef at lunch (in fact, that was my first time meeting him), and he had an informative update: turns out the reason that the WebEx sessions have been cutting out is the DHCP leases have been expiring, complete with new IP addresses. He and others are working towards eliminating this, if possible (e.g., getting long leases, etc.). As stated before, all these trials and tribulations are going in to The Book so we'll have iteratively better solutions for remote participants at each future conference. See you on IRC in about 40 minutes! d On Wed, Apr 18, 2012 at 11:01 AM, Stefano Maffulli stef...@openstack.org wrote: Working on this. I restored the session in Seacliff C this morning and Bayview B is running too. It will take a while for the others to come up. We're learning new things every hours, thanks for the patience. stef On Wed 18 Apr 2012 09:56:44 AM PDT, hitesh wadekar wrote: Hello, Currently I'm on Quantum Webex session. It is working well. Refer this link, https://openstack.webex.com/mw0306ld/mywebex/default.do?siteurl=openstack and select current meeting. Thanks, Hitesh On Wed, Apr 18, 2012 at 10:10 PM, Duncan McGreggor dun...@dreamhost.com mailto:dun...@dreamhost.com wrote: Pinging Stef on this... d On Wed, Apr 18, 2012 at 9:15 AM, Mark Gius m...@markgius.com mailto:m...@markgius.com wrote: All of the WebEx sessoins appear to be expired. Probably because the meeting was scheduled to end last night. Is somebody able to recreate them? Mark On Wed, Apr 18, 2012 at 8:19 AM, Duncan McGreggor dun...@dreamhost.com mailto:dun...@dreamhost.com wrote: On Mon, Apr 16, 2012 at 3:15 PM, Duncan McGreggor dun...@dreamhost.com mailto:dun...@dreamhost.com wrote: On Thu, Apr 12, 2012 at 10:11 AM, Stefano Maffulli stef...@openstack.org mailto:stef...@openstack.org wrote: On Wed, 2012-04-11 at 23:13 -0400, Duncan McGreggor wrote: The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b A reminder for those at home: I'm going to be camped out in Seacliff A/B all day today in the DevOps track, with the IRC channel open. Ping me (oubiwann) with a question (if you use my name, an alert will pop up, and I'll see it easier -- I'm also going to be taking notes). See you there! d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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 mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Openstack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ 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] Remote participation from Design Summit (and conference)
On Wed, Apr 11, 2012 at 8:13 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Wed, Apr 11, 2012 at 5:52 PM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 14:03 -0700, Matt Joyce wrote: Ballroom: Intro Plenary, Breakout tables, Lightning Talks Seacliff A+B: Design summit sessions (fishbowl setup)* Seacliff C: Design summit sessions (fishbowl setup)* Seacliff D: Design summit sessions (fishbowl setup)* Marina: Design summit sessions (fishbowl setup)* Bayview B: Design summit sessions (fishbowl setup)* Golden Gate: Unconference room (theater setup)* Bayview A: Developer's lounge The association between rooms+track will be published soon, once the revisions on summit.openstack.org are completed. The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Each channel is also getting logged, viewable via HTTP here: http://irclogs.osds.cogitat.io/ I've updated the publishbot to log channel topics, so there will now be a record of the session changes in the IRC logs. Next, I'll add support for SSH'ing into the logger bot to mass-update session channels for topic changes and broadcast messages... d ___ 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] Remote participation from Design Summit (and conference)
On Tue, Apr 17, 2012 at 10:38 AM, Duncan McGreggor dun...@dreamhost.com wrote: On Wed, Apr 11, 2012 at 8:13 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Wed, Apr 11, 2012 at 5:52 PM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 14:03 -0700, Matt Joyce wrote: Ballroom: Intro Plenary, Breakout tables, Lightning Talks Seacliff A+B: Design summit sessions (fishbowl setup)* Seacliff C: Design summit sessions (fishbowl setup)* Seacliff D: Design summit sessions (fishbowl setup)* Marina: Design summit sessions (fishbowl setup)* Bayview B: Design summit sessions (fishbowl setup)* Golden Gate: Unconference room (theater setup)* Bayview A: Developer's lounge The association between rooms+track will be published soon, once the revisions on summit.openstack.org are completed. The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Each channel is also getting logged, viewable via HTTP here: http://irclogs.osds.cogitat.io/ I've updated the publishbot to log channel topics, so there will now be a record of the session changes in the IRC logs. Next, I'll add support for SSH'ing into the logger bot to mass-update session channels for topic changes and broadcast messages... Okay, I've got it set up so that I can ssh into the IRC bot, send out broadcast message, and batch-update channel topics. It's getting much easier to manage than the manual crap I've been doing :-) Ideally, we've have this stuff pulling from the calendar, and there'd be no-hands... maybe we can save that for next year ;-) d ___ 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] Remote participation from Design Summit (and conference)
On Thu, Apr 12, 2012 at 10:11 AM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 23:13 -0400, Duncan McGreggor wrote: The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Each channel is also getting logged, viewable via HTTP here: http://irclogs.osds.cogitat.io/ Awesome, thank you Duncan. We have also (thanks to Cisco) https://openstack.webex.com/ that we can use to stream audio from the rooms. Before we sing our happy song, though, we need to jump a few hoops: Hey folks, We don't seem to be giving the remote folks much love :-( Quick fixes: * does someone have a link to all the etherpads for the sessions? Let's get that emailed out to everyone * I'm going to start going around to each session and pasting info into the channels for remote folks Issues: * seems that the webex stuff isn't working consistently * sometimes audio isn't turned on * microphones aren't being passed around * there's no one appointed in the sessions to watch on IRC and pass questions to the speakers I'm sure there's lots of other issues... Folks who are remote: this is only the second OpenStack conference, and (I think?) this is the first time any sort of remote support has been attempted. It's probably going to take a couple conferences to get this ironed out. Do note, however, that the IRC sessions are logged and will be combed for problems, complaints, etc. I've already gone through them once today, to see what I missed. Keep messaging, keep raising your voices... you'll be heard eventually, and this will help make remote support better with each conference. See you online, d ___ 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] Remote participation from Design Summit (and conference)
On Mon, Apr 16, 2012 at 3:15 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Thu, Apr 12, 2012 at 10:11 AM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 23:13 -0400, Duncan McGreggor wrote: The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Each channel is also getting logged, viewable via HTTP here: http://irclogs.osds.cogitat.io/ Awesome, thank you Duncan. We have also (thanks to Cisco) https://openstack.webex.com/ that we can use to stream audio from the rooms. Before we sing our happy song, though, we need to jump a few hoops: Hey folks, We don't seem to be giving the remote folks much love :-( Quick fixes: * does someone have a link to all the etherpads for the sessions? Let's get that emailed out to everyone * I'm going to start going around to each session and pasting info into the channels for remote folks Issues: * seems that the webex stuff isn't working consistently * sometimes audio isn't turned on * microphones aren't being passed around * there's no one appointed in the sessions to watch on IRC and pass questions to the speakers I'm sure there's lots of other issues... Folks who are remote: this is only the second OpenStack conference, and (I think?) this is the first time any sort of remote support has been attempted. It's probably going to take a couple conferences to get this ironed out. Do note, however, that the IRC sessions are logged and will be combed for problems, complaints, etc. I've already gone through them once today, to see what I missed. Keep messaging, keep raising your voices... you'll be heard eventually, and this will help make remote support better with each conference. See you online, d creiht on IRC just pasted this link: http://wiki.openstack.org/FolsomSummitEtherpads d ___ 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] Remote participation from Design Summit (and conference)
Ugh... did anyone take pictures of the easel work? Or take (less old fashioned) notes? d On Mon, Apr 16, 2012 at 7:44 PM, Mark A Carlson mark.carl...@oracle.com wrote: It was old fashioned marker on easel -- mark On Apr 16, 2012, at 6:45 PM, Ahn, Jaesuk bluejay@gmail.com wrote: Does anyone know if there is an etherpad link for scalinng openstack session today? I cannot find on wiki or anywhere else. Thank you. Apr 17, 2012, 8:57 AM, Dan Wendlandt 작성: On Mon, Apr 16, 2012 at 3:59 PM, Piyanai Saowarattitada pns...@gmail.com wrote: http://etherpad.openstack.org/quantum-folsom = Quantum track especially - not listed on the main folsom summit etherpads wiki added it this morning... should be up there. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: 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 -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community ___ 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-operators] Health Monitoring Blueprints
On Sat, Apr 14, 2012 at 12:23 PM, Jorge O. Castro jo...@ubuntu.com wrote: On Sat, Apr 14, 2012 at 1:35 AM, Duncan McGreggor dun...@dreamhost.com wrote: What about running on a LiveCD? You should be able to install Webex, as long as the file system is mounted. Jorge, is that correct? It's been a while since I've used LiveCD. This will work (I've done this sort of thing in the past.). What might work better is running off of a liveUSB stick with persistence enabled, so you can set them one prior to the event with everything you need and then just clone them; then you'd be able to reuse them if you need to swap out hardware. You are the MAN, Jorge! Thanks :-) See you in a day or so! d ___ 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] Health Monitoring Blueprints
Lyle replied yes -- sadly, we can't edit the sessions anymore. Fortunately, there's the wiki :-) I've updated the session to point to these blueprints: http://wiki.openstack.org/Summit/Folsom/DevOps d On Wed, Apr 11, 2012 at 4:41 PM, Duncan McGreggor dun...@dreamhost.com wrote: Lyle, would you mind if I add these to the Instrumenting OpenStack session? http://summit.openstack.org/sessions/edit/163 d On Wed, Apr 11, 2012 at 4:33 PM, Wilkinson, Lyle lyle.wilkin...@hp.com wrote: Hi folks, We’ve created a set of 3 blueprints on the topics of health and monitoring, metrics data collection, and cloud inventory maintenance. https://blueprints.launchpad.net/nova/+spec/resource-monitor-alerts-and-notifications https://blueprints.launchpad.net/nova/+spec/utilizationdata https://blueprints.launchpad.net/nova/+spec/cloud-inventory-manager We’re hoping to discuss these at the design summit next week, but currently don’t know if they’ll be part of an existing session or covered in a separate session in one of the open space. We’ve created some etherpad pages to get the discussion going, so if you have questions, suggestions, etc., feel free to contribute there. http://etherpad.openstack.org/ResourceMonitorAlertsandNotifications http://etherpad.openstack.org/utilizationdata http://etherpad.openstack.org/Cloud-Inventory-Manager Thanks in advance! Lyle Wilkinson ___ 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-operators] Health Monitoring Blueprints
cc'ing Jorge Castro from Canonical (who will be at the conference... and maybe the summit?). Jorge, question below on how to deal with Webex on Ubuntu and limited time/people resources. On Fri, Apr 13, 2012 at 9:48 PM, Stefano Maffulli stef...@openstack.org wrote: On 04/11/2012 02:52 PM, Stefano Maffulli wrote: We're not yet sure to be able to offer this. Wait for an official communication. Here is a brief update regarding the live streaming situation. Here is the good news: Cisco kindly offered http://openstack.webex.com. If you get there you'll see some meetings setup for the days of the Summit, one meeting per each day, per room. Zareason kindly offered 9 computers to be put in each room, connected to the audio equipment available there. Each of Zareason's PC will act as a 'robot-presenter' for Webex. The good news stop here. There is bad news: at least 6 of the zareason PCs run 64bit systems, and 64bit Java on Linux is not compatible with Webex (audio issues). Two of the remaining computers may be too slow to run Webex (I haven't tested them). Possible solutions: - offer live streaming only from 3 rooms (at best, only one at worst) (which ones?) - spend a few hours on Sunday wiping out the 6 machines and put 32 bit systems on What about running on a LiveCD? You should be able to install Webex, as long as the file system is mounted. Jorge, is that correct? It's been a while since I've used LiveCD. d - is there a simpler hack to run 32bit Java on 64bit Ubuntu 11.10 systems? - these hours will have to be on top of the hours necessary to setup the rooms, make sure that audio capture really works with the hotel's audio system etc - give to session leaders the honor/burden to run Webex sessions from their own laptops (given how Webex conferencing works, it may be nearly impossible) Other ideas? I'm inclined to go with the simplest option, #1. Unless many (more than 10) people reply to this message asking me to provide full coverage of the event, I'd go with it. For the other options, I'd ask for somebody else to take the lead: that means, helping wipe and install the machines, install java, test them and install them. I'll be glad to provide all support needed. Let me know asap, so I can plan the weekend. stef ___ 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] EC2 compat.
Lurking on the thread, but love what I'm seeing :-) Nice work, guys! d On Tue, Apr 10, 2012 at 10:43 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Very cool, glad to see that is being worked on, it looks pretty similar to what I was thinking of. I’m all for open dialogues. In fact. I was thinking of what is needed to make this work better. Open questions/thoughts/brainstorm (at least that I was thinking of): How strict do we want to be with the XSD? (there aren’t a lot of tolerant xsd validators out there, which sux) Should we use something like jaxb for python, that should be more tolerant (unsure as what the best solution here is) How do we continuously measure the compatibility level? # of test cases passing, # of xml differences, # of xsd issues Should we use boto as a intermediate layer? (it is very tolerant) From what I understand there XML code is basically selecting certain attributes out of the XML using SAX, then adding any unknown attributes dynamically on to a object How do we make it repeatable? For a given test X, if there is a problem with test X and its response Y, how do we easily recreate that test X and response Y (so that dev’s can fix it)? Do we have a “golden set” of responses that when test X is called it should match golden response Z (otherwise there is an issue) This is where the mock server maybe useful, in that we can point test X at the mock server; get the expected responses Z, Then point the test X at the real openstack server and get responses Y that should match Z (exactly, minus the request id?) EC2 seems to also already have some type of mocking, but I haven’t used it... (http://bit.ly/HJkdh7) I like how there is a tests folder that u guys have, that seems like it could be a good location for the “content checking tests” which actually require code/logic to dig into the XML response. It might make sense to use another tool to verify the XSD’s (how tolerant we want to be is an open question) and another tool that will show u the xml differences (some of which might be ok, some not). I have used in java xmlunit to do those kind of xml difference comparisons, it provides some nifty ways of ignoring certain differences and such. If say we had 3 levels of tests I think that would make sense (starting say from XSD validation, to difference comparisons to content comparisons), and would make a hell of a EC2 cool validation toolkit. The other usage of the site I was making was to list all the known error conditions, and any other incompatibilities that I am noticing with EC2 (error conditions, features, parameters...). That seems really needed to allow for anyone to actually use the EC2 apis and handle all the cases which could be thrown at them. -Josh On 4/10/12 7:02 PM, Eric Windisch e...@cloudscaling.com wrote: Josh, as a follow-up, it would be good to keep an open dialogue on this. When/if you get a chance to review the aws-compat branch, I'd like to get your feedback as well. PS I meant to write assess, not access. I only noticed when I read back my email. I'm too pedantic to not correct myself. ___ 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] Health Monitoring Blueprints
Lyle, would you mind if I add these to the Instrumenting OpenStack session? http://summit.openstack.org/sessions/edit/163 d On Wed, Apr 11, 2012 at 4:33 PM, Wilkinson, Lyle lyle.wilkin...@hp.com wrote: Hi folks, We’ve created a set of 3 blueprints on the topics of health and monitoring, metrics data collection, and cloud inventory maintenance. https://blueprints.launchpad.net/nova/+spec/resource-monitor-alerts-and-notifications https://blueprints.launchpad.net/nova/+spec/utilizationdata https://blueprints.launchpad.net/nova/+spec/cloud-inventory-manager We’re hoping to discuss these at the design summit next week, but currently don’t know if they’ll be part of an existing session or covered in a separate session in one of the open space. We’ve created some etherpad pages to get the discussion going, so if you have questions, suggestions, etc., feel free to contribute there. http://etherpad.openstack.org/ResourceMonitorAlertsandNotifications http://etherpad.openstack.org/utilizationdata http://etherpad.openstack.org/Cloud-Inventory-Manager Thanks in advance! Lyle Wilkinson ___ 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] Health Monitoring Blueprints
Resharing with the Operators list... d On Wed, Apr 11, 2012 at 4:33 PM, Wilkinson, Lyle lyle.wilkin...@hp.com wrote: Hi folks, We’ve created a set of 3 blueprints on the topics of health and monitoring, metrics data collection, and cloud inventory maintenance. https://blueprints.launchpad.net/nova/+spec/resource-monitor-alerts-and-notifications https://blueprints.launchpad.net/nova/+spec/utilizationdata https://blueprints.launchpad.net/nova/+spec/cloud-inventory-manager We’re hoping to discuss these at the design summit next week, but currently don’t know if they’ll be part of an existing session or covered in a separate session in one of the open space. We’ve created some etherpad pages to get the discussion going, so if you have questions, suggestions, etc., feel free to contribute there. http://etherpad.openstack.org/ResourceMonitorAlertsandNotifications http://etherpad.openstack.org/utilizationdata http://etherpad.openstack.org/Cloud-Inventory-Manager Thanks in advance! Lyle Wilkinson ___ 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-operators] Health Monitoring Blueprints
On Wed, Apr 11, 2012 at 5:03 PM, Matt Joyce m...@nycresistor.com wrote: Problem of course is many operators aren't on the design summit contributor list ( ala don't have codes to get into it ) and if it's later it's 500 USD to attend. Maybe not the best means of collaborating on something that effects them deeply. Pondering that. That's a really good point. In the post-conference conversations that deal with attendance policy, this should be kept in mind. In lieu of not being able to attend in person, keep in mind the live-casting that will be done, in combination with IRC channels. When I led tracks at Ubuntu Developer Summits, we were able to keep remote attendees closely in the loop. As non-optimal as this may be, we can still work hard to get the best out of it. I'm not sure it the Design Summit will be projecting IRC chat on a screen for each session (like is done at UDS); at the very least, I can make sure I'm on Freenode and can act as a proxy -- ensuring any questions or concerns from IRC get audibly voiced and become part of the conversation. I will be attending all of the DevOps (and related) sessions, as long as they don't conflict. Thanks for bringing this up, d ___ 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-operators] Health Monitoring Blueprints
On Wed, Apr 11, 2012 at 5:52 PM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 14:03 -0700, Matt Joyce wrote: Problem of course is many operators aren't on the design summit contributor list ( ala don't have codes to get into it ) and if it's later it's 500 USD to attend. There will be over 400 people at the summit, not all of them are developers. I expect lots of operators/users have a representation there. Will there be enough to justify having this discussion there? I don't know but we can try. On Wed, 2012-04-11 at 17:16 -0400, Duncan McGreggor wrote: That's a really good point. In the post-conference conversations that deal with attendance policy, this should be kept in mind. We probably should set a date for a post-mortem discussion, after the conference. I'm quite sure I'll take a few days off after April 20, maybe have a couple of live feedback sessions in the first week of May would work? +1 for me! In lieu of not being able to attend in person, keep in mind the live-casting that will be done, We're not yet sure to be able to offer this. Wait for an official communication. Whoops, my bad -- sorry about that Stefano! in combination with IRC channels. This we can do: use IRC but there will be only one projector in the rooms, not two like at UDS. Each track leader can decide how to use it (for IRC or something else). Since you are already familiar with UDS setup, would you mind setting up the IRC channels for each of the rooms at the summit? Sure thing! This is the layout of the rooms and their expected usage: Ballroom: Intro Plenary, Breakout tables, Lightning Talks Seacliff A+B: Design summit sessions (fishbowl setup)* Seacliff C: Design summit sessions (fishbowl setup)* Seacliff D: Design summit sessions (fishbowl setup)* Marina: Design summit sessions (fishbowl setup)* Bayview B: Design summit sessions (fishbowl setup)* Golden Gate: Unconference room (theater setup)* Bayview A: Developer's lounge The association between rooms+track will be published soon, once the revisions on summit.openstack.org are completed. Thanks, Stefano! Good info. I'll let you know when it's set up. d Cheers, stef ___ 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-operators] Health Monitoring Blueprints
On Wed, Apr 11, 2012 at 5:52 PM, Stefano Maffulli stef...@openstack.org wrote: On Wed, 2012-04-11 at 14:03 -0700, Matt Joyce wrote: Problem of course is many operators aren't on the design summit contributor list ( ala don't have codes to get into it ) and if it's later it's 500 USD to attend. There will be over 400 people at the summit, not all of them are developers. I expect lots of operators/users have a representation there. Will there be enough to justify having this discussion there? I don't know but we can try. On Wed, 2012-04-11 at 17:16 -0400, Duncan McGreggor wrote: That's a really good point. In the post-conference conversations that deal with attendance policy, this should be kept in mind. We probably should set a date for a post-mortem discussion, after the conference. I'm quite sure I'll take a few days off after April 20, maybe have a couple of live feedback sessions in the first week of May would work? In lieu of not being able to attend in person, keep in mind the live-casting that will be done, We're not yet sure to be able to offer this. Wait for an official communication. in combination with IRC channels. This we can do: use IRC but there will be only one projector in the rooms, not two like at UDS. Each track leader can decide how to use it (for IRC or something else). Since you are already familiar with UDS setup, would you mind setting up the IRC channels for each of the rooms at the summit? This is the layout of the rooms and their expected usage: Ballroom: Intro Plenary, Breakout tables, Lightning Talks Seacliff A+B: Design summit sessions (fishbowl setup)* Seacliff C: Design summit sessions (fishbowl setup)* Seacliff D: Design summit sessions (fishbowl setup)* Marina: Design summit sessions (fishbowl setup)* Bayview B: Design summit sessions (fishbowl setup)* Golden Gate: Unconference room (theater setup)* Bayview A: Developer's lounge The association between rooms+track will be published soon, once the revisions on summit.openstack.org are completed. The following channels have been created on Freenode and are registered. #osds-ballroom #osds-seacliff-a-b #osds-seacliff-c #osds-seacliff-d #osds-marina #osds-bayview-a #osds-bayview-b #osds-golden-gate Each channel is also getting logged, viewable via HTTP here: http://irclogs.osds.cogitat.io/ Feel free to put another logger in there ;-) At UDS, messages get sent to IRC channels at a countdown interval... not sure if we have anything that sophisticated for OSDS. At the very least, we can monitor the times ourselves and post messages to the channels. d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Ops] Folsom Design Summit DevOps Track
Hey folks, I've listed all the DevOps sessions for the summit in the following wiki page: http://wiki.openstack.org/Summit/Folsom/DevOps We got such an overwhelmingly awesome set of inputs for the Input from the Wild session that we'll be splitting that into several new sessions (that's ttx!). The list of sessions and the (forthcoming) notes from email will help us clearly identify any overlap with accepted sessions and ensure that we can fill in the gaps. Feel free to add notes of your own on the wiki page! d ___ 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] Metadata and File Injection (code summit session?)
On Tue, Apr 10, 2012 at 3:12 PM, Eric Windisch e...@cloudscaling.com wrote: EC2 is strategically important. I don't believe that building gold images is the right focus for OpenStack. Indeed. Amazon drives a huge portion of the IaaS market today, and has an enormous impact on non-Amazon IaaS implementations/deployments. If we in OpenStack do not provide for the easy migration between OpenStack and AWS (EC2 in this case), the project will quickly become a non-starter for all the businesses that see Amazon as having defined cloud standards. Until the market gives up on Amazon, we should probably provide robust compatibility between the two. d Anyone wanting to use config-drive would need to support it in their images, that is a no-brainer. It should not be required that images launching in Nova via the EC2 API support config-drive. The EC2 metadata service must remain. The EC2 API is intended to mimic EC2 behavior and provide compatibility. The OpenStack implementations should not diverge or break that compatibility. -- Eric Windisch On Tuesday, April 10, 2012 at 2:05 PM, Justin Santa Barbara wrote: Config drive can support all EC2 functionality, I believe. Images would need to be respun for OpenStack with config-drive, unless we populated the config drive in a way that worked with cloud-init. (Scott?) Personally, I'd rather our effort went into producing great images for OpenStack, than into compatibility with last-generation clouds. Any idea what the important EC2 images are? Are there a handful of images that we could duplicate and then just forget about EC2? On Tue, Apr 10, 2012 at 10:30 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Except for the fact that the config drive is non-EC2 right? That might blow it out of the water to start, as I know a lot of people want the EC2 equivalents/compat. But maybe if done right it shouldn’t matter (ie cloud-init could instead of calling out to urls could also call out to “local files” on a config drive). I just worry that config drive is openstack api only, afaik. ___ 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 2012.1 (Essex) is RELEASED !
Nicely done! Congratulations, everyone!!! d On Thu, Apr 5, 2012 at 10:52 AM, Thierry Carrez thie...@openstack.org wrote: Hello everyone, I'm very happy to announce the immediate release of OpenStack 2012.1 (code-named Essex). This coordinated release contains 5 components: OpenStack Compute (Nova) 2012.1: https://launchpad.net/nova/essex/2012.1 OpenStack Object Storage (Swift) 1.4.8: https://launchpad.net/swift/essex/1.4.8 OpenStack Image Service (Glance) 2012.1: https://launchpad.net/glance/essex/2012.1 OpenStack Identity (Keystone) 2012.1: https://launchpad.net/keystone/essex/2012.1 OpenStack Dashboard (Horizon) 2012.1: https://launchpad.net/horizon/essex/2012.1 You can find tarballs for download, as well as comprehensive lists of features and bugfixes, at the URLs above. You are strongly encouraged to read the Release Notes at: http://wiki.openstack.org/ReleaseNotes/Essex Enjoy! -- 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] Best approach for deploying Essex?
On Tue, Apr 3, 2012 at 2:21 PM, Adam Gandelman ad...@canonical.com wrote: On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. [snip] Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. DreamHost is interested! It'd be great if you could do this :-) d ___ 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] Moving nova.rpc into openstack.common
+1 Thanks for exploring this, Russell! Next step: getting a common REST API abstraction in place that all the projects can use... ;-) d On Mon, Apr 2, 2012 at 4:26 PM, Russell Bryant rbry...@redhat.com wrote: Greetings, There was a thread on this list a little while ago about moving the notification drivers that are in nova and glance into openstack.common since they provide very similar functionality, but have implementations that have diverged over time. Is anyone actively working on this? If so, please let me know. For the message queue notifiers, nova uses nova.rpc to do the heavy lifting. Glance has notifiers written against the messaging libs directly. I think it makes sense to take the nova approach. This would mean moving nova.rpc into openstack.common before the notifiers can get moved. I have started looking at moving nova.rpc to openstack.common.rpc. My plan is: 1) Write a series of patches that reduces coupling in nova.rpc on the rest of nova. 2) Submit changes needed to support this decoupling to openstack.common. 3) Once nova.rpc is sufficiently decoupled, move it to openstack.common. While doing the above, I want to aim for the least amount of disruption to the rpc interface as is practical. While we're at it, is it time to drop nova.rpc.impl_carrot? It is marked as deprecated in Essex. Is there any reason anyone would still use impl_carrot over impl_kombu? Thoughts? Thanks, -- Russell Bryant ___ 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] Please stop the devstack non-sense!
On Tue, Mar 20, 2012 at 3:14 PM, Chris Wright chr...@sous-sol.org wrote: * Joshua Harlow (harlo...@yahoo-inc.com) wrote: https://github.com/yahoo/Openstack-DevstackPy Its our chance to make it right :-) Hopefully your session, or a joint session will make the Common development track so we can at least put to rest the best way to handle distro agnostic devstack. thanks, -chris Not sure what the intent here is, but putting to rest sounds ominous ;-) As members of a large and diverse open source project and members of the larger open source ecosystem, innovation should be embraced. Just because a decision is made in one cycle, doesn't mean that's the best way to do something from then on. I would encourage us, as a group, not to seek (or get chased into) the rut of dogmatism... But, perhaps you just meant: let's get some consensus from project leaders on the recommended way for now -- and that sounds great to me ;-) d ___ 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 Projects Development History Visualisation
+1 :-) d On Mon, Mar 5, 2012 at 10:30 AM, Ziad Sawalha ziad.sawa...@rackspace.com wrote: Really cool! Thanks, Syed. We should have these running at the keynote at the conference while everyone is waiting to get started :-) From: Armaan dce3...@gmail.com Date: Mon, 5 Mar 2012 08:21:54 +0530 To: openstack@lists.launchpad.net Subject: [Openstack] OpenStack Projects Development History Visualisation Hello, I have created few videos visualising the development history of various OpenStack projects. Links for the videos are given below: (1)Nova: http://www.youtube.com/watch?gl=INv=l5PrjqezhgI (2)Swift: http://www.youtube.com/watch?v=vFO4ibrgWTs (3)Horizon: http://www.youtube.com/watch?v=5G27xsCrm7A (4)Keystone: http://www.youtube.com/watch?v=aRDRNuFfYGo (5)Glance: http://www.youtube.com/watch?v=Gjl6izUjJs0 Best Regards Syed Armani ___ 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 Projects Development History Visualisation
No kidding... that was amazing to watch :-) Thanks for doing it and sharing it!! d On Sun, Mar 4, 2012 at 10:21 PM, Devin Carlen devin.car...@gmail.com wrote: Seriously awesome! On Sunday, March 4, 2012 at 6:51 PM, Armaan wrote: Hello, I have created few videos visualising the development history of various OpenStack projects. Links for the videos are given below: (1)Nova: http://www.youtube.com/watch?gl=INv=l5PrjqezhgI (2)Swift: http://www.youtube.com/watch?v=vFO4ibrgWTs (3)Horizon: http://www.youtube.com/watch?v=5G27xsCrm7A (4)Keystone: http://www.youtube.com/watch?v=aRDRNuFfYGo (5)Glance: http://www.youtube.com/watch?v=Gjl6izUjJs0 Best Regards Syed Armani ___ 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] eventlet weirdness
On Fri, Mar 2, 2012 at 2:40 PM, Johannes Erdfelt johan...@erdfelt.com wrote: On Fri, Mar 02, 2012, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I agree, but then the whole assumption of adopting eventlet to simplify the programming model is hindered by the fact that one has to think harder to what is doing...Nova could've kept Twisted for that matter. The programming model would have been harder, but at least it would have been cleaner and free from icky patching (that's my own opinion anyway). Twisted has a much harder programming model with the same blocking problem that eventlet has. Like so many things that are aesthetic in nature, the statement above is misleading. Using a callback, event-based, deferred/promise oriented system is hard for *some*. It is far, far easier for others (myself included). It's a matter of perception and personal preference. It may be apropos to mention that Guido van Rossum himself has stated that he shares the same view of concurrent programming in Python as Glyph (the founder of Twisted): https://plus.google.com/115212051037621986145/posts/a9SqS7faVWC Glyph's post, if you can't see that G+ link: http://glyph.twistedmatrix.com/2012/01/concurrency-spectrum-from-callbacks-to.html One thing to keep in mind is that with Twisted, you always have the option of deferring to a thread for operations are not async-friendly. d ___ 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] eventlet weirdness
On Fri, Mar 2, 2012 at 3:38 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Duncan McGregor wrote: Like so many things that are aesthetic in nature, the statement above is misleading. Using a callback, event-based, deferred/promise oriented system is hard for *some*. It is far, far easier for others (myself included). It's a matter of perception and personal preference. I would also agree that coding your application as a series of responses to events can produce code that is easier to understand and debug. And that would be a wonderful discussion if we were starting a new project. But I hope that nobody is suggesting that we rewrite all of OpenStack code away from eventlet pseudo-threading after the fact. Personally I think it was the wrong decision, but that ship has already sailed. Agreed. d ___ 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] eventlet weirdness
On Fri, Mar 2, 2012 at 4:10 PM, Monsyne Dragon mdra...@rackspace.com wrote: On Mar 2, 2012, at 9:17 AM, Jay Pipes wrote: On 03/02/2012 05:34 AM, Day, Phil wrote: In our experience (running clusters of several hundred nodes) the DB performance is not generally the significant factor, so making its calls non-blocking gives only a very small increase in processing capacity and creates other side effects in terms of slowing all eventlets down as they wait for their turn to run. Yes, I believe I said that this was the case at the last design summit -- or rather, I believe I said is there any evidence that the database is a performance or scalability problem at all? That shouldn't really be surprising given that the Nova DB is pretty small and MySQL is a pretty good DB - throw reasonable hardware at the DB server and give it a bit of TLC from a DBA (remove deleted entries from the DB, add indexes where the slow query log tells you to, etc) and it shouldn't be the bottleneck in the system for performance or scalability. ++ We use the python driver and have experimented with allowing the eventlet code to make the db calls non-blocking (its not the default setting), and it works, but didn't give us any significant advantage. Yep, identical results to the work that Mark Washenberger did on the same subject. Has anyone thought about switching to gevent? It's similar enough to eventlet that the port shouldn't be too bad, and because it's event loop is in C, (libevent), there are C mysql drivers (ultramysql) that will work with it without blocking. We've been exploring this possibility at DreamHost, and chatted with some other stackers about it at various meat-space venues. Fwiw, it's something we'd be very interested in supporting (starting with as much test coverage as possible of eventlet's current use in OpenStack, to ensure as pain-free a transition as possible). d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Essex OpenStack Global Hack-In
LLoyd and others, The blog post announcement for this event [1] mentions working on resolving high priority bugs -- I'm assuming that the following list is what identifies them? (I have filtered on essex-4 and rc1) http://goo.gl/Qe17g That includes In Progress ones. This one excludes those, so should offer a list of unclaimed high-priority bugs? http://goo.gl/hMHzb I included essex-4 since I'm not sure if unfinished, unclaimed essex-4 bugs have been moved over to rc1 yet... Is there any other page, document, etc., that tracks what folks should be specifically focusing on today? Thanks so much! d [1] http://www.openstack.org/blog/2012/02/essex-openstack-global-hack-in/ ___ 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] New OpenStack Meetup Group: Atlanta
Woo! /me high-fives the Colorado team! d On Thu, Mar 1, 2012 at 12:23 PM, David Medberry david.medbe...@canonical.com wrote: Stef, et al, I never announced the OpenStack Colorado group on the list. We're already listed in the Global Hack In (and were underway today :^) I'll subscribe to the Int'l User Groups. -dave http://meetup.com/OpenStack-Colorado/ On Wed, 2012-02-29 at 10:51 -0800, Stefano Maffulli wrote: On Tue, 2012-02-28 at 19:29 -0500, Duncan McGreggor wrote: DreamHost is starting up a new office on the East Coast of the US in Atlanta... and one of the first things we did was create an Atlanta OpenStack meetup group: http://www.meetup.com/openstack-atlanta/ Congratulations for both news :) make sure that the coordinator of that group (you) joins the OpenStack International User Groups Community” team on https://launchpad.net/~openstack-community (and subscribes to the mailing list) and ... I already see that Atlanta is listed on http://wiki.openstack.org/OpenStackUsersGroup#Atlanta Perfect. Happy hacking, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [ubuntu-cloud] Update on Ubuntu automated testing and CI of Openstack
Adam, you've outdone yourself :-) That was a phenomenal reply with tons of good information. You've provided our team with all the info we need now -- thanks! d On Mon, Feb 27, 2012 at 10:36 PM, Adam Gandelman ad...@canonical.com wrote: On 02/27/2012 09:22 AM, Duncan McGreggor wrote: It's been an invaluable source for not only information, but also planning for the cloud work here at DreamHost. This is great to hear! I'm happy to hear other people are benefiting from this as much as Ubuntu To the point of this email, though, I have a question for you that I wasn't able to parse an explicit answer to from your post: For the packages that are built in the PPA linked above, are they only built after all the components of OpenStack have been confirmed working as a whole? Or are they built just after individual testing? The jenkins trunk build jobs are the ones responsible for uploading to the PPA. It basically stuffs the newly built package in the local repository and uploads it to the PPA (if it fails to build, it doesnt upload). The nova trunk build also triggers the deployment + testing. So, to answer, those PPA packages are *pre* deployment + smoke testing. The idea with that is that we can use the PPA externally to debug specific issues that might turn up during testing without blocking the deployment/smoke testing queue. We're limited by the number of machines we have and can not currently run deployment testing in parallel. My question comes from this concern: if we're building out a product based on this PPA, (before Precise is delivered) we want to make sure that when we bring up new systems by installing the packages from the PPA, all of those work together properly. If the latest code from keystone, for example, hasn't been building due to testing errors, we want to make sure that the presence of the older keystone package in the PPA won't be causing issues with the newer builds of the rest of OpenStack. So you might have noticed the version of Keystone we are testing is getting a bit dusty. We decided to freeze the version of Keystone we're testing just before the KSL/redux branch was merged. There are still some features that need to land before we can modify our Juju charms to deploy the new version (specifically SQL persistence for the service catalog). I'm hoping these will land before e4 (tomorrow) so we can begin testing the new branch this week. To clarify: in your blog post, you explicitly mention the validation process per component, starting with the upstream git repos. In the deploy phase, you verify that the system as a whole (all of OpenStack) works as expected. But what happens when one or more of those components don't work? Are packages rolled back in the PPA until the PPA only provides packages that will result in, once installed, a complete working system? So far, we haven't rolled anything back in the PPA or the local repository. I believe Keystone is the only package we've had to freeze while things stabilize upstream. Fortunately, we've found the CI (even with the limited test coverage we currently run) is picking up new bugs almost instantaneously. In most cases we're able to either get a fix into gerrit same day or find a proposed fix that we can cherry pick into our debian/patches/ repository and carry temporarily in our lp:~openstack-ubuntu-testing packages branches until its been fixed proper upstream. Please understand the PPA is for testing purposes only, and we're not making any promise that what installs from there is stable/usable/working. We're using the work around that PPA and this CI to essentially gate what goes into the Ubuntu archive. This cycle, Chuck has been uploading a weekly snapshot of Openstack (usually every Friday). With the CI in place, we can essentially verify that those packages build clean and install okay, and provide something usable given the last weeks Gerrit churn. Keep in mind this is still a developing process. I expect this will evolve over the next few months. We've just begun trigger pre-commit testing to the Diablo stable branch against Oneiric. Still working out some kinks, but we'll hopefully be going into Folsom+Precise with coverage of both trunk and stable updates to Essex/Precise LTS. Also note that, at this point in the Ubuntu development cycle, it can often take *a long time* before an upload to a PPA is built and ready for use. Its probably safe to assume that what you're using from the PPA is what we were testing yesterday (check the version of the package for a timestamp) Keep up the great work, guys -- you have fans out here in the wild, wild world of OpenStack :-) :) Cheers, Adam -- Ubuntu-cloud mailing list ubuntu-cl...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-cloud ___ Mailing list: https
[Openstack] New OpenStack Meetup Group: Atlanta
Hey folks, DreamHost is starting up a new office on the East Coast of the US in Atlanta... and one of the first things we did was create an Atlanta OpenStack meetup group: http://www.meetup.com/openstack-atlanta/ If you're in the greater Atlanta area, be sure to join us :-) We're working with Internap (also with local offices) and Ken Pepple has agreed to be our first speaker (thanks Ken!). We'll also be participating in the Global OpenStack HackIn, so we'll see you guys online! d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [ubuntu-cloud] Update on Ubuntu automated testing and CI of Openstack
On Wed, Feb 8, 2012 at 6:57 PM, Adam Gandelman ad...@canonical.com wrote: As promised for anyone who was interested when we announced to the last last week, here is a blog post James Page and I put together describing our Openstack testing efforts and infrastructure in greater detail: http://javacruft.wordpress.com/2012/02/08/automating-openstack-testing-on-ubuntu/ Adam, thanks for this great write up :-) Part of my morning ritual involves hitting these pages every day when I get up: * https://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/ * https://launchpad.net/~openstack-ubuntu-testing/+archive/openstack-trunk-testing It's been an invaluable source for not only information, but also planning for the cloud work here at DreamHost. To the point of this email, though, I have a question for you that I wasn't able to parse an explicit answer to from your post: For the packages that are built in the PPA linked above, are they only built after all the components of OpenStack have been confirmed working as a whole? Or are they built just after individual testing? My question comes from this concern: if we're building out a product based on this PPA, (before Precise is delivered) we want to make sure that when we bring up new systems by installing the packages from the PPA, all of those work together properly. If the latest code from keystone, for example, hasn't been building due to testing errors, we want to make sure that the presence of the older keystone package in the PPA won't be causing issues with the newer builds of the rest of OpenStack. To clarify: in your blog post, you explicitly mention the validation process per component, starting with the upstream git repos. In the deploy phase, you verify that the system as a whole (all of OpenStack) works as expected. But what happens when one or more of those components don't work? Are packages rolled back in the PPA until the PPA only provides packages that will result in, once installed, a complete working system? So there's that practical side of it, but to be honest, it's also simply an interesting question :-) I find the logistics of automated testing a great source of interest and fascination... Keep up the great work, guys -- you have fans out here in the wild, wild world of OpenStack :-) d ___ 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] Running for Nova PTL
On Thu, Feb 23, 2012 at 9:17 AM, Soren Hansen so...@linux2go.dk wrote: I've put my name on the ballot for Nova PTL, and I'd like to explain what I expect to do (my platform, if you will). Nova is facing many separate, but related problems. * Nova is too big. Very few (if any) core developers are comfortable reviewing every part of the code base. In itself, this isn't necessarily a problem, but I think it would be valuable to try to somehow acknowledge that the average focus is much narrower than all of nova. This has been one of my biggest concerns since I started using OpenStack... * Lots of things in Nova that should be orthogonal are not. This problem is especially prevalent in the virtualisation layer. The layout and number of disks you get attached to instances shouldn't depend on the hypervisor you've chosen, but it does. There is lots and lots and lots of logic embedded in both the libvirt and XenServer drivers that isn't related to the hypervisor, but is a result of the origin of these drivers. And this has been my very biggest concern, as I believe it is the root cause for other things which I am keenly interested in seeing addressed (e.g., quality, maintainability, interoperability, etc.). Soren, if elected, by what processes/policies etc. would you accomplish these goals? Are there blueprints that already exist which you would rally folks around? Or would you introduce a new effort to more thoroughly componentize OpenStack? More specifically, how do you envision: 1) clarifying what needs to be done 2) building consensus around this, and 3) accomplishing these goals? (it's a lot of work!) Thanks, d * The overall quality is decreasing There's an almost unilateral focus on features across the board. The topic of almost every session at the summit is some new feature. There is very little focus on stability, predictability and operation. Personally, I think that shows very clearly in the final product. I'd like to try to shift our focus and turn the proverbial ship around. I'd like to remove any incentive to rush things into Nova trunk. 1. A much shorter release cycle (as Thierry also suggests[1]) would be very beneficial. Noone wants to have to wait an extra 6 months getting some new feature in just because it missed the feature freeze. However, just a single month of delay... That should be manageable in most cases. 2. I'd like to make it more straight forward to have things mature somewhere separete from Nova trunk, but still make it easy to collaborate on them or get people to test them. 3. I'd like to encourage a stronger focus on QA and testing. Specifically, I'd love to have more people focused on making it easier to test things in Nova. Tempest is a great effort, but the unit test suite is our first line of defence. It should be fast and comprehensive. Right now, it's neither. 4. I'd like a stronger focus on extensibility and plugability. 5. I'd like us to rethink our configuration management strategy. So far, we've punted on it and deferred to deployers to choose between Puppet, Chef or whatever else to handle this. However, many things will crash and burn if the configuration of various components is out of sync with each other or with the database. This is particularly clear in the networking area. [1]: http://fnords.wordpress.com/2012/02/21/open-dev-releases-quality/ -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Announcing StackTach ...
Nice one, Sandy! I was planning creating a tool exactly like this -- thanks so much! Can't wait to try it out... d Sent from my iPhone On Feb 20, 2012, at 3:15 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Hey! Last week I started on a little debugging tool for OpenStack based on AMQP events that I've been calling StackTach. It's really handy for watching the flow of an operation through the various parts of OpenStack. It consists of two parts: 1. The Worker. Sits somewhere on your OpenStack network. It listens to AMQP monitor.* notifications and sends them to the StackTach server. (I need this branch to land for it to work ... hint hint) https://review.openstack.org/#change,4194 2. The Web Interface Collects events via REST calls (poorman multi-tenant) and presents these events in a funky little web interface. You can play around with the UI here: http://darksecretsoftware.com/stacktach/1/ (this is with data coming from my personal OpenStack Dev env) What do I do? Click on anything and you'll see the particulars in the Details window. Click on [+] to see the JSON for the event. Hosts shows the last 20 events that have a Host defined. Instances shows the last 20 events that have the Instance field populated. Hosts and Instances windows are resize-able. You may see duplication between both windows. Click on Time to see any events around that time (+/- 1 minute I think) Where is the code? The code is hosted below. There's LOTS of work to do to make it ready for prime-time ... but please, contribute. https://github.com/rackspace/stacktach How do I install it? I need to make this process cleaner. Right know you need to know how to create a Django Project and stick StackTach in there. Look forward to the feedback. Cheers, Sandy ___ 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] announcing api.openstack.org
*high fives* to Anne and everyone else involved! d On Thu, Feb 16, 2012 at 9:02 AM, Anne Gentle a...@openstack.org wrote: I'm pleased to point you to http://api.openstack.org. Collecting OpenStack APIs on one page, built with an API developer in mind. This design implementation fulfills a blueprint for the openstack-manuals project. Inspired by sites like https://dev.twitter.com/docs/api but with a scope that we could actually complete prior to Essex, the site shows Identity 2.0, Compute 1.1, and Image 1.0 APIs with Object Storage to follow. The API site aims to document the installation at http://trystack.org for starters. Different OpenStack deployments may choose different API extensions, for example, and extensions are not reflected on this site quite yet. The source for the page is three WADL files plus an index page that builds the HTML with a Maven plugin. There are JSON and XML samples for some of the methods, defaulting to JSON. A search box allows you to search the entire page whether the content is revealed or not. Click the details buttons to expand the content below each PUT/POST/GET/DELETE method. Click the close button to contract the content back to one line. Refresh the page to compress all expanded content. We welcome bug reports (and know of some bugs already) against the openstack-manuals project, tagged with api-site. Much appreciation and love for Joe Heck for cheerleading for the site and scope. A huge shout-out to the doc tools team at Rackspace especially David Cramer, Joe Savak, and Thu Doan for their efforts. Brian Waldon and Jorge Williams reviewed the site as we iterated on it and I appreciate it. Thanks y'all! I humbly hand it over to you all to keep improving it - the content needs additions for certain and we need to get the Object Storage WADL written. Patches welcome! Warmly, Anne ___ 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] PyCon 2012 Sprints?
On Wed, Dec 14, 2011 at 4:23 PM, Duncan McGreggor dun...@dreamhost.com wrote: I just found out that PyCon 2012 registration opened up: https://us.pycon.org/2012/registration/ and was wondering: * are there any OpenStack sprints planned for March 12 through Thursday March 15? * is there a wiki page for this yet on wiki.openstack.org? A quick search answered my question on the latter point, so I created these two pages: * http://wiki.openstack.org/Sprints * http://wiki.openstack.org/Sprints/PyCon2012 There's no content there yet, just placeholders waiting for that first bullet item... ;-) d Are any folks in the OpenStack community planning to attend the PyCon sprints? Meat-space attendance isn't required; lots of sprinting happens over IRC. I've updated the wiki with some topics proposed by various folks I've chatted with face-to-face. Feel free to add more... d ___ 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] Redux deps?
I'm always amazed, Chuck, that a guy this busy: http://goo.gl/xXLqn gets so much done... d On Thu, Feb 16, 2012 at 3:44 PM, Chuck Short chuck.sh...@canonical.com wrote: You are welcome :) On Thu, 16 Feb 2012 14:33:18 -0800 Joshua Harlow harlo...@yahoo-inc.com wrote: Thx chuck short :-P On 2/16/12 2:27 PM, Andy Smith andys...@gmail.com wrote: The package dependencies for redux are in devstack (the devstack redux branch was merged to master), however quick look says bcrypt is no longer needed. We are likely to remove pyCLI in the next day or so, however, because Chuck Short asked nicely. On Thu, Feb 16, 2012 at 1:58 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Hi all, After the keystone redux change I am seeing that new PIP packages were added (or maybe dependencies added it, idk). PyCLI seems to be the new hotness. Is there any reason why we continue to need new PIP pkgs and such? Haven't we gotten down CLI parsing :-P Makes it a pain to make devstackPY work since we actually expect a working list of pkgs in that devstack version and new ones seem to continue to pop up. What are the new pkg requirements for keystone redux??? Is https://github.com/openstack-dev/devstack/blob/master/files/apts/keystone https://github.com/openstack-dev/devstack/blob/master/files/pips/keystone valid anymore? It'd be much appreciated if we could email everyone here when pkgs change in those as I need to reflect them @ https://github.com/yahoo/Openstack-DevstackPy/tree/master/conf which has the multiple distribution equivalent (also a much more complete dependency list afaik). Thx much! -Josh ___ 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] PyCon 2012 Sprints?
On Thu, Feb 16, 2012 at 6:26 PM, Michael Pittaro mik...@lahondaresearch.org wrote: On Thu, Feb 16, 2012 at 2:50 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Wed, Dec 14, 2011 at 4:23 PM, Duncan McGreggor dun...@dreamhost.com wrote: I just found out that PyCon 2012 registration opened up: https://us.pycon.org/2012/registration/ and was wondering: * are there any OpenStack sprints planned for March 12 through Thursday March 15? * is there a wiki page for this yet on wiki.openstack.org? A quick search answered my question on the latter point, so I created these two pages: * http://wiki.openstack.org/Sprints * http://wiki.openstack.org/Sprints/PyCon2012 There's no content there yet, just placeholders waiting for that first bullet item... ;-) d Are any folks in the OpenStack community planning to attend the PyCon sprints? Meat-space attendance isn't required; lots of sprinting happens over IRC. I've updated the wiki with some topics proposed by various folks I've chatted with face-to-face. Feel free to add more... d I'll be attending the Sprints. I also added OpenStack to the Pycon sprints page, to to carve out our space before it's all taken. https://us.pycon.org/2012/community/sprints/projects/ mike Nice! Thanks, Mike :-) d ___ 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] [DEVSTACK] officialize it!
On 06 Feb 2012 - 10:29, Joshua Harlow wrote: Hi all, Over the weekend I was thinking (I know a first, haha). I was wondering if the community could elevate devstack to a official openstack project, instead of being a unofficial project. Since it seems like pretty much every developer (and even CI) is either depending on the shell script or the python script, so the unofficial wording seems incorrect. Hopefully we can have that happen and have this official project focus on just a developer setup script (imho the python version, since it fits in with the whole python model every other component is using and allows for features the shell script is not doing, multi-distro support, starting, stopping, uninstalling, object oriented design, to name a few...) of the openstack components (and not dive into the scripts that are showing up), ie leave that to 3rd party websites. What does everyone think? +1 d Maybe this can happen after essex? -Josh ___ 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] Ubuntu OpenStack QA Lab up and running
Nicely done, guys! Very, very cool. d On 26 Jan 2012 - 13:22, Robbie Williamson wrote: http://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/ James Page[1] has setup the jobs in the Ubuntu OpenStack QA Lab to start publishing to our public Jenkins QA instance this morning. We now have automated build testing of all core openstack components triggered from upstream trunk commits. This is followed by automated deployment (-deploy) of OpenStack in the lab with a serving of testing (-test) once its all up and running. Credit to Adam Gandelman[2] for the Juju[3] charm work, deployment framework and test execution and to Chuck Short[4] for the hugely misnamed tarball.sh script which completes the git/bzr/packaging fu to build and deploy openstack packages! The plan is to get the upstream Tempest test suite running in the lab; at the moment we are running a more limited test script just to ensure that you can spin up and instance and see it on the network. Ultimately, our plan is to leverage this testing to help us ensure a stable and robust Ubuntu Cloud release in Ubuntu Server 12.04LTS. Comments and feedback are always welcome! Thanks, -Robbie Williamson [1] https://launchpad.net/~james-page [2] https://launchpad.net/~gandelman-a [3] https://code.launchpad.net/charms [4] https://launchpad.net/~zulcss -- Robbie Williamson rob...@ubuntu.com robbiew[irc.freenode.net] Don't make me angry...you wouldn't like me when I'm angry. -Bruce Banner ___ 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] ZeroMQ RPC Driver - FF-Exception request
FWIW, I'd love to see this land in E3... d On 24 Jan 2012 - 16:08, Eric Windisch wrote: Per today's meeting, I am proposing the ZeroMQ RPC driver for a feature-freeze exception. I am making good progress on this blueprint, it adds a new optional module and service without modifying any existing code or modules. I have been pushing to complete this work by E3, so I am close to completion, but cannot finish by tonight's deadline. The ZeroMQ driver will provide an alternative to Kombu (RabbitMQ) and QPID for messaging within Nova. Currently, the code passes unit tests but fails on smoketests. I expect to have the code viable for a merge proposal in less than a week, tomorrow if I'm smart, lucky, and the store doesn't sell out of RedBull. A two week grace would give me a nice buffer. Thanks, Eric Windisch ___ 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] ZeroMQ RPC Driver - FF-Exception request
Under specific architectures, 0MQ can process millions of messages per second vs. RabbitMQ's many thousands. RabbitMQ is a messaging system; 0MQ is a messaging framework. There's a pretty good write-up on some of the basic differences here: http://www.zeromq.org/docs:welcome-from-amqp Note that the creators of 0MQ (iMatix) were also the guys that invented AMQP... so they've learned many excellent lessons ;-) d On 24 Jan 2012 - 20:20, Yun Mao wrote: Hi I'm curious and unfamiliar with the subject. What's the benefit of 0MQ vs Kombu? Thanks, Yun On Tue, Jan 24, 2012 at 7:08 PM, Eric Windisch e...@cloudscaling.com wrote: Per today's meeting, I am proposing the ZeroMQ RPC driver for a feature-freeze exception. I am making good progress on this blueprint, it adds a new optional module and service without modifying any existing code or modules. I have been pushing to complete this work by E3, so I am close to completion, but cannot finish by tonight's deadline. The ZeroMQ driver will provide an alternative to Kombu (RabbitMQ) and QPID for messaging within Nova. Currently, the code passes unit tests but fails on smoketests. I expect to have the code viable for a merge proposal in less than a week, tomorrow if I'm smart, lucky, and the store doesn't sell out of RedBull. A two week grace would give me a nice buffer. Thanks, Eric Windisch ___ 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] F release naming poll - Cast your vote !
On 12 Jan 2012 - 10:52, Diego Parrilla Santamar?a wrote: Just listening Johnny Cash's 'Folsom Prison Blues'! ... so my vote goes to... Besides, it just *sounds* good: the folsom release Rolls of the tongue quite well. And serious bonus points for the Cash connection ;-) d -- Diego Parrilla http://www.stackops.com/*CEO* *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 | skype:diegoparrilla* * http://www.stackops.com/ ** On Thu, Jan 12, 2012 at 10:34 AM, Thierry Carrez thie...@openstack.orgwrote: Fawnskin, Felton, Fillmore, Flournoy, Folsom, Fortuna, Fowler... How should the F version of OpenStack, due Fall 2012, be named ? Please participate to the F naming poll at: https://launchpad.net/~openstack/+poll/f-release-naming/+vote Pick your choice among the 28 options we have ! This is open to all members of the Launchpad OpenStack team (which is an open team). The poll closes next Tuesday, January 17, at 21:30 UTC. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Metadata and File Injection
On 01 Jan 2012 - 03:23, Ewan Mellor wrote: -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Richard W.M. Jones Sent: 21 December 2011 10:56 To: Scott Moser Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Metadata and File Injection On Thu, Dec 15, 2011 at 11:43:13AM -0500, Scott Moser wrote: c.) No way to modify contents of the service after instance launch. OK, I said 2 features, and really this one is wishlist. If we had an arbitrary key-value store that was available, the user could interact with the guest using this service. It'd have to be poll-based, but a in-guest hypervisor could watch for creation and deletion of keys. Potentially, the MD might be RW from inside guest, meaning it could even convey information back. Sounds like xenstore ... Yes, that's exactly what XenStore is. Even better, you don't even have to poll -- it has an event system where you can block on a file descriptor until a subtree changes. Oh, and it's a tree, not just a flat keyspace. Do you know, Rich, of any plans to implement something like XenStore for KVM? OpenStack would have no problem abstracting the differences between two similar services, if there was something there to abstract over, but up until now people have pushed back hard on any feature that needed XenStore-like functionality, because it is completely missing from KVM. I think that that's a shame, because there are lots of interesting things that you can do when you have a bidirectional, live channel into the guest. I wonder, even, if you could use XenStore on KVM. There's not a great deal there that's Xen-specific. Any mechanism that let you pass messages between the host OS and the guest would be sufficient to build a XenStore driver on top. (In Xen's case it's a shared memory page plus an event channel, but I'm sure it could be anything.) That would be fun for someone ;-) Hey Ewan, This does seem like an interesting project -- I've asked one of our guys at DreamHost to do some investigation (LoE estimates, mostly) over the next week or so, as he has time. This may be something that we're interested in building. If anyone has done something like this, we'd love to hear from you. Could be a nice side-project to collaborate on. d 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 ___ 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 really need a CLA? [was Re: Using Gerrit to verify the CLA]
That was a refreshing perspective, Richard -- thanks for taking the time to write that for us. This one's a keeper. d On 05 Jan 2012 - 14:11, Richard Fontana wrote: On Wed, Jan 04, 2012 at 09:49:29PM +, Mark McLoughlin wrote: Hi Rick, On Tue, 2012-01-03 at 09:02 -0600, Rick Clark wrote: Hey Mark, First of all, orthogonally, we are very lucky to not have Copyright Assignment crushing this project. That is what the management at Rackspace wanted, only NASA's inability to sign such a document prevented it. Copyright assignment would certainly be worse than an Apache-style CLA. I currently regard Apache-style CLAs are worse (scare quotes intentional) than copyright assignment, since (1) they are essentially equivalent to copyright assignment in the legal effect that seems like it ought to matter to developers the most -- that is, under both copyright assignment and an Apache-style CLA, the inbound party gets to do whatever they want with the code contributed, yet (2) for strange sociological reasons many developers tend to see copyright assignment as bad but Apache CLAs as inherently benign. To put it more simply, my concern is that Apache-style CLAs are deceptive in a way that copyright assignment is not, given the well-established antipathy to copyright assignment in open source development culture. For an Apache-licensed project like OpenStack this is not too significant, however. Just kind of perplexing. IANAL, but I was told by lawyers when we were in the planning stages of starting Openstack, that while in the US submitting code under the Apache License 2.0 was enough to bind the submitter to it, that is not the case in all countries. Some countries require explicit acceptance to be bound by it. I've cc-ed Richard Fontana who I'm sure can comment on that. Thank you, Mark, for the opportunity for a bit of a rant. I can't resist talking about this topic. :) I've heard many arguments in favor of formal CLAs and copyright assignment and the like, but this may be a new one. It is not necessary to consider the underlying legal issue, because the argument collapses on its own logic. If it's important to have explicit acceptance to bind a contributor to OpenStack to the license granted on the inbound contribution to the OpenStack project (or whatever entity is acting as the alter ego of it), it ought to be equally important to bind such project/entity (Rackspace, OpenStack Foundation, the non-corporate collective of individual OpenStack committers, whatever) in their offering of the Apache License 2.0 outbound to any given member of the public downstream from OpenStack. Yet when I download OpenStack code, I don't get any such formal indication of binding assent from upstream. I don't get any signed statement with a wax seal affixed committing the upstream contractually to giving me the rights I'm supposed to be getting under the Apache License 2.0. All I get is some software with a text file containing a copy of the Apache License 2.0. Now, I think that's perfectly fine, because that's how free software/open source has always worked. Indeed it is a key part of why it works. It would be strange if OpenStack did things any differently. But if *that's* okay, why is it not okay for contributors to OpenStack to have the same freedom to indicate their licensing in of contributions in a traditional manner -- namely, by merely providing notice of the license (which might as well be the Apache License 2.0)? It doesn't make sense. Moreover, anyone who thinks that open source is unsafe or unreliable without a system of explicit acceptance by the licensor of inbound contributions should immediately cease using it altogether, since 99% or so of it was produced without any such system in place. Any suggestion otherwise is dismissable, but I think it does some damage to suggest that there's something unsafe about using an alternate-universe version of OpenStack where the project did not make use of a CLA, as it unnecessarily casts doubt on that 99 or so % of open source software that is developed without such cumbersome mechanisms, and indeed it casts doubt on the reliability of open source licensing itself. Thus, by using an Apache-style CLA, OpenStack is shooting itself in the foot. There are other things one might mention, such as the fact that the Apache License 2.0 ingeniously contains a built-in contributor agreement of sorts already. We have a bigger hole in the Corporate CLA, IMHO. I have been told that since it is necessary for a corporate signer to explicitly name their individual contributers, and we have no way of updating the document, openstack is potentially left open to a lawsuit, if an employee unspecified in the CLA, contributes something they consider IP. I seriously hate all this legal stuff. I sympathize... I'll leave that one for Richard too :-) On this one,
Re: [Openstack] Tempita usage?
Fwiw, I'm +1 on this :-) I look forward to reviewing the branch... d On 04 Jan 2012 - 14:51, Jay Pipes wrote: No argument from me. Feel free to propose a branch that does the things you describe below. I'm sure you'll get feedback in code review :) Cheers! -jay On Tue, Jan 3, 2012 at 2:17 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I was wondering if there has been any thought or consideration of removing tempita and replacing it with ???just python???. Personally the current tempita usage (libvirt.xml.template) seems to be heading down a hairy path and I wanted to see others opinions on say replacing this with something that doesn???t require a whole templating language to use. Some of this may just be my bias against templating languages from experience in different projects @ yahoo (they always start to get hairy, especially when u start to code in them). Some thoughts: Assuming we can get a libvirt.domain.xsd (?) we can use a xsd-object model utility to transform that xsd into a python object model (there seem to be a couple of these?) http://www.rexx.com/~dkuhlman/generateDS.html or http://pyxsd.org/ (or something else?) Create a exposed ???tree??? representation of the sections of the libvirt domain xml that we are interested in (and only those that we are interested in) as python objects and have current code create these objects (which right now is basically a set of python hashes getting sent to the tempita library) Pass the root element of this exposed ???tree??? representation to a formatter class (which itself could use pyxsd objects, or tempita ??? for backward compatibility, or something else, but I have a strong preference for keeping a single language in use, instead of a tempita language and a python language). Write output created by formatter class to domain.xml file (and continue as normal). Profit! Some of the benefits I think exist with this: XML escaping will actually happen (does this happen right now?) We can have a underlying object layer which comes directly from the libvirt.domain.xsd (and possibly have versions of this to work with different libvirt versions) We can have an exposed object layer which will attempt to be version independent of the underlying layer and only contain methods/properties that we will use with libvirt (ie the xsd will have many properties/fields we will not use, thus we should not expose them). We can have a formatter layer that will know how to use this exposed layer and return a object that can convert the exposed layer into a string, thus allowing for different implementations (or at least a separation of what is exposed, how its formatted and what the formatter internally uses). We can have the if statements and loops and such that are starting to get put in the template code in python code (thus u don???t have to context switch into a templating language to make changes, thus making it easier to work with libvirt). Possible remove a dependency (always good). Thoughts? -Josh ___ 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
[Openstack] [Ops] Admin API: Actions to perform on accounts
Hey Ops folks, There is a blueprint on LP for admin account actions that is set as a high priority, but is missing the following information: * status * series goal * milestone target The blueprint is here: https://blueprints.launchpad.net/nova/+spec/admin-account-actions Devin Carlen, I see that a branch you own has been attached to this blueprint; are you working on this? Does your branch intend to cover all the work? Or are you going to split it over multiple branches? If you're working on this blueprint, do you expect to complete it for this milestone? If the latter, could you provide a list of work items you (or someone else) needs to complete for the feature to be complete? I'll update the blueprint with that info as well as the status/series goal/milestone info. Thanks! d -- Duncan McGreggor OpenStack, Ops Sub-Team Lead ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] PyCon 2012 Sprints?
I just found out that PyCon 2012 registration opened up: https://us.pycon.org/2012/registration/ and was wondering: * are there any OpenStack sprints planned for March 12 through Thursday March 15? * is there a wiki page for this yet on wiki.openstack.org? A quick search answered my question on the latter point, so I created these two pages: * http://wiki.openstack.org/Sprints * http://wiki.openstack.org/Sprints/PyCon2012 There's no content there yet, just placeholders waiting for that first bullet item... ;-) d ___ 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] Providing packages for stable releases of OpenStack
On 07 Dec 2011 - 08:15, Mark McLoughlin wrote: On Tue, 2011-12-06 at 14:12 -0800, Duncan McGreggor wrote: On 06 Dec 2011 - 13:52, Duncan McGreggor wrote: On 06 Dec 2011 - 21:14, Thierry Carrez wrote: Tim Bell wrote: I'm not clear on who will be maintaining the stable/diablo branch. The people such as EPEL for RedHat systems need to have something with the appropriate bug fixes back ported. There are an increasing number of sites looking to deploy in production and cannot follow the latest development version. Agreed on the need, we discussed this at length during the design summit. The stable branches have been established and are maintained by the OpenStack Stable Branch Maintainers team. Currently this team is mostly made of distribution members (Ubuntu and Fedora/RedHat, mostly) collaborating on a single branch to avoid duplication of effort. See: https://launchpad.net/~openstack-stable-maint http://wiki.openstack.org/StableBranch Okay, I think this mostly addresses item #4 that I wanted to add to your summary, Thierry. I do have the following minor concerns, though: * that wiki page's summary (intro sentence) only specifically mentions Diablo; I'd like to see something along the lines of currently focusing on Diablo. If these processes evolve into a successful model, they will be applied to all future releases. Added. * the discussion on the page treats this as an experiment (this is good!), but I'd like to see a phrase alone the lines of if this experiment is successful, we will do X to ensure these processes become an official part of the workflow. Cleaned up the this is an experiment text a bit, it's gone beyond an experiment now I think. Very cool, Mark! Thanks so much!! d ___ 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] Gating on deployment and integration tests for stable/diablo
Nice work!! d On 08 Dec 2011 - 14:12, James E. Blair wrote: Hi, A lot of people would like to see us with more commit gating jobs that test functionality across the full range of core OpenStack projects. We've made some progress in that direction, and I think we can start some limited testing by turning on a gating job for the stable/diablo branch of several projects. We have a job on Jenkins that creates a new VM, runs devstack on it, and then exercise.sh: https://jenkins.openstack.org/job/dev-gate-integration-tests-devstack-vm/ It will eventually run the tempest test suite once it's ready. It is triggered by gerrit changes to the following projects and branches: openstack/nova stable/diablo openstack/glancestable/diablo openstack/keyston stable/diablo openstack/openstack-ci master openstack/python-novaclient master openstack-dev/devstack stable/diablo A change to any of those projects (on those branches) currently triggers this job, in silent mode, which means it runs on the change before it's merged into gerrit, but does not vote, and so can not reject the change. This configuration has been running for a couple of weeks now. In general, it usually works, but we have seen a few failures, typically either a failure to deploy a VM from the cloud provider or a part of the install or setup process that hits the network and encounters a failure. We'll continue to work on stabilizing it (volunteers welcome!) In the mean time, it's fairly easy to retrigger the test in either jenkins or gerrit. There are still a number of issues involved in turning this on for trunk, not only related to stability and determinism, but also to coordinating simultaneous changes to multiple projects. However, I think this is reasonably stable and workable for the stable/diablo branch. It will allow us to get some experience with a cross-project integration test gating job without risking slowing down trunk development too much. And it just might catch a bug. So unless anyone objects, I'd like to disable silent mode and make this an actual gating job for stable/diablo. -Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Providing packages for stable releases of OpenStack
On 07 Dec 2011 - 08:22, Mark McLoughlin wrote: On Tue, 2011-12-06 at 10:11 -0800, Duncan McGreggor wrote: On 06 Dec 2011 - 14:28, Thierry Carrez wrote: So the general consensus so far on this discussion seems to be: (0) The 2011.3 release PPA bears false expectations and should be removed now. In the future, we should not provide such PPAs: 0-day packages for the release should be available from the last milestone PPA anyway. (1) OpenStack, as an upstream project, should focus on development rather than on providing a production-ready distribution. (2) We could provide daily builds from the stable/diablo branch for a variety of releases (much like what we do for the master branch), but those should be clearly marked not for production use and be best-effort only (like our master branch builds). (3) This should not prevent a group in the community from working on a project providing an openstack on Lucid production-ready distribution if they so wishes. This project would just be another distribution of OpenStack. This doesn't seem like enough to me. OpenStack isn't just a library; it's a fairly substantial collection of software and services, intended to be used as a product. If it can't be used as a product, what's the use? Someone made the suggestion that a new OpenStack group be started, one whose focus is on producing a production-ready, distribution-ready, release of the software. So can we add one more (need some help with wording, here...): This paragraph makes it sound like you think OpenStack upstream should produce production-ready binary packages? Nope, just production-ready code. Doing the many things necessary so that: 1) when someone wants to build a binary package, they have everything that they need to do so; 2) when the OpenStack components are installed from these packages, they run well; 3) when someone wants to read the documentation for that release, it's available, up-to-date, and accurate; 4) when the unit tests are run for a given release, they all pass on a properly configured system (which is documented, supporting #3 above); 5) when the next release is out, upgrading is a clear and straight-forward process. The idea is not that these are *all* missing; rather, it appears to me (and others on this list) that the activities outlined above are not well-coordinated and/or prioritized. (4) OpenStack will accept and foster a new project, one that is not focused on development, but rather the distribution and it's general stability. This distro project will be responsible for advocating on behalf of various operating systems/distros/sponsoring vendors for bugs that affect performance and stability of OpenStack, or prevent an operating system from running OpenStack. This sounds like you want want OpenStack to focus more on the quality of its releases. Agreed, but it's not just about QA -- there is a lot involved here. With lots of different teams. My thought is that if there was an actual point of contact (person or team) that was responsible for coordinating on the specific set of areas that were agreed to have the most impact on creating a production-ready product, operators/users, vendors, etc., would have much more confidence in OpenStack as a dependable platform that business-critical systems could put their trust in. It also sounds like you want more co-ordination upstream between downstream distributions of OpenStack. I think there's already pretty good co-ordination. Is there any specific problem you've seen on that front? I think that if we had something in place like the 5 numbered points above (and other points that have been mentioned in this thread), such that an operator could quickly and easily get from 0 to production-ready in a few short steps, OpenStack would be truly unstoppable. And an obvious choice for both those with no budget and those with big budgets. d ___ 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] Providing packages for stable releases of OpenStack
On 06 Dec 2011 - 10:11, Duncan McGreggor wrote: On 06 Dec 2011 - 14:28, Thierry Carrez wrote: So the general consensus so far on this discussion seems to be: (0) The 2011.3 release PPA bears false expectations and should be removed now. In the future, we should not provide such PPAs: 0-day packages for the release should be available from the last milestone PPA anyway. (1) OpenStack, as an upstream project, should focus on development rather than on providing a production-ready distribution. (2) We could provide daily builds from the stable/diablo branch for a variety of releases (much like what we do for the master branch), but those should be clearly marked not for production use and be best-effort only (like our master branch builds). (3) This should not prevent a group in the community from working on a project providing an openstack on Lucid production-ready distribution if they so wishes. This project would just be another distribution of OpenStack. This doesn't seem like enough to me. OpenStack isn't just a library; it's a fairly substantial collection of software and services, intended to be used as a product. If it can't be used as a product, what's the use? Someone It was Loic Dachary. He said: However, as it evolves towards a system widely used in production, it will face new challenges and the communities working on packaging for each distribution will provide valuable input to developers. Creating a packaging team with representatives for each distribution and electing someone to represent them in the Policy Board could achieve this. d made the suggestion that a new OpenStack group be started, one whose focus is on producing a production-ready, distribution-ready, release of the software. So can we add one more (need some help with wording, here...): (4) OpenStack will accept and foster a new project, one that is not focused on development, but rather the distribution and it's general stability. This distro project will be responsible for advocating on behalf of various operating systems/distros/sponsoring vendors for bugs that affect performance and stability of OpenStack, or prevent an operating system from running OpenStack. Thoughts? d ___ 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] Providing packages for stable releases of OpenStack
On 06 Dec 2011 - 13:52, Duncan McGreggor wrote: On 06 Dec 2011 - 21:14, Thierry Carrez wrote: Tim Bell wrote: I'm not clear on who will be maintaining the stable/diablo branch. The people such as EPEL for RedHat systems need to have something with the appropriate bug fixes back ported. There are an increasing number of sites looking to deploy in production and cannot follow the latest development version. Agreed on the need, we discussed this at length during the design summit. The stable branches have been established and are maintained by the OpenStack Stable Branch Maintainers team. Currently this team is mostly made of distribution members (Ubuntu and Fedora/RedHat, mostly) collaborating on a single branch to avoid duplication of effort. See: https://launchpad.net/~openstack-stable-maint http://wiki.openstack.org/StableBranch Okay, I think this mostly addresses item #4 that I wanted to add to your summary, Thierry. I do have the following minor concerns, though: * that wiki page's summary (intro sentence) only specifically mentions Diablo; I'd like to see something along the lines of currently focusing on Diablo. If these processes evolve into a successful model, they will be applied to all future releases. * the discussion on the page treats this as an experiment (this is good!), but I'd like to see a phrase alone the lines of if this experiment is successful, we will do X to ensure these processes become an official part of the workflow. These are tiny things, but I think they will better set expectations and give more warm fuzzies to organizations thinking about deploying OpenStack in production environments, seeing that we're considering the long-term (given success of the experiment). In addition, I would like to emphasize Tim's point from earlier, though: it's not just packaging... he said it very well, so I'll quote: Tim Bell wrote: We need more than 'just' packaging it is using the testing, documentation and above all care to produce *and* maintain a stable release that production sites can rely on for 6-12 months and know that others are relying on it too. I would like to see verbage reflecting Tim's concerns added to the wiki page as well. * What is the QA/testing story? * What is the documentation story? * What is the support cycle story? Yikes! I forgot an incredibly important one: * What is the migration path story (diablo to essex, essex to f, etc.)? d Ghe Rivero, Michael Pittaro, Tim Bell: does the stable maintenance team address your concerns? d ___ 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] Providing packages for stable releases of OpenStack
On 06 Dec 2011 - 23:56, Loic Dachary wrote: On 12/06/2011 09:24 PM, Thierry Carrez wrote: Duncan McGreggor wrote: On 06 Dec 2011 - 14:28, Thierry Carrez wrote: So the general consensus so far on this discussion seems to be: (0) The 2011.3 release PPA bears false expectations and should be removed now. In the future, we should not provide such PPAs: 0-day packages for the release should be available from the last milestone PPA anyway. (1) OpenStack, as an upstream project, should focus on development rather than on providing a production-ready distribution. (2) We could provide daily builds from the stable/diablo branch for a variety of releases (much like what we do for the master branch), but those should be clearly marked not for production use and be best-effort only (like our master branch builds). (3) This should not prevent a group in the community from working on a project providing an openstack on Lucid production-ready distribution if they so wishes. This project would just be another distribution of OpenStack. This doesn't seem like enough to me. OpenStack isn't just a library; it's a fairly substantial collection of software and services, intended to be used as a product. If it can't be used as a product, what's the use? Someone made the suggestion that a new OpenStack group be started, one whose focus is on producing a production-ready, distribution-ready, release of the software. So can we add one more (need some help with wording, here...): (4) OpenStack will accept and foster a new project, one that is not focused on development, but rather the distribution and it's general stability. This distro project will be responsible for advocating on behalf of various operating systems/distros/sponsoring vendors for bugs that affect performance and stability of OpenStack, or prevent an operating system from running OpenStack. I don't think you need a project (openstack projects are about upstream software): you need a *team* to coordinate distribution efforts and make sure openstack projects are packageable etc. Like zul said, that team actually already informally exists and has an IRC channel :) Packaging is a tremendous amount of work, I'm sure you agree on this otherwise this thread would not exist ;-) It is not upstream code development indeed. However the people working to package openstack provide valuable input to developers and patches that are not only essential to packaging but also to the useability of the components. Creating a packaging team that acknowledge their contribution to the upstream project will show that the packagers contributions are an integral part of the openstack development, it would motivate new packagers to contribute their changes upstream instead of keeping them in a patch directory within the package. I think there is an opportunity to leverage the momentum that is growing in each distribution by creating an openstack team for them to meet. Maybe Stefano Maffulli has an idea about how to go in this direction. The IRC channel was a great idea and it could become more. Good packages make a huge difference when it comes to deploying a solution made of numerous components. A packaging team that spans all openstack components would reduce the workload as intended while keeping the subject on the agenda. Cheers Wow. I'm so +1 on this. Very well said; sums up my feelings on the matter too. Maybe this could be made an agenda item for the next PPB meeting? d begin:vcard fn:Loic Dachary n:Dachary;Loic org:Artisan Logiciel Libre adr:;;12 bd Magenta;Paris;;75010;France email;internet:l...@dachary.org title:Senior Developer tel;work:+33 4 84 25 08 05 tel;home:+33 9 51 18 43 38 tel;cell:+33 6 64 03 29 07 note:Born 131414404 before EPOCH. url:http://dachary.org/ version:2.1 end:vcard ___ 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] [nova-testing] Efforts for Essex
On 30 Nov 2011 - 11:07, Duncan McGreggor wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: ? https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. I've created a blueprint for this proposed work here: https://blueprints.launchpad.net/nova/+spec/unit-test-reorg d All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen ? ? ? ?| http://linux2go.dk/ Ubuntu Developer ? ?| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to ? ? : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help ? : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova-testing] Efforts for Essex
On 30 Nov 2011 - 11:07, Duncan McGreggor wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: ? https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests This was a typo, and should have read: * move all volume-related tests ... d * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen ? ? ? ?| http://linux2go.dk/ Ubuntu Developer ? ?| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to ? ? : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help ? : https://help.launchpad.net/ListHelp ___ 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] Providing packages for stable releases of OpenStack
On 30 Nov 2011 - 13:57, Loic Dachary wrote: Hi, TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. As Julien Danjou wrote, we ( OpenStack Debian GNU/Linux packagers [1]) discussed your mail. We are comfortable with the idea that OpenStack focuses on development and that packaging is left to the packagers involved in each distribution. Packaging related patches from Julien Danjou were recently accepted upstream (https://review.openstack.org/#dashboard,1669). This is the kind of cooperation that makes it possible to maintain packages matching the Debian GNU/Linux quality standard. We are confident in our ability to provide stable packages in the future. OpenStack packaging is not an easy task. It currently fits nicely in Debian GNU/Linux. However, as it evolves towards a system widely used in production, it will face new challenges and the communities working on packaging for each distribution will provide valuable input to developers. Creating a packaging team with representatives for each distribution and electing someone to represent them in the Policy Board could achieve this. Very +1. d Cheers [1] PKG OpenStack page : https://alioth.debian.org/projects/openstack/and corresponding packages: http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org http://qa.debian.org/developer.php?packages=nova http://qa.debian.org/developer.php?packages=glance begin:vcard fn:Loic Dachary n:Dachary;Loic org:Artisan Logiciel Libre adr:;;12 bd Magenta;Paris;;75010;France email;internet:l...@dachary.org title:Senior Developer tel;work:+33 4 84 25 08 05 tel;home:+33 9 51 18 43 38 tel;cell:+33 6 64 03 29 07 note:Born 131414404 before EPOCH. url:http://dachary.org/ version:2.1 end:vcard ___ 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] [nova-testing] Efforts for Essex
On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova-testing] Efforts for Essex
On 30 Nov 2011 - 19:26, Chris Behrens wrote: I need to catch up a bit with this thread, but I wanted to mention I have a huge patch coming that refactors almost all of the scheduler tests into true unit tests. Nice! I'd started this for other reasons and I hope it jives with the plans here. But if anyone is looking at the scheduler tests, we should sync up. I was going to actually use the scheduler as the example when I sent this email out, but I switched to something a bit cleaner instead... so this is great news! Can't wait to see it :-) d - Chris On Nov 30, 2011, at 1:07 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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
