hi,
i have this error..
--
root@ubuntu:/home/khalid# gedit /etc/network/interfaces
root@ubuntu:/home/khalid# sudo nova-manage network create 192.168.3.0/24 1
255
network does not match any options:
user
project
role
shell
vpn
Your nova-manage command does not know the "network" subcommand. It
only know the 6 it lists.
This means you have a *very* old installation of Nova. You should
upgrade to a more recent version.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack De
2011/5/24 abbou khalid :
> what abou this error:
>
> root@ubuntu:/home/khalid# sudo nova-manage db sync
> Command failed, please check log for more info
I would guess that command was unsuccessful in some way. Perhaps you
can find a hint in the log files as to what went wrong?
(Remember to reply-
Hi,
what this error:
root@ubuntu:/home/khalid# sudo nova-manage db sync
Command failed, please check log for more info
tanks you all.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://l
Hello everyone,
Our weekly team meeting will take place at 21:00 UTC this Tuesday in
#openstack-meeting on IRC. PTLs, if you can't make it, please name a
substitute on [2].
One week away from the first Diablo milestones, we'll discuss the status
and priorities in preparation for those.
Check out
Huang,
If you are willing to modify code, you might want to take a look at the code at
lp:~usc-isi/nova/hpc-trunk that has a scheduler (nova/scheduler/arch.py) that
does not allow creating new instances if cpu or other resources are used up. If
you have any question on the branch, please feel f
On Mon, May 23, 2011 at 5:54 PM, Sandy Walsh wrote:
> We can have Feats of Strength later to decide how this should live on in an
> OS API 2.0 world.
I'll bring the Festivus pole.
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to :
Only a small scream on PUT /zones/server/
PUT would work in my mind if we allowed users to create their own
ReservationIDs, but since (I assume) we're generating them it would make more
sense to me to use POST on /zones/server.
-Original Message-
From: "Sandy Walsh"
Sent: Monday, May 2
Actually, I'm cool with it either way.
I'm not really sure of the value in letting users generate their own
Reservation ID though. What would the typical motivation be?
That said, anyone else have preferences (PUT + user defined reservation ID's)
vs. (POST + zone generated ID's)?
-S
On May 24, 2011, at 10:30 AM, Brian Lamar wrote:
> Only a small scream on PUT /zones/server/
>
> PUT would work in my mind if we allowed users to create their own
> ReservationIDs, but since (I assume) we're generating them it would make more
> sense to me to use POST on /zones/server.
Hmm, not sure I like changing the return type based on the input type. Return
types should be consistent.
From: Ed Leafe
> If we are going to add an optional parameter to specify the number of
> instances, would it be acceptable to specify that when t
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
> Hmm, not sure I like changing the return type based on the input type. Return
> types should be consistent.
Agreed, but I liked changing the meaning of PUT even less. :)
-- Ed Leafe
___
M
On May 24, 2011, at 10:43 AM, Sandy Walsh wrote:
> I'm not really sure of the value in letting users generate their own
> Reservation ID though. What would the typical motivation be?
>
> That said, anyone else have preferences (PUT + user defined reservation ID's)
> vs. (POST + zone generated I
I'm for zone-generated ids. If we take user input it is one more
thing to sanitize and scope accordingly. As the number is essentially
disposable, I don't know why they would care to provide one anyway, it
just seems like changing who is responsible for making a uuid.
On Tue, May 24, 2011 at 10:
POST isn't an issue for me. I honestly don't know why I wrote PUT ... I blame
the Canadian holiday.
From: Ed Leafe
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
> Hmm, not sure I like changing the return type based on the input type. Return
> typ
Hi
I think I was unclear. What I meant were having network wire constructs
like a T where there are actually 3 end points and one of the end points
of the T could be in sniff mode or in a bump-in-the-wire mode. I am not
sure how the current API would support these semantics.
Use case: imagine vm
Yup ... agreed.
I'll press on in this direction (POST with zone generated ID's)
-S
From: Todd Willey [t...@ansolabs.com]
Sent: Tuesday, May 24, 2011 12:13 PM
To: Sandy Walsh
Cc: Brian Lamar; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStac
Hi Debo,
That makes sense as a use case. One way to model that would be as a "port
mirror" ( http://en.wikipedia.org/wiki/Port_mirroring ). Port mirroring is
sometimes referred to as SPAN thanks to a large networking vendor ;)
In your example, if VM A is connected on port XYZ, a quantum plugin
Hi Dan
J
My T idea is *slightly* different from the port mirroring idea. We might
want to have the semantics in the wire (not the port). So when you
unplug the wire and replug it elsewhere, you don't have to worry about
mirroring the new port. Similarly you want a bump in the wire use case
On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh wrote:
> Actually, I'm cool with it either way.
>
> I'm not really sure of the value in letting users generate their own
> Reservation ID though. What would the typical motivation be?
>
> That said, anyone else have preferences (PUT + user defined res
Glad to see we are converging.
Couple of things/questions that we need to discuss/decide in our meeting
today.
1. For plugin-specific extensions - Option 1: Use DataExtension
scheme as in Jorge proposal with Key-Value pairs.
Any other options? Or just go with. BTW, I agree with this
Hi All,
We are having our weekly NetStack meeting after at UTC 22:00 today
directly after the Openstack release meeting.
The agenda is here:
[http://wiki.openstack.org/Network/Meetings]
Feel free to add anything you want to talk about.
Cheers,
Rick
__
Just a note for those not watching the forums, Stephen just posted a topic
about the Fall 2011 event - in case any of you would like to join/follow the
discussion on that: http://opns.tk/4
___
Mailing list: https://launchpad.net/~openstack
Post to :
One more thing we can discuss in today's meeting:
What are standard attributes associated with Resources in Core API?
In Alex's revision of core API spec
http://wiki.openstack.org/QuantumAPIBase?action=AttachFile&do=get&target
=Quantum_API_spec-draft-v0.11+-+Alex.docx
, he proposed some.
2011/5/23 Sandy Walsh :
> To Soren's point about "losing the ability to rely on a fixed set of
> topics in the message queue for doing scheduling" this is not the case,
> there are no new topics introduced.
That's not exactly what I meant.
If we stuck with the simple flavours that we have right n
Hi openstackers
Coverage 3.4 supports branch a coverage feature now.
http://nedbatchelder.com/code/coverage/branch.html
We can use it on nose using dstanekcom-python-nose branch.
I run it for nova. (See wiki page)
http://wiki.openstack.org/branch_coverage
# You can download a result of branch co
26 matches
Mail list logo
