Re: [Openstack] Keystone Grizzly RC2 available

[Andy Smith]

The change I made to build tokens from existing data (rather than
re-querying it all from the db) didn't go in?

Without it extensions are not able to build custom tokens (meaning just
about any extension that wants to do something with auth is not possible).


On Thu, Mar 28, 2013 at 2:34 AM, Thierry Carrez thie...@openstack.orgwrote:

 Hello everyone,

 Due to the renaming of the trust extension and a response backward
 compatibility issue, we created a new Grizzly release candidate for
 OpenStack identity (Keystone).

 You can find the RC2 tarball and the list of fixed bugs at:
 https://launchpad.net/keystone/grizzly/grizzly-rc2

 This is hopefully the last Grizzly release candidate for Keystone.
 Unless new release-critical regressions are found that warrant another
 release candidate respin, this RC2 will be formally included in the
 common OpenStack 2013.1 final release next week. You are therefore
 strongly encouraged to test and validate this tarball.

 Alternatively, you can grab the code at:
 https://github.com/openstack/keystone/tree/milestone-proposed

 If you find a regression that could be considered release-critical,
 please file it at https://bugs.launchpad.net/keystone/+filebug and tag
 it *grizzly-rc-potential* to bring it to the release crew's attention.

 Happy regression hunting,

 --
 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] There is no object-store endpoint on this auth server.

[Andy Smith]

Just ran into this, the issue is that swift expects the user to be of the
form TENANTNAME:USERNAME

swift will accept the ST_USER env variable, so you can add something like
this to your env:

export ST_USER=openstackDemo:adminUser


On Tue, May 8, 2012 at 8:42 AM, Shashi Kanth Boddula
shashi@gmail.comwrote:

 Ubuntu 12.04 LTS with Essex.

 I have created endpoint for swift, but still swift reports there is no
 endpoint.


 root@OpenStack:~# export OS_USERNAME=swift
 root@OpenStack:~# export OS_TENANT_NAME=service
 root@OpenStack:~# export OS_PASSWORD=swiftpass
 root@OpenStack:~# export OS_AUTH_URL=http://OpenStack:5000/v2.0/
 root@OpenStack:~# export OS_REGION_NAME=RegionOne

 *root@OpenStack:~# swift list
 There is no object-store endpoint on this auth server.

 *# cat creds/openrc
 export OS_USERNAME=adminUser
 export OS_TENANT_NAME=openstackDemo
 export OS_PASSWORD=secretword
 export OS_AUTH_URL=http://OpenStack:5000/v2.0/
 export OS_REGION_NAME=RegionOne*

 *root@OpenStack:~# source creds/openrc *

 root@OpenStack:~# swift list
 There is no object-store endpoint on this auth server.

 *
 # curl -d '{auth: {tenantName: openstackDemo,
 passwordCredentials:{username: adminUser, password:
 secretword}}}' -H Content-type: application/json
 http://OpenStack:35357/v2.0/tokens | python -mjson.tool

 {
 endpoints: [
 {
 adminURL: http://OpenStack:8080/;,
 internalURL: 
 http://OpenStack:8080/v2/AUTH_0e63498833bf44e4aeb0ac314635b68f;,
 publicURL: 
 http://OpenStack:8080/v2/AUTH_0e63498833bf44e4aeb0ac314635b68f;,
 region: RegionOne
 }
 ],
 endpoints_links: [],
 name: swift,
 type: object-store
 },


 # cat /etc/keystone/keystone.conf | grep templ
 template_file = /etc/keystone/default_catalog.templates

 # cat /etc/keystone/default_catalog.templates | grep object
 catalog.RegionOne.object-store.publicURL =
 http://localhost:8080/v1/AUTH_$(tenant_id)s
 catalog.RegionOne.object-store.adminURL = http://localhost:8080/
 catalog.RegionOne.object-store.internalURL =
 http://localhost:8080/v1/AUTH_$(tenant_id)s
 catalog.RegionOne.object-store.name = 'Object Store Service'

 root@OpenStack:~# ps -ef | grep proxy-server
 swift11192 1  0 05:52 ?00:00:10 /usr/bin/python
 /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf
 swift11197 11192  0 05:52 ?00:00:10 /usr/bin/python
 /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf
 root 11753 10159  0 06:10 pts/200:00:00 grep --color=auto
 proxy-server
 root@OpenStack:~#



 --
 Thanks  Regards,
 Shashi Kanth


 ___
 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] [Keystone] What exactly are we modeling with endpoints?

[Andy Smith]

How about let's rephrase this question:

Who is actually explicitly using the service catalog (besides just having
keystoneclient find the next auth endpoint)? What complaints do you have?

AKA, trying to pull some data out of it and use it to in some way
discover a service.

From my experiences, it appears Nova uses it to find out where Glance is,
and Horizon uses it to find out where Nova and Glance are.

--andy


On Wed, Apr 25, 2012 at 9:37 AM, Nguyen, Liem Manh liem_m_ngu...@hp.comwrote:

  I would like to keep the service type  and name under the service and
 not the endpoint, too.  Make it easier to parse for a given service.

 ** **

 One thing is that I am not sure if we need the metadata tag… In the
 Keystone XSD, we have the construct anyAttribute namespace=##other
 processContents=lax/, which allows any additional,
 implementation-specific attribute to be added.  Those that do not support
 the specific attribute can simply ignore it.   A couple of benefits I can
 see with not using the metadata tag, and just use the custom element
 directly like this:  http://paste.openstack.org/show/13832/, which the
 anyAttribute supports, are:

 ** **

 **· **Simplier parsing, one level less.

 **· **If that attribute becomes a core attribute later, no need
 to change the parser.

 ** **

 Liem

 ** **

 *From:* openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net[mailto:
 openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
 *Joe Savak
 *Sent:* Tuesday, April 24, 2012 1:04 PM
 *To:* Joseph Heck; openstack@lists.launchpad.net (
 openstack@lists.launchpad.net)
 *Cc:* Adam Gandelman
 *Subject:* Re: [Openstack] [Keystone] What exactly are we modeling with
 endpoints?

 ** **

 Having endpoints under the service construct is supposed to make it easier
 to programmatically find the endpoint(s) you are interested in. 

 ** **

 For example – as nova client I can parse the service catalog and identity
 nova by service-type “compute” in order to get the public, internal, and
 admin endpoints for nova. 

 ** **

 By having service type  name as attributes under the endpoint, I’ll have
 a harder time doing that (having to dive into each endpoint construct to
 identify the ones with service-type “compute”).

 Maybe it would be better to have each endpoint have its own construct
 inside of a service. 

 ** **

 So instead of http://paste.openstack.org/show/13678/

 Maybe http://paste.openstack.org/show/13682/

 ** **

 ** **

 *From:* openstack-bounces+joe.savak=rackspace@lists.launchpad.net[mailto:
 openstack-bounces+joe.savak=rackspace@lists.launchpad.net] *On Behalf
 Of *Joseph Heck
 *Sent:* Friday, April 20, 2012 4:16 PM
 *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net)
 *Cc:* Adam Gandelman
 *Subject:* [Openstack] [Keystone] What exactly are we modeling with
 endpoints?

 ** **

 While I've been roaming about the summit and conference, I've been trying
 to figure out exactly what we're modeling with the current service and
 endpoints that are in the API today. After talking with a number of
 folks, it's getting clearer that how it's being used is very installation
 specific.

 ** **

 I'd like to simplify this aspect of the API if at all possible, especially
 with a lot of the good ideas around describing the relationships between
 endpoints and and their installation.

 ** **

 The use cases I'm hearing actively in use are:

 ** **

 * (Horizon/UI/client) To indicate to a user where they can go to access
 their data

 * (Glance, Nova, Keystone client) to find the endpoint relevant to
 uploading images (current client implementations appear to assume there is
 only one image endpoint)

 ** **

 The use case to indicate a geographic location for a datacenter or cloud
 is not consistent - some implementations I've learned of have that feature
 (and use Region for that sort of information), and others are load
 balancing a single endpoint to deploy to multiple datacenters and
 geographic regions from a single endpoint.

 ** **

 At the summit and conference, I heard a desire to expose geographic
 information with the endpoints, but that is clearly an operator specific
 implementation/deployment detail. Likewise I heard a lot of We could
 really... if additional metadata was easily available on endpoints, again
 in fairly implementation/deployment specific detail.

 ** **

 So looking forward towards a v.next API, what do you all think about
 having just endpoints, with everything else being attributes on those
 endpoints (including what service and type it is), with some expected
 conventions (that there are a few well defined types - such as PublicURL
 and InternalURL, and relevant names for the rest API endpoints (ec2,
 compute, volume, image, identity...) 

 ** **

 Additional metadata can then float on the endpoints in
 deployment/implementation specific ways 

Re: [Openstack] Who wrote Essex?

[Andy Smith]

commit early, commit often ;)

On Friday, April 6, 2012, Stefano Maffulli wrote:

 Thank you Mark.

 I use a different tool to get the weekly stats, cvsanaly and then build
 the charts with Pentaho Reporting. I'm glad to have more people looking
 at the data and provide alternatives though :)

 See you in a few days
 stef

 On Fri, 2012-04-06 at 08:16 +0100, Mark McLoughlin wrote:
  Hey,
 
  I've played around with Jonathan Corbet's gitdm[1] which is used to
  publish the Who Wrote Linux articles on LWN for each kernel release.
 
  It's really quite fun to apply it to OpenStack and see what comes out,
  like who the top 20 contributors are across Nova, Glance, Swift,
  Keystone, Horizon and Quantum:
 
Processed 3481 csets from 217 developers
100 employers found
A total of 421695 lines added, 256904 removed (delta 164791)
 
Developers with the most changesets
termie 238 (6.8%)
Gabriel Hurley 207 (5.9%)
Brian Waldon   195 (5.6%)
Johannes Erdfelt   146 (4.2%)
Vishvananda Ishaya 116 (3.3%)
Dolph Mathews   98 (2.8%)
Dan Prince  84 (2.4%)
Ziad Sawalha80 (2.3%)
Jason Kölker   77 (2.2%)
Mark McLoughlin 73 (2.1%)
Jake Dahn   73 (2.1%)
Rick Harris 71 (2.0%)
Alex Meade  70 (2.0%)
Trey Morris 62 (1.8%)
Joe Heck58 (1.7%)
Chris Behrens   52 (1.5%)
Russell Bryant  50 (1.4%)
Eoghan Glynn50 (1.4%)
Joe Gordon  47 (1.4%)
Jesse Andrews   46 (1.3%)
Covers 54.380925% of changesets
 
  w00t! Congrats and thanks to those for all their hard work on Essex!
 
  I've pushed my gitdm fork here:
 
https://github.com/markmc/openstack-gitdm
 
  and the first attempt Essex statistics here:
 
https://github.com/markmc/openstack-gitdm/tree/results/essex
 
  Note that it also includes launchpad and gerrit stats. It's all a bit
  unpolished, but interesting nonetheless. Feel free to fork and improve
  it!
 
  I'm looking forward to discussing this stuff more at Stefano's Design
  Summit community metrics session.
 
  Cheers,
  Mark.
 
  [1] - http://lwn.net/Articles/290957/
 
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net javascript:;
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net javascript:;
 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] is this a bug in milestone-proposed keystone ? (cannotget endpoint-list, nor create endpoint)

[Andy Smith]

On Mon, Mar 26, 2012 at 11:12 AM, David Kranz david.kr...@qrclab.comwrote:

  Thanks for the explanation. But I am still a little confused about the
 point of the templates. Having two implementations, one simple and one less
 simple, is not simpler than having only one. You still need to user the CLI
 for user, roles, etc.  so having a different mechanism for endpoints does
 not seem simple. With regard to performance, won't these endpoint values be
 changing infrequently and so any reasonable caching strategy would give
 good performance? Or am I missing something?


