date:20111124

2011/11/24 Lloyd Dewolf :
> On Thu, Nov 24, 2011 at 8:03 AM, Soren Hansen 
> wrote:
> 2011/11/24 Lloyd Dewolf :
>>> A. As my former boss, as of this week, Matt Mullenweg [1] would so
>>> often remind us, "don't be so negative" -- he literally reminded my
>>> VIP Services sub-team of that last week -- it's natural when you are
>>> deep in the trenches. Instead use "Words that Work". [2]
>> This is not marketing material. It's not meant to sell anything or
>> convince anyone of anything. It's supposed to accurately convey what
>> this team is and what it isn't. If you want to rephrase it, knock
>> yourself out, but being unambiguous trumps "sounding good". You don't
>> see legislation being rephrased to make it sound better either :)
> Hi Soren,

Hello.

> I may be misreading, but both your response and part of ttx's reads to
> me as a straw man argument -- you give back a single unrelated phrase
> as opposed to demonstrating the value of all three phrases.

I have no idea what you're saying here?

You complain that the text in question sounds negative. I point out that
its purpose doesn't warrant putting lots of effort into phrasing it any
differently just for the sake of it and give another example of a type
of text where the same holds true.  I then move on to suggest that if
you think it's important, you go for it. I'm not sure what it is that
you're referring to as "unrelated"?

> I'm frustrating by your mention of "marketing material" and ttx's
> posslbe fallback of "technical page". What is the context of that?

The context? I'm again not sure what you're asking. As I said, the page
does not exist to convince anyone of anything. It's not a piece of
marketing or recruitment material. Its purpose is to explain what has
been agreed.

> If I were to guess where you are coming from, which I hate doing, my
> response would good communication is accessible to many audiences,
> encourages participation (is positive!), translates well (hard!), and
> still meets the needs of us pendantic fools.

To be blunt, I think that's a waste of time. As long as it accurately
explains what it's meant to explain, it can be harsh, negative,
humourous, sad, happy, prosaic, poetic, whatever. I don't care, as long
as it's not at the expense of unambiguity.

> Second, unambiguous? That doesn't ring true to me. One sentence, the
> first sentence, is about what the list is, followed by a whole
> paragraph on what it isn't? Maybe, let's start with fleshing out that
> first paragraph.

My point is that if you want to rephrase it because you find it too
negative, that's fine, *as long as it doesn't negatively affect its
accuracy/unambiguity*. If it's already ambiguous, please explain how, so
that we can address it.

> Three times a lady? [1]

?!?

> I think there is an opportunity to be concise, eliminate the seeding
> of fear of immaturity and unprofessionalism, (translate better), and
> get on with focusing that OpenStack has dedicated, profession
> participants.

Great. Go for it.

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

> How can we get your fantastic expertises humoring me by exploring
> solutions rather than throwing down spike strips. Nothing is worse
> than the new guy also offering "solutions" [3] when the relevant
> issues have already been well considered, often multiple times, and
> where the participants likely already have some other solutions that
> might be voted up by the context of additional considerations.

So far, this conversation hasn't been about the contents the wiki page
in question. It's been about its language. I'm at least as much of a
language nut as the next guy, but I don't get paid to be a copy writer.
I can't justify spending time making sure our policy documents are
phrased in a specific way.

Don't get me wrong. I think there are lots and lots and lots of text
under this project's purview where these concerns are paramount. That
page just isn't it.

-- 
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] Mailing list archive delay -was- Re: Vulnerability Management concerns: negativity & count

On Thu, Nov 24, 2011 at 2:12 PM, Chmouel Boudjnah  wrote:
> Hi Llyod,
>
>> Oh man mail-archive.com also has some delay, but not as bad. The
>> message that I'm responding to from you, ttx, isn't there yet either,
>> and I double checked that you didn't directly cc me. We can't win at
>
> I am wondering, why do you need near instant mail archiving if they
> are coming to your mailbox?

Good question.

I think hours behind is pretty far from near instant, but I get your point.

Cool URIs don't change [1] -- hopes reverted to a web developer geek,
but I'm only have kicking.

I want to be able to reference, log, and/or *share* the permalink. My
need is being able to finish. Finish whatever, now, so I free my mind
[2], and move on.

I want to be able to check the status of a thread, or quickly look
what is going on without having to log in to email, publicly.

Aside, if it is working as expected, yuck, then it should display a
message informing about the possible delay. And if I was choosy add
some CSS styling of the header while they are at it.

Thanks for asking,
Lloyd

1. http://www.w3.org/Provider/Style/URI
2. http://www.youtube.com/watch?v=9tIYpvlQP_s Yes, I'm already sorry
for doing that to you!

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

Re: [Openstack] Mailing list archive delay -was- Re: Vulnerability Management concerns: negativity & count

2011-11-24 Thread Chmouel Boudjnah

Hi Llyod,

> Oh man mail-archive.com also has some delay, but not as bad. The
> message that I'm responding to from you, ttx, isn't there yet either,
> and I double checked that you didn't directly cc me. We can't win at

I am wondering, why do you need near instant mail archiving if they
are coming to your mailbox?

Chmouel.

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

Re: [Openstack] Mailing list archive delay -was- Re: Vulnerability Management concerns: negativity & count

