Re: [Openstack] Events in 2012 that OpenStack should not miss

[Loic Dachary]

On 12/01/2011 02:45 AM, Stefano Maffulli wrote:
> Hello all,
>
> I'd like to compile a list of events, conferences and such, around the
> world where OpenStack should be represented. 
>
> I have started with the few events I'm already aware of. You'll see that
> most of them are US-centric and I'm interested in other events around
> the world where you think OpenStack should be.
>
> What event do you think the OpenStack community should be going to,
> presenting or sponsoring? Add them to the etherpad:
>
> http://etherpad.openstack.org/OpenStackEvents2012
Hi,

I've added LSM in Geneva.

Cheers

<>

signature.asc
Description: OpenPGP digital signature
___
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] How to using keystone with ldap

[Leandro Reox]

Seems like you jave duplicated attributes on your openldap try listing
everythin with ldap search adapting the command below and then delete
duplicate

ldapsearch -s base -b "" -D cn=Administrator,cn=users,dc=domain,dc=com -w
'password' -x -h 192.168.3.10 objectClass=* subschemasubentry

Regards
On Nov 30, 2011 11:16 PM, "DeadSun"  wrote:

> Thanks Leandro
>
> But I also according this article, when I add ldif to ldap, it show error:
> $ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f
> keystone-2012.1/keystone/backends/ldap/keystone.ldif
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> adding new entry "cn=keystone,cn=schema,cn=config"
> ldap_add: Other (e.g., implementation specific) error (80)
> additional info: olcObjectClasses: Duplicate option before (
> keystoneEnabled ) MAY ( mail $ userPassword ) )
>
> 2011/11/30 Leandro Reox 
>
>> Maybe this link can help you out :
>> http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html
>>
>> Regards
>>
>> 2011/11/30 DeadSun 
>>
>>>  Now I according to keystone/test/etc/ldap.conf.template to set ldap
>>> configuration in my keystone.conf
>>>
>>> But I have no idea that wich dn in ldap keystone used and there is no dn
>>> in keystone.ldif . How to set it?
>>>
>>> Anyone using keystone with ldap can help me?
>>> --
>>> 非淡薄无以明志，非宁静无以致远
>>>
>>> ___
>>> 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] how to list all account and get disk usage info?

[andi abes]

take a look at this: https://github.com/notmyname/slogging

It collects usage information for swift, including storage usage and
traffic statistics.
(it has pretty good documentation - just build from source in doc/)


On Wed, Nov 30, 2011 at 6:45 PM, pf shineyear  wrote:

> my question is for swift
>
> but, this python code not for swift, it's for nova
>
> can anyone tell me how do that in swift?
>
> thanks.
>
>
> On Thu, Dec 1, 2011 at 10:29 AM, Tom Fifield wrote:
>
>> Hi,
>>
>> Is this for Swift?
>>
>> Regards,
>>
>> Tom
>>
>>
>> On 12/01/2011 09:41 AM, pf shineyear wrote:
>>
>>> hi all :
>>>
>>> does anyone know how to list all account and get each account's disk
>>> usage info?
>>>
>>> because i want to get every account disk usage info for bill per hour.
>>>
>>> thanks.
>>>
>>
>> __**_
>> 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] How to using keystone with ldap

[DeadSun]

Thanks Leandro

But I also according this article, when I add ldif to ldap, it show error:
$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f
keystone-2012.1/keystone/backends/ldap/keystone.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=keystone,cn=schema,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: olcObjectClasses: Duplicate option before (
keystoneEnabled ) MAY ( mail $ userPassword ) )

2011/11/30 Leandro Reox 

> Maybe this link can help you out :
> http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html
>
> Regards
>
> 2011/11/30 DeadSun 
>
>> Now I according to keystone/test/etc/ldap.conf.template to set ldap
>> configuration in my keystone.conf
>>
>> But I have no idea that wich dn in ldap keystone used and there is no dn
>> in keystone.ldif . How to set it?
>>
>> Anyone using keystone with ldap can help me?
>> --
>> 非淡薄无以明志，非宁静无以致远
>>
>> ___
>> 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] Events in 2012 that OpenStack should not miss

[Stefano Maffulli]

Hello all,

I'd like to compile a list of events, conferences and such, around the
world where OpenStack should be represented. 

I have started with the few events I'm already aware of. You'll see that
most of them are US-centric and I'm interested in other events around
the world where you think OpenStack should be.

What event do you think the OpenStack community should be going to,
presenting or sponsoring? Add them to the etherpad:

http://etherpad.openstack.org/OpenStackEvents2012

thanks
stef


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

Re: [Openstack] how to list all account and get disk usage info?

[pf shineyear]

my question is for swift

but, this python code not for swift, it's for nova

can anyone tell me how do that in swift?

thanks.

On Thu, Dec 1, 2011 at 10:29 AM, Tom Fifield wrote:

> Hi,
>
> Is this for Swift?
>
> Regards,
>
> Tom
>
>
> On 12/01/2011 09:41 AM, pf shineyear wrote:
>
>> hi all :
>>
>> does anyone know how to list all account and get each account's disk
>> usage info?
>>
>> because i want to get every account disk usage info for bill per hour.
>>
>> thanks.
>>
>
> __**_
> 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] how to list all account and get disk usage info?

[pf shineyear]

thanks a lot , but how can i do this in swift?


On Thu, Dec 1, 2011 at 10:24 AM, Anthony Young
wrote:

> Take a look at this extension:
>
>
> https://github.com/openstack/nova/blob/master/nova/api/openstack/v2/contrib/simple_tenant_usage.py
>
> I don't believe a client has yet been added to python-novaclient to access
> this endpoint, though it should be simple enough to implement.
>
> A
>
> On Wed, Nov 30, 2011 at 2:41 PM, pf shineyear  wrote:
>
>> hi all :
>>
>> does anyone know how to list all account and get each account's disk
>> usage info?
>>
>> because i want to get every account disk usage info for bill per hour.
>>
>> thanks.
>>
>> ___
>> 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] how to list all account and get disk usage info?

[Tom Fifield]

Hi,

Is this for Swift?

Regards,

Tom

On 12/01/2011 09:41 AM, pf shineyear wrote:

hi all :

does anyone know how to list all account and get each account's disk
usage info?

because i want to get every account disk usage info for bill per hour.

thanks.


___
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] how to list all account and get disk usage info?

[Anthony Young]

Take a look at this extension:

https://github.com/openstack/nova/blob/master/nova/api/openstack/v2/contrib/simple_tenant_usage.py

I don't believe a client has yet been added to python-novaclient to access
this endpoint, though it should be simple enough to implement.

A

On Wed, Nov 30, 2011 at 2:41 PM, pf shineyear  wrote:

> hi all :
>
> does anyone know how to list all account and get each account's disk usage
> info?
>
> because i want to get every account disk usage info for bill per hour.
>
> thanks.
>
> ___
> 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] how to list all account and get disk usage info?

[pf shineyear]

hi all :

does anyone know how to list all account and get each account's disk usage
info?

because i want to get every account disk usage info for bill per hour.

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

Re: [Openstack] nova-api crashes due to ImportError

[Andy Bierman]

Yep - that was it.  There was an old version in /etc/nova.
I copied the new version there and nova-api works now.


Thanks,
Andy


From: Brian Waldon [mailto:brian.wal...@rackspace.com]
Sent: Wednesday, November 30, 2011 12:57 PM
To: Andy Bierman
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] nova-api crashes due to ImportError

You probably need to update your api-paste.ini file. Compare what you have to 
what you see here: 
https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini. I bet 
you're missing the Metadata section.

Brian


On Nov 30, 2011, at 3:08 PM, Andy Bierman wrote:


Hi,

I am running the code from yesterday (lp:nova) on Ubuntu 11.04 (x64).
All nova-* programs except nova-api are starting OK.
That program terminates because it cannot import 'metadatarequesthandler'.
See the trackback attached.  How can I get nova-api working?

thanks,
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

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

Re: [Openstack] nova-api crashes due to ImportError

[Brian Waldon]

You probably need to update your api-paste.ini file. Compare what you have to 
what you see here: 
https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini. I bet 
you're missing the Metadata section.

Brian


On Nov 30, 2011, at 3:08 PM, Andy Bierman wrote:

> Hi,
>  
> I am running the code from yesterday (lp:nova) on Ubuntu 11.04 (x64).
> All nova-* programs except nova-api are starting OK.
> That program terminates because it cannot import ‘metadatarequesthandler’.
> See the trackback attached.  How can I get nova-api working?
>  
> thanks,
> 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

___
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.org/security copyedit review -was- Re: Vulnerability Management concerns: negativity & count

[Anne Gentle]

Hi all -
Wanted to circle back on this one. We have a request logged in the
openstack-manuals project tagged with "website" and Thierry and Lloyd
are putting the finishing touches on the draft copy. My suggested
placement will be as a left-side nav item on openstack.org/projects
with the link going to openstack.org/security. While I realize search
engine optimization was the original goal here we need to ensure
visibility for visitors to the site. I don't believe it deserves
top-nav treatment but will certainly entertain eloquent arguments.

Once the content and placement are good-to-go, I'll do the work.
Likely this should only take me an hour and I can completed it this
week.