The preference is to switch the default to the SQL driver, the other
backend was simply the first driver written and will likely be deprecated.

--andy



  -David


 On 3/26/2012 1:39 PM, Dolph Mathews wrote:

 I think I'm to blame (apologies!) for suggesting that one driver was
 preferred over the other (that was my understanding a few weeks ago, based
 on test coverage). However, test coverage has since improved and I think
 people are having good experience with the SQL driver.

  The two methods are *not* functionally identical. The file-based driver
 is simple and high-performance, and the sql-based driver provides
 flexibility and API/CLI administration.

  I've just proposed a review to clarify each option in the
 http://keystone.openstack.org/configuration.html docs:
 https://review.openstack.org/#change,5820

  As well as a separate review to change the default backend to SQL, since
 most users are looking for the CLI management commands out of the box:
 https://review.openstack.org/#change,5821

 -Dolph

 On Mon, Mar 26, 2012 at 8:29 AM, David Kranz david.kr...@qrclab.comwrote:

  There seems to be an unfortunate difference in opinion out there about
 whether the keystone endpoints should be defined using templates (devstack)
 or keystone calls (ubuntu).  I don't know why keystone is offering two very
 different, but seemingly functionally identical, ways to do this. Is there
 a good reason? Can this be sorted out so there is only one documented way
 to do this?

  -David


 On 3/26/2012 7:25 AM, Andiabes wrote:

 Can you include your config?
 The behavior you're describing seems to be consistent with a missing
 backers configuration ...

  Something like:

 [identity]
 driver = keystone.identity.backends.sql.Identity
 [catalog]
 driver = keystone.catalog.backends.sql.Catalog
 Also, where/how are you installing?


 On Mar 26, 2012, at 6:56 AM, Mandar Vaze mandar.v...@vertex.co.in
 wrote:

   I’m also getting the same error on latest master branch (updated today)

 Using setup created by devstack



 -Mandar



 *From:* openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net [
 mailto:openstack-bounces+mandar.vaze= openstack-bounces+mandar.vaze=
 vertex.co...@lists.launchpad.net] *On Behalf Of *.?o 0 O??
 *Sent:* Monday, March 26, 2012 12:45 PM
 *To:* Pierre Amadio
 *Cc:* openstack
 *Subject:* Re: [Openstack] is this a bug in milestone-proposed keystone
 ? (cannotget endpoint-list, nor create endpoint)



 hi,

 I don't know if it is a bug but I come across the same problem and
 wondering how to solve it.





 -- Original --

 *From: * Pierre Amadiopierre.ama...@canonical.com;

 *Date: * Sun, Mar 25, 2012 04:35 AM

 *To: * openstackopenstack@lists.launchpad.net;

 *Subject: * [Openstack] is this a bug in milestone-proposed keystone ?
 (cannotget endpoint-list, nor create endpoint)



 Hi there !

 I wanted to give a try to the milestone-proposed branch of keystone and
 got stuck quite fast.

 I am not sure if i hit a bug and should report it, or if i'm doing
 something wrong.

 With previous version of keystone (read packaged on ubuntu precise), i
 was able to create endpoint the following way once keystone has been
 installed:

 1) setting some env variables:
 export KEYSTONE_IP=192.168.122.102 # IP of your keystone API server
 export SERVICE_ENDPOINT=http://$KEYSTONE_IP:35357/v2.0/
 export SERVICE_TOKEN=999888777666
 export NOVA_PUBLIC_URL=http://$NOVA_IP:8774/v1.1/%(tenant_id)s
 export NOVA_ADMIN_URL=$NOVA_PUBLIC_URL
 export NOVA_INTERNAL_URL=$NOVA_PUBLIC_URL

 2) creating services:
 keystone service-create --name nova --type compute --description
 'OpenStack Compute Service'

 keystone service-create --name swift --type object-store --description
 'OpenStack Storage Service'

 keystone service-create --name glance --type image --description
 'OpenStack Image Service'

 keystone service-create --name keystone --type identity --description
 'OpenStack Identity Service'

 3) creating an endpoint for those services, starting with the compute
 service:

 ID=$(keystone service-list | grep -i compute | awk '{print $2}')


 keystone endpoint-create --region RegionOne --service_id $ID --publicurl
 $NOVA_PUBLIC_URL --adminurl $NOVA_ADMIN_URL --internalurl
 $NOVA_INTERNAL_URL

 When i run this command with milestone-proposed, i experience the
 following:

 No handlers could be found for logger 

Re: [Openstack] Being pedantic about pedanticism: HACKING styleguide

[Andy Smith]

 I am happy to take on and implement any of these approaches, up to and
 including scheduling an in-person Code Summit Battledome in order to
 resolve differences of opinion about docstring whitespace.  But, my
 preference for a unified style-guide is a mild one, and I'll probably just
 opt for solution 1 unless others express that unification is worth the
 trouble.


May the odds be ever in your favor.





 -Andrew



 __**_
 Mailing list: 
 https://launchpad.net/~**openstackhttps://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : 
 https://launchpad.net/~**openstackhttps://launchpad.net/~openstack
 More help   : 
 https://help.launchpad.net/**ListHelphttps://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] Being pedantic about pedanticism: HACKING styleguide

[Andy Smith]

On Fri, Mar 23, 2012 at 1:17 PM, Mark McLoughlin mar...@redhat.com wrote:

 On Thu, 2012-03-22 at 22:00 -0700, Andy Smith wrote:

  It is something pulled from the google style guide.

 You know what else is in the Google style guide? Avoid global
 variables :-)


 http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Global_variables#Global_variables

 Mark.


And yet they use a global config object in most of their code, as do
facebook and digg (at quick survey of those people sitting near me).

They also have a variety of things in there that we don't follow because it
is easier to convince people of PEP8 than of the google style guide, but
there are plenty of other good ideas in there that we could absorb, too.
___
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] Being pedantic about pedanticism: HACKING styleguide

[Andy Smith]

On Thu, Mar 22, 2012 at 9:22 AM, Andrew Bogott abog...@wikimedia.orgwrote:

Just now I set out to merge a recent style guide change from
 python-novaclient into the hacking docs of other OpenStack projects.  My
 patch didn't apply, though, because each project has subtly diverging
 HACKING files.

Rather than contribute to this divergence, I've now read and compared
 the style guides from Nova, Glance, Keystone, python-keystoneclient, and
 python-novaclient.  From these diffs I've created a file (attached) that
 encompasses the total of all guidelines from all projects.  Remarkably,
 this merge produced only minor disagreements, described below under the
 heading FLAMEBAIT.

I propose that this unified style guide be copied into each of the
 above projects, with a mandate to maintain consistency henceforth.  Any
 objections?

 -Andrew


 FLAMEBAIT (docstring format):

 The only explicit contradiction I came across is regarding docstring
 formatting.  Glance says this:

 **DO NOT** leave an extra newline before the closing triple-double-quote.

 Nova, this:

  A docstring ends with an empty line before the closing quotations.

 I propose that we just pick one or the other, or remove both prescriptions.


I'm fine with moving forward to not having the trailing newline, it was for
an emacs feature that has since become smarter (and who cares about emacs
anyway). It is mentioned as the preferred way in PEP8, so it runs into some
disagreements from time to time. Most of the code in the projects has been
written with the older rule (yes on trailing newline) but I haven't been
blocking new code from not using it.



 FLAMEBAIT (filename):

 Some projects have a HACKING file, and some have a HACKING.rst file.
  Doesn't .rst generally indicate a REST API definition?  I propose that the
 file be called HACKING.


HACKING.rst makes github format it correctly, let's move everything to rst.




 ___
 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] Being pedantic about pedanticism: HACKING styleguide

[Andy Smith]

Oh, and we should include the file in each project with a link to whatever
the base one is.

That said, I don't intend to change the style of my project just because
the common one changes, and it shouldn't be a wiki because that makes it
too easy to change.

On Thu, Mar 22, 2012 at 3:01 PM, Andy Smith andys...@gmail.com wrote:



 On Thu, Mar 22, 2012 at 9:22 AM, Andrew Bogott abog...@wikimedia.orgwrote:

Just now I set out to merge a recent style guide change from
 python-novaclient into the hacking docs of other OpenStack projects.  My
 patch didn't apply, though, because each project has subtly diverging
 HACKING files.

Rather than contribute to this divergence, I've now read and compared
 the style guides from Nova, Glance, Keystone, python-keystoneclient, and
 python-novaclient.  From these diffs I've created a file (attached) that
 encompasses the total of all guidelines from all projects.  Remarkably,
 this merge produced only minor disagreements, described below under the
 heading FLAMEBAIT.

I propose that this unified style guide be copied into each of the
 above projects, with a mandate to maintain consistency henceforth.  Any
 objections?

 -Andrew


 FLAMEBAIT (docstring format):

 The only explicit contradiction I came across is regarding docstring
 formatting.  Glance says this:

 **DO NOT** leave an extra newline before the closing triple-double-quote.

 Nova, this:

  A docstring ends with an empty line before the closing quotations.

 I propose that we just pick one or the other, or remove both
 prescriptions.


 I'm fine with moving forward to not having the trailing newline, it was
 for an emacs feature that has since become smarter (and who cares about
 emacs anyway). It is mentioned as the preferred way in PEP8, so it runs
 into some disagreements from time to time. Most of the code in the projects
 has been written with the older rule (yes on trailing newline) but I
 haven't been blocking new code from not using it.



 FLAMEBAIT (filename):

 Some projects have a HACKING file, and some have a HACKING.rst file.
  Doesn't .rst generally indicate a REST API definition?  I propose that the
 file be called HACKING.


 HACKING.rst makes github format it correctly, let's move everything to rst.




 ___
 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] Being pedantic about pedanticism: HACKING styleguide

[Andy Smith]

On Thu, Mar 22, 2012 at 4:26 PM, Maru Newby mne...@internap.com wrote:

 Hi Jay,

 On 2012-03-22, at 2:13 PM, Jay Pipes wrote:


 Object Imports
 ==

 In addition, the following DOES NOT appear in Glance's section on imports:

 - Do not import objects, only modules

 Nowhere in PEP8 does it mention anything about not importing objects. In
 fact, PEP8

 says this:


The rule is there because it makes it obvious where you are using objects
from (and they aren't in the current namespace), prevents that where is
this defined -scan around the file- oh, it is being imported from this
other thing, let's go look there pattern, instead you see very obviously
that it isn't defined in the file and usually has a unique enough name
already that you know exactly where to look.

It is something pulled from the google style guide.


 I'm pretty sure the reason for this rule has nothing to do with PEP8, and
 is instead intended to avoid circular imports.  I don't see the utility in
 applying the rule to 3rd party modules, since circular imports wouldn't be
 an issue, but I do consider it a best practice for project code.

 Cheers,


 Maru

 ___
 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] Redux deps?

[Andy Smith]

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.comwrote:

  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

[Openstack] Keystone: Redux (Dubstep Remix)

[Andy Smith]

tl;dr proposal to merge keystone redux: same API, same client, new
service.  Please review and ask questions!

FRIENDS, ROMANS

We are gathered here today to celebrate the commencement of Keystone
(redux) to fill the role of Keystone (henceforth known as legacy). It is
with great pride that we propose this stand-up-fellow of a refactor to join
the ranks of the other OpenStack projects.

There will be differences, both in how you develop and how you use it,
though we've tried to keep those to a minimum (it has the same API, client,
and migration paths from existing deploys)

You will notice that the code is organized rather differently in most
cases, though still in line with the general form of OpenStack projects,
and we use the standard tools and procedures you may be familiar with from
work on a project like Nova.  (Your wrists will be shattered if you attempt
to use double quotes where single quotes might better suffice.)