On Thu, Nov 24, 2011 at 12:03 PM, Thierry Carrez  wrote:
> Lloyd Dewolf wrote:
>> On Thu, Nov 24, 2011 at 8:57 AM, Lloyd Dewolf  wrote:
>>>
>>> 1. I need a list archive that is up to date!
>>
>> Has someone submitted a bug with lists.launchpad about
>> https://lists.launchpad.net/openstack/ being delayed? This will drive
>> me batty before long.
>> [...]
>> Someone must already have a read-only archive -- make it public please? ;-)
>
> Just use http://www.mail-archive.com/openstack@lists.launchpad.net/

Oh man mail-archive.com also has some delay, but not as bad. The
message that I'm responding to from you, ttx, isn't there yet either,
and I double checked that you didn't directly cc me. We can't win at
this, the servers ate too much American Thanksgiving!

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

Hi ttx,

Very good points.

The gating factor is triage, and this is what we first have to build
our, OpenStack's, Vulnerability Management solution around.

If the needed resources are not yet available let's fully understand that.

If distros and other OpenStack builders are not able to provide
direct, accessible, 24/7 contact for coordinated disclosure in, say,
the emergence of a zero day attack, then we can't do much more for
them than hope they are not compromised before they can respond to the
public disclosure.

Prepare for the worst, hope for the best.


I think we will soon be surprised by how much resources we, OpenStack,
have available, and who you will be able to access at any time of day
[1] if the issue warrants it -- code forbid!

Just think it has takes these last many months (and for many, some
more months) for the most recent cohorts to explore the code, play
with the experience, and start to investigate solutions. 2012 is going
to be a huge year for OpenStack!


Aside, I don't like your amateur vs professional angle for a couple of
reasons. For starters, my skimming through the archives, wiki, and
code trees, it was clear before I started that you are anything but an
amateur.

Further, passion is one of the tools that the amateur, the maker, has
to bring more fully to bear than the profession -- I <3 passion!


It sounds like from your experiences you are all too familiar that
until someone (you!) puts something in place, there is much dragging
of feet, and once it is place everyone is a critic ;-)

Thanks for your patience with me, and thoughtful explanations. Thanks
for taking so much of your day today to engage me on this issue -- I
can't wait to some day not-to-far-away meet you.


After this long weekend I'll see if I can't bend some of your PPB
ears, and see us iterate to the next solution. I trust you will
continue to be a passionate participant!


Cheers,
Lloyd


1. The sun is always shining on an international project!

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

Re: [Openstack] Mailing list archive delay -was- Re: Vulnerability Management concerns: negativity & count

Lloyd Dewolf wrote:
> On Thu, Nov 24, 2011 at 8:57 AM, Lloyd Dewolf  wrote:
>>
>> 1. I need a list archive that is up to date!
> 
> Has someone submitted a bug with lists.launchpad about
> https://lists.launchpad.net/openstack/ being delayed? This will drive
> me batty before long.
> [...]
> Someone must already have a read-only archive -- make it public please? ;-)

Just use http://www.mail-archive.com/openstack@lists.launchpad.net/

-- 
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] Vulnerability Management concerns: negativity & count

Lloyd Dewolf wrote:
> On Thu, Nov 24, 2011 at 7:30 AM, Thierry Carrez  wrote:
>> I want to turn the question around: why do *you* want more ?
> I don't think you are implying it, but just to snuff out any though.
> I'm completely comfortable speaking for Piston Cloud that if by some
> craziness adjusting this policy to better serve the project required
> that Piston Cloud *never* was a member of the vulnerabiliity group I'm
> certain I can get sign off on that.

I'm not implying anything. My question is why do you want more. Why is 3
not enough. From the rest of your (long) reply I suspect that you want
more in order to have immediate, 24x7 coverage of security issues
reported in openstack software.

> I feel like you might have accidently skipped in your quoting at least
> one of my question. What is the successful three person, email-based,
> implimentation this is based on?

It's based on my own experience managing a Linux distribution security
team that used to have some success
(http://www.gentoo.org/security/en/index.xml). And on that case the
minimum necessary number was actually (and still is) 2 people.

> [...]
> The process to come up with this list might look like:
> 1. Revisit who are the top candidate volunteers2. Put their "usual"
> work day on a calendar including *weekends*. No healthy person works
> the same 8hrs seven days a week, so no one better claim they do ;-)
> 2.a Only allow each candidate volunteer to identify 8hrs per day.
> 
> Come up with the minimum list with density of at least three at each hour.

I agree with you that such coverage requires way more than 3 people.
Nobody in the current vulnerability management team is covering
weekends. We rely on core project developers to implement and review the
fixes, and those people don't work on weekends either. We coordinate the
critical fixes and disclosure with multiple downstream distributions,
which takes days -- and those don't work on weekends either.

My understanding is that you find the current team setup not good
enough. I suggest you come up with a new improved proposal, together
with the resources that would make it happen. I'm perfectly fine to let
my amateur community-based team be taken over by professionals, if
that's the wish of the PPB. Doing this was never part of my job description.

The setup we proposed was (1) to have something (one month ago, we had
*nothing*) and (2) to be realistic in relation with the rest of our
current development processes (what's the point in covering weekends if
you have to wait for week days to produce a fix or coordinate the
disclosure).

-- 
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] After each meeting -was- Re: [QA] Team IRC meeting moved back one hour

