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 envi
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.
G
2011/12/8 Vishvananda Ishaya :
> 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 have one
> meeting
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
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" 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 OpenStack proje
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
Hey Anne,
Great feedback! As for number 8, I think the nova-api team might be the best
group to be tasked with reviewing code and documentation for any extensions
proposed to Nova's codebase. And we can absolutely discuss this at the meeting
today!
Brian
On Dec 9, 2011, at 9:17 AM, Anne Gent
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 a
Ziad Sawalha 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
solved before we start
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]
https://github.com/openstack-dev/devstack/blob/stable/diablo/files/keyston
On Fri, Dec 9, 2011 at 5:22 AM, Isaku Yamahata wrote:
> 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 Ope
On Thu, Dec 8, 2011 at 2:27 PM, Mark Washenberger
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 computing are tangential
> to
> 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 resolu
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 c
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
* 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 th
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 che
> 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 no
2011/12/9 Paul Voccio :
> 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 decided upon. Having t
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 a
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
https://lists.laun
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 wit
On Fri, Dec 9, 2011 at 5:13 PM, Isaku Yamahata wrote:
>
>
> 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 is to have the OVS
- Original message -
> 2011/12/9 Paul Voccio :
> 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 GMT+8 (China,
Singapo
28 matches
Mail list logo