The bulk of the work put into `redux` has been to reduce the complexity of
and provide a more easily extensible version of `legacy` while still
providing the features that the other projects require. We think we have
been successful in this, and we hope you'll agree.

Read on for more specifics.

MERGE PROPOSAL:

Please voice your comments  votes on the merge proposal:

  *
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

Since this is a rather large merge, you can explore the code at github
(reviews should happen in gerrit using the above link):

  * https://github.com/openstack/keystone/tree/redux
  * https://github.com/openstack-dev/devstack/tree/redux

DELTA:

The two major items we are working on adding to redux at time of writing.
Support for XML and LDAP integration.  We propose evaluating the merge with
these known issues, as work is being done to re-add support before E4.

State of XML (via Dolph Mathews)

   Work is underway to support the existing XSD/WADLs
   XML code in its current state is posted to
https://review.openstack.org/#change,4037
   Our hope is to convert XML to/from python objects with minor tweaks
where needed to meet the spec.
   Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
verify correctness, we hope to use a more pythonic tool in redux

State of LDAP (via Adam Young):

   LDAP code in its current state is posted to
https://github.com/admiyo/keystone/tree/ldap2
   Unit tests pass against fakeldap, with the exception of the ones that
check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
   I am working on getting the scheme documented for the LDAP server, and
for prepopulating Roles.
   Authentication against a live LDAP server works.  Roles and Tenants are
currently ignored.  Getting the schema straight needs to happen first.
   Should have working code in the next day or two.

BUGS:

We've been tagging bugs as redux that are against the rewrite.  You can
view the full list at full bug list at
https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
that are needed to land before this merge as CRITICAL, and before E4 as
HIGH.

Post Merge:

After merge we will continue improving Keystone, specifically:

 * Target critical/high bugs for E4
 * Work with downstream/packagers on changes needed for their distros
 * Work with tempest on test coverage
 * Another pass through the bugs  blueprints to update the state

Thanks to all the contributors to the rewrite:

Andy Smith
Anthony Young
Brian Waldon
Chmouel Boudjnah
Chuck Short
Dean Troyer
Devin Carlen
Dolph Mathews
James E. Blair
Jesse Andrews
Joe Heck
Justin Santa Barbara
Monty Taylor
Vishvananda Ishaya

HOYOOO!


p.s. wubwubwubSKRwubwub
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Keystone: Redux (Dubstep Remix)

[Andy Smith]

Hey there Joshua,

Good question! `redux` started due to a variety of frustrations with the
previous design that arose from decisions made early in the original
development and were deemed infeasible to resolve in an evolutionary way.

My team and the teams we work with closely felt we were in a good position
to re-imagine some of those decisions while still providing a service that
was functional (since we rely on it heavily for day to day work) and robust.

There will certainly be bugs introduced by this move, but we have an
extremely strong vested interest in fixing them rapidly and feel that the
new code base will greatly improve our ability to do so.

--andy

On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).

 *Sorry if this is a repeat*...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of
 and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.
 Support for XML and LDAP integration.  We propose evaluating the merge with
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
 verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
 https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones that
 check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
I am working on getting the scheme documented for the LDAP server, and
 for prepopulating Roles.
Authentication against a live LDAP server works.  Roles and Tenants are
 currently ignored.  Getting the schema straight needs to happen first.
Should have working code in the next day or two.

 BUGS:

 We've been tagging bugs as redux that are against the rewrite.  You can
 view the full list at full bug list at
 https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
 that are needed to land before this merge as CRITICAL, and before E4 as
 HIGH.

 Post Merge:

 After merge we will continue improving Keystone, specifically:

  * Target critical/high bugs for E4
  * Work with downstream/packagers on changes needed for their distros
  * Work with tempest on test coverage
  * Another pass through the bugs  blueprints to update the state

 Thanks to all the contributors to the rewrite:

 Andy Smith
 Anthony Young
 Brian Waldon
 Chmouel Boudjnah
 Chuck Short
 Dean Troyer
 Devin Carlen
 Dolph Mathews
 James E. Blair
 Jesse Andrews
 Joe Heck
 Justin Santa Barbara
 Monty Taylor
 Vishvananda Ishaya

 HOYOOO!


 p.s. wubwubwubSKRwubwub


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack

Re: [Openstack] Proposal for new devstack (v2?)

[Andy Smith]

Looks cool :)

I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.

We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.

The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.

The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.

I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote
servers allows for some more versatility.

--andy

On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Hi all,

 I would just like to propose a new devstack (v2?) that we have been
 starting to work on that uses python throughout as well as has
 componentized installs (for glance, nova...) and a nice object oriented
 design and the like (including having a json format for defining package
 and pip dependencies that allows simple comments so people can know what
 the pkgs are). We are currently trying to get equivalence going for ubuntu
 (and at the same time rhel6.x) and I would like it if we could get peoples
 initial thoughts on this.

 I know the current devstack shell script is starting to explode (LOC wise)
 and it seems like it is a good time to stop that from exploding by creating
 something a little more flexible (and maintainable imho).

 Please check it out @ https://github.com/yahoo/Openstack-Devstack2

 Comments welcome!

 We are working on getting as much equivalence as we can (while still
 maintaining a “clean” design).

 Thx,

 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] [RFC] Common config options module

[Andy Smith]

Took a look over the wiki for this. The approach is very similar to one
I've used recently so I wanted to bring up something that looks like it may
have been overlooked.

In testing it is frequent practice that you want to ensure global config
state and somehow overwrite global config state on the fly (for example
when you have dynamic ports being assigned to a service), passing config
dicts around everywhere makes this task a bit harder. My solution was to
force all instances being handed an options dict to assign it to the
.options attribute on itself, and to use a common name for chained
applications so that it is possible to traverse the tree:

https://github.com/termie/keystonelight/blob/master/keystonelight/test.py#L107

--andy

On Mon, Nov 28, 2011 at 12:57 PM, Mark McLoughlin mar...@redhat.com wrote:

 Hi Jason,

 On Mon, 2011-11-28 at 10:24 -0600, Jason Kölker wrote:
  On Mon, 2011-11-28 at 08:06 -0800, Monty Taylor wrote:
The idea is to unify option handling across projects with this new
 API.
The module would eventually (soon?) live in openstack-common.
  
   Awesome. So - whaddya think about making openstack-common an
   installable/consumable module?
 
  I've extracted openstack-common as a stanalone module from
  openstack-skeleton at https://github.com/jkoelker/openstack-common for
  melange. I also converted the rest of openstack-skeleton to a paster
  template in the openstack-paste repo. Its there for the picking if
  anyone wants to use it.
 
  I'd love to see a unified effort on some front extracting bits and
  moving them into the openstack namespace as an official gerrit, et. al.
  project.
 
  Happy Hacking!

 Cool stuff. I'll dig into it soon and send you a pull request with the
 cfg module.

 Cheers,
 Mark.


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
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] Some updates to REST API specs

[Andy Smith]

We need to add these codes to maintain compliance.

https://tools.ietf.org/html/draft-nottingham-http-new-status-02

--andy
___
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] GitHub migration timeline?

[Andy Smith]

Jay and Monty, could you give the list an update on the status and timeline
of the GitHub migration?

The last informal estimate I had heard was that July 15th was the planned
date. What are the current issues?

--andy
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack-poc] Meeting tomorrow

[Andy Smith]

I shared an initial plan with a few people (mostly PTLs + thierry, I think)
and it kind of stalled out on getting pushed to the main list due to Monty /
Thierry wanting additional features from GitHub.

I've been mostly talking with John DIckinson as it seems like Swift is the
likely first project to switch over, and sharing the migration tool I
wrote: https://github.com/termie/lp2gh

The interesting pages there are:

https://github.com/termie/lp2gh/blob/master/docs/moving_branches.rst

and

https://github.com/termie/lp2gh/blob/master/docs/moving_issues.rst

I can rebuild the original email about a plan, but it will still need to get
buy in from Monty to move forward.

--andy

On Mon, Jun 13, 2011 at 11:25 AM, John Dickinson 
john.dickin...@rackspace.com wrote:


 On Jun 13, 2011, at 1:17 PM, John Purrier wrote:
 
  For tomorrow's meeting... PTL's, can you update us on where each of your
  projects stand on this? Termie and mtaylor (added to the email) were
 going
  to come up with a plan for review, is this getting done?

 I have a very good start on swift's migration plan. We've been practicing
 some with the swauth project in Launchpad/GitHub. I've got a few docs
 written on it, and I'm planning on sharing those with other involved persons
 as soon as I have a little more details. Our plan is to set a date and make
 sure all parties are taken care of.

 --John
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Overview of CI/Testing

[Andy Smith]

Thanks for the update Monty :)


  That's just testing API in a VM though, and doesn't get us to testing
 actual bare-metal deployment or integration testing. At Rackspace, we
 have some machines set aside at the moment, and have had others offer
 chunks of machines to test various combinations of things. At its heart,
 the abstract version of this looks fairly identical to the smoketests
 job - pxe boot machines, shove version to be tested on them, run tests.
 However, there are several moving bits on the best way to actually do
 the how. At the moment, the fine folks at rPath have a Jenkins
 installing and testing rPath OpenStack images, so Mihai and I are going
 to look at getting that setup ported to our Jenkins. However, although
 that will be an excellent test of code, as our main target platform is
 Ubuntu, we're also looking at doing a straight-up cobbler install using
 generated .debs.


Jesse and I had already gotten quite far along using chef to do the
provisioning of baremetal boxes once we'd pxe booted them into ubuntu, it
seems like chef or puppet (our current preference is chef) should be used
there as well instead of generated .debs.

At the moment the two closest things to being official installations for
us (me? are the chef recipes and the nova.sh script (the nova.sh script
obviously being only targeted at testing and dev though), those are what we
use to verify that the system is functional and I think we'd like to use
chef or puppet for baremetal deployments as well.

TL;DR: Can we focus on the chef recipes instead of on .debs?



 In any case, this is the bit which is still in the
 planning and discussion phase, but so far all of the conversations I've
 had with folks have been great - and I'd love to get more folks involved
 in that (thus this email)

 However- latent goal here is that whatever mechanism we're having
 Jenkins use to deploy OpenStack onto real hardware should be consumable
 and one that actual people might actually use - otherwise what the heck
 are we testing?

 Additionally, as you may have surmised, it is also a goal to run as much
 of this as possible from the OpenStack Jenkins, because that way we can
 as a project choose to incorporate as much of the feedback/results of
 various forms of testing directly in to branch testing/approval as we
 want. For some things (spinning up 20 node OpenStack clusters) doing it
 on every merge proposal or giving all devs the ability to click a button
 and have it run on their branch will likely be overkill - but if it
 turns out not to be, it would be great to have the ability to do it.

 End goal is to have:
  - publicly accessible and usable system for testing and build automation
  - resources that it uses to spin up clouds in order to test them are
 themselves usable by people to spin up clouds
  - tooling around this is done in a manner that makes us of and
 contributes back to existing projects (jenkins plugins, patches back to
 cobbler/orchestra/whatever)

 If you didn't read my _other_ long email from a few moments ago, actual
 discussion of getting this done - and figuring out other people's
 needs/tools and how to integrate them - is hopefully happening next week
 right before the regular openstack-meeting. In the mean time, please
 either flame on right here in list, or ping me back personally.

 Thanks everyone!
 Monty

 ___
 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] Coalescing and Coordinating Continuous Integration, Developer Tools, Function and Smoke Testings Efforts

[Andy Smith]