2011-11-24 Thread Jay Pipes

For the record, I usually try to put together some sort of summary, as
shown here:

https://lists.launchpad.net/openstack/msg05517.html

Just didn't get around to it yesterday.

Cheers,
-jay

On Thu, Nov 24, 2011 at 9:48 AM, Lloyd Dewolf  wrote:
> It would be dope if after each meeting there was a post to the list
> with only the highlights (bait!), and a link to the fully summary, and
> the log.
>
>
> On Wed, Nov 23, 2011 at 8:44 AM, Jay Pipes  wrote:
>> Thank you, Thierry :)
>>
>> On Wed, Nov 23, 2011 at 10:10 AM, Thierry Carrez  
>> wrote:
>>> Jay Pipes wrote:
 Hi QAers!

 So, to make West Coast US folks a little happier, we are moving the
 regular Wednesday IRC meeting for the QA team back one hour:

 9am PST
 12pm EST
 5pm UTC
>>>
>>> Updated the gCal and http://wiki.openstack.org/Meetings
>>>
>>> --
>>> Thierry Carrez (ttx)
>>> Release Manager, OpenStack
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

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

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

[Openstack] Mailing list archive delay -was- Re: Vulnerability Management concerns: negativity & count

On Thu, Nov 24, 2011 at 8:57 AM, Lloyd Dewolf  wrote:
>
> 1. I need a list archive that is up to date!

Has someone submitted a bug with lists.launchpad about
https://lists.launchpad.net/openstack/ being delayed? This will drive
me batty before long.

I haven't submitted a bug related to launchpad since... 2006,
https://bugs.launchpad.net/launchpad/+bug/42644 , and it's been about
as long since I last really got to enjoy Canonical's Infrastructure.

I confirmed it's not my connection, computer or browser:
https://skitch.com/lloydbudd/gmgtt/confirmation-lists.launchpad.net-openstack-stale
.

Is this a feature of lists.launchpad then? ;-)

Someone must already have a read-only archive -- make it public please? ;-)

Any advice on reporting this issue? Anyone know from experience how
long the delay is?

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] After each meeting -was- Re: [QA] Team IRC meeting moved back one hour

On Thu, Nov 24, 2011 at 7:34 AM, Thierry Carrez  wrote:
> Lloyd Dewolf wrote:
>> It would be dope if after each meeting there was a post to the list
>> with only the highlights (bait!), and a link to the fully summary, and
>> the log.
>
> Sounds great... Are you volunteering ?

I'm ramping up my participation as quickly as possible though I'm also
pragmatic. OpenStack will enjoy my participation for years, if I
ensure that Piston Cloud is successful.

> Kidding aside, the main reason we are not doing that is that redacting
> highlights takes time and we all have other more pressing things to
> do... People who care enough usually read the summaries and logs, and
> the additional value of redacted summaries is not enough.

I disagree with what you wrote, but suspect we actually agree on the concepts.

I involuntary shudder [1] when I read "we all have other more pressing
thing". On the other hand saying, "this didn't happen today, because
this specific priority *unexpected* needed to be done" is completely
understandable. Do you agree?

The last part of any meeting I participate in will always be an
attempt to articulate at least what the themes where. Sharing that is
all I'm asking, and providing the links, so we are regularly
encouraged to participate ;-)

Unless someone loves being the chair, I enjoy when the chair rotates
for each meeting.

Thank you,
Lloyd

--
1. Hmm, are all shudders involuntary?

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

Re: [Openstack] Keystone API Design Issues

2011-11-24 Thread Ziad Sawalha

Hi Paul - thank you for the good feedback.

I'm going to address your points individually below, but before I want to
to set some context and address some of your broader concerns.

The 2.0 API for Keystone is released and multiple implementers are already
working on it (in fact, we at Rackspace have just released ours). There
were many calls for comments on the API throughout the year, but we locked
down the spec finally in September to try to deliver an implementation in
time for Diablo.

The focus for Essex, as voiced by the community in the summit in Boston,
is on maturing the OpenStack implementation and adding some extensions
like role based access control (RBAC). Therefore, there is not much of a
discussion going right now about the next version of the API (although
this could be it starting!). So the silence is not the symptom of a closed
discussion, but the absence of one at this time.

See below...

On 11/23/11 4:21 PM, "Paul Querna"  wrote:

>Hello Y'all,
>
>I'm writing the list with some of my thoughts as an user of the
>Keystone 2.0 API.
>
>Generally, I believe the API is too complicated, has too many 'hacks'
>for backwards compatibility put into the wrong places, and pushes too
>much logic into consumers and service implementers.
>
>My experience with Keystone comes from several separate projects using
>the API:
>
>1) A new Rackspace Service, not yet publicly announced, which uses the
>Keystone API to validate tokens. (We wrote our own internal library in
>Node.js for interacting with Keystone)
>
>2) In Apache Libcloud, I implemented support for the Keystone API,
>specifically to get tokens for a service like OpenStack Nova,
>Rackspace Cloud Servers, Load Balancers or Cloud Files.
>
>3) I also work with the team implementing a new Rackspace Control
>Panel project. This project uses Libcloud for it's interaction with
>Keystone, but has several more use cases beyond simple Username and
>API Key validation.
>
>
>Part 1: Specific Issues
>
>A) The Token Validation API is fail deadly, because of support for
>Tokens without a Tenant ID scope:
>
>  
>validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations
>-d1e1356.html>
>
>When you are implementing a service that needs to validates tokens,
>you pass in the tenant scope as the belongsTo parameter with the
>Tenant ID.  However, this parameter is optional.  If a malicious
>Tenant Id is passed in, for example if a service doesn't perform
>sufficient validation, like letting a user pass in a & into the
>tenantId, a token is considered valid for _all_ contexts.  Now, in
>theory, you should be looking at the roles provided under the user,
>and the examples given in the OpenStack documentation echo back the
>validated Tentant ID to you, however in practice, and as seen in
>production environments, this response body includes a default
>identity role, and does not echo back the validated Tenant ID.