We'd also like to work on creating a group and project in Launchpad
for openstack.org content and framework maintenance. Hopefully with
Launchpad oauth we can offer single-sign on to the CMS that runs
openstack.org, Silverstripe. I'd like to discuss this at the next
doc/web team meeting, Dec. 12, 20:00 UTC. Please attend in
#openstack-meeting on IRC if this is a topic of interest to you.

Thanks,
Anne

On Thu, Nov 24, 2011 at 6:11 PM, Anne Gentle  wrote:
> Hi Lloyd -
>
> Doc coordinator here, glad to see you're joining in and willing to edit. For
> Etherpads that are written at a Design Summit there is no editorial pass.
> Feel free to propose moving relevant content to a better location and
> editing it as you do so considering audience and purpose as you go. Let me
> know some goals you have for this content and I'm happy to help you with
> placement.
>
> Thanks,
> Anne
>
> On Thu, Nov 24, 2011 at 11:32 AM, Lloyd Dewolf 
> wrote:
>>
>> On Thu, Nov 24, 2011 at 7:30 AM, Thierry Carrez 
>> wrote:
>> > Lloyd Dewolf wrote:
>> >> [...]
>> >> I do have a couple of serious concerns:
>> >> [...]
>> >> Every sentence in the first paragraph is dripping with negativity
>> >> - "will not give prior notice to their employer"
>> >> - "not about getting advance notice"
>> >> - "reduce the disclosure of vulnerability in the early stages"
>> >
>> > This page is work in progress policy for the vulnerability management
>> > team. The more public-oriented contents of the proposed
>> > openstack.org/security page, as brainstormed by all people that have
>> > shown interest in security at the last design summit, is here:
>> >
>> > http://etherpad.openstack.org/8hWNQwkWf9
>>
>> I really like what you have there!
>>
>> There is a little copy editing to be done. Did the doc team have a
>> chance to review this yet? I'd assume it is a priority for them, and
>> something they will get to soon?
>>
>> Either way I'm happy to provide my limited editorial skills, once we
>> explore possibly changes to the Vulnerability Management team.
>>
>> Hit me up then if you like,
>> Lloyd
>>
>> ___
>> 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] nova-api crashes due to ImportError

[Andy Bierman]

Hi,

I am running the code from yesterday (lp:nova) on Ubuntu 11.04 (x64).
All nova-* programs except nova-api are starting OK.
That program terminates because it cannot import 'metadatarequesthandler'.
See the trackback attached.  How can I get nova-api working?

thanks,
Andy

2011-11-30 11:55:45,801 CRITICAL nova [-] No module named metadatarequesthandler
(nova): TRACE: Traceback (most recent call last):
(nova): TRACE:   File "/usr/local/bin/nova-api", line 7, in 
(nova): TRACE: execfile(__file__)
(nova): TRACE:   File "/home/user01/launchpad/nova/bin/nova-api", line 51, in 

(nova): TRACE: servers.append(service.WSGIService(api))
(nova): TRACE:   File "/home/user01/launchpad/nova/nova/service.py", line 301, 
in __init__
(nova): TRACE: self.app = self.loader.load_app(name)
(nova): TRACE:   File "/home/user01/launchpad/nova/nova/wsgi.py", line 411, in 
load_app
(nova): TRACE: return deploy.loadapp("config:%s" % self.config_path, 
name=name)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
(nova): TRACE: return loadobj(APP, uri, name=name, **kw)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
(nova): TRACE: return context.create()
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in 
create
(nova): TRACE: return self.object_type.invoke(self)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in 
invoke
(nova): TRACE: **context.local_conf)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/util.py", line 56, in 
fix_call
(nova): TRACE: val = callable(*args, **kw)
(nova): TRACE:   File "/usr/lib/pymodules/python2.7/paste/urlmap.py", line 25, 
in urlmap_factory
(nova): TRACE: app = loader.get_app(app_name, global_conf=global_conf)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
(nova): TRACE: name=name, global_conf=global_conf).create()
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
(nova): TRACE: APP, name=name, global_conf=global_conf)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
(nova): TRACE: global_additions=global_additions)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 559, in 
_pipeline_app_context
(nova): TRACE: APP, pipeline[-1], global_conf)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
(nova): TRACE: section)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
(nova): TRACE: value = import_string(found_expr)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 22, in 
import_string
(nova): TRACE: return pkg_resources.EntryPoint.parse("x=" + s).load(False)
(nova): TRACE:   File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line 1989, in load
(nova): TRACE: entry = __import__(self.module_name, globals(),globals(), 
['__name__'])
(nova): TRACE: ImportError: No module named metadatarequesthandler
(nova): TRACE: 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [nova-testing] Efforts for Essex

[Duncan McGreggor]

