Sure, that's possible too. I'll leave it to the folks setting up the
tests and working with tarmac/bzr/jenkins/... to decide what is the
easiest way to implement it. Lots of ways to do it. :)
-Eric
On Thu, Feb 24, 2011 at 06:05:48PM -0600, Trey Morris wrote:
>can't the other tests/systems als
can't the other tests/systems also pull the LP topic branch straight from LP
for testing?
This would allow:
test system 1 to pull trunk, merge topic branch A and test. if success it
passes it off to
test system 2 to pull trunk, merge topic branch A and test, while
test system 1 moves on, pulls trun
That is how it works now, but if we need to run tests that are not
on the tarmac machine, we need to push that local branch somewhere
so other things can test the same thing.
Monty Taylor will have a much better idea of how to orchestrate all
of this, I'm going off what we did in the past, and I k
yikes! i assumed tarmac was running things locally merged with trunk to test
and actually merging after success. That's surprising. The branches would
definitely be safer.
On Thu, Feb 24, 2011 at 4:41 PM, Eric Day wrote:
> Yup. Right now when a -core member clicks 'Approve'
> after code review,
Yup. Right now when a -core member clicks 'Approve'
after code review, tarmac picks it up and pushes to trunk assuming
unittests pass. Instead it could push to staging and trigger a hook
in jenkins which would fire off a bunch of other jobs that run the
staging branch through a battery of tests. If
Correct, no human would use them.
On Thu, Feb 24, 2011 at 5:36 PM, Trey Morris wrote:
> I see. So their use would in general be for the use of automated systems?
>
> On Thu, Feb 24, 2011 at 4:33 PM, Eric Day wrote:
>>
>> The extra branches are just an implementation detail, we can have
>> them o
I see. So their use would in general be for the use of automated systems?
On Thu, Feb 24, 2011 at 4:33 PM, Eric Day wrote:
> The extra branches are just an implementation detail, we can have
> them or not. It's really a matter of if it's possible and/or easier
> to have jenkins fire off new jobs
The extra branches are just an implementation detail, we can have
them or not. It's really a matter of if it's possible and/or easier
to have jenkins fire off new jobs with arbitrary branches that need
to be merged with trunk for each job vs merging and pushing to a
staging branch and have the jobs
I'm curious what the point of having a line of trunks for a commit to bounce
down on its way to trunk would gain us other than having to manage a line of
trunks. What's wrong with status quo branch management (other than tests)?
What's wrong with having the commit sit in its LP topic branch, which
On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
wrote:
>> This is what we're working on, and what Justin is proposing, Mark.
>>
>> Basically, in Drizzle-land, people propose a merge into trunk, Hudson
>> picks up that proposal, pulls the brnach into lp:drizzle/staging,
>> builds Drizzle on all
> This is what we're working on, and what Justin is proposing, Mark.
>
> Basically, in Drizzle-land, people propose a merge into trunk, Hudson
> picks up that proposal, pulls the brnach into lp:drizzle/staging,
> builds Drizzle on all supported platforms (>12 OS/distro combos), then
> runs all aut
ever the priority should *not* be on refactoring the auth API or
>>> the way the auth layer in Nova is handled. The priority should be
>>> on
>>> writing a smoketest for the OpenStack API so that we can link it
>>> into
>&
-jay
>> On Wed, Feb 23, 2011 at 10:03 PM, Paul Voccio
>> wrote:
>> > Justin,
>> > I think you hit upon the reason of why I think it was approved and
>> reverted.
>> > Because it hadn't been ta
> think we're all open to talking about how to better the auth
> system and make
> > improvements. Dragon has already discussed some alternatives and
> suggestions
> > on the BP page below. I think this is the right way to continue
>
these types of issues can be automatically caught.
>>>
>>> -jay
>>>
>>> On Wed, Feb 23, 2011 at 10:03 PM, Paul Voccio
>>> wrote:
>>> > Justin,
>>> > I think you hit upon the reason of why I think it was approved and
>>> re
On Thu, Feb 24, 2011 at 1:24 PM, Trey Morris wrote:
> We just need the tests. No matter how many stability levels of trunk we have,
> without better tests we can't guarantee stability.
Yep. :)
-jay
___
Mailing list: https://launchpad.net/~openstack
Po
ves weren't considered before pushing it through to begin with.
>> I
>> > think we're all open to talking about how to better the auth system and
>> make
>> > improvements. Dragon has already discussed some alternatives and
>> suggestions
>> > on
open to talking about how to better the auth system and
> make
> > improvements. Dragon has already discussed some alternatives and
> suggestions
> > on the BP page below. I think this is the right way to continue the
> dialog
> > and we all can agree on a good way f
ident we can figure it out.
> If I missed a conversation, my apologies.
> pvo
> From: Vishvananda Ishaya
> Date: Wed, 23 Feb 2011 18:19:41 -0800
> To: Justin Santa Barbara
> Cc:
> Subject: Re: [Openstack] Should the OpenStack API re-use the EC2
> credentials?
>
> H
Justin Santa Barbara wrote:
> Here's an overview of the problem:
>
> EC2 uses an (api_key, api_secret) pair. Post-revert, OpenStack uses the
> api_key(!) as the password, but a different value entirely as the
> username: (username, api_key). The bugfix made it so that both APIs
> used the EC2 cr
Now that I have looked at the nova auth code, I see what you are getting at,
and doesn't work as I would have expected it to. Essentially both auth
systems work the same, but the terminology is different. As is, the easiest
thing to do would be to change _authorize_user in nova/api/openstack/auth
The issue is that _if_ you're also running the EC2 API over non-SSL (which
is supposed to be safe - other than for replay attacks?), then you send the
api_key in the clear (the api_secret remains secret because it's only
'passed' via the one-way-hashed signature.) However, api_key is currently
the
>
>
> However, I think we want the same credentials for users ('username' &
> 'password'), irrespective of the API (or auth protocol) they're using. I
> think the weird terminology is what got us into the odd situation in which
> we now find ourselves where there are two sets of credentials (and o
Agree that we could support multiple different authentication protocols -
signing, direct passing, tokens etc. Sounds like the OpenStack technique
will change in the future, so we should revisit the supported set at that
time.
However, I think we want the same credentials for users ('username' &
It seems that most of the confusion is around the conflicting terminology of
the EC2 and Rackspace apis. I doubt either of those can really change, but
there isn't a reason that both auth methods can be supported. As an example
this is already done in the S3 compatibility layer for Swift.
--
Chu
No hard feelings or anything like that. :) We actually did just have a talk
about the possibility of merging it in with Nova (or perhaps combining them
with other toolsets). I imagine it will hit the ML soon for further
discussion once we get the kinks worked out.
On Wed, Feb 23, 2011 at 9:11 PM,
Hi Josh - I didn't think your Python API bindings were in particularly
widespread use yet because they were so new. But I'm a big fan and love how
they are moving so quickly. I think I hit some bugs in them one day and
then when I pulled the next day you'd fixed them all. Perhaps there was
some
net>>
Subject: Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?
Hey Justin,
Does it make any difference that the way the auth is (theoretically) supposed
to work with the os api is that the user gets an auth token from an external
auth server and then uses username
Two people may have come into the channel and brought it to our attention
today, but this was a very recent change. I can assure you there are many
more OS API consumers out there already. It's likely that most just haven't
pulled trunk since it landed.
I think we all agree that a decision on a st
When the authentication protocol changes, then OpenStack wrapper libraries
will need to change - good point. So there's even less reason to treat
OpenStack as if it were a stable API.
However, we can't expect people using those libraries to change their
credentials - there was enough kicking and
Hey Justin,
Does it make any difference that the way the auth is (theoretically) supposed
to work with the os api is that the user gets an auth token from an external
auth server and then uses username / authtoken to actually contact the api? I
think it is just faked out right now to use the a
I previously fixed OpenStack authentication so it would use the same
credentials as EC2. This bugfix was just reverted, because it caused
OpenStack API users to have to enter in different credentials (sorry!), but
primarily because it hadn't been discussed on the mailing list. So here
goes!
Here
32 matches
Mail list logo