On Tue, Jun 7, 2011 at 8:44 AM, Monty Taylor mord...@inaugust.com wrote:

 Hey all!

 It's time to both expand and contract some things around automation and
 testing. Thusfar all of the work on Jenkins and Tarmac and other
 'official' build and testing automation has been done exclusively by
 Soren and me, In the mean team, several people have been hacking on
 projects that range from helpful to spectacular, and because of lack of
 communication, only some of them are directly useful to the project's
 infrastructure. I'd like to change this. Specificaly, I'd like to make
 sure we can expand how we're working so that there is greater visibility
 in to what/how we doing things in Jenkins land, and that the barrier to
 entry to helping out isn't terrible. And I'd like to contract the number
 of unrelated efforts in to something resembling a plan.

 a) I'm working on geting relevant bits from our jenkins into to VC
 somewhere so that it's easier for us all to collaborate. I'm using the
 launchpad.net/openstack-ci project for that.


Would you like to check in the various configs I sent you from the anso
setups, should I propose that merge, or do you think that this is not the
proper place for jenkins configs + testing scripts?



 b) I configured the OpenStack Jenkins to use Launchpad's OpenID provider
 as a SSO source - so now I can use Launchpad teams to manage who can do
 what on Jenkins - which means better federation of that management.


Yay for no longer having manual config there :)



 c) I want to set up a regular (say weekly) IRC meeting for everyone
 interested in CI, dev tools and functional/smoke testing. (although for
 sake of sanity, lets keep interested to be interested in working on
 I was thinking perhaps the hour right before the normal openstack one...
 anybody have strong thoughts? Of the topics/actions to be discussed are
 managing/moving forward with the current work on the testing
 infrastructure, and having discussions about how/if various work by
 folks can be leveraged by the Jenkins that is the gatekeeper over
 openstack branches.


I suppose I should be on that list.



 d) Make sure people know what we're doing over here in OpenStack
 CI/Tools land, so that they are aware of the tools already present so
 that they don't duplicate effort, and also of the current todo list in
 case anyone wants to help. Our Jenkins already does several things that
 it turns out nobody knows about. That's gotta get fixed. (Speaking of-
 if there's any Java folks laying around out there sick of all the
 python, there are a couple of tasks that can use love - more to come on
 that)

 The meeting should be simple this time around - I propose meeting the
 hour before the openstack meeting, starting next week. I don't think we
 really need a separate mailing list, but I'm open to opinions... Also,
 in the mean time, ping me back and let me know if you're wanting to be
 part of this.

 Thanks!
 Monty

 ___
 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] Overview of CI/Testing

[Andy Smith]

On Tue, Jun 7, 2011 at 1:29 PM, Jay Pipes jaypi...@gmail.com wrote:

 I'd like to propose that you two agree that you've agreed to agree on
 agreeing.

 All in agreement?


NO.

P.S. Maybe?



 -jay

 On Tue, Jun 7, 2011 at 4:11 PM, Monty Taylor mord...@inaugust.com wrote:
 
 
  On 06/07/2011 03:03 PM, Andy Smith wrote:
 
 
  On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor mord...@inaugust.com
  mailto:mord...@inaugust.com wrote:
 
  On 06/07/2011 02:38 PM, Andy Smith wrote:
   Thanks for the update Monty :)
 
  My pleasure as always. :)
 
That's just testing API in a VM though, and doesn't get us to
  testing
   actual bare-metal deployment or integration testing. At
  Rackspace, we
   have some machines set aside at the moment, and have had
  others offer
   chunks of machines to test various combinations of things. At
  its heart,
   the abstract version of this looks fairly identical to the
  smoketests
   job - pxe boot machines, shove version to be tested on them,
  run tests.
   However, there are several moving bits on the best way to
  actually do
   the how. At the moment, the fine folks at rPath have a Jenkins
   installing and testing rPath OpenStack images, so Mihai and I
  are going
   to look at getting that setup ported to our Jenkins. However,
  although
   that will be an excellent test of code, as our main target
  platform is
   Ubuntu, we're also looking at doing a straight-up cobbler
  install using
   generated .debs.
  
  
   Jesse and I had already gotten quite far along using chef to do
 the
   provisioning of baremetal boxes once we'd pxe booted them into
 ubuntu,
   it seems like chef or puppet (our current preference is chef)
  should be
   used there as well instead of generated .debs.
 
  I have every intention of moving the current work that is running to
 be
  based on the chef work you did... but I do not view chef and .debs
 to be
  mutually exclusive options. The goal here is to be able to use chef
 to
  install and configure the official debs. If this is not possible,
 then
  there are fundamental flaws that must be fixed.
 
   At the moment the two closest things to being official
 installations
   for us (me? are the chef recipes and the nova.sh script (the
 nova.sh
   script obviously being only targeted at testing and dev though),
 those
   are what we use to verify that the system is functional and I
  think we'd
   like to use chef or puppet for baremetal deployments as well.
  
   TL;DR: Can we focus on the chef recipes instead of on .debs?
 
  nova.sh is great for devs, but isn't really something I'd imagine
 would
  be used as the basis of a production deployment (which is kind of
 the
  point of doing post-install smoke testing)
 
 
  (I'm pretty sure that is what I said above)
 
  Yup. I think I was obtusely just agreeing with you there.
 
  And again, chef can happily
  install the software from the produced debs.
 
 
  Agreed, I think, maybe we're just talking past each other, it sounded
  form your email that you would be generating additional debs to handle
  the install rather than continuing to use the existing debs (and related
  deb generation process). If that is not the case and you instead to use
  the packages mostly as they exist today then I think we're already
 agreeing.
 
  AH Yes. Definitely talking past each other. Definitely using existing
  debs. We agree with each other. That's much better!
 
  It's not really just about debs - for the rPath based testing
 backend,
  we'll obviously be testing RPMs. But in general, testing the
 packaged
  software that we ship is kind of important.
 
  To sum up: yes to using the chef recipes, no to instead of.
 
  Monty
 
   In any case, this is the bit which is still in the
   planning and discussion phase, but so far all of the
  conversations I've
   had with folks have been great - and I'd love to get more
  folks involved
   in that (thus this email)
  
   However- latent goal here is that whatever mechanism we're
 having
   Jenkins use to deploy OpenStack onto real hardware should be
  consumable
   and one that actual people might actually use - otherwise what
  the heck
   are we testing?
  
   Additionally, as you may have surmised, it is also a goal to
  run as much
   of this as possible from the OpenStack Jenkins, because that
  way we can
   as a project choose to incorporate as much of the
  feedback/results of
   various forms of testing directly in to branch
  testing/approval as we
   want. For some things (spinning up 20 node OpenStack clusters)
  doing

Re: [Openstack] Lieutenants (Again)

[Andy Smith]

Added myself to a variety of things, not necessarily expecting to manage
them all but trying to fill holes.

On Wed, May 4, 2011 at 1:34 AM, Christian Berendt bere...@b1-systems.dewrote:


  I'm still looking for points of contact for the remaining sections.

 Added myself and my co-worker Andre Naehring to packaging for SUSE

 Bye, Christian.

 --
 Christian Berendt
 Linux / Unix Consultant  Developer
 Tel.: +49-171-5542175
 Mail: bere...@b1-systems.de

 B1 Systems GmbH
 Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A single cross-zone database?

[Andy Smith]

Coming back from a long break and getting back up to speed.

I believe Sandy and I spoke about this at decent length before, the proposal
that I understood we both walked away happy with was this:

1. As a first step, implement it with a single db, because that is what we
already have and what is the easiest first step. Zones are an additional
column or join table and implemented as a filter on the query for instances
and the like. Zones in this case being used largely to mean grouping of
servers with some common, possibly distinct, property. We only support a
single level of 'zones' for the moment, no arbitrary nesting.
2. See whether that works, it probably will for the current scaling targets
and use cases.
3. To implement bursting/hybrid stuff, we then work on a data abstraction
for aggregating the results of remote calls, understanding that we expect
remote calls to have lower performance.

The blueprint as it stands (http://wiki.openstack.org/MultiClusterZones) is
following a 'turtles all the way down' approach that probably isn't really
appropriate for real world usage. In reality there are things that are
global level, things that are region level and things that are cluster
level.
 * A global service will be in charge of specific requests that need to be
global and have very specific and constrained scaling properties, perhaps
global dns management.
 * A region represents the largest unit of scaling, the maximum number of
nodes and services that can managed at time while meeting SLAs, including
the public endpoints, most things above region level need to be managed
client side: one does not expect to list all instances across all regions in
a single call, one expects to make three requests to the three regions one's
instances are in.
 * A cluster represents a grouping unit with common properties, either rack
commonality, capability commonality, or simply special case customers.
Subgroupings here may still be interesting or useful but are unlikely to be
necessary. Clusters are likely to share many things at the region level as
well as have individual cluster level concerns.

This design handles the needs of plenty of large organizations already and
is easy to move to piecemeal from our current codebase, the first step being
that zones are clusters and can share a regional registry (database) and
public endpoint while still having per-zone services (scheduler, et al).

--andy

On Wed, Mar 16, 2011 at 4:51 PM, Sandy Walsh sandy.wa...@rackspace.comwrote:

  Yup, that's a fair assessment.

  That said, even without SDB and caching it's going to be tight for Cactus
 anyway. There are lots of little issues that are cropping up once I got down
 to 100'.

  -S

  --
  From: Justin Santa Barbara jus...@fathomdb.com

  *
 *
 Sandy: Have I got the wrong end of the stick here?  Are these our choices?

  Justin

   Confidentiality Notice: This e-mail message (including any attached or
 embedded documents) is intended for the exclusive and confidential use of the
 individual or entity to which this message is addressed, and unless otherwise
 expressly indicated, is confidential and privileged information of Rackspace.
 Any dissemination, distribution or copying of the enclosed material is 
 prohibited.
 If you receive this transmission in error, please notify us immediately by 
 e-mail
 at ab...@rackspace.com, and delete the original message.
 Your cooperation is appreciated.


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Design Summit Registration Open

[Andy Smith]

Sorry if I am just way out of the loop here, but where do we submit talk
proposals / sign up for a talk?

On Sun, Mar 20, 2011 at 4:18 PM, Mandelson, Jacob j...@midokura.jp wrote:

 On Fri, Mar 11, 2011 at 12:25 AM, Thierry Carrez thie...@openstack.orgwrote:

 Stephen Spector wrote:
  The OpenStack community is proud to announce the opening of registration
  for our April 26-29, 2011 Design Summit conference in Santa Clara, CA at
  the Hyatt Regency. Confirmed speakers for the first 2 days of the event
  include NASA, Wikimedia, eBay, Intel, Citrix, Cloudscaling, GigaSpaces,
  KT, Gluster, Scalr, Arista Networks, Mach Technology, Rackspace, and
  Hyperstratus with the distance award to Paul Pettigrew the CEO of Mach
  Technology from Brisbane, Australia. Please register for the event here
  
 http://www.cvent.com/events/openstack-design-summit-spring-2011/event-summary-51c521e3af73406dbc548746c25423c4.aspx
 .

 Hey Stephen,

 There is a small error in the Agenda page on the website. On Day 2 it
 only shows Open Stack Conference while we also have the Design Summit
 starting on that day. We need to fix that ASAP so that people make the
 right travel choices.

 The Event overview could also make it clearer that the event comes in
 two overlapping flavors (Conference and Design Summit).

 Everyone:
 The Design Summit starts on Wednesday and ends on Friday. Feel free to
 come earlier to also attend the Conference on Tuesday (with Keynotes,
 Technical and Community tracks)


 Another minor error:
 The Event Overview page says:

- When
-

04/26/11 9:00 am - 04/29/11 4:30 pm
Central Time

 Surely you mean Pacific Time, not Central?

 -- Jacob



 ___
 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] Authn Authz Proposal

[Andy Smith]

Oh, the merge proposal is at
https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119

On Thu, Mar 3, 2011 at 6:04 PM, Andy Smith andys...@gmail.com wrote:

 On Thu, Mar 3, 2011 at 3:42 PM, Zed A. Shaw zeds...@zedshaw.com wrote:

 On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
  There have been numerous mailing list discussions about common auth
 methods.  I feel like we end up devolving into theoretical discussions at
 some point, and I find it hard to evaluate different approaches without
 example code.  Termie, Jesse, Paul Voccio, and I had a discussion in person
 the other day about a possible common implementation for auth.
  ...
  We decided to go ahead and implement a prototype.  Furhter information
 available here:
 

 That's what I'm talking about.  Code wins.

 Alright, I want to help with this.  What do you guys need next?  How do
 I get in on it?  When's your next meeting about it?  Can we hack on it
 at PyCon?


 I think we've got the initial code covered but code review help to clean up
 some rough edges for the initial bits, and then I think there are a ton of
 things to improve upon and a lot of places to start integrating the authz
 portions into the system.

 I think we'd also love to experiment with some signed-request options
 rather than just a bearer token, though I think we've got good traction on
 the first pass so I just want to get it into trunk and start from there :)

 --andy



 --

 Zed A. Shaw
 http://zedshaw.com/

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] UPDATE on Active reviews - filtered by target branch