On Wed, Nov 30, 2011 at 11:35 AM, Jason Kölker  wrote:
> On Wed, 2011-11-30 at 11:07 -0800, Duncan McGreggor wrote:
>>  * create nova/volume/tests
>>  * move all scheduler-related tests (there are several) from
>> nova/tests into nova/volume/tests
>>  * break out tests on a per-module basis (e.g., nova/volume/driver.py
>> would get the test module nova/volume/tests/test_driver.py, etc.)
>>  * for modules that have already been broken out at a more
>> fine-grained level, keep (smaller test case modules are nice!)
>>  * only nova/*.py files will have a test case module in nova/tests
>>  * bonus: update the test runner to print the full dotted path so it's
>> immediately (and visually) clear where one has to go to address any
>> failures
>>
>> Given approval, this work would be done in its own blueprint. All this
>> work would be done in small chunks (probably one branch per module) so
>> that it will be easy to review and adjust the approach as needed.
>>
>> Thoughts?
>
> I like this. It paves the way being able to break nova up into smaller
> inter-changeable packages. My only hesitation is stubs and fakes
> sharing.
>
> I don't want to bring up the unit vs func test debate again, but
> currently if a change happens on one side of the rpc layer, there is
> *hopefully* only one fake/stub set to change. If each module contains
> it's own set of tests, I worry that each module will start having their
> own set of fakes which will have to be updated. (I know this is already
> the case in many places, but hopefully we are all working on fixing
> that, right...? ;)

Yup! That's currently part of the work I'm doing in this blueprint:
  https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure

Note this line:
  [oubiwann] moving other fakes in various subpackages into
nova.testing.fake: TODO

:-)

d

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

Re: [Openstack] [nova-testing] Efforts for Essex

[Chris Behrens]

It'll be a couple days yet.  I was refactoring a few things in the scheduler 
and while re-doing some tests, I ended up going down this rabbit hole of 
re-doing all of the tests.  It's turned into a 6500 line diff so far... :) 
which is a bit much for just the refactoring that I need to get in first.  So, 
I'm currently splitting these out into a couple of different reviews.

- Chris


On Nov 30, 2011, at 1:53 PM, Duncan McGreggor wrote:

> On 30 Nov 2011 - 19:26, Chris Behrens wrote:
>> I need to catch up a bit with this thread, but I wanted to mention I
>> have a huge patch coming that refactors almost all of the scheduler
>> tests into true unit tests.
> 
> Nice!
> 
>> I'd started this for other reasons and I
>> hope it jives with the plans here.  But if anyone is looking at the
>> scheduler tests, we should sync up.
> 
> I was going to actually use the scheduler as the example when I sent
> this email out, but I switched to something a bit cleaner instead... so
> this is great news! Can't wait to see it :-)
> 
> d
> 
>> - Chris
>> 
>> On Nov 30, 2011, at 1:07 PM, Duncan McGreggor  wrote:
>> 
>>> On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen  wrote:
 It's been a bit over a week since I started this thread. So far we've
 agreed that running the test suite is too slow, mostly because there
 are too many things in there that aren't unit tests.
 
 We've also discussed my fake db implementation at length. I think
 we've generally agreed that it isn't completely insane, so that's
 moving along nicely.
 
 Duncan has taken the first steps needed to split the test suite into
 unit tests and everything else:
 
  https://review.openstack.org/#change,1879
 
 Just one more core +1 needed. Will someone beat me to it? Only time
 will tell :) Thanks, Duncan!
 
 Anything else around unit testing anyone wants to get into The Great
 Big Plan[tm]?
>>> 
>>> Actually, yeah... one more thing :-)
>>> 
>>> Jay and I were chatting about organization of infrastructure last
>>> night/this morning (on the review comments for the branch I
>>> submitted). He said that I should raise a concern I expressed for
>>> wider discussion: right now, tests are all piled into the tests
>>> directory. Below are my thoughts on this.
>>> 
>>> I think such an approach is just fine for smaller projects; there's
>>> not a lot there, and it's all pretty easy to find. For large projects,
>>> this seems like not such a good idea for the following reasons:
>>> 
>>> * tests are kept separate from the code they relate to
>>> * there are often odd test module file naming practices required
>>> (e.g., nova/a/api.py and nova/b/api.py both needing test cases in
>>> nova/tests/)
>>> * there's no standard exercised for whether a subpackage gets a
>>> single test case module or whether it gets a test case subpackage
>>> * test modules tend to be very long (and thus hard to navigate) due
>>> to the awkwardness of naming modules when all the code lives together
>>> * it makes it harder for newcomers to find code; when they live
>>> together, it's a no-brainer
>>> 
>>> OpenStack is definitely not a small project, and as our test coverage
>>> becomes more complete, these issues will have increased impact. I
>>> would like to clean all of this up :-) And I'm volunteering to do the
>>> work! Here's the sort of thing I envision, using nova.volume as an
>>> example:
>>> 
>>> * create nova/volume/tests
>>> * move all scheduler-related tests (there are several) from
>>> nova/tests into nova/volume/tests
>>> * break out tests on a per-module basis (e.g., nova/volume/driver.py
>>> would get the test module nova/volume/tests/test_driver.py, etc.)
>>> * for modules that have already been broken out at a more
>>> fine-grained level, keep (smaller test case modules are nice!)
>>> * only nova/*.py files will have a test case module in nova/tests
>>> * bonus: update the test runner to print the full dotted path so it's
>>> immediately (and visually) clear where one has to go to address any
>>> failures
>>> 
>>> Given approval, this work would be done in its own blueprint. All this
>>> work would be done in small chunks (probably one branch per module) so
>>> that it will be easy to review and adjust the approach as needed.
>>> 
>>> Thoughts?
>>> 
>>> d
>>> 
 
 --
 Soren Hansen| http://linux2go.dk/
 Ubuntu Developer| http://www.ubuntu.com/
 OpenStack Developer | http://www.openstack.org/
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://

Re: [Openstack] [nova-testing] Efforts for Essex

[Duncan McGreggor]

On 30 Nov 2011 - 19:26, Chris Behrens wrote:
> I need to catch up a bit with this thread, but I wanted to mention I
> have a huge patch coming that refactors almost all of the scheduler
> tests into true unit tests.

Nice!

> I'd started this for other reasons and I
> hope it jives with the plans here.  But if anyone is looking at the
> scheduler tests, we should sync up.

I was going to actually use the scheduler as the example when I sent
this email out, but I switched to something a bit cleaner instead... so
this is great news! Can't wait to see it :-)

d

> - Chris
>
> On Nov 30, 2011, at 1:07 PM, Duncan McGreggor  wrote:
>
> > On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen  wrote:
> >> It's been a bit over a week since I started this thread. So far we've
> >> agreed that running the test suite is too slow, mostly because there
> >> are too many things in there that aren't unit tests.
> >>
> >> We've also discussed my fake db implementation at length. I think
> >> we've generally agreed that it isn't completely insane, so that's
> >> moving along nicely.
> >>
> >> Duncan has taken the first steps needed to split the test suite into
> >> unit tests and everything else:
> >>
> >>   https://review.openstack.org/#change,1879
> >>
> >> Just one more core +1 needed. Will someone beat me to it? Only time
> >> will tell :) Thanks, Duncan!
> >>
> >> Anything else around unit testing anyone wants to get into The Great
> >> Big Plan[tm]?
> >
> > Actually, yeah... one more thing :-)
> >
> > Jay and I were chatting about organization of infrastructure last
> > night/this morning (on the review comments for the branch I
> > submitted). He said that I should raise a concern I expressed for
> > wider discussion: right now, tests are all piled into the tests
> > directory. Below are my thoughts on this.
> >
> > I think such an approach is just fine for smaller projects; there's
> > not a lot there, and it's all pretty easy to find. For large projects,
> > this seems like not such a good idea for the following reasons:
> >
> > * tests are kept separate from the code they relate to
> > * there are often odd test module file naming practices required
> > (e.g., nova/a/api.py and nova/b/api.py both needing test cases in
> > nova/tests/)
> > * there's no standard exercised for whether a subpackage gets a
> > single test case module or whether it gets a test case subpackage
> > * test modules tend to be very long (and thus hard to navigate) due
> > to the awkwardness of naming modules when all the code lives together
> > * it makes it harder for newcomers to find code; when they live
> > together, it's a no-brainer
> >
> > OpenStack is definitely not a small project, and as our test coverage
> > becomes more complete, these issues will have increased impact. I
> > would like to clean all of this up :-) And I'm volunteering to do the
> > work! Here's the sort of thing I envision, using nova.volume as an
> > example:
> >
> > * create nova/volume/tests
> > * move all scheduler-related tests (there are several) from
> > nova/tests into nova/volume/tests
> > * break out tests on a per-module basis (e.g., nova/volume/driver.py
> > would get the test module nova/volume/tests/test_driver.py, etc.)
> > * for modules that have already been broken out at a more
> > fine-grained level, keep (smaller test case modules are nice!)
> > * only nova/*.py files will have a test case module in nova/tests
> > * bonus: update the test runner to print the full dotted path so it's
> > immediately (and visually) clear where one has to go to address any
> > failures
> >
> > Given approval, this work would be done in its own blueprint. All this
> > work would be done in small chunks (probably one branch per module) so
> > that it will be easy to review and adjust the approach as needed.
> >
> > Thoughts?
> >
> > d
> >
> >>
> >> --
> >> Soren Hansen| http://linux2go.dk/
> >> Ubuntu Developer| http://www.ubuntu.com/
> >> OpenStack Developer | http://www.openstack.org/
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] [nova-testing] Efforts for Essex

[Jason Kölker]

On Wed, 2011-11-30 at 11:07 -0800, Duncan McGreggor wrote:
>  * create nova/volume/tests
>  * move all scheduler-related tests (there are several) from
> nova/tests into nova/volume/tests
>  * break out tests on a per-module basis (e.g., nova/volume/driver.py
> would get the test module nova/volume/tests/test_driver.py, etc.)
>  * for modules that have already been broken out at a more
> fine-grained level, keep (smaller test case modules are nice!)
>  * only nova/*.py files will have a test case module in nova/tests
>  * bonus: update the test runner to print the full dotted path so it's
> immediately (and visually) clear where one has to go to address any
> failures
> 
> Given approval, this work would be done in its own blueprint. All this
> work would be done in small chunks (probably one branch per module) so
> that it will be easy to review and adjust the approach as needed.
> 
> Thoughts?

I like this. It paves the way being able to break nova up into smaller
inter-changeable packages. My only hesitation is stubs and fakes
sharing.

I don't want to bring up the unit vs func test debate again, but
currently if a change happens on one side of the rpc layer, there is
*hopefully* only one fake/stub set to change. If each module contains
it's own set of tests, I worry that each module will start having their
own set of fakes which will have to be updated. (I know this is already
the case in many places, but hopefully we are all working on fixing
that, right...? ;)

TS;DR Is Bueno! I'm lazy.

Happy Hacking!

7-11


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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Vishvananda Ishaya]

On Nov 30, 2011, at 4:18 AM, Thierry Carrez wrote:

> Soren Hansen wrote:
>> I propose we start building packages from the stable branches and put
>> them in an appropriately named/labeled PPA, such as nova-core/diablo-qa
>> or nova-core/diablo-not-for-production (or perhaps under
>> openstack-stable-maint).
>> [...]
> 
> That would work (and inside the current project). Just two remarks:
> 
> * Expectations are difficult to control. Even if we use an intimidating
> name, some people will still expect this to provide more than it
> actually does. For example, people kept thinking that the "2011.3"
> release PPA would be updated, while it explicitly said it wouldn't.
> 
> * I don't think that's what Vish and Monty are after -- they
> specifically mentioned the lack of a production-ready distribution
> channel as the problem that we needed to solve

I won't speak for Monty, but Soren's suggestion checks all of my boxes.  The 
use case I'm trying to fill is user's with existing infrastructure (or even 
older openstack installs!) that are evaluating diablo.  We can't expect these 
users to upgrade to Oneiric.  I just want to be able to tell them a place to go 
that they can install on Lucid that will actually work.

I don't mind making it clear that they will have to take responsibility for 
maintaining packages if they want to take it into production. There are so many 
barriers of entry to getting started with OpenStack, so I'm just trying to pull 
down as many of those as I can.

Vish

> 
> -- 
> 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] [nova-testing] Efforts for Essex

[Chris Behrens]

I need to catch up a bit with this thread, but I wanted to mention I have a 
huge patch coming that refactors almost all of the scheduler tests into true 
unit tests.  I'd started this for other reasons and I hope it jives with the 
plans here.  But if anyone is looking at the scheduler tests, we should sync up.

- Chris

On Nov 30, 2011, at 1:07 PM, Duncan McGreggor  wrote:

> On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen  wrote:
>> It's been a bit over a week since I started this thread. So far we've
>> agreed that running the test suite is too slow, mostly because there
>> are too many things in there that aren't unit tests.
>> 
>> We've also discussed my fake db implementation at length. I think
>> we've generally agreed that it isn't completely insane, so that's
>> moving along nicely.
>> 
>> Duncan has taken the first steps needed to split the test suite into
>> unit tests and everything else:
>> 
>>   https://review.openstack.org/#change,1879
>> 
>> Just one more core +1 needed. Will someone beat me to it? Only time
>> will tell :) Thanks, Duncan!
>> 
>> Anything else around unit testing anyone wants to get into The Great
>> Big Plan[tm]?
> 
> Actually, yeah... one more thing :-)
> 
> Jay and I were chatting about organization of infrastructure last
> night/this morning (on the review comments for the branch I
> submitted). He said that I should raise a concern I expressed for
> wider discussion: right now, tests are all piled into the tests
> directory. Below are my thoughts on this.
> 
> I think such an approach is just fine for smaller projects; there's
> not a lot there, and it's all pretty easy to find. For large projects,
> this seems like not such a good idea for the following reasons:
> 
> * tests are kept separate from the code they relate to
> * there are often odd test module file naming practices required
> (e.g., nova/a/api.py and nova/b/api.py both needing test cases in
> nova/tests/)
> * there's no standard exercised for whether a subpackage gets a
> single test case module or whether it gets a test case subpackage
> * test modules tend to be very long (and thus hard to navigate) due
> to the awkwardness of naming modules when all the code lives together
> * it makes it harder for newcomers to find code; when they live
> together, it's a no-brainer
> 
> OpenStack is definitely not a small project, and as our test coverage
> becomes more complete, these issues will have increased impact. I
> would like to clean all of this up :-) And I'm volunteering to do the
> work! Here's the sort of thing I envision, using nova.volume as an
> example:
> 
> * create nova/volume/tests
> * move all scheduler-related tests (there are several) from
> nova/tests into nova/volume/tests
> * break out tests on a per-module basis (e.g., nova/volume/driver.py
> would get the test module nova/volume/tests/test_driver.py, etc.)
> * for modules that have already been broken out at a more
> fine-grained level, keep (smaller test case modules are nice!)
> * only nova/*.py files will have a test case module in nova/tests
> * bonus: update the test runner to print the full dotted path so it's
> immediately (and visually) clear where one has to go to address any
> failures
> 
> Given approval, this work would be done in its own blueprint. All this
> work would be done in small chunks (probably one branch per module) so
> that it will be easy to review and adjust the approach as needed.
> 
> Thoughts?
> 
> d
> 
>> 
>> --
>> Soren Hansen| http://linux2go.dk/
>> Ubuntu Developer| http://www.ubuntu.com/
>> OpenStack Developer | http://www.openstack.org/
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] [nova-testing] Efforts for Essex

[Duncan McGreggor]

On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen  wrote:
> It's been a bit over a week since I started this thread. So far we've
> agreed that running the test suite is too slow, mostly because there
> are too many things in there that aren't unit tests.
>
> We've also discussed my fake db implementation at length. I think
> we've generally agreed that it isn't completely insane, so that's
> moving along nicely.
>
> Duncan has taken the first steps needed to split the test suite into
> unit tests and everything else:
>
>   https://review.openstack.org/#change,1879
>
> Just one more core +1 needed. Will someone beat me to it? Only time
> will tell :) Thanks, Duncan!
>
> Anything else around unit testing anyone wants to get into The Great
> Big Plan[tm]?

Actually, yeah... one more thing :-)

Jay and I were chatting about organization of infrastructure last
night/this morning (on the review comments for the branch I
submitted). He said that I should raise a concern I expressed for
wider discussion: right now, tests are all piled into the tests
directory. Below are my thoughts on this.

I think such an approach is just fine for smaller projects; there's
not a lot there, and it's all pretty easy to find. For large projects,
this seems like not such a good idea for the following reasons:

 * tests are kept separate from the code they relate to
 * there are often odd test module file naming practices required
(e.g., nova/a/api.py and nova/b/api.py both needing test cases in
nova/tests/)
 * there's no standard exercised for whether a subpackage gets a
single test case module or whether it gets a test case subpackage
 * test modules tend to be very long (and thus hard to navigate) due
to the awkwardness of naming modules when all the code lives together
 * it makes it harder for newcomers to find code; when they live
together, it's a no-brainer

OpenStack is definitely not a small project, and as our test coverage
becomes more complete, these issues will have increased impact. I
would like to clean all of this up :-) And I'm volunteering to do the
work! Here's the sort of thing I envision, using nova.volume as an
example:

 * create nova/volume/tests
 * move all scheduler-related tests (there are several) from
nova/tests into nova/volume/tests
 * break out tests on a per-module basis (e.g., nova/volume/driver.py
would get the test module nova/volume/tests/test_driver.py, etc.)
 * for modules that have already been broken out at a more
fine-grained level, keep (smaller test case modules are nice!)
 * only nova/*.py files will have a test case module in nova/tests
 * bonus: update the test runner to print the full dotted path so it's
immediately (and visually) clear where one has to go to address any
failures

Given approval, this work would be done in its own blueprint. All this
work would be done in small chunks (probably one branch per module) so
that it will be easy to review and adjust the approach as needed.

Thoughts?

d

>
> --
> Soren Hansen        | http://linux2go.dk/
> Ubuntu Developer    | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Duncan McGreggor]

On 30 Nov 2011 - 13:57, Loic Dachary wrote:
> Hi,
> > TL;DR summary: The resources needed to do that properly are bigger
> > than you think (and doing that will alienate some distro packaging
> > resources), so we'll either do a terrible job at it, or lose focus
> > on the development release. If there is a need, it should be done as
> > an alternate distribution, not inside the OpenStack project.
> >
>
> As Julien Danjou wrote, we ( OpenStack Debian GNU/Linux packagers [1])
> discussed your mail.  We are comfortable with the idea that OpenStack
> focuses on  development and that packaging is left to the packagers
> involved in  each distribution.
>
> Packaging related patches from Julien Danjou were recently accepted
> upstream (https://review.openstack.org/#dashboard,1669). This is the
> kind of cooperation that makes it possible to maintain packages
> matching  the Debian GNU/Linux quality standard. We are confident in
> our ability  to provide stable packages in the future.
>
> OpenStack packaging is not an easy task. It currently fits nicely in
> Debian GNU/Linux. However,  as it evolves towards a system widely used
> in production, it will face  new challenges and the communities
> working on packaging for each  distribution will provide valuable
> input to developers. Creating a  "packaging team" with representatives
> for each distribution and electing  someone to represent them in the
> Policy Board could achieve this.

Very +1.

d

> Cheers
>
> [1] PKG OpenStack page :
> https://alioth.debian.org/projects/openstack/and corresponding
> packages:
> http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
> http://qa.debian.org/developer.php?packages=nova
> http://qa.debian.org/developer.php?packages=glance
>
>
>

> begin:vcard
> fn:Loic Dachary
> n:Dachary;Loic
> org:Artisan Logiciel Libre
> adr:;;12 bd Magenta;Paris;;75010;France
> email;internet:l...@dachary.org
> title:Senior Developer
> tel;work:+33 4 84 25 08 05
> tel;home:+33 9 51 18 43 38
> tel;cell:+33 6 64 03 29 07
> note:Born 131414404 before EPOCH.
> url:http://dachary.org/
> version:2.1
> end:vcard
>




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


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

Re: [Openstack] Cloud Computing StackExchange site proposal

[Everett Toews]

I would like to see a way to identify the version (or milestone) the
question pertains to, perhaps via a select box. OpenStack is moving quickly
and I expect many questions will become irrelevant just as quickly. There
could also be an "All" option, if the question is about something
fundamental (e.g. "ping and ssh don't work"). Maybe there could also be an
option for people with enough reputation/karma/points to edit the version.

Of course you could do this with a tag but that's easily forgotten and
people will often invent their own tags for the same version.

Everett

On Tue, Nov 29, 2011 at 12:16 PM, Stefano Maffulli wrote:

> On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote:
> > Where do I find this previous discussion?
>
> around here:
> https://lists.launchpad.net/openstack/msg02169.html
>
> What do you think of the requirements we're gathering for the Q&A
> system? I'd like your opinion on that as we move on.
>
> thanks
> stef
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Proposal for Mark McLoughlin to join nova-core

[Matt Dietz]

+1 from me, too

On 11/30/11 4:47 AM, "Soren Hansen"  wrote:

>2011/11/29 Vishvananda Ishaya :
>> Mark is maintaining openstack for Fedora and has made some excellent
>>contributions to nova.  He has also been very prolific with reviews
>>lately. Lets add him to core and make his reviews count towards
>>potential merges!
>
>I'd be delighted to have Mark on the core team. +1
>
>-- 
>Soren Hansen| http://linux2go.dk/
>Ubuntu Developer| http://www.ubuntu.com/
>OpenStack Developer | http://www.openstack.org/
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


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

Re: [Openstack] Proposal for Lorin Hochstein to join nova-core

[Matt Dietz]

+1!

On 11/30/11 8:05 AM, "Sandy Walsh"  wrote:

>+1 ... good call!
>
>From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
>[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on
>behalf of Vishvananda Ishaya [vishvana...@gmail.com]
>Sent: Tuesday, November 29, 2011 2:03 PM
>To: openstack (openstack@lists.launchpad.net)
>Subject: [Openstack] Proposal for Lorin Hochstein to join nova-core
>
>Lorin has been a great contributor to Nova for a long time and has been
>participating heavily in reviews over the past couple of months.  I think
>he would be a great addition to nova-core.
>
>Vish
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


___
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] Cloud Computing StackExchange site proposal

[Stefano Maffulli]

On Wed, 2011-11-30 at 10:26 -0300, Alejandro Comisario wrote:
> Today i think there are enough data on launchpad to solve, 

When you say 'enough data in launchpad' what do you mean exactly?

> A forum is more than ok also, because 
[...]

lets avoid talking about tools. I'd like to understand what features we
want to offer to new users searching for answers to their questions. And
I'd also like to understand what features are important for experts and
developers in order for them to participate in giving answers, when
needed.

> Making posts promoted to FAQS or post becoming GUIDES and going into
> the FAQS, and the search engine suggesting something like [...]

If I understand correctly, you would like to have a system where a
question from a new user can be marked as FAQ and that question, with
the relevant answer can go populate a list of FAQs. Is that what you
have in mind?

> "Ok, if you didnt find your answer, maybe you are having troubles
> because of an implementation or a setup problem, why dont you go to
> the IMPLEMENTATION AND MOST IMPORTANT GUIDES to see if you can improve
> that and fix your real problem ??" 

The Documentation and Guides should be the first stop for anybody
looking for answers, right?  

/stef


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

Re: [Openstack] Lloyd Learning Docs & website content processes

[Lloyd Dewolf]

On Wed, Nov 30, 2011 at 6:18 AM, Lloyd Dewolf  wrote:
> On Wed, Nov 30, 2011 at 2:45 AM, Thierry Carrez
>  wrote:> Lloyd Dewolf wrote:>> 2. Lloyd will
> log Thierry "ttx" Carrez's solid openstack.org/security>> content from
> http://etherpad.openstack.org/8hWNQwkWf9 to>>
> http://launchpad.net/openstack-manuals , if it is not already there.>>
> He will do a copyedit to the etherpad, and also upload his revision
> to>> openstack-manuals. We'll take it from there based on the process
> Anne>> is updating to the wiki.>> Note that the content was pushed to
> www.openstack.org webmaster for> publication, without much result yet
> (the idea was to quickly replace> "nothing" with "something", and then
> improve incrementally).>> It would be great if we could have a more
> dynamic way to review/update> the main website content (in the same
> way we control the docs site> contents): it could prove useful in
> further revisions.
> Fantastic! We're of the same mind. And I'm so thankful for how hard
> you've pushed this forward over these past months.
> 1. I'm trying to motivate a revision in the same spirit as what you
> wrote to get online as soon as possible. From there we can look to
> come together to evolve the processes and communications 2. With a
> documented process with public visibility, we will now have a
> foundation where people can step forward as stakeholders, and we can
> quantify the time to publish. From here we can align with people's
> workloads, and negotiate the priority of our items.
> Thanks,Lloyd

Ugg, sorry for the formatting again. I thought this was resolved in
the latest Google Chrome Canary.

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

Re: [Openstack] Providing packages for stable releases of OpenStack

[David Kranz]

On 11/30/2011 7:59 AM, Soren Hansen wrote:



I don't have anything concrete to offer as an alternative, but I'd
love to see something like devstack that runs either from git or
tarballs and supports multiple distributions.

For production, we recommend people use packages. I think there's a lot
of value in using the same installation mechanism for QA as for
production.

This, for us, is the main issue.  We use devstack for various things but 
unfortunately "install from source" is very different from "install for 
production", more so in python/openstack than some other technologies.  
When we are testing a new build to see whether a problem was fixed or a 
new feature is working we just want to change the pointer to the ppa. I 
understand that if some source change induces the need for a packaging 
change then an auto-created ppa will stop working. It is also true that 
creating packages as part of a build process may end up favoring some 
packaging system over another. Still, I don't think that is a reason to 
force users to have their own  (or, cringe, manual) processes to create 
packages that can feed into a test-for-production environment when 
jenkins can just do it for a few popular systems.


 -David


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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Lloyd Dewolf]

On Wed, Nov 30, 2011 at 4:07 AM, Soren Hansen 
wrote:>> To me, the PPA's have always been a QA tool. I wanted people
willing to> help test OpenStack to be able to do so with as little
effort as> possible.  Building packages per-commit gave us that.
+1
I don't have any insights on the implementation details, and agreethat
it is hard to do well, but it is essential for quality.
It's more than the level of effort for testing, we need to
eliminatevariability, and everyone be able to point to the same thing
and say,"is good".
But working on this today, would it introduce great variability
verseswhat will be deployed to production? I hesitate to suggest this
mightbe a problem for six months from now when everyone has had some
timeto work out the details of their own flavors, and worked with
thoseflavors with customers.

Still without something how do we measure quality.

___
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] future-me -was- Re: Vulnerability Management concerns: negativity & count

[Lloyd Dewolf]

On Thu, Nov 24, 2011 at 2:58 PM, Soren Hansen  wrote:
> 2011/11/24 Lloyd Dewolf :
>
>> Future-me will be proud that we have a robust solution (which I feel
>> like you guys are challenging me to brainstorm on) and that we've
>> never had a premature disclosure.
>
> We're not quite a point yet where I'd consider that last point any sort
> of success. To me, it's kind of like celebrating that the shuttle hasn't
> exploded yet when the spaceship is still on the launch pad.

I'm not inviting you to my happy place Soren! ;-)

It's a popular communicate technique used to build consensus. I find
it often worthwhile to present things in a number of ways as we all
use different lens, and we don't want to limit our audience
(particularly prematurely).

Examples of variations of this technique are:

* Amazon's "working backwards"
http://www.shmula.com/start-with-the-customer-and-work-backwards/324/
http://www.allthingsdistributed.com/2006/11/working_backwards.html

* Automattic often drafts the blog post and help pages before starting on
design and implimentation.


The very best to you,
Lloyd

___
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] Cloud Computing StackExchange site proposal

[Alejandro Comisario]

Hi guys.
When we have any kind of trouble, we hit the logs right away, and when 
we see the stacks, what i want to do is to copy & paste the error, and 
wait for the "search engine" to do its job, since at this point i 
consider myself a user, so, i try to think like one, and most of the 
time what i want, is not to ask for a problem, but to see if someone 
already has it.


Today i think there are enough data on launchpad to solve, or al least, 
give a very accurate hint about 90% of the problem a user may face 
(nova, swift, glance, maybe keystone) when they are stuck, but some 
times the search are not accurate enough for a search regarding an issue 
i know its there. so ... maybe i ended up using google search to look 
into lauchpad.


So ... first, launchpad works pretty well as a Q&A site for openstack 
projects, but at least, i feel theres no a good way to show all the 
experience is stored there to a "fresh" user, so a more than good search 
engine i think is a must, mainly because having lack of resources for 
showing an answer that is already solved to a user, lead to the user to, 
90% of the time, duplicate a question, and so .. a lot of admin work ( 
maybe deleting those, or teling the user it was already answered on THIS 
link), or the feeling of the Q&A system to be forsaken because of the 
amount of questions "unsolved".


A forum is more than ok also, because it gives the feeling of community 
and unity where the user feels confortable, but mixing that with a Q&A 
system, its a little difficult.


Making posts promoted to FAQS or post becoming GUIDES and going into the 
FAQS, and the search engine suggesting something like "Ok, if you didnt 
find your answer, maybe you are having troubles because of an 
implementation or a setup problem, why dont you go to the IMPLEMENTATION 
AND MOST IMPORTANT GUIDES to see if you can improve that and fix your 
real problem ??" is a nice to have, make the user confortable that they 
can find what they need, whitout asking for it ... in wich case, they 
actually can.


As a last note, from mercadolibre since we have a lot already tested, 
and working into production ( nova clusters, nova volumes, keystone, 
swift, glance ) we can really share our experience in the form of "THE 
DEFINITVE GUIDE TO ..." or something that, maybe doesnt actually fix a 
certain user problem, but helps them understand how things gets 
configured, and actually how they work 2gether, we can really help on 
this, but i think this guides need to be put in a place where the user 
actually knows they exists, and no like just one post on the forum, or a 
"question" on launchpad.


The official documentation is a great starting point, its has been 
greatly improved and we've always used it every time we tried a new 
openstack part of the solution, so .. nicely done there Anne.


hope this gives a little user perspective.

---
Alejandro
mercadolibre.com

On 11/30/2011 06:39 AM, Leandro Reox wrote:
I think that the main problem is that we have many places to search 
for information, but a few people giving helpful answers. A lot of 
newcomers join the forum but particular setups problems sometimes 
leads to packaging problems, bugs and we as moderators have to 
redirect the user to re-post his problem on launchpad, starting over. 
I think that we have to split packaging and developing questions vs 
implementations doubts, concept misunderstanding, etc. The main reason 
of people dropping Openstack on pre-production or testing environments 
its cause they aren't even mid experienced python developers, and they 
cant find a solution in a matter of time that they "experience with 
the product" leaves them a "good taste" to invest more time trying to 
implement it later. I read a lot of "that's and end-user question, 
etc" don't you guys forget that actually the "end-users" are Companies 
sysadmins maybe trying to deliver an real IaaS based on an Opensource 
product like Openstack. We have a huge Openstack implementation using 
almost every core product, and our environment is growing everyday 
faster than we expected, but when we approach to implement a new 
service, or integrate for example Keystone with Swift or Nova, we 
fought for days, fixing a lot of code and ended-up on a packaging 
problem, cloning the Cloudbuilders repo were the code was already 
fixed. That sensation to "cross up" docs, and blogs, and examples, and 
launchap question to get just to a test env, ends on companies leaving 
Openstack as a "possible solution". We're pretty comfortable at python 
so we love to face issues like this, but imagine a sysadmin reading 
the docs, following line but line ending up with a non-working 
environment asking himself why he did wrong, and maybe a magic "oh you 
have to chmod all this folder" was missing on the docs.
docs.openstack.org  must be the bible for 
users that want to try openstack out, the forums and the IRC to help 
"final users out", and launchpa

Re: [Openstack] Lloyd Learning Docs & website content processes

[Lloyd Dewolf]

On Wed, Nov 30, 2011 at 2:45 AM, Thierry Carrez
 wrote:> Lloyd Dewolf wrote:>> 2. Lloyd will
log Thierry "ttx" Carrez's solid openstack.org/security>> content from
http://etherpad.openstack.org/8hWNQwkWf9 to>>
http://launchpad.net/openstack-manuals , if it is not already there.>>
He will do a copyedit to the etherpad, and also upload his revision
to>> openstack-manuals. We'll take it from there based on the process
Anne>> is updating to the wiki.>> Note that the content was pushed to
www.openstack.org webmaster for> publication, without much result yet
(the idea was to quickly replace> "nothing" with "something", and then
improve incrementally).>> It would be great if we could have a more
dynamic way to review/update> the main website content (in the same
way we control the docs site> contents): it could prove useful in
further revisions.
Fantastic! We're of the same mind. And I'm so thankful for how hard
you've pushed this forward over these past months.
1. I'm trying to motivate a revision in the same spirit as what you
wrote to get online as soon as possible. From there we can look to
come together to evolve the processes and communications 2. With a
documented process with public visibility, we will now have a
foundation where people can step forward as stakeholders, and we can
quantify the time to publish. From here we can align with people's
workloads, and negotiate the priority of our items.
Thanks,Lloyd

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

Re: [Openstack] Proposal for Lorin Hochstein to join nova-core

[Sandy Walsh]

+1 ... good call!

From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Vishvananda Ishaya [vishvana...@gmail.com]
Sent: Tuesday, November 29, 2011 2:03 PM
To: openstack (openstack@lists.launchpad.net)
Subject: [Openstack] Proposal for Lorin Hochstein to join nova-core

Lorin has been a great contributor to Nova for a long time and has been 
participating heavily in reviews over the past couple of months.  I think he 
would be a great addition to nova-core.

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

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

[Openstack] dashboard don't support chinese

[ljvsss]

hi:
i am a chinese, i want use dashboard in chinese;is there anyone can help me? 
thanks



in the /var/log/apache/error.log:
[Wed Nov 30 21:31:24 2011] [error] DEBUG:django_openstack.api:admin_api 
connection created using token "ee56dcd8ff2ef8e02001" and url 
"http://192.168.1.2:8774/v1.1/1";
[Wed Nov 30 21:31:24 2011] [error] ERROR:django_openstack.forms:Nonspecific 
error while handling form
[Wed Nov 30 21:31:24 2011] [error] Traceback (most recent call last):
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstack-dashboard/django-openstack/django_openstack/forms.py", line 
177, in maybe_handle
[Wed Nov 30 21:31:24 2011] [error] return form, form.handle(request, data)
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstack-dashboard/django-openstack/django_openstack/syspanel/views/flavors.py",
 line 56, in handle
[Wed Nov 30 21:31:24 2011] [error] int(data['flavorid']))
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstack-dashboard/django-openstack/django_openstack/api.py", line 450, 
in flavor_create
[Wed Nov 30 21:31:24 2011] [error] name, int(memory), int(vcpu), int(disk), 
flavor_id))
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstackx/openstackx/admin/flavors.py", line 34, in create
[Wed Nov 30 21:31:24 2011] [error] return self._create('/admin/flavors', 
body, "flavor")
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstackx/openstackx/api/base.py", line 40, in _create
[Wed Nov 30 21:31:24 2011] [error] resp, body = 
self.api.connection.post(url, body=body)
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstackx/openstackx/api/connection.py", line 81, in post
[Wed Nov 30 21:31:24 2011] [error] return self._cs_request(url, 'POST', 
**kwargs)
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstackx/openstackx/api/connection.py", line 63, in _cs_request
[Wed Nov 30 21:31:24 2011] [error] **kwargs)
[Wed Nov 30 21:31:24 2011] [error]   File 
"/opt/openstackx/openstackx/api/connection.py", line 48, in request
[Wed Nov 30 21:31:24 2011] [error] raise exceptions.from_response(resp, 
body)
[Wed Nov 30 21:31:24 2011] [error] ApiException: Cannot create instance_type 
with name \\u6d4b\\u8bd5 and flavorid 10 (HTTP 500)
[Wed Nov 30 21:31:24 2011] [error] DEBUG:django_openstack.api:admin_api 
connection created using token "ee56dcd8ff2ef8e02001" and url 
http://192.168.1.2:8774/v1.1/1

in the /var/log/nova/nova-api.log:

(nova.exception): TRACE:   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1359, in 
flush
(nova.exception): TRACE: self._flush(objects)
(nova.exception): TRACE:   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1447, in 
_flush
(nova.exception): TRACE: raise
(nova.exception): TRACE: TypeError: exceptions must be old-style classes or 
derived from BaseException, not NoneType
(nova.exception): TRACE:
(nova.instance_types): TRACE: Traceback (most recent call last):
(nova.instance_types): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/compute/instance_types.py", line 56, in 
create
(nova.instance_types): TRACE: rxtx_cap=rxtx_cap))
(nova.instance_types): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/db/api.py", line 1334, in 
instance_type_create
(nova.instance_types): TRACE: return IMPL.instance_type_create(context, 
values)
(nova.instance_types): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 101, in 
wrapper
(nova.instance_types): TRACE: return f(*args, **kwargs)
(nova.instance_types): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 3331, in 
instance_type_create
(nova.instance_types): TRACE: raise exception.DBError(e)
(nova.instance_types): TRACE: DBError: exceptions must be old-style classes or 
derived from BaseException, not NoneType
(nova.instance_types): TRACE:
2011-11-30 21:31:24,376 ERROR nova.api.openstack [-] Caught error: Cannot 
create instance_type with name 娴.. and flavorid 10
(nova.api.openstack): TRACE: Traceback (most recent call last):
(nova.api.openstack): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/__init__.py", line 64, in 
__call__
(nova.api.openstack): TRACE: return req.get_response(self.application)
(nova.api.openstack): TRACE: return self.app(env, start_response)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.7/webob/dec.py", line 159, in __call__
2011-11-30 21:31:00,938 INFO nova.api.openstack.wsgi [-] GET 
http://192.168.1.2:8774/v1.1/1/flavors/detail?fresh=1322659860.88
2011-11-30 21:31:03,445 INFO nova.api.openstack.wsgi [-] GET 
http://192.168.1.2:8774/v1.1/1/admin/services?fresh=1322659863.39
2011-11-30 21:31:24,293 INFO nova.api.openstack.wsgi [-] POST 
http://192.168.1.2:8774/v1.1/1/admin/flavors
(nova.exception): TRACE:   File 
"/usr/lib/python2.7/dist-packages/nova/exception.py", line 78, in _wrap
(nova.exception): TRACE: return f(*args, **kwargs)
(nova.exception): TRACE:   File 
"/usr/li

Re: [Openstack] Providing packages for stable releases of OpenStack

[Soren Hansen]

2011/11/30 Mark McLoughlin :
> On Wed, 2011-11-30 at 13:07 +0100, Soren Hansen wrote:
>> I propose we start building packages from the stable branches and put
>> them in an appropriately named/labeled PPA, such as
>> nova-core/diablo-qa or nova-core/diablo-not-for-production (or
>> perhaps under openstack-stable-maint).
> I'm not convinced that distribution specific packaging is the best way
> to go about this.

That's a valid discussion.

At the moment, this is what we do for trunk commits. This is how we
generally propose that people test things out. I don't see any reason
why the mechanics for testing the stable branches should be different.
So, a discussion about these mechanisms shouldn't be isolated to the
context of the stable branch.

> I want Fedora users to be able to test out, and get involved with,
> upstream as easily as Ubuntu users are.

I'd be happy for us to build Fedora packages as well, fwiw.

> Same for other distros. The thought of getting into the game of
> maintaining this upstream packaging for multiple distros, and e.g.
> having to make sure any dependencies are packaged for these distros
> ... ugh.

Yes, this is a lot of work. This is one of the primary reasons we chose
a reference platform to begin with: Being able to focus the efforts and
actually succeed rather than trying to do everything and fail.

We had (and have) people involved in the project that could actually
take this on. If someone wants to do the same for Fedora (and other
distros), that'd be awesome.

> I don't have anything concrete to offer as an alternative, but I'd
> love to see something like devstack that runs either from git or
> tarballs and supports multiple distributions.

For production, we recommend people use packages. I think there's a lot
of value in using the same installation mechanism for QA as for
production.

> There's also the likes of jhbuild, GARGNOME, minuteman and surely more
> - perhaps we can take a leaf out of their books?

I hope I'n not stepping on anyone's toes, but I consider those things to
be relics from a time before things such as PPA's became prevalent.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Loic Dachary]

Hi,
> TL;DR summary:
> The resources needed to do that properly are bigger than you think (and
> doing that will alienate some distro packaging resources), so we'll
> either do a terrible job at it, or lose focus on the development
> release. If there is a need, it should be done as an alternate
> distribution, not inside the OpenStack project.
>

As Julien Danjou wrote, we ( OpenStack Debian GNU/Linux packagers [1]) 
discussed your mail.  We are comfortable with the idea that OpenStack focuses 
on  development and that packaging is left to the packagers involved in  each 
distribution. 

Packaging related patches from Julien Danjou were recently accepted  upstream 
(https://review.openstack.org/#dashboard,1669). This is the  kind of 
cooperation that makes it possible to maintain packages matching  the Debian 
GNU/Linux quality standard. We are confident in our ability  to provide stable 
packages in the future.

OpenStack packaging is not an easy task. It currently fits nicely in Debian 
GNU/Linux. However,  as it evolves towards a system widely used in production, 
it will face  new challenges and the communities working on packaging for each  
distribution will provide valuable input to developers. Creating a  "packaging 
team" with representatives for each distribution and electing  someone to 
represent them in the Policy Board could achieve this. 

Cheers

[1] PKG OpenStack page : https://alioth.debian.org/projects/openstack/and 
corresponding packages: 
http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
http://qa.debian.org/developer.php?packages=nova 
http://qa.debian.org/developer.php?packages=glance



<>

signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Providing packages for stable releases of OpenStack

[Soren Hansen]

2011/11/30 Thierry Carrez :
> Soren Hansen wrote:
>> I propose we start building packages from the stable branches and put
>> them in an appropriately named/labeled PPA, such as nova-core/diablo-qa
>> or nova-core/diablo-not-for-production (or perhaps under
>> openstack-stable-maint).
>> [...]
> That would work (and inside the current project). Just two remarks:
>
> * Expectations are difficult to control. Even if we use an intimidating
> name, some people will still expect this to provide more than it
> actually does. For example, people kept thinking that the "2011.3"
> release PPA would be updated, while it explicitly said it wouldn't.

The reason I want the PPA name to be scary looking is exactly because
of the lesson learned from those PPA's. It's easy to miss the
disclaimers on Launchpad (and if you happen to find the PPA info
somewhere else, there might be no disclaimer at all!). The PPA name is
the most obvious place to put this. Only if you're running someone
else's script to enable it will you never see it. Some people will
still miss it, but I think it's the best we can do.

> * I don't think that's what Vish and Monty are after -- they
> specifically mentioned the lack of a production-ready distribution
> channel as the problem that we needed to solve

Right. I agree we shouldn't do that. Someone else should. But I don't
want that to hold back the creation of the per-commit PPA for
diablo/stable which I find important for QA purposes.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Mark McLoughlin]

On Wed, 2011-11-30 at 13:07 +0100, Soren Hansen wrote:
> I think there are two distinct use cases here.

Totally agree. We need to make it as easy as possible for people to test
upstream git branches and releases.

> To me, the PPA's have always been a QA tool. I wanted people willing to
> help test OpenStack to be able to do so with as little effort as
> possible.  Building packages per-commit gave us that.
> 
> It seems incredibly counterintuitive to me that someone who wants to
> help us verify the stable branches need to jump through more hoops to do
> so. IMO we should be as least as concerned about the quality of stable
> updates as anything else. This is why I think we should be offering a
> PPA with per-commit builds from the stable branch(es).
> 
> This is completely different from a "production" PPA. I wouldn't dream
> of pointing people to the above mentioned PPA for their production
> environment.  If someone wants to offer this outside of (but perhaps in
> cooperation with) OpenStack, that'd be great. I'd be delighted to see
> companies taking this on and offering a supported OpenStack
> distribution, but I don't think this is our job for pretty much all the
> same reasons Thierry outlines.
> 
> I propose we start building packages from the stable branches and put
> them in an appropriately named/labeled PPA, such as nova-core/diablo-qa
> or nova-core/diablo-not-for-production (or perhaps under
> openstack-stable-maint).

I'm not convinced that distribution specific packaging is the best way
to go about this.

I want Fedora users to be able to test out, and get involved with,
upstream as easily as Ubuntu users are. Same for other distros. The
thought of getting into the game of maintaining this upstream packaging
for multiple distros, and e.g. having to make sure any dependencies are
packaged for these distros ... ugh.

I don't have anything concrete to offer as an alternative, but I'd love
to see something like devstack that runs either from git or tarballs and
supports multiple distributions.

Or maybe the answer is for OpenStack to publish everything to pypi and
something like devstack which uses a virtualenv.

There's also the likes of jhbuild, GARGNOME, minuteman and surely more -
perhaps we can take a leaf out of their books?

But until something like this exists, I guess you're right - throwing
out the per-commit PPAs is a backward step. However, I think Thierry's
point was about PPAs containing packaged releases (e.g. 2011.3.1)

Cheers,
Mark.


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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Thierry Carrez]

Soren Hansen wrote:
> I propose we start building packages from the stable branches and put
> them in an appropriately named/labeled PPA, such as nova-core/diablo-qa
> or nova-core/diablo-not-for-production (or perhaps under
> openstack-stable-maint).
> [...]

That would work (and inside the current project). Just two remarks:

* Expectations are difficult to control. Even if we use an intimidating
name, some people will still expect this to provide more than it
actually does. For example, people kept thinking that the "2011.3"
release PPA would be updated, while it explicitly said it wouldn't.

* I don't think that's what Vish and Monty are after -- they
specifically mentioned the lack of a production-ready distribution
channel as the problem that we needed to solve

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] How to using keystone with ldap

[Leandro Reox]

Maybe this link can help you out :
http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html

Regards

2011/11/30 DeadSun 

> Now I according to keystone/test/etc/ldap.conf.template to set ldap
> configuration in my keystone.conf
>
> But I have no idea that wich dn in ldap keystone used and there is no dn
> in keystone.ldif . How to set it?
>
> Anyone using keystone with ldap can help me?
> --
> 非淡薄无以明志，非宁静无以致远
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Providing packages for stable releases of OpenStack

[Soren Hansen]

I think there are two distinct use cases here.

To me, the PPA's have always been a QA tool. I wanted people willing to
help test OpenStack to be able to do so with as little effort as
possible.  Building packages per-commit gave us that.

It seems incredibly counterintuitive to me that someone who wants to
help us verify the stable branches need to jump through more hoops to do
so. IMO we should be as least as concerned about the quality of stable
updates as anything else. This is why I think we should be offering a
PPA with per-commit builds from the stable branch(es).

This is completely different from a "production" PPA. I wouldn't dream
of pointing people to the above mentioned PPA for their production
environment.  If someone wants to offer this outside of (but perhaps in
cooperation with) OpenStack, that'd be great. I'd be delighted to see
companies taking this on and offering a supported OpenStack
distribution, but I don't think this is our job for pretty much all the
same reasons Thierry outlines.

I propose we start building packages from the stable branches and put
them in an appropriately named/labeled PPA, such as nova-core/diablo-qa
or nova-core/diablo-not-for-production (or perhaps under
openstack-stable-maint).

At the same time, I'd like to propose that we limit ourselves to fewer
supported versions of Ubuntu (for trunk builds as well as these new,
stable branch builds).  Specifically:

 * Most recent LTS
 * Most recent release (which may or may not be an LTS)
 * Current development release

LTS's would go out of support when the subsequent LTS's first point
release is released. Non-LTS's would go out of support a month after the
subsequent release is out.

This means that right now, we'd build:

 * Lucid (until 12.04.1 is released (July 2012))
 * Oneiric (until May 2012)
 * Precise (until (probably) July 2014)

This gives people ample opportunity to upgrade to the next release and
at the same time reduces the amount of releases we need to worry about
significantly.

I think we'd get a valuable QA tool back and we'd reduce the burden of
maintaining the per-commit packages by having fewer distro versions to
worry about.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

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

Re: [Openstack] Proposal for Mark McLoughlin to join nova-core

[Soren Hansen]

2011/11/29 Vishvananda Ishaya :
> Mark is maintaining openstack for Fedora and has made some excellent 
> contributions to nova.  He has also been very prolific with reviews lately. 
> Lets add him to core and make his reviews count towards potential merges!

I'd be delighted to have Mark on the core team. +1

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

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

Re: [Openstack] Lloyd Learning Docs & website content processes

[Thierry Carrez]

Lloyd Dewolf wrote:
> 2. Lloyd will log Thierry "ttx" Carrez's solid openstack.org/security
> content from http://etherpad.openstack.org/8hWNQwkWf9 to
> http://launchpad.net/openstack-manuals , if it is not already there.
> He will do a copyedit to the etherpad, and also upload his revision to
> openstack-manuals. We'll take it from there based on the process Anne
> is updating to the wiki.

Note that the content was pushed to www.openstack.org webmaster for
publication, without much result yet (the idea was to quickly replace
"nothing" with "something", and then improve incrementally).

It would be great if we could have a more dynamic way to review/update
the main website content (in the same way we control the docs site
contents): it could prove useful in further revisions.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

[Openstack] Australian OpenStack User Group meet up Sydney

[Kavit Munshi]

Hello all,
 
Not sure if this is the right place to post this, I apologise in advance if it 
isn't. Australian OpenStack User Group is meeting for the first time in Sydney 
and I would like to extend an invitation to all who may wish to attend. Details 
follow:
 
When: Tuesday, December 13, 2011 6:30 PM to 11.30pm
Where: Harbour View Hotel
18 Lower Fort Rd, The Rocks Sydney 
Sydney
RSVP limit: 60 "Yes" RSVPs, If you plan to attend, please take a moment to 
RSVP. (You can RSVP "No" or "Yes".)
For more details, see the full listing:
 
http://aosug.openstack.org.au/events/40240882/
 
Cheers,
 
Kavit
 
 


Kavit Munshi
Solutions Director
Aptira Pty Ltd
1800 APTIRA
http://aptira.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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Mark McLoughlin]

On Wed, 2011-11-30 at 10:32 +0100, Thierry Carrez wrote:

> TL;DR summary:
> The resources needed to do that properly are bigger than you think (and
> doing that will alienate some distro packaging resources), so we'll
> either do a terrible job at it, or lose focus on the development
> release. If there is a need, it should be done as an alternate
> distribution, not inside the OpenStack project.

I think the conclusion is fair, especially if you consider that for the
OpenStack project to convincingly do binary distributions we would also
need to support a wider range distros/platforms.

But if a thriving community effort around doing producing binary
distributions of OpenStack for multiple platforms did happen to develop,
I think it would be valid to leave open the possibility of that effort
joining the project. That doesn't look terribly likely right now,
though.

Cheers,
Mark.


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

Re: [Openstack] Providing packages for stable releases of OpenStack

[Julien Danjou]

On Wed, Nov 30 2011, Thierry Carrez wrote:

Hi Thierry,

> TL;DR summary:
> The resources needed to do that properly are bigger than you think (and
> doing that will alienate some distro packaging resources), so we'll
> either do a terrible job at it, or lose focus on the development
> release. If there is a need, it should be done as an alternate
> distribution, not inside the OpenStack project.

With my Debian developer and Debian OpenStack packaging team hat on, I
must say that you're totally right about this.

All upstreams projects trying to do packaging does a terrible job at it,
because that's not something you can improvise.

It's more important to understand the needs of the packagers (e.g. a
proper setup.py) than to try to do their jobs worse.

-- 
Julien Danjou
// eNovance  http://enovance.com
// ✉ julien.dan...@enovance.com  ☎ +33 1 49 70 99 81

___
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] Cloud Computing StackExchange site proposal

[Leandro Reox]

I think that the main problem is that we have many places to search for
information, but a few people giving helpful answers. A lot of newcomers
join the forum but particular setups problems sometimes leads to packaging
problems, bugs and we as moderators have to redirect the user to re-post
his problem on launchpad, starting over. I think that we have to split
packaging and developing questions vs implementations doubts, concept
misunderstanding, etc. The main reason of people dropping Openstack on
pre-production or testing environments its cause they aren't even mid
experienced python developers, and they cant find a solution in a matter of
time that they "experience with the product" leaves them a "good taste" to
invest more time trying to implement it later. I read a lot of "that's and
end-user question, etc" don't you guys forget that actually the "end-users"
are Companies sysadmins maybe trying to deliver an real IaaS based on an
Opensource product like Openstack. We have a huge Openstack implementation
using almost every core product, and our environment is growing everyday
faster than we expected, but when we approach to implement a new service,
or integrate for example Keystone with Swift or Nova, we fought for days,
fixing a lot of code and ended-up on a packaging problem, cloning the
Cloudbuilders repo were the code was already fixed. That sensation to
"cross up" docs, and blogs, and examples, and launchap question to get just
to a test env, ends on companies leaving Openstack as a "possible
solution". We're pretty comfortable at python so we love to face issues
like this, but imagine a sysadmin reading the docs, following line but line
ending up with a non-working environment asking himself why he did wrong,
and maybe a magic "oh you have to chmod all this folder" was missing on the
docs.
docs.openstack.org must be the bible for users that want to try openstack
out, the forums and the IRC to help "final users out", and launchpad for
issuing bugs, we need to work on getting an updated documentation, getting
a "my instances get stucked on scheduling" or "i cannot ssh into instances"
should not exist with a clean and clear doc. We see a lot of people stuck
in a single node installation, or on his "devstack setup" thinking about
going back with they 3 vmware esxis nodes to create they VMs, and they
never experience the real benefits of running a true IaaS all the way.
Leaving the people "googling or blogging up" a few minutes after their
setup is not good at all for the platform, we try to write up very detailed
installation posts on the forums that are very usefull for the users, with
tips and common issues that we faced installing the product.
We're helping out everyday on the IRC and the forums to reduce the traffic
o users hitting common issues, and of course Anne you can count on us to
improve the docs, so that sysadmins loose their fears and feeling of this
being "too greeny to production" and surprise themselves like we do
everyday after 5 months later running all of our applications and our
productive infrastructure over Openstack ( +1000 phy +6000 instances )

Sorry for the long writing . My two cents!

Regards

Leandro Reox
Sr. Infrastructure Engineer at mercadolibre.com


On Tue, Nov 29, 2011 at 10:37 PM, Lloyd Dewolf wrote:

> On Tue, Nov 29, 2011 at 11:16 AM, Stefano Maffulli
>  wrote:
> > On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote:
> >> Where do I find this previous discussion?
> >
> > around here:
> > https://lists.launchpad.net/openstack/msg02169.html
> >
> > What do you think of the requirements we're gathering for the Q&A
> > system? I'd like your opinion on that as we move on.
>
> Thanks Stefano. I really like everyone reframing the discussion to
> figure out what our needs are as opposed to ... shiny!
>
> I do think stackexchange (SE) is miles [1] ahead and the only system
> that will meet the majority of our requirements.
>
> If we can get our own Area51 then it's by far the best immediate solution.
>
> I spoke to a friend at Area51, and he suggested we might have
> different results if we tried again. So I feel like this is on the
> table if we want to pursue.
>
>
> Of course, having very active SE participants (high reputation) put
> the proposal forward and committing to it carries a lot of weight.
>
> My reputation [2] is weak today, but I'm sure myself and others could
> ramp up the levels quickly over the next few months.
>
> Cheers,
> Lloyd
>
> --
> 1. See I'm getting used to United States customary units,
> http://en.wikipedia.org/wiki/Customary_units
> 2. http://stackexchange.com/users/25765?tab=accounts
>
> ___
> 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 : o

[Openstack] Providing packages for stable releases of OpenStack

[Thierry Carrez]

Hi everyone,

Yesterday, Vish and Monty raised the need for the OpenStack project to
provide a maintained set of packages for stable versions of OpenStack on
yet-unsupported versions of distributions.

TL;DR summary:
The resources needed to do that properly are bigger than you think (and
doing that will alienate some distro packaging resources), so we'll
either do a terrible job at it, or lose focus on the development
release. If there is a need, it should be done as an alternate
distribution, not inside the OpenStack project.

Long version:

First let me agree on the need. A very good, very stable distribution of
OpenStack on stable versions of distributions (a.k.a. stable/diablo on
Lucid) is definitely needed. The 2011.3 release PPA does not provide
that and bears false expectations, so it should die a painful death, and
quickly.

That doesn't mean we, as an upstream project, should necessarily enter
the distribution business to cure the deficiencies of their model. I
think distributions are separate projects with a separate skillset -- if
we try to do it we'll dilute our effort *and* alienate the existing
distributions. Those should compete between them, not with us.

Providing a production-ready, maintained distribution channel is more
than just "building packages for Lucid", unfortunately. That is good for
test packages (like our trunk PPA). A production channel needs to be
always installable and upgradeable (unlike our trunk PPAs that are
routinely broken). Any backport in there needs to be watched for
security updates. You commit to maintain it for a given length in time.

Our resources are limited and the skillset is particular. Last month
Monty was arguing we should not provide packages as project deliverables
at all, for the precise reason that we could not gate on packaging with
only a few people with that skill (he apparently changed his mind ?).
Resources are limited, so where do we stop ? Where does "user
convenience" end ? What distributions and series should we support ?
What versions of OpenStack ? How long do we support them ? Do we support
Diablo on OpenSUSE 10.1 for 5 years ? For every combination added, the
resources are spread even thinner.

We used to limit the scope of the OpenStack project to producing code,
and letting downstream distributions do what they do best, i.e.
integrating and distributing. We only provided test/evaluation PPAs for
user convenience, since the cost/benefit ratio was reasonable. Everyone
was at his place, happy and collaborating on packaging. If we do
production PPAs, we create competition and conflicts. Monty says "I do
not care about conflicts with distros" -- but that's a sure way of
losing distro packagers help. For example, the current packaging team
working on Ubuntu packages is about 6 people, 4 of which happen to work
for the distro.

My point is that if there is such a need for "OpenStack on Lucid", then
a new distribution (99% based on Lucid) will address that. It does not
have to be "OpenStack" itself. My fear is that we would do a very bad
job at this, and it would reflect on the project as a whole. Branding
ours "official" won't make it better than "unofficial" ones, but will
alienate distros. I prefer this to be done separately: that ensures that
OpenStack remains focused on code and keeps collaborating with every
distro on an equal footing. And if you're so interested by this, you
could be in both projects.

A last remark: we are already doing this. And we are not being
successful with it. Swift "last release" PPA [1] provides a decent
production channel, updated roughly every month, for running stable
Swift on stable Ubuntu. If it was a wild success and everyone was
collaborating on packaging work for it... it could prove me wrong. But
for some reason, nobody (including Rackspace) is using that. They are
using their own packaging and their own repositories. Why ? And what
makes you think that generalizing that idea to every project would
suddenly make it work ?

[1] https://launchpad.net/~swift-core/+archive/release

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] development document: how to write a filter module to swift

[Razique Mahroua]

Thanks for that document !We'll see how/ where integrate it into Swift documentation.Regards,Razique
Nuage & Co - Razique Mahroua razique.mahr...@gmail.com

Le 30 nov. 2011 à 00:29, pf shineyear a écrit :http://wiki.openstack.org/development/swift/filterit's not perfect but i think this can help some people at the beginning.

if someone can help me to move this document to Swift Developer Documentation

i will say thank you. 
___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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