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
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
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.
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 :
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
__
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
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
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
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
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
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
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
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:
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
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
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 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.
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
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
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 :
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
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
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
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-
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
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
26 matches
Mail list logo