Tokens without scope are supported by the API - we had requests with use
cases for it - but it is not required. In fact, the Rackspace
implementation always returns a scoped token.

This is one of those examples I think you refer to where we had to keep
the spec loose enough to meet the needs of all parties in the discussion
and hit the dates we were aiming for. But we are always working on
improving things and if you have a suggestion for how to improve this one
we're listening. We accept contributions voraciously and have been know to
implement other peoples good ideas even when they don't come with code :-)

In fact, I know at least one $BigCo that is working on a proposal to
improve this. But as a user, your input will be weighted highly so feel
free to email, blueprint, or submit a proposal.

>
>
>B) Requiring consumers to pass Tenant IDs around is not a common
>pattern in other cloud APIs.  A consumer was already keeping track of
>their username, apikey, and temporal token, and now they essentially
>need to keep another piece of information around, the Tenant ID.
>This seems like it is an unneeded variable.  For example, Amazon
>implements AWS Identity and Access Management by changing the API key
>& secret that is used against the API depending on the role of the
>account -- this hides the abstraction away from both client libraries
>and validating services -- they still just care about the API key and
>secret, and do not need to pass around an extra Tenant ID.

This sounds like a concern with the OpenStack implementation and not the
API spec.

The Keystone API spec doesn't require consumers to pass Tenant IDs around.
It even allows for a full implementation without the consumer having to
know or manage their tenant IDs. We've done that at Rackspace where you
auth with your credentials, get URLs back for the services you have, and
then you call those URLs using your token. Granted, the tenant ID (a.k.a
account numbers) is embedded in the URL, but this comes fr

Re: [Openstack] Vulnerability Management concerns: negativity & count

Sorry, I don't know why Chrome Canary is losing the vertical spacing
between paragraphs. He's been a bad birdy lately, seen
http://code.google.com/p/chromium/issues/detail?id=104771 ? That's my
favorite bug report since
https://github.com/MrMEEE/bumblebee/issues/123 .

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

On Thu, Nov 24, 2011 at 7:30 AM, Thierry Carrez  wrote:
> I want to turn the question around: why do *you* want more ?
I don't think you are implying it, but just to snuff out any though.
I'm completely comfortable speaking for Piston Cloud that if by some
craziness adjusting this policy to better serve the project required
that Piston Cloud *never* was a member of the vulnerabiliity group I'm
certain I can get sign off on that.
I feel like you might have accidently skipped in your quoting at least
one of my question. What is the successful three person, email-based,
implimentation this is based on?
Actually really though that question was only for my own interest, and
doesn't matter. The argument ends at three humans do not *physically*
have the coverage to *insure* timely *initial* response, particularly
from a sophisticated bad actor.
There might not be as many reports as I think, but the issues will
have the potential of being magnitudes more complex than Firefox
issues. And it will only takes one, the first disaster to set back
OpenStack, and potentially kill off a member organizations ability to
participate in OpenStack  -- I hadn't considered that previously, it
is dramatic, but thinking in it, we are not taking little leagues
here, and I imagine a lot of people have put themselves on the line to
get behind OpenStack.
So assuming we want to focus on it being hard coded at a number, what
would the number be, and what would the list look like if the
requirement is: three -- the magic number -- members "usually"
covering each hour including weekends.

The process to come up with this list might look like:
1. Revisit who are the top candidate volunteers2. Put their "usual"
work day on a calendar including *weekends*. No healthy person works
the same 8hrs seven days a week, so no one better claim they do ;-)
2.a Only allow each candidate volunteer to identify 8hrs per day.

Come up with the minimum list with density of at least three at each hour.
Thank 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] Vulnerability Management concerns: negativity & count

On Thu, Nov 24, 2011 at 8:03 AM, Soren Hansen 
wrote:> 2011/11/24 Lloyd Dewolf :>> A. As my
former boss, as of this week, Matt Mullenweg [1] would so>> often
remind us, "don't be so negative" -- he literally reminded my>> VIP
Services sub-team of that last week -- it's natural when you are>>
deep in the trenches. Instead use "Words that Work". [2]>> This is not
marketing material. It's not meant to sell anything or> convince
anyone of anything. It's supposed to accurately convey what> this team
is and what it isn't. If you want to rephrase it, knock> yourself out,
but being unambiguous trumps "sounding good". You don't> see
legislation being rephrased to make it sound better either :)
Hi Soren,
I may be misreading, but both your response and part of ttx's reads to
me as a straw man argument -- you give back a single unrelated phrase
as opposed to demonstrating the value of all three phrases.
I'm frustrating by your mention of "marketing material" and ttx's
posslbe fallback of "technical page". What is the context of that? If
I were to guess where you are coming from, which I hate doing, my
response would good communication is accessible to many audiences,
encourages participation (is positive!), translates well (hard!), and
still meets the needs of us pendantic fools. As I said I'm very
sensitive to all communications around security, and always have been.
Second, unambiguous? That doesn't ring true to me. One sentence, the
first sentence, is about what the list is, followed by a whole
paragraph on what it isn't? Maybe, let's start with fleshing out that
first paragraph.