[Andy Smith]

Possibly a feature request and possibly just a launchpad help request, is
there a way to sort my open merge proposals by most recent activity?

Last modified seems to only apply to changes pushed to the branch, not
comments made on the merge prop.

--andy

On Fri, Feb 25, 2011 at 12:50 PM, Jay Pipes jaypi...@gmail.com wrote:

 Hi all, especially Salvatore and Armando,

 The Launchpad team responded to my feature request. You can see active
 reviews for a specific branch using the following:

 https://code.launchpad.net/BRANCH/+activereviews

 Therefore, to see only the active reviews for the Nova trunk, you can use
 this:

 https://code.launchpad.net/~hudson-openstack/nova/trunk/+activereviews

 likewise, to see active reviews for branches proposed to merge into,
 say, the Citrix peer-review branch, you'd go here:


 https://code.launchpad.net/~citrix-openstack/nova/peer-review/+activereviews

 The other request from Justin Santa Barbara is being addressed in this
 bug: https://bugs.launchpad.net/launchpad/+bug/725163

 Cheers,
 jay

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Novatools ...

[Andy Smith]

Well, my previous reply somehow isn't going through to the list... so...
here it is again:

I've got some objections so far:

1. relying on python-cloudservers is a good metric by which to judge your
compatibility with the rackspace cloud, once jacob has accepted the changes
to support changing the auth endpoint. My opinion is that this project
should be a fork of python-cloudservers with the same name and whose
intention is not to add additional features at this time.

1a. To support your additional features for the very short term you should
be writing extensions to python-cloudservers (possibly with your minor
compat modifications) via actual python extension mechanisms (import,
inherit and extend).

2. the existing spec for openstack api 1.1 is still contested, so basing
the tool chain going forward off of something that is made for compat with
cloudservers is possibly misguided at this point.

3. i'm not sure there need to be separate tools/libraries to interact with
each service, but i do like the idea of each being able ot provide a piece
of a web dashboard.

4. Emails from sandy/others are being duplicated multiple times in this
thread, i am replying only to the list for this message.


On Thu, Feb 24, 2011 at 11:20 AM, Thierry Carrez thie...@openstack.orgwrote:

 Eric Day wrote:
  For copyright headers, just add a new Copyright 2011 OpenStack,
  LLC. line for existing files under the old copyright line. You can add
  a new license for new code for existing files, but that gets messy. For
  new files, just do as we usually do for new files (copyright + license
  brief). You can also add new files under a different license (Apache
  instead of BSD) if you like, but I'd probably keep it the same within
  one project for simplicity. Note that this is only suitable since
  it's BSD, if it were GPL (or some other viral license), it would be
  a bit different.

 In fact, the current files do not have any copyright header. Should we
 invent the copyright line that should have been there, and add to it ?

 --
 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] Novatools ...

[Andy Smith]

This thread seems to be radically messed up, but from where I am sitting it
certainly doesn't seem like everybody is agreeing, so far it appears that
most people disagree about most things.

On Thu, Feb 24, 2011 at 2:33 PM, Trey Morris trey.mor...@rackspace.comwrote:

 sounds like we agree then. Each service has it's own tool set, and services
 which are made up of sub-services will have a tool set which can make calls
 translating through the tool sets of its sub-services.

 On Thu, Feb 24, 2011 at 3:30 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote:
  On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
  I just don't want to end up with:
 
  os-describe-images
  os-describe-image-attribute
  os-describe-instances
  os-describe-groups
  os-describe-zones
  os-describe-keypairs
  os-describe-volumes
  os-describe-snapshots
 
  The above is asinine, IMO.
 
  Completely agree. :)

 Cool. Was starting to lose my mind thinking people *really* wanted to
 duplicate the eucatools mess...

  If you want to have an os-compute and an os-network CLI tool, cool,
  but I think that:
 
  os-compute describe images
  os-compute describe image-attribute
  os-compute describe instances
  os-compute describe groups
  etc...
 
  is far more workable than 15 separate CLI tools that do essentially
  identical things.
 
  Yup, agree. Also keep in mind that some operations may be duplicates
  across services, just with a different context. For example,
  in a deployment where you use glance backed by swift for nova,
  os-compute describe image id may be the same as os-image describe
  id or os-object describe id (swift), but the os-compute is in
  the context of instances so it could have more metadata. This will
  mirror the dependency tree we see between services (especially as
  they are split out).

 ++

  We want to make sure there are tools so services can stand alone as
  needed (for example, os-image if you run glance standalone). Services
  that combine other services (like nova) should aggregate these into
  context-specific commands so you don't *need* to use the underlying
  service tools for most things. This allows you to control nova use
  one tool. :)

 No disagreement from me.

 -jay

 p.s. thx for not sending me to /dev/null ;)

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Novatools ...

[Andy Smith]

(by radically messed up i mean i am getting up to 4 copies of each message
and the ordering has been non-chronological)

On Thu, Feb 24, 2011 at 3:36 PM, Andy Smith andys...@gmail.com wrote:

 This thread seems to be radically messed up, but from where I am sitting it
 certainly doesn't seem like everybody is agreeing, so far it appears that
 most people disagree about most things.


 On Thu, Feb 24, 2011 at 2:33 PM, Trey Morris trey.mor...@rackspace.comwrote:

 sounds like we agree then. Each service has it's own tool set, and
 services which are made up of sub-services will have a tool set which can
 make calls translating through the tool sets of its sub-services.

 On Thu, Feb 24, 2011 at 3:30 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote:
  On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
  I just don't want to end up with:
 
  os-describe-images
  os-describe-image-attribute
  os-describe-instances
  os-describe-groups
  os-describe-zones
  os-describe-keypairs
  os-describe-volumes
  os-describe-snapshots
 
  The above is asinine, IMO.
 
  Completely agree. :)

 Cool. Was starting to lose my mind thinking people *really* wanted to
 duplicate the eucatools mess...

  If you want to have an os-compute and an os-network CLI tool, cool,
  but I think that:
 
  os-compute describe images
  os-compute describe image-attribute
  os-compute describe instances
  os-compute describe groups
  etc...
 
  is far more workable than 15 separate CLI tools that do essentially
  identical things.
 
  Yup, agree. Also keep in mind that some operations may be duplicates
  across services, just with a different context. For example,
  in a deployment where you use glance backed by swift for nova,
  os-compute describe image id may be the same as os-image describe
  id or os-object describe id (swift), but the os-compute is in
  the context of instances so it could have more metadata. This will
  mirror the dependency tree we see between services (especially as
  they are split out).

 ++

  We want to make sure there are tools so services can stand alone as
  needed (for example, os-image if you run glance standalone). Services
  that combine other services (like nova) should aggregate these into
  context-specific commands so you don't *need* to use the underlying
  service tools for most things. This allows you to control nova use
  one tool. :)

 No disagreement from me.

 -jay

 p.s. thx for not sending me to /dev/null ;)

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Novatools ... where to place in /nova/?

[Andy Smith]

Unless the mailing lists are being even crazier than I think, I don't
believe anybody has addressed any of the concerns I brought up in the
novatools thread.

Am I missing a set of emails or have you?

--andy

