Hi all,
We are glad to announce the Ryu open-sourced Network Operating System.
Ryu is released under GPL v3 license. It's fully written in Python.
http://www.osrg.net/ryu/
The project goal is to develop an OSS Network Operating System that
has high quality enough for use in large production
Hi, this is a neat project, thanks for sending it out.
I'm really happy to see that you've already performed the Quantum
integration by extending the Open vSwitch plugin. This work is a great
example of how Quantum can be used to plug in a variety of different
back-end networking technologies.
2011/12/8 Vishvananda Ishaya vishvana...@gmail.com:
I'm hesitant to do more meetings as well, but we do need some
coordination.
I call false dichotomy on this. I don't buy the without meetings, we
can't coordinate anything notion.
I will leave the one for Monday on the board for now. Lets
On Fri, Dec 09, 2011 at 03:31:22AM -0800, Dan Wendlandt wrote:
Hi, this is a neat project, thanks for sending it out.
Hi.
I'm really happy to see that you've already performed the Quantum integration
by extending the Open vSwitch plugin. This work is a great example of how
Quantum can be
Very cool!
Any plans to have a silent (or daily, or on demand) one running against
trunk for all projects?
On 12/8/11 4:12 PM, James E. Blair cor...@inaugust.com wrote:
Hi,
A lot of people would like to see us with more commit gating jobs that
test functionality across the full range of core
Hi everyone -
Overall I support this effort and have discussed it at length with the
Rackers working on it.
I'd really like to get feedback from everyone who thinks they'll
consume this type of information. I don't find it easy to use from an
API consumer's perspective, but it is an absolute must
On Thu, 2011-12-08 at 14:12 -0800, James E. Blair wrote:
There are still a number of issues involved in turning this on for
trunk, not only related to stability and determinism, but also to
coordinating simultaneous changes to multiple projects. However, I
think this is reasonably stable and
Ziad Sawalha ziad.sawa...@rackspace.com writes:
Very cool!
Any plans to have a silent (or daily, or on demand) one running against
trunk for all projects?
Yes, our next focus will be on a post-commit integration test job for
trunk. That means we don't have to have all the technical problems
nova-manage does not talk to keystone, and exporting credentials will not work.
If you want to use keystone with nova, your best bet is to see how devstack
sets up users [1] and paste config [2] and credentials [3].
[1]
On Fri, Dec 9, 2011 at 5:22 AM, Isaku Yamahata yamah...@valinux.co.jpwrote:
On Fri, Dec 09, 2011 at 03:31:22AM -0800, Dan Wendlandt wrote:
Hi, this is a neat project, thanks for sending it out.
Hi.
I'm really happy to see that you've already performed the Quantum
integration
by
On Thu, Dec 8, 2011 at 2:27 PM, Mark Washenberger
mark.washenber...@rackspace.com wrote:
Does code specific to Trusted Computing belong in Nova? It seems like it
should be supported through Scheduler plugins and API plugins (if necessary).
It seems like the ideas of attestation and trusted
Yes, our next focus will be on a post-commit integration test job for
trunk. That means we don't have to have all the technical problems
solved before we start testing trunk but we can draw attention to bugs.
Super awesome!!
Jim++
-Jim
___
Hi,
Thanks for the update James.
The Ubuntu project has also been setting up per-commit testing for
both stable/* and trunk, where the cloud setup is achieved by juju
using per-commit packages.
I would quite like for this test run to initially be a post-commit
blame alert requiring manual
I suggested a couple alternative solutions for implementations in one of the
reviews. Hoping to hear back from fred yang/intel on whether one of those
solutions will work. Copied suggestions here in case anyone else is following
along.
Brian Waldon and I were discussing the possibility of a
I totally agree with Anne that the documentation in this split up format is
very hard to both find and parse. It's not inaccurate, so much as it leaves a
gaping hole in understanding what is and isn't available when you have 9+
documents to read and they're not really interlinked.
The effort I
* Vishvananda Ishaya (vishvana...@gmail.com) wrote:
1. add an admin api to add and remove hosts from an availabilty zone. Then
the component that is verifying trust could periodically check the hosts and
remove them from the trusted zone if they fail. The scheduler could just use
regular
-Original Message-
From: openstack-bounces+fred.yang=intel@lists.launchpad.net
[mailto:openstack-bounces+fred.yang=intel@lists.launchpad.net] On
Behalf Of Vishvananda Ishaya
Sent: Friday, December 09, 2011 11:33 AM
To: Michael Pittaro
Cc: OpenStack Mailing List; Mark
* Yang, Fred (fred.y...@intel.com) wrote:
* Vishvananda Ishaya (vishvana...@gmail.com) wrote:
1. add an admin api to add and remove hosts from an availabilty zone.
Then the component that is verifying trust could periodically check the
hosts and remove them from the trusted zone if they
Do we need anything more than a way to inject a third-party filter into
schedulers?
I'm assuming that we need to schedule based on whether or not the attestation
server verifies the host. And I understand that this situation introduces some
peculiar and novel requirements on the scheduler. But
From: Chris Wright [mailto:chr...@sous-sol.org]
* Yang, Fred (fred.y...@intel.com) wrote:
* Vishvananda Ishaya (vishvana...@gmail.com) wrote:
1. add an admin api to add and remove hosts from an availabilty
zone.
Then the component that is verifying trust could periodically check
the
Behalf Of Mark Washenberger
Do we need anything more than a way to inject a third-party filter into
schedulers?
I'm assuming that we need to schedule based on whether or not the
attestation server verifies the host. And I understand that this
situation introduces some peculiar and novel
2011/12/9 Paul Voccio paul.voc...@rackspace.com:
I think the benefits of an all hands irc/irl meeting is to reduce
the overall amount of time needed to drive to a decision. I can
usually do this in a 30 minute meeting if I have the relevant people
and have a handful of items that need to be
Soren:
Your concerns are perfectly reasonable. We will try to come up with a plan for
communication that doesn't involve more meetings. I'm already in way too many
meetings as it is. We will do Monday without you and take your concerns into
account for our plans.
Everyone Else:
The simple
OpenStack Community Newsletter –December 9, 2011
HIGHLIGHTS
* Stackops Openstack Distro 0.3 Diablo Stable released
http://blog.stackops.com/2011/12/06/stackops-openstack-distro-0-3-diablo-stable-released/
* Changes to the OpenStack Nova subteams
On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote:
Oh, definitely. I really should have set create a blueprint and target it as
essex-3 as a place-holder. We'll definitely need to talk through the design
first (though we probably don't need to flood the entire OS community with
On Fri, Dec 9, 2011 at 5:13 PM, Isaku Yamahata yamah...@valinux.co.jpwrote:
The polling period is the window. Shortening the interval make the window
small, but never eliminates it. I'd like to make the agent work done before
staring instance.
I think one way to do what you are suggesting
- Original message -
2011/12/9 Paul Voccio paul.voc...@rackspace.com:
We put *every* single meeting in this
project in US business hours, *every* single meeting *outside* European
and Japanese business hours
If I may, also *every* time it's out of reach for
an normal humain living in
27 matches
Mail list logo