Three times a lady? [1] I think there is an opportunity to be concise,
eliminate the seeding of fear of immaturity and unprofessionalism,
(translate better), and get on with focusing that OpenStack has
dedicated, profession participants.

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.

How can we get your fantastic expertises humoring me by exploring
solutions rather than throwing down spike strips. Nothing is worse
than the new guy also offering "solutions" [3] when the relevant
issues have already been well considered, often multiple times, and
where the participants likely already have some other solutions that
might be voted up by the context of additional considerations.

Sure though I've thought on this and will make a proposal... another
email to follow shortly.

Thank you,Lloyd
1. I need a list archive that is up to date!2. The opportunity to be
absurd was too tempting. I need to get some sleep.
3. I will always try to articulate a problem first and not provide
solutions much to your possible frustration. Once we have a solution
in our head, we often find the problem to match the solution. By
separating out the possible solutions we will write a stronger report,
create space for alternate solution proposals by other people, and
hopefully reduce the subconscious repulsion experienced by the people
who worked so hard on the current solutions. For my favorite
presentation of this read Chapter 9 “Problems and Solutions” in The
Myths of Innovation by Scott Berkun.

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

2011/11/24 Lloyd Dewolf :
> A. As my former boss, as of this week, Matt Mullenweg [1] would so
> often remind us, "don't be so negative" -- he literally reminded my
> VIP Services sub-team of that last week -- it's natural when you are
> deep in the trenches. Instead use "Words that Work". [2]

This is not marketing material. It's not meant to sell anything or
convince anyone of anything. It's supposed to accurately convey what
this team is and what it isn't. If you want to rephrase it, knock
yourself out, but being unambiguous trumps "sounding good". You don't
see legislation being rephrased to make it sound better either :)

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

[Openstack] workshop ?

2011-11-24 Thread Zeeshan Ali Shah

Hi is there any planned Workshop/Training in EU ?

Zeeshan
___
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] Vulnerability Management concerns: negativity & count

2011/11/24 Thierry Carrez :
> This is actually linked to the next section. If you limit the numbers of
> members in a vulnerability handling team, you create resentment with
> those members or companies that are not part of it. The phrasing is
> there to reassure non-members that there is no advantage for being "in".

Exactly. We're bootstrapping the team and the process. We (as a project)
don't necessarily know the people stepping forward to take on a
membership of this team, so it's important that the responsibilities (of
which there are many) and privileges (of which there are really none)
are clear. I see no reason not to be clear about the ground rules up
front, and make it explicit that it's not an "early warning list".  It's
a response team.

-- 
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] After each meeting -was- Re: [QA] Team IRC meeting moved back one hour

Lloyd Dewolf wrote:
> It would be dope if after each meeting there was a post to the list
> with only the highlights (bait!), and a link to the fully summary, and
> the log.

Sounds great... Are you volunteering ?

Kidding aside, the main reason we are not doing that is that redacting
highlights takes time and we all have other more pressing things to
do... People who care enough usually read the summaries and logs, and
the additional value of redacted summaries is not enough.

-- 
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] Vulnerability Management concerns: negativity & count

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

You won't find so much negativity there.

> What I hear when I read that is that we have the most serious issues
> of professionalism among us -- crazy, embarrassing issues! That I've
> just jumped into a nest of vipers -- Josh and Chris didn't say
> anything about my impending death when they got me to join!
> Thankfully, I very much doubt this is the reality! -- it wasn't at the
> meetup I was at last night.
> 
> So is there a non-negative way of articulating this? *once*

This is actually linked to the next section. If you limit the numbers of
members in a vulnerability handling team, you create resentment with
those members or companies that are not part of it. The phrasing is
there to reassure non-members that there is no advantage for being "in".
The members will not abuse the fact that they are privileged. This is a
technical page oriented towards team members. I prefer to call a "cat" a
"cat", rather than "feline predator" because its less negative.

> B. Maximum of 3 people. This may have caused my heart to skip a beat.
> Is there a reference implementation of this? Who's successes are we
> emulating?
> 
> Having spent 2 years on Mozilla's private security list in a former
> life, and five years being party to every WordPress security issue [3]
> only 3 people is madness.
> [...]

The Vulnerability management team is all about managing disclosure. The
members control which groups to include in the "know", in order to give
a timely response while limiting the risk of accidental disclosure.

The number of "3" is not about the number of people that will know about
the vulnerability. It's about the number of people who are tasked to
deal with it in the first place. For example, the first thing we do
(after confirming the flaw) is include the PTL of the affected project.

Increasing this number to include "anyone that demonstrated value and
professionalism" does not help. You don't need people that just like to
be kept in the loop. You don't need bystanders that will handle one
vulnerability every year. You need people actively participating and
committed to owning the process of private vulnerability fixing.

As soon as you say "anyone that demonstrated value and professionalism"
you are talking about dozens of people. And with them comes an increased
risk of leakage. There is no way to keep a secret in a group of more
than 6 people. So you basically assume that the vulnerability is almost
public.

In every project with a large first-line group handling incoming issues,
you end up having reporters submitting their most serious
vulnerabilities to a handful of people they know, rather than sending to
the list. That's what I want to avoid. Having a group too large to be
used for anything serious. That's the drawback of "more".

I want to turn the question around: why do *you* want more ?

> [...]
> Even ignoring that, do three people alone have the stamina to
> investigate and deal with *all* the false reports. ;-)

There might not be as many reports as you'd think. This is not Wordpress
or Mozilla. If we can't keep up with the flow, we'll add new members for
sure.

-- 
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] Swift 1.4.4 released

2011-11-24 Thread John Dickinson

Happy Thanksgiving (to those in the US)!

Today, I'm thankful that I can announce that swift 1.4.4 is officially
released. This release has quite a few good changes in it, and, as always, this
is a stable, production-ready release. You can upgrade from previous versions
of swift to this version with no downtime. The full changelog can be found
below:

https://github.com/openstack/swift/blob/457b7441953687fc56977ce7664be94fab8fa4f3/CHANGELOG

I'd like to highlight a few of the biggest changes in this release.

We have added expiring objects support to swift. Expiring objects allows a user
to set an expire time on an object and ensure that it is inaccessible after
that time and it will be automatically deleted by the system. The feature is
documented at http://swift.openstack.org/overview_expiring_objects.html.

We have fixed several customer-facing bugs in this release. A bug where certain
objects could not be used with the COPY command has been fixed. Also an error
in the server-side calculation of etags for large objects has been fixed. For
deployers, we have added man pages and added new reports to swift-recon.
Importantly, we have fixed a few bugs related to a memory leak in the proxy
server under certain conditions.

I would recommend that all deployers upgrade to swift 1.4.4, if possible.

For more detail on this release, see the swift 1.4.4 release page on Launchpad
(https://launchpad.net/swift/essex/1.4.4). The official Openstack PPA for this
release is https://launchpad.net/~swift-core/+archive/release.

As always, we welcome all input and patches. The swift code is found on github
at https://github.com/openstack/swift and we'd be happy to answer questions on
the openstack mailing list or on IRC (#openstack on freenode).

--John Dickinson
Openstack swift Project Technical Lead

smime.p7s
Description: S/MIME cryptographic 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

[Openstack] After each meeting -was- Re: [QA] Team IRC meeting moved back one hour

It would be dope if after each meeting there was a post to the list
with only the highlights (bait!), and a link to the fully summary, and
the log.


On Wed, Nov 23, 2011 at 8:44 AM, Jay Pipes  wrote:
> Thank you, Thierry :)
>
> On Wed, Nov 23, 2011 at 10:10 AM, Thierry Carrez  
> wrote:
>> Jay Pipes wrote:
>>> Hi QAers!
>>>
>>> So, to make West Coast US folks a little happier, we are moving the
>>> regular Wednesday IRC meeting for the QA team back one hour:
>>>
>>> 9am PST
>>> 12pm EST
>>> 5pm UTC
>>
>> Updated the gCal and http://wiki.openstack.org/Meetings
>>
>> --
>> Thierry Carrez (ttx)
>> Release Manager, OpenStack
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

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

[Openstack] Vulnerability Management concerns: negativity & count

ttx's update on the SEO, information architecture, and technical
documentation issue(s) described in my email "OpenStack Security
Group", 23 Nov 2011,
https://lists.launchpad.net/openstack/msg05646.html has made my day.
With the holiday today in the US, and knowing that our US peers would
likely need to provide coverage for them, I didn't expect momentum on
this until some time next week. Thank you Thierry!

So with that ball excellerating thanks to Thierry's, and I'm sure
other's hard work, I've turned my attention to explore this emotive
topic further -- again, once the external optics and high level best
practices look good to me, or more likely I understand the thinking
behind the equally excellent OpenStack practices, I'll be trying to
stay away from security -- I've already shortened my life too much
from past experiences :-D

So looking at the actual Vulnerability Management team document,
http://wiki.openstack.org/VulnerabilityManagement , I see the result
of thoughtful, fantastic collaboration!


I do have a couple of serious concerns:

A. As my former boss, as of this week, Matt Mullenweg [1] would so
often remind us, "don't be so negative" -- he literally reminded my
VIP Services sub-team of that last week -- it's natural when you are
deep in the trenches. Instead use "Words that Work". [2]

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"

What I hear when I read that is that we have the most serious issues
of professionalism among us -- crazy, embarrassing issues! That I've
just jumped into a nest of vipers -- Josh and Chris didn't say
anything about my impending death when they got me to join!
Thankfully, I very much doubt this is the reality! -- it wasn't at the
meetup I was at last night.

So is there a non-negative way of articulating this? *once*


A.2 If somehow this language reflects demonstrated reality, we need to
get the relevant parties *physical* in a room this week, and deal with
this! Let's also remember that the most likely "original reporter" is
one of us relevant parties.



B. Maximum of 3 people. This may have caused my heart to skip a beat.
Is there a reference implementation of this? Who's successes are we
emulating?

Having spent 2 years on Mozilla's private security list in a former
life, and five years being party to every WordPress security issue [3]
only 3 people is madness.

Mozilla private security list was (assume still is) open to membership
to anyone that demonstrated value and professionalism. I consider
Daniel Veditz's [1] Mozilla security team a model security citizen,
and consistent and very successful for at least the eight years I've
been been paying attention. [5]


B.2 But let's assume that there is some real reason to hard code the
membership count. Five years working with Automattic's Technical
Operations Lead Barry Abrahamson [5] -- the best in the business --
has impressed upon me through his leadership and actions It some cases
it can only take a few hours of lack of communication to turn a grey
hat [6] into a bad actor. So let's assume all three members are
available at the time the report comes in, one person owns
communication and collaboration with the reporter, and we hope that
both of the other two [7] have the expertise in the vector area to
rapidly assess the impact and pervasiveness, and now you've lost
another person, who works on IMing, email and phoning the area
exports; one is the loneliest number.

I don't want to give anyone my nightmares, but it is seasonal, let's
not forget that a sophisticated black hat is most likely to launch an
attack during a holiday, or when he knows another crisis is being
dealt with. You think only having three people gives favorable odds
that they are going to be available to respond to the first vender who
is investigating this with their panicked business-on--the-line
customer?

Even ignoring that, do three people alone have the stamina to
investigate and deal with *all* the false reports. ;-)