On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh sandy.wa...@rackspace.com
 wrote:
  Hmm, that's a little tricky since oscompute will be contain the cmdline
 tool and the client tool to the REST API (cmdline is just a shell interface
 over the client). It would mean splitting things up and the setup.py would
 get complicated.

 Why are they together?

  To Eric's point
  .../clients/python/*
  .../clients/ruby/*

 Why have ruby clients in the Nova package?

 -jay

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Andy Smith]

Please summarize these on the wiki and add your information the wiki, that
is what the wiki page was made to do and what I asked you to do.

--andy

On Thu, Feb 24, 2011 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:

 Andy has listed a few things on the wiki. I'll summarize the known efforts
 here:

 * Anso has created some Vagrant scripts that test multi-node
 functionality of the EC2 API, libvirt + KVM, and nova-objectstore
 * Vishy/Devin  have been refactored Nova's existing smoketests/ and
 updated to include netadmin tests. Still only testing EC2 API
 * Trey has been volunteered to write an OpenStack API smoketest for
 XenServer functionality (https://bugs.launchpad.net/nova/+bug/720941)
 * Jordan Rinke has been working on a 10-machine test cluster for
 testing deployments and running smoketests on
 * Other rackers (Pvo, Ant?) have been working on getting a much larger
 production-level test cluster for running longer, more complex tests
 on

 Stuff we need to do:

 * Create a staging/testing branch, have Openstack Hudson LP user own it
 * Get the test cluster machines entered into Hudson
 * On each merge proposal into trunk, have Tarmac pull the branch, run
 unit tests automatically, fire off smoketests/ against the test
 machines automatically, and notify the merge proposal that tests pass
 or don't pass.
 * For merge proposals that pass the merge into staging and all tests
 that also have 2 Approves from core devs, have Tarmac merge into trunk
 * Create long-running functional tests that are essentially re-playing
 large Apache/nginx log files of existing Nebula and Cloud Servers API
 nodes against Nova staging branch with various configurations

 -jay

 On Thu, Feb 24, 2011 at 3:49 PM, Sandy Walsh sandy.wa...@rackspace.com
 wrote:
  Jay,
  Nice to see this issue being addressed ... it's a big deal.
  From reading this (long) thread, my biggest source of confusion was so
  many we're doing something on this front too ... messages.
  Would it be possible to get a summary of the various integration testing
  efforts underway so we can find out where the
  commonality/biggest-bang-for-the-buck/overlap is? Perhaps a wiki page
  already exists for this?
  Thx,
  -S
 
 
  
  From:  a cast of thousands ... delete 
 
  Confidentiality Notice: This e-mail message (including any attached or
  embedded documents) is intended for the exclusive and confidential use of
  the
  individual or entity to which this message is addressed, and unless
  otherwise
  expressly indicated, is confidential and privileged information of
  Rackspace.
  Any dissemination, distribution or copying of the enclosed material is
  prohibited.
  If you receive this transmission in error, please notify us immediately
 by
  e-mail
  at ab...@rackspace.com, and delete the original message.
  Your cooperation is appreciated.
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
 
 

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Andy Smith]

That url is http://wiki.openstack.org/TestingBrainstorm btw

On Thu, Feb 24, 2011 at 4:06 PM, Andy Smith andys...@gmail.com wrote:

 Please summarize these on the wiki and add your information the wiki, that
 is what the wiki page was made to do and what I asked you to do.

 --andy


 On Thu, Feb 24, 2011 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:

 Andy has listed a few things on the wiki. I'll summarize the known efforts
 here:

 * Anso has created some Vagrant scripts that test multi-node
 functionality of the EC2 API, libvirt + KVM, and nova-objectstore
 * Vishy/Devin  have been refactored Nova's existing smoketests/ and
 updated to include netadmin tests. Still only testing EC2 API
 * Trey has been volunteered to write an OpenStack API smoketest for
 XenServer functionality (https://bugs.launchpad.net/nova/+bug/720941)
 * Jordan Rinke has been working on a 10-machine test cluster for
 testing deployments and running smoketests on
 * Other rackers (Pvo, Ant?) have been working on getting a much larger
 production-level test cluster for running longer, more complex tests
 on

 Stuff we need to do:

 * Create a staging/testing branch, have Openstack Hudson LP user own it
 * Get the test cluster machines entered into Hudson
 * On each merge proposal into trunk, have Tarmac pull the branch, run
 unit tests automatically, fire off smoketests/ against the test
 machines automatically, and notify the merge proposal that tests pass
 or don't pass.
 * For merge proposals that pass the merge into staging and all tests
 that also have 2 Approves from core devs, have Tarmac merge into trunk
 * Create long-running functional tests that are essentially re-playing
 large Apache/nginx log files of existing Nebula and Cloud Servers API
 nodes against Nova staging branch with various configurations

 -jay

 On Thu, Feb 24, 2011 at 3:49 PM, Sandy Walsh sandy.wa...@rackspace.com
 wrote:
  Jay,
  Nice to see this issue being addressed ... it's a big deal.
  From reading this (long) thread, my biggest source of confusion was so
  many we're doing something on this front too ... messages.
  Would it be possible to get a summary of the various integration testing
  efforts underway so we can find out where the
  commonality/biggest-bang-for-the-buck/overlap is? Perhaps a wiki page
  already exists for this?
  Thx,
  -S
 
 
  
  From:  a cast of thousands ... delete 
 
  Confidentiality Notice: This e-mail message (including any attached or
  embedded documents) is intended for the exclusive and confidential use
 of
  the
  individual or entity to which this message is addressed, and unless
  otherwise
  expressly indicated, is confidential and privileged information of
  Rackspace.
  Any dissemination, distribution or copying of the enclosed material is
  prohibited.
  If you receive this transmission in error, please notify us immediately
 by
  e-mail
  at ab...@rackspace.com, and delete the original message.
  Your cooperation is appreciated.
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
 
 

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Review days for nova-core members

[Andy Smith]

This stuff was discussed and decided upon in the release meeting a couple
days ago, unless somebody more official wants to make a statement the
results of the decision were:

(1) Developer review days are a go, Soren will set up a wiki page assigning
devs to days (i don't think this is done yet).
(2) Corollary is that if you are unable to perform the reviews regularly you
should be dropped from the nova-core group.
(3) A document explaining best practices for the review process will be
generated by Termie (me, not done yet)
(4) Developers should target their reviews to applicable reviewers whenever
possible, much of the developer-on-duty's task will be doing initial review
of un-targeted reviews and re-targeting at an appropriate developer. (jk0
has set up a wiki page to track who has expertise over which areas:
http://wiki.openstack.org/NovaCore , that page may be re-usable as the
developer review day assignment page?)

--andy


On Thu, Feb 24, 2011 at 10:10 AM, Trey Morris trey.mor...@rackspace.comwrote:

 +1 to improving reviews since I agree with sandy on it being our greatest
 strength. I also I prefer sandy's approach (unless I'm mistaken), jump in
 and see how it goes, we can update a wiki as things proceed. I don't
 understand the need for a more formal documentation of process. I'd just
 hate for it to be a point of contention.

 On Mon, Feb 21, 2011 at 3:34 PM, Andy Smith andys...@gmail.com wrote:



 On Mon, Feb 21, 2011 at 12:52 AM, Thierry Carrez 
 thie...@openstack.orgwrote:

 Andy Smith wrote:
  I have some anecdotal evidence to add to this from my time at Google:
 
  (1) At Google in all reality you spent at least 2 days a week pretty
  much only participating in code review and mailing list responses. This
  is due to a couple things, but mostly because code review is taken
  extremely seriously, the reviewer of the code has as much
 responsibility
  for what lands as the person writing the code, their name (or names) go
  in change commit. If that code creates a problem it is up to all people
  involved in that process to quickly come up with a resolution.
 
  That responsibility leads to some other great things:
   * Lessening of self-defensiveness / personal investment in code: the
  code is not yours, it is multiple people's.
   * You also always have at least one buddy who can back up the
  decisions that were made, if you are not around to argue a point that
  person probably can, and no attacks can ever be leveled at you
 personally.

 We should definitely add the nova-core reviewers LPids to the commit
 message, in order to encourage that spirit. Something like:

 [r=soren,termie] Rest of commit message...


 Anybody know how hard it is to incorporate this into our tarmac?



  (2) At Google you generally have to give explicit targets for who
 should
  be your code reviewer. This prevents some tragedy of the commons
  behaviors (when there is nobody assigned everybody expects somebody
 else
  to do it).
 
  This also leads to people who are defacto (or explicit) leaders for
  certain sections of code. For example, when fixing a bug on a section
 of
  code you are not usually working in it is common to ask around on IRC
  (or just the office) to find out who knows most about that area and
  should do the review.

 This can easily be done by specifying reviewers when you do the branch
 merge proposal.


 Sure, we just need to remove it automatically selecting Nova Core and
 likewise as a reviewer for you so that people are forced to explicitly add a
 reviewer.



  (3) At Google one of the first things that new developers do is read
  through a couple nicely written documents on how to conduct code
  reviews, what your responsibilities are when doing code review, and
 some
  ways to make sure your tone comes off constructively.
 
  This keeps everybody on most of the same page and helps acclimatize
  people to social interaction related to coding.

 +1 on reference docs :)

  I think adopting these behaviors would be in our best interest as a
  project, if that sounds good I am willing to take the time to generate
  the initial draft of the document and get the appropriate
 configurations
  / code updated to support tracking reviewers and requiring explicit
  reviewers.

 For (1), ideally Tarmac would support rewriting the commit message in
 transit to include those names... (2) is already doable with our current
 toolset. For (3), just let us know when the wiki draft is up so that we
 can participate in improving it.

 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

Re: [Openstack] Novatools ...

[Andy Smith]

On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote:
  Well, my previous reply somehow isn't going through to the list... so...
  here it is again:
  I've got some objections so far:
  1. relying on python-cloudservers is a good metric by which to judge your
  compatibility with the rackspace cloud, once jacob has accepted the
 changes
  to support changing the auth endpoint. My opinion is that this project
  should be a fork of python-cloudservers with the same name and whose
  intention is not to add additional features at this time.

 Why? As much as I like JKM, I don't think relying on someone who has
 no interaction with the OpenStack community to accept patches from the
 OpenStack community is a good idea.


That's not at all what I said. You have two tasks here, the one described in
(1) is make minimal changes to python-cloudservers such that you can point
it at a nova deployment and test compat with existing cloudservers
implementations. The second task is described in (1a) make extensions to
that to support your immediate needs that are beyond the cloudservers
compatibility.



  1a. To support your additional features for the very short term you
 should
  be writing extensions to python-cloudservers (possibly with your minor
  compat modifications) via actual python extension mechanisms (import,
  inherit and extend).

 Again, why? With python-novatools we have complete control over the
 code and don't need to push it back to python-cloudservers, which is
 not OpenStack-based, it's specific to Rackspace Cloud Servers.


One of your needs is to provide something that is compatible with
cloudservers so that you can migrate without breaking existing customers.



  2. the existing spec for openstack api 1.1 is still contested, so
 basing
  the tool chain going forward off of something that is made for compat
 with
  cloudservers is possibly misguided at this point.

 Only if you hamstring it by saying that the changes should be pushed
 back upstream.


I don't see what changes or upstream you are referring to, I was stating
that there is not agreement over what the openstack api should be and basing
plans heavily upon the existing proposal may be premature.



  3. i'm not sure there need to be separate tools/libraries to interact
 with
  each service, but i do like the idea of each being able ot provide a
 piece
  of a web dashboard.

 I'm not sure I understand what #3 has to do with novatools being
 separate from python-cloudservers. Could you explain?


I was responding to John Purrier's statements.

--andy



 -jay

 
  On Thu, Feb 24, 2011 at 11:20 AM, Thierry Carrez thie...@openstack.org
  wrote:
 
  Eric Day wrote:
   For copyright headers, just add a new Copyright 2011 OpenStack,
   LLC. line for existing files under the old copyright line. You can
 add
   a new license for new code for existing files, but that gets messy.
 For
   new files, just do as we usually do for new files (copyright + license
   brief). You can also add new files under a different license (Apache
   instead of BSD) if you like, but I'd probably keep it the same within
   one project for simplicity. Note that this is only suitable since
   it's BSD, if it were GPL (or some other viral license), it would be
   a bit different.
 
  In fact, the current files do not have any copyright header. Should we
  invent the copyright line that should have been there, and add to it ?
 
  --
  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] Novatools ... where to place in /nova/?

[Andy Smith]

Please ignore the first clause of that email as it appears the message was
indeed received.

I still feel there is discussion about this (novatools) going on in the
novatools thread.

--andy

On Thu, Feb 24, 2011 at 5:41 PM, Jay Pipes jaypi...@gmail.com wrote:

 Looking at https://lists.launchpad.net/openstack/threads.html I see a
 few posts from you, but they all complain about the list missing
 messages from you. Not sure what the issue is. Seems replies from
 everyone but you are working just fine.

 -jay

 On Thu, Feb 24, 2011 at 7:03 PM, Andy Smith andys...@gmail.com wrote:
  Unless the mailing lists are being even crazier than I think, I don't
  believe anybody has addressed any of the concerns I brought up in the
  novatools thread.
  Am I missing a set of emails or have you?
  --andy
 
  On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote:
 
  On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh sandy.wa...@rackspace.com
 
  wrote:
   Hmm, that's a little tricky since oscompute will be contain the
 cmdline
   tool and the client tool to the REST API (cmdline is just a shell
 interface
   over the client). It would mean splitting things up and the setup.py
 would
   get complicated.
 
  Why are they together?
 
   To Eric's point
   .../clients/python/*
   .../clients/ruby/*
 
  Why have ruby clients in the Nova package?
 
  -jay
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
 
 

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Novatools ...

[Andy Smith]

On Thu, Feb 24, 2011 at 6:25 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith andys...@gmail.com wrote:
  On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote:
  On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote:
   Well, my previous reply somehow isn't going through to the list...
 so...
   here it is again:
   I've got some objections so far:
   1. relying on python-cloudservers is a good metric by which to judge
   your
   compatibility with the rackspace cloud, once jacob has accepted the
   changes
   to support changing the auth endpoint. My opinion is that this project
   should be a fork of python-cloudservers with the same name and whose
   intention is not to add additional features at this time.
 
  Why? As much as I like JKM, I don't think relying on someone who has
  no interaction with the OpenStack community to accept patches from the
  OpenStack community is a good idea.
 
  That's not at all what I said. You have two tasks here, the one described
 in
  (1) is make minimal changes to python-cloudservers such that you can
 point
  it at a nova deployment and test compat with existing cloudservers
  implementations. The second task is described in (1a) make extensions to
  that to support your immediate needs that are beyond the cloudservers
  compatibility.

 OK, we're clearly not communicating properly here. This is the
 original quote from Sandy that I was trying to address why your (1)
 above isn't working:

 The reality is we need a place where we can push changes quickly and
 not be hogtied waiting for merge. Without this, we end up pointing the
 community to our local branch anyway. If jacobian wants to regain
 control of this branch, we need assurances of timely responses.

 Sandy *has* tried to make minimal changes to python-cloudservers and
 have those changes merged. No response from JKM yet, according to
 Sandy.

 
   1a. To support your additional features for the very short term you
   should
   be writing extensions to python-cloudservers (possibly with your minor
   compat modifications) via actual python extension mechanisms (import,
   inherit and extend).
 
  Again, why? With python-novatools we have complete control over the
  code and don't need to push it back to python-cloudservers, which is
  not OpenStack-based, it's specific to Rackspace Cloud Servers.
 
  One of your needs is to provide something that is compatible with
  cloudservers so that you can migrate without breaking existing customers.

 *If* Sandy's minimal changes were merged, then python-cloudservers
 would be that something that is compatible with cloudservers (and
 nova) that you talk about above. But JKM has not been responsive.
 Again, Sandy needs to do something... not wait for JKM to get back in
 touch.


My original suggestion is that renaming it to novatools is not required for
that, renaming makes it that much less likely that jkm will be interested in
merging the changes, and pulling the code directly into nova as the other
novatools thread suggests makes that process even harder.

My suggestion is to simply fork the project on github and make the minimal
changes there (and clone to launchpad and make PPAs if that helps for
testing in the meantime).

Also per JKM responsiveness, I poked him:

02:16  jacobkm termie: going back a bit, but patches welcome. I'm working
on a light refactoring to support multiple
 providers (so it'll work with openstack, etc.) and a few
other cleanups, but send me stuff and I'll
 integrate it.

So we have perhaps a decent chance of getting things rolling there?

I think it is worth pursuing.

--andy





 -jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] documentation of flags, introducing of a naming convention for flags

[Andy Smith]

A few points:

(1) I agree with Todd and others that having flags localized to where they
are used is good idea.

(2) We should do some work to re-localize many of the flags, there has been
a lot of kludge over time that just needs a little re-organization. This
will solve the which flags are common and which flags are specific issue
(common flags will be in a common area, specific flags in more specific
areas). Right now we have too many flags in a common area and it bogs down
the help output.

(3) We should also do some work to standardize the names, as suggested, as
that will help keep the brain storage down to a minimum.

(4) I did some work on a sphinx plugin that was never finished to
automatically document the flags, I can put some effort into finishing that
if we want it. It basically added the docs for the flags per module and
could be expanded to generate a master list of flags document also.

For #2 and #3 I feel pretty comfortable getting those started, I understand
the systems well and have access to people like Vish in shouting distance
for when I run into flags that I don't immediately have a place/name for.
For #4, I can take a look again and see how hard it will be to get that code
working. For #1 I think we can agree to keep things localized for now and I
am open to starting a separate conversation (in a different thread) about
the benefits of that if people are concerned.

--andy

On Tue, Feb 22, 2011 at 11:24 AM, Todd Willey t...@ansolabs.com wrote:

 The separation of flag definitions into the modules that consume them
 is a good practice, IMO.  This is especially true with a system as
 configurable/pluggable as nova, as you don't want flags for unused
 modules polluting your help output, etc.  It also goes most of the way
 into creating the logical boundaries you'd need to speak to when
 documenting configurations.

 -todd[1]

 2011/2/22 Brian Schott bsch...@isi.edu:
  +1
 
  We are also struggling with the various and sundry deployment options.
  Getting bit by the multiple mechanisms to install and launch openstack.
 
  ---
  Brian Schott, Project Leader
  USC Information Sciences Institute
  http://www.east.isi.edu/~bschott
  ph: 703-812-3722 fx: 703-812-3712
 
 
 
  On Feb 22, 2011, at 10:07 AM, Diego Parrilla Santamaría wrote:
 
  I have counted 160 configuration parameters in Nova, and only about 15
  are documented. This is clearly one of the areas of improvement in the
  project.
 
  I have been fighting with Nova Bexar in not-so-standard configurations
  and deployments and believe me, I would appreciate more information
  about what they do.
 
  Something that took me a lot of time to figure out was what are
  'common' flags for all the components in nova, and what are 'specific'
  flags for each component. If you are setting up an environment with
  specialized nodes
  (compute,network,volume,api,objectstore,scheduler...) this is a must
  if you want to have more than a couple of servers running Nova.
 
  Diego
  -
  Diego Parrilla
  nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
  +34 649 94 43 29
 
 
 
 
  On Tue, Feb 22, 2011 at 3:29 PM, Jay Pipes jaypi...@gmail.com wrote:
  can of worms
  Just use optparse/argparse. paste.deploy handles configuration files
  already, which is where most flags should really be... gflags adds
  unneeded complexity for no real gains, IMHO. Swift and Glance do just
  fine without gflags, as do the vast majority of Python projects. As
  for documentation of program options, the most common practice in the
  open source world is to document configuration options in the example
  configuration files that ship with your project, and document command
  line options inline to show up in --help output.
  /can of worms
 
  On Tue, Feb 22, 2011 at 1:37 AM, Christian Berendt
  bere...@b1-systems.de wrote:
  Hi.
 
  At the moment we're using a lot of flags spread all over the code.
 
  a) we should create a useful documentation including all flags
 
  b) we should introduce a naming convention for new flags and we should
  rename existing flags
 
  example:
 
  all flags related to default values are starting with default_, all
  flags related to a path are starting with path_.
 
  Looks like most of the flags have good names at the moment, but I
 think
  we should write it down in the wiki or the developer documentation to
  reduce the possibility of bad names in the future.
 
  c) if it's possible we should collect all flags in one file
 
  At the moment the flags are defined in the files where they are used.
 I
  think it would be nice to have on file, for example nova/flags.py,
  including all flags used all over the code.
 
  Bye, Christian.
 
  --
  Christian Berendt
  Linux / Unix Consultant  Developer
  Tel.: +49-171-5542175
  Mail: bere...@b1-systems.de
 
  B1 Systems GmbH
  Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
  GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
 
  

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Andy Smith]

A few emails back (I have been in meetings and travel for the past two weeks
so I am just catching up on email now), Jay pretty much described our plan
of setting up a bunch of machines in multiple configurations for use as a
test cluster.

Towards that goal I'd love to start compiling the various systems mentioned
in this thread so far into a place so that we can look at the configurations
people are already using. My vote is just a wiki page linking to Jenkins
deployments and tarballs of Jenkins build configurations and so forth.

http://wiki.openstack.org/TestingBrainstorm

Soren, based on your blog post I suspect you have a bunch of this material
already, could you add it to that wiki?

Brian Schott, could you add your deployment and existing testing strategy to
that wiki?

I'll take care of getting the Anso/NASA pieces (we have a bunch of
vagrant-based stuff) in there.

--andy

On Fri, Feb 18, 2011 at 8:40 AM, Trey Morris trey.mor...@rackspace.comwrote:

 yeah I agree with jay, makes me feel more comfortable with this process.
 also, re jay: guess i had better get to work on that bug

 -tr3buchet


 On Fri, Feb 18, 2011 at 7:29 AM, Jay Pipes jaypi...@gmail.com wrote:

 This was an excellent explanation. Thank you, Thierry.

 -jay

 On Fri, Feb 18, 2011 at 2:55 AM, Thierry Carrez thie...@openstack.org
 wrote:
  Trey Morris wrote:
  I don't like that it currently only runs on ubuntu + the ppa. If it
  doesn't work with existing versions I think we're doing something
 wrong.
  Even when natty comes out, I don't like the idea of having to ensure I
  have latest ubuntu for openstack to run.
 
  Maybe with my Ubuntu core developer hat on, I can try to clarify.
 
  Once an Ubuntu version is released, you can't push new versions of
  libraries or new features in it, only critical bugfixes.
 
  So when for openstack we happen to need to new version of a library, it
  won't run on the current stable version. We have a choice between
  avoiding new versions of libraries altogether, or use a PPA to add the
  required version.
 
  The route we follow is to provide the new version of the library in a
  PPA for the current stable releases (Lucid/Maverick), and update the
  development release (Natty) proper.
 
  The end goal being, when Natty goes out, the corresponding Openstack
  release (Cactus) runs on it without the need for a PPA. For those that
  prefer to run it on an older stable release (or an LTS), the release
  PPA can be used.
 
  Regards,
 
  --
  Thierry Carrez (ttx)
  Release Manager, OpenStack
  Core developer, Ubuntu
 
  ___
  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


 Confidentiality Notice: This e-mail message (including any attached or
 embedded documents) is intended for the exclusive and confidential use of the
 individual or entity to which this message is addressed, and unless otherwise
 expressly indicated, is confidential and privileged information of Rackspace.
 Any dissemination, distribution or copying of the enclosed material is 
 prohibited.
 If you receive this transmission in error, please notify us immediately by 
 e-mail
 at ab...@rackspace.com, and delete the original message.
 Your cooperation is appreciated.


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance waiting on scheduling

[Andy Smith]

Hi :)

This is probably something you want to move to the questions and answers
section on Launchpad:

https://answers.launchpad.net/nova

And the first thing you will want to do is start to look at your logs in
/var/log/nova

--andy

On Fri, Feb 18, 2011 at 2:30 PM, Harshavardhana har...@gluster.com wrote:

 Hi Everyone,

 I have been following this blog in test environment with just one node
 running.

 I have completed till the process of

 euca-run-instances $emi -k mykey -t m1.tiny

 But all i am seeing now is the instance is just waiting for scheduling for
 an Hr or so

 RESERVATION r-lcb18uqx myproject default
 INSTANCE i-0002 ami-xggshuo1 scheduling mykey (myproject, None) 0 
 m1.tiny2011-02-18
 22:26:19.277799 unknown zone


 http://fnords.wordpress.com/2010/12/02/bleeding-edge-openstack-nova-on-maverick/


 Is there anything that i missed here? can any one help me.

 Regards

 --


 Harshavardhana
 Gluster Inc - http://www.gluster.com

 +1(408)-770-1887, Ext-113
 +1(916)-538-1466



 ___
 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] Review days for nova-core members

[Andy Smith]

I have some anecdotal evidence to add to this from my time at Google:

(1) At Google in all reality you spent at least 2 days a week pretty much
only participating in code review and mailing list responses. This is due to
a couple things, but mostly because code review is taken extremely
seriously, the reviewer of the code has as much responsibility for what
lands as the person writing the code, their name (or names) go in change
commit. If that code creates a problem it is up to all people involved in
that process to quickly come up with a resolution.

That responsibility leads to some other great things:
 * Lessening of self-defensiveness / personal investment in code: the code
is not yours, it is multiple people's.
 * You also always have at least one buddy who can back up the decisions
that were made, if you are not around to argue a point that person probably
can, and no attacks can ever be leveled at you personally.

(2) At Google you generally have to give explicit targets for who should be
your code reviewer. This prevents some tragedy of the commons behaviors
(when there is nobody assigned everybody expects somebody else to do it).

This also leads to people who are defacto (or explicit) leaders for certain
sections of code. For example, when fixing a bug on a section of code you
are not usually working in it is common to ask around on IRC (or just the
office) to find out who knows most about that area and should do the review.

(3) At Google one of the first things that new developers do is read through
a couple nicely written documents on how to conduct code reviews, what your
responsibilities are when doing code review, and some ways to make sure your
tone comes off constructively.

This keeps everybody on most of the same page and helps acclimatize people
to social interaction related to coding.

-

I think adopting these behaviors would be in our best interest as a project,
if that sounds good I am willing to take the time to generate the initial
draft of the document and get the appropriate configurations / code updated
to support tracking reviewers and requiring explicit reviewers.

--andy

On Thu, Feb 17, 2011 at 11:13 AM, Soren Hansen so...@ubuntu.com wrote:

 2011/2/17 Jay Pipes jaypi...@gmail.com:
  Also, good point to keep in mind: Membership to nova-core isn't a
  privilege or even any fun. It's a responsibility and a duty to your
  fellow contributors :)

 The first draft of my e-mail said something about it being a chore,
 but I decided to edit that out to not demotivate people from joining
 :)

 --
 Soren Hansen
 Ubuntu Developerhttp://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] Network Service for L2/L3 Network Infrastructure blueprint

[Andy Smith]

I'd second a bit of what Jay says and toss in that I don't think the code is
ready to be splitting services off:

- There have already been significant problems dealing with glance, the nasa
people and the rackspace people have effectively completely different code
paths (nasa: ec2, objectstore, libvirt; rackspace: rackspace, glance,
xenapi) and that needs to be aligned a bit more before we can create more
separations if we want everybody to be working towards the same goals.
- Try as we might there is still not a real consensus on high level coding
style, for example the Xen-related code is radically different in shape and
style from the libvirt code as is the rackspace api from the ec2 api, and
having projects split off only worsens the problem as individual developers
have fewer eyes on them.

My goal and as far as I can tell most of my team's goals are to rectify a
lot of that situation over the course of the next release by:

- setting up and working through the rackspace side of the code paths (as
mentioned above) enough that we can start generalizing its utility for the
entire project
- actual deprecation of the majority of objectstore
- more thorough code reviews to ensure that code is meeting the overall
style of the project, and probably a document describing the code review
process

After Cactus if the idea makes sense to split off then it can be pursued
then, but at the moment it is much too early to consider it.

On Fri, Jan 28, 2011 at 7:06 AM, Rick Clark r...@openstack.org wrote:

 On 01/28/2011 08:55 AM, Jay Pipes wrote:
  On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark r...@openstack.org wrote:
  I recognise the desire to do this for Cactus, but I feel that pulling
  out the network controller (and/or volume controller) into their own
  separate OpenStack subprojects is not a good idea for Cactus.  Looking
  at the (dozens of) blueprints slated for Cactus, doing this kind of
  major rework will mean that most (if not all) of those blueprints will
  have to be delayed while this pulling out of code occurs. This will
  definitely jeopardise the Cactus release.
 
  My vote is to delay this at a minimum to the Diablo release.
 
  And, for the record, I haven't seen any blueprints for the network as
  a service or volume as a service projects. Can someone point us to
  them?
 
  Thanks!
  jay

 Whew, Jay I thought you were advocating major changes in Cactus.  That
 would completely mess up my view of the world :)

 https://blueprints.launchpad.net/nova/+spec/bexar-network-service
 https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model
 https://blueprints.launchpad.net/nova/+spec/bexar-network-service


 It was discussed at ODS, but I have not seen any code or momentum, to date.

 I think it is worth while to have an open discussion about what if any
 of this can be safely done in Cactus.  I like you, Jay, feel a bit
 conservative.  I think we lost focus of the reason we chose time based
 releases. It is time to focus on nova being a solid trustworthy
 platform.  Features land when they are of sufficient quality, releases
 contain only the features that passed muster.

 I will be sending an email about the focus and theme of Cactus in a
 little while.

 Rick



 ___
 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] Network Service for L2/L3 Network Infrastructure blueprint

[Andy Smith]

On Fri, Jan 28, 2011 at 10:18 AM, John Purrier j...@openstack.org wrote:

 Some clarification and a suggestion regarding Nova and the two new proposed
 services (Network/Volume).

 To be clear, Nova today contains both volume and network services. We can
 specify, attach, and manage block devices and also specify network related
 items, such as IP assignment and VLAN creation. I have heard there is some
 confusion on this, since we started talking about creating OpenStack
 services around these areas that will be separate from the cloud controller
 (Nova).

 The driving factors to consider creating independent services for VM,
 Images, Network, and Volumes are 1) To allow deployment scenarios that may
 be scoped to a single service, so that we don't drag all of the Nova code in
 if we just want to deploy virtual volumes, and 2) To allow greater
 innovation and community contribution to the individual services.

 Another nice effect of separation of services is that each service can
 scale horizontally per the demands of the deployment, independent of the
 other services.


This statement is invalid, nova is already broken into services, each of
which can be dealt with individually and scaled as such, whether the code is
part of the same repository has little bearing on that. The goals of scaling
are orthogonal to the location of the code and are much more related to
separation of concerns in the code, making sure that volume code does not
rely on compute code for example (which at this point it doesn't
particularly).



 We have an existing blueprint discussing the Network Service. We have *not*
 published a blueprint discussing the Volume Service, this will be coming
 soon.

 The net is that creating the correct architecture in OpenStack Compute
 (automation and infrastructure) is a good thing as we look to the future
 evolution of the project.

 Here is the suggestion. It is clear from the response on the list that
 refactoring Nova in the Cactus timeframe will be too risky, particularly as
 we are focusing Cactus on Stability, Reliability, and Deployability (along
 with a complete OpenStack API). For Cactus we should leave the network and
 volume services alone in Nova to minimize destabilizing the code base. In
 parallel, we can initiate the Network and Volume Service projects in
 Launchpad and allow the teams that form around these efforts to move in
 parallel, perhaps seeding their projects from the existing Nova code.


That suggestion is contradictory, first you say not to separate then you
suggest creating separate projects. I am against creating separate projects,
the development is part of Nova until at least Cactus.


 Once we complete Cactus we can have discussions at the Diablo DS about
 progress these efforts have made and how best to move forward with Nova
 integration and determine release targets.

 Thoughts?

 John

 -Original Message-
 From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:
 openstack-bounces+john openstack-bounces%2Bjohn=openstack.org@
 lists.launchpad.net] On Behalf Of Rick Clark
 Sent: Friday, January 28, 2011 9:06 AM
 To: Jay Pipes
 Cc: Ewan Mellor; Søren Hansen; openstack@lists.launchpad.net
 Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure
 blueprint

 On 01/28/2011 08:55 AM, Jay Pipes wrote:
  On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark r...@openstack.org wrote:
  I recognise the desire to do this for Cactus, but I feel that pulling
  out the network controller (and/or volume controller) into their own
  separate OpenStack subprojects is not a good idea for Cactus.  Looking
  at the (dozens of) blueprints slated for Cactus, doing this kind of
  major rework will mean that most (if not all) of those blueprints will
  have to be delayed while this pulling out of code occurs. This will
  definitely jeopardise the Cactus release.
 
  My vote is to delay this at a minimum to the Diablo release.
 
  And, for the record, I haven't seen any blueprints for the network as
  a service or volume as a service projects. Can someone point us to
  them?
 
  Thanks!
  jay

 Whew, Jay I thought you were advocating major changes in Cactus.  That
 would completely mess up my view of the world :)

 https://blueprints.launchpad.net/nova/+spec/bexar-network-service
 https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model
 https://blueprints.launchpad.net/nova/+spec/bexar-network-service


 It was discussed at ODS, but I have not seen any code or momentum, to date.

 I think it is worth while to have an open discussion about what if any of
 this can be safely done in Cactus.  I like you, Jay, feel a bit
 conservative.  I think we lost focus of the reason we chose time based
 releases. It is time to focus on nova being a solid trustworthy platform.
  Features land when they are of sufficient quality, releases contain only
 the features that passed muster.

 I will be sending an email about the focus and theme of Cactus in a 

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Andy Smith]

On Fri, Jan 28, 2011 at 1:19 PM, John Purrier j...@openstack.org wrote:

 Thanks for the response, Andy. I think we actually agree on this J.



 You said:



 *This statement is invalid, nova is already broken into services, each of
 which can be dealt with individually and scaled as such, whether the code is
 part of the same repository has little bearing on that. The goals of scaling
 are orthogonal to the location of the code and are much more related to
 separation of concerns in the code, making* sure *that volume code does
 not rely on compute code for example (which at this point it doesn't
 particularly).*



 The fact that the volume code and the compute code are not coupled make the
 separation easy. One factor that I did not mention is that each service will
 present public, management, and optional extension APIs, allowing each
 service to be deployed independently.


So far that is all possible under the existing auspices of Nova. DirectAPI
will happily sit in front of any of the services independently, any of the
services when run can be configured with different instances of RabbitMQ to
point at, DirectAPI supports a large amount of extensibility and pluggable
managers/drivers support a bunch more.

Decoupling of the code has always been a goal, as have been providing
public, management, and extension APIs and we aren't doing so bad.

I don't think we disagree about wanting to run things independently, but for
the moment I have seen no convincing arguments for separating the codebase.





 You said:



 *That suggestion is contradictory, first you say not to separate then you
 suggest creating separate projects. I am against creating separate projects,
 the development is part of Nova until at least Cactus.*



 This is exactly my suggestion below. Keep Nova monolithic until Cactus,
 then integrate the new services once Cactus is shipped. There is work to be
 done to create the service frameworks, API engines, extension mechanisms,
 and porting the existing functionality. All of this can be done in parallel
 to the stability work being done in the Nova code base. As far as I know
 there are not major updates coming in either the volume or network
 management code for this milestone.


Where is this parallel work being done if not in a separate project?

--andy





 John



 *From:* Andy Smith [mailto:andys...@gmail.com]
 *Sent:* Friday, January 28, 2011 12:45 PM
 *To:* John Purrier
 *Cc:* Rick Clark; Jay Pipes; Ewan Mellor; Søren Hansen;
 openstack@lists.launchpad.net

 *Subject:* Re: [Openstack] Network Service for L2/L3 Network
 Infrastructure blueprint





 On Fri, Jan 28, 2011 at 10:18 AM, John Purrier j...@openstack.org wrote:

 Some clarification and a suggestion regarding Nova and the two new proposed
 services (Network/Volume).

 To be clear, Nova today contains both volume and network services. We can
 specify, attach, and manage block devices and also specify network related
 items, such as IP assignment and VLAN creation. I have heard there is some
 confusion on this, since we started talking about creating OpenStack
 services around these areas that will be separate from the cloud controller
 (Nova).

 The driving factors to consider creating independent services for VM,
 Images, Network, and Volumes are 1) To allow deployment scenarios that may
 be scoped to a single service, so that we don't drag all of the Nova code in
 if we just want to deploy virtual volumes, and 2) To allow greater
 innovation and community contribution to the individual services.

 Another nice effect of separation of services is that each service can
 scale horizontally per the demands of the deployment, independent of the
 other services.



 This statement is invalid, nova is already broken into services, each of
 which can be dealt with individually and scaled as such, whether the code is
 part of the same repository has little bearing on that. The goals of scaling
 are orthogonal to the location of the code and are much more related to
 separation of concerns in the code, making sure that volume code does not
 rely on compute code for example (which at this point it doesn't
 particularly).




 We have an existing blueprint discussing the Network Service. We have *not*
 published a blueprint discussing the Volume Service, this will be coming
 soon.

 The net is that creating the correct architecture in OpenStack Compute
 (automation and infrastructure) is a good thing as we look to the future
 evolution of the project.

 Here is the suggestion. It is clear from the response on the list that
 refactoring Nova in the Cactus timeframe will be too risky, particularly as
 we are focusing Cactus on Stability, Reliability, and Deployability (along
 with a complete OpenStack API). For Cactus we should leave the network and
 volume services alone in Nova to minimize destabilizing the code base. In
 parallel, we can initiate the Network and Volume Service projects in
 Launchpad and allow the teams

Re: [Openstack] Lazy import of modules

[Andy Smith]

Thanks phone, that was a yup to separate repository generally. Small
libraries could sneak in but usually best to separate repo in my opinion.
On Jan 14, 2011 10:05 AM, Jay Pipes jaypi...@gmail.com wrote:
 On Fri, Jan 14, 2011 at 11:28 AM, John Purrier j...@openstack.org wrote:
 Another thought, as we envision moving OpenStack forward we will likely
be including code and projects that are not written in Python. Being forward
looking should we structure openstack-common to segment along language
lines?

 That wasn't the original intent of openstack-common, but I suppose we
 could adapt it. Generally, though, I've found that open source
 libraries are separated by language. I don't think I've seen a
 packaged open-source library that served two languages. I think for
 other languages (especially bindings), it's better to have them in a
 separate project that can be packaged according to the customs of that
 programming language/platform.

 -jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp