Brian Schott wrote:
> How did you install and launch OpenStack? The instances are stored in a
> sqllite or mysql table depending on how things are configured.
I think George's point is that if you reboot the compute node, you lose
the instances that were running on it. I don't really know if t
John Purrier wrote:
> And we are back to the discussion about orchestration... Given the
> flexibility of the OpenStack system and the goals of independently
> horizontally scaling services I think we will need to address this head on.
> #3 is the most difficult, but is also the right answer for th
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
Justin,
I think you hit upon the reason of why I think it was approved and reverted.
Because it hadn't been talked about in a blueprint or a mail sent to the list
(I think I'm up to date on the threads) and a patch landed means other
alternatives weren't considered before pushing it through to
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
Yes i have Ubuntu 10.04 LTS and installed from pkg
Well in my scenario i need to have a powerful server(physical machine) that
hosts VMs
so i considered cloud to be any time able to scale that and even for
redundancy.(starting from 1 server expanding to more possible)
Can i do it with nova with a
And we are back to the discussion about orchestration... Given the
flexibility of the OpenStack system and the goals of independently
horizontally scaling services I think we will need to address this head on.
#3 is the most difficult, but is also the right answer for the project as we
look forward
How did you install and launch OpenStack? The instances are stored in a
sqllite or mysql table depending on how things are configured.
Brian
Brian Schott
bfsch...@gmail.com
On Feb 23, 2011, at 1:53 PM, George Argyrides wrote:
>
> Why do i lose instances after reboot?
> How can they remai
Why do i lose instances after reboot?
How can they remain permanent?
does it have something to do that every reboot i need to source novarc?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https
Agreed that this is the right way to go.
We need some sort of supervisor to tell the network to allocate the network
before dispatching a message to compute. I see three possibilities (from
easiest to hardest):
1. Make the call in /nova/compute/api.py (this code runs on the api host)
2. Make
I agree, this is exactly where we want to take the network services for
OpenStack. The goal should be to decouple Compute from Network, with an eye
toward a project separation post-Cactus (this should have a lot of
discussion at the next design summit). For Cactus we have explicitly kept
the networ
+1 to this!
On 2/17/11 3:28 PM, "Soren Hansen" wrote:
>+1! (Yup, that was +factorial(1), for those keeping score at home)
>
>2011/2/17 Sandy Walsh :
>> I'd like to help out on the review process as
>> per http://wiki.openstack.org/Governance/Approved/CoreDevProcess
>> I like quiet walks in the p
I think this is very much inline with what we've been thinking. To me,
providing a clean and generic programming interface that decouples the
network functionality from the existing nova stack is a first step in
creating a standalone network service.
Also, I am not sure if this is implied by step
Hi everyone,
I have been following the discussion regarding the new 'pluggable' network
service design, and wanted to drop in my 2 cents ;-)
Looking at the current implementation of Nova, there seems to be a very
strong coupling between compute and network services. That is, tasks that
are done
I forgot to add something to my 'wishlist' ;-)
Changing the way we configure Nova should be a process announced in
advanced. One or two releases in advance, to give enough time to teams
doing deployments and upgrades of Nova to be prepared. Changes that
can impact in the upgrade of the product (da
This is now done.
Den 21/02/2011 08.46 skrev "Soren Hansen" :
> 2011/2/19 Rick Harris :
>> Throwing my hat into the ring for nova-core membership. Eager to help
knock
>> down that merge-prop backlog we have at the moment :-)
>
> +1
>
> The 5 day grace period expires on Wednesday. If noone has objec
Andy Smith wrote:
> (4) I did some work on a sphinx plugin that was never finished to
> automatically document the flags, I can put some effort into finishing
> that if we want it. It basically added the docs for the flags per module
> and could be expanded to generate a master list of flags docume
26 matches
Mail list logo