Sorry, if I'm a little worked up here. Too many exclamation marks,
right? I'm just so excited to be working with you guys and gals, and
want us all to really shine. Once again, I'm very impressed with the
Vulnerability Management document, and once these issues are
addressed, we'll be crushing it!


If I should be discussing this elsewhere please let me know, or want
additional context or thoughts please let me know.

Hope that helps,
Lloyd

--

1. http://en.wikipedia.org/wiki/Matt_Mullenweg
2. The best training material ;-) on this as recommend by Matt, and
which I thoroughly aggree with is is Frank I. Luntz, "Words That Work:
It's Not What You Say, It's What People Hear"
3. WordPress security issues are popular with the press ;-)
4. You may know Daniel Veditz as dveditz
5. http://barry.wordpress.com/about/
6. People just want to be taken seriously ;

Re: [Openstack] OpenStack Security Group

Lloyd Dewolf wrote:
> I'll be starting slowly with looking at documentation and the wiki.
> 
> I always look at security first, and then try to stay away thereafter ;-)
> 
> Problem:
> 
> Currently a Google search for "openstack security issue" returns the
> wrong page: 
> http://wiki.openstack.org/Governance/Proposed/OpenStack%20Security%20Group
> which is a draft and does not provide contact and reporting process
> information.
> [...]

This is being worked on. I submitted (yesterday) to the openstack.org
webmaster content to be posted under openstack.org/security pointing to
the recently-setup vulnerability management team and other
security-related teams. Hopefully that content will come online soon.

-- 
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] Keystone + Swift integration

2011-11-24 Thread Leandro Reox

Ok, solved !!! was an issue on the Storage nodes, the path /srv/node was
not found so the sda6 was returning "unmounted" ... actually weird the way
that is presented to the user

Regards

On Wed, Nov 23, 2011 at 7:41 PM, Marcelo Martins
wrote:

> Hi Leandro,
>
>
> If you search all swift services logs for the transaction Id returned what
> do you see ?
>
>
>
>
>
>
> Marcelo Martins
> Openstack-swift
> btorch...@zeroaccess.org
>
> “Knowledge is the wings on which our aspirations take flight and soar.
> When it comes to surfing and life if you know what to do you can do it. If
> you desire anything become educated about it and succeed. “
>
>
>
>
> On Nov 23, 2011, at 8:25 AM, Leandro Reox wrote:
>
> Im getting 404 with both tools, curl and swift , we're using the repo
> where you commited 41 minutes ago
>
>
> Regards
>
> On Wed, Nov 23, 2011 at 10:51 AM, Chmouel Boudjnah 
> wrote:
>
>> Hi,
>>
>> Which version did you use for keystone2 from cloudbuilders github
>> trunk? can you try again (I just updated some fixes to it just now).
>>
>> And what do you mean you are getting 404,  how do you test it ? with
>> swift cli or via curl ?
>>
>> Chmouel.
>>
>> On Wed, Nov 23, 2011 at 2:27 PM, Leandro Reox 
>> wrote:
>> > Hi Hugo,
>> >
>> > We changed out everything to keystone2 , now we're getting a 404 when
>> we try
>> > to create the container, maybe the account autocreation is not working
>> > properly any thoughts ?
>> >
>> > Regards
>> >
>> > On Wed, Nov 23, 2011 at 10:20 AM, Kuo Hugo  wrote:
>> >>
>> >> Hi Leandro ,
>> >> Post on launchpad QA will be a better place though. Plz post it on
>> >> launchpad , and we will jump to there for further discussion.
>> >> 1. Verify that your keystone is running , via curl -v -H "X-Auth-User:
>> >> MAX" -H "X-Auth-Key: Infa" http://%keystone_IP%:5000/v1.0
>> >> If keystone working properly , should return X-Auth-Token &
>> X-Storage-url
>> >>   etc.
>> >> After  step 1 ...
>> >> Use the returned X-Auth-Token and X-Storage-Url for the following cURL
>> cmd
>> >> curl -k -v -H "X-Auth-Token: %token%" %Returned
>> >> X-storage-Url%  http://%Swift-proxy_IP%:8080/v1/AUTH_%tenant_id%
>> >> I guess it will be
>> >> curl -v -k -H "X-Auth-Token: 1234567890"
>> >>   http://172.16.0.88:8080/v1/AUTH_%tenant_ID%
>> >>
>> >> If so , I believe that your problem is on the protocol of Swift-proxy
>> , as
>> >> your post , it's under https in your proxy-server.conf .
>> >> To disable it by comment
>> >> cert_file = /etc/swift/cert.crt
>> >> key_file = /etc/swift/cert.key
>> >> or correct the endpoint of swift to https..
>> >> If you were deploying keystone via cloudbuilder/devstack script ... You
>> >> might need to check the sampledata .   With swift client v1.0 , it
>> needs the
>> >> value of Tenant_Id in USERS table.
>> >> Hope it help ...
>> >> --
>> >> +Hugo Kuo+
>> >> tonyt...@gmail.com
>> >> hugo@cloudena.com
>> >> +886-935-004-793
>> >> www.cloudena.com
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: Re: resize of existing VM possible?

2011-11-24 Thread Christian Berendt

Bitte Diskussion auf der Maillingliste weiterfuehren. Ich weiss spontan
nicht was "openst...@b1-systems.de" ist/macht. Ist das ein alter
Verteiler? Der sollte geloescht werden und in Zukunft sollten fuer
OenStack Themen ausschliesslich diese Liste genutzt werden.

 Original Message 
Subject: Re: resize of existing VM possible?
Date: Thu, 24 Nov 2011 13:18:07 +0100
From: Christian Berendt 
Organization: B1 Systems GmbH
To: baum...@b1-systems.de
CC: Andre Naehring , openst...@b1-systems.de

Tag zusammen.

> ein Kunde benötigt das Feature das Image einer bestehenden VM zu
> vergrößern - somit kann dann der Kunde dem die VM gehört in der VM die
> LVM Partition ebenfalls vergrößern um dann mehr Volumes anzulegen oder
> bestehende zu vergrößern.

NOTE: Bitte im Bezug auf OpenStack immer von Instanzen und nicht von VMs
sprechen. So ist der OpenStack Sprech...

Momentan befindet sich dieses Feature in der Vorbereitung, die Flavour
einer Instanz zu aendern und damit automatisch auch RAM, VCPUs und
Storage entsprechend anzupassen. Bislang ist das noch nicht moeglich.

Der bereits von mir erwaehnte Workaround ist die Verwendung von
nova-volume. Man stellt ein zusaetzliches Volume der Instanz zur
Verfuegung und erstellt darauf ein Physical Volume, welches man in die
bestehende Volume Group einbindet. Danach ist es dann moeglich
bestehende Logical Volumes zu vergroessern.

Vom Prinzip her gehoert ein Base Image nie modifiert und vom Prinzip her
gehoeren Nutzdaten auch nicht auf das Base Image.

Warum muss der Kunde ein bestehendes Logical Volume vergroessern? Meiner
Meinung nach ist da beim Design des Base Images schief gelaufen, der
Fall sollte gar nicht auftreten. Die Nutzdaten gehoeren nicht im Klon
des Base Images hinterlegt sondern auf separaten Volumes/Mountpoints
welche _nur_ fuer die Nutzlast da sind. Diese Volumes/Mountpoints werden
eben durch nova-volume zur Verfuegung gestellt.

HTH, Christian.

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

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

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

2011-11-24 Thread Yuriy Taraday

Forgot to CC maillist again.

Kind regards, Yuriy.

On Thu, Nov 24, 2011 at 14:13, Yuriy Taraday  wrote:

> > 2011-11-24T00:12:57   I guess eventually we need to push
> that to all nova..api layers
>
> I think, there should be some common package that should allow do this
> with any joint where we can plug lots of different modules. Such joints
> exist in all OpenStack projects, so this package should be used in every
> one of them. It's function should be like "make sure that all this modules
> look and behave like this etalon (fake) one, and let tests use the fake
> one".
>
> By the way, speaking about other projects. I was developing LDAP store for
> Keystone and found the structure of the store API there as not ideal, but
> much better than the one in Nova. The one strong point there is that all
> parts of storage are (or strive for being) loose-coupled, so that we can
> just tune config to store different parts of knowledge in separate
> independent storages.
> Such loose coupling makes it easier to test and develop storage backend
> piece-by-piece.
>
> Kind regards, Yuriy.
>
> PS: I strongly believe in this community and dream about OpenStack Common
> project.
>
>
> On Thu, Nov 24, 2011 at 13:30, Soren Hansen  wrote:
>
>> 2011/11/24 Sandy Walsh :
>> > haha ... worse email thread ever.
>> >
>> > I'll catch you on IRC ... we've diverged too far to make sense.
>>
>> For anyone interested, this conversation continued on IRC yesterday.
>> You can read it at the very end of
>>
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2011-11-23.log
>>
>> as well as the very beginning of
>>
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2011-11-24.log
>>
>> My internet connection disappeared just as we were finishing our
>> discussion.
>>
>> --
>> Soren Hansen| http://linux2go.dk/
>> Ubuntu Developer| http://www.ubuntu.com/
>> OpenStack Developer | http://www.openstack.org/
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

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