We understand. We¹re willing, ready, and able to assist with all of the
upstream items that need to happen in order to get our submission in and
more. We just need to know so we can help.
Best,
‹Randy
On 6/8/16, 6:09 PM, "Matt Riedemann" wrote:
>That
Ryan,
Thanks your really helpful comments.
If the lswitch is determined by flow classifier, I think no need to record
in logical router, ovn creates patch port pair for router interface, one
patch port connects logical switch, the other connects logical router. The
one connects logical switch
Hello,
A tempest plugin was written for the Kingbird
https://review.openstack.org/#/c/328683/, the plugin and test cases could be
discovered by tempest, and the configuration is working if we add the
configuration items into the tempest.conf manfully, but if we run tox
-egenconfig in the
"discuss" wrote on 06/14/2016 10:31:40
PM:
> From: John McDowall
> To: Na Zhu
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"
On Jun 14, 2016, at 7:28 PM, Monty Taylor wrote:
>
> On 06/14/2016 05:42 PM, Doug Hellmann wrote:
>> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
>>> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
Excerpts from Matthew
Hi Congress team,
A quick update on progress at OPNFV on integrating Congress into the OPNFV
Colorado release (Mitaka-based). With the help of RedHat (Dan Radez) and
Canonical (Narinder Gupta, Liam Young) we are getting very close to upstreaming
two key things to OpenStack:
-
John,
Here is the steps to configure sfc,
1, create flow-classifer
2, create port-pairs
3, create port-pair-group with port-pairs
4, create port-chain with flow-classifer and port-pair-groups
You can see that the port-chain is not related to network, my question is
how to get the lswitch for
+1 both for Alexander Tivelkov and Zhu Rong. Well deserved.
Regards,
Lin Yang
On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev
> wrote:
Hello team, I want to annonce the following changes to murano core team:
1) I’d like to nominate Alexander
Hi Kolla o/
I'm writing to you because I'm concerned.
In case you didn't already know, the RDO community collaborates with
upstream deployment and installation projects to test it's packaging.
This relationship is beneficial in a lot of ways for both parties, in summary:
- RDO has improved test
Hi John,
Another question, I think port-chain is irrelevant with lswitch, one
port-chain includes multiple port-pair-groups and one flow-classifier, how
to get the lswitch by port-chain?
Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building
John,
Since you have port-chain as child of lswitch, do you need port-pairs as
child of lswitch any more?
Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
District, Shanghai,
On Tue, Jun 14, 2016, at 07:36 PM, Tony Breeds wrote:
> Hi All,
> I'd like to add GPT partitioning supporg to DIB. My current
> understanding is that the only partitioning in DIB currently is
> provided by partitioning-sfdisk, which will not support GPT.
>
This isn't made very clear
On 14/06/2016 12:10 PM, Ian Cordasco wrote:
> I wonder why more projects aren't seeing this in stable/liberty. Perhaps,
> ceilometer stable/liberty isn't using upper-constraints? I think oslo.utils
> 3.2.0
>
Thanks Masayuki for the comments and thanks Bob for the explanation.
All,
Please let's know if there are more comments/ concerns or if we're good to
proceed for voting. Thanks very much.
Regards,
Jianghua
-Original Message-
From: Bob Ball
Sent: Tuesday, June 14, 2016 6:23 PM
To:
It is hard for kolla to support both release of Ubuntu.
Because docker separate the image build from deploy. We have no idea about
the Ubuntu version in Dockerfile
except runing command to test it. We build the image by using Dockerfile.
If we want support multi release of
Ubuntu, the Dockerfile
On 06/13/2016 04:06 AM, Wang, Shane wrote:
> Hi, OpenStackers,
>
> As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug
> Smash at Hangzhou, China.
> The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd
> was at Chengdu.
>
> We are constructing the
Perhaps the right way to schedule these bug smashes is to do it at the same
time as the release scheduling is determined. Decide on a fixed time within
the release cycle (it's been just after M3/feature freeze a few times) and when
the schedule is put together, the bugsmash is part of the
On 06/14/2016 06:11 PM, Angus Lees wrote:
Yep (3) is quite possible, and the only reason it doesn't just do this
already is because there's no way to find the name of the rootwrap
command to use (from any library, privsep or os-brick) - and I was never
very happy with the current need to specify
On 06/14/2016 07:28 PM, Monty Taylor wrote:
On 06/14/2016 05:42 PM, Doug Hellmann wrote:
I think this is the most important thing to me as it relates to this.
I'm obviously a huge proponent of clouds behaving more samely. But I
also think that, as Doug nicely describes above, we've sort of
John,
OK, I will change networking-ovn IDL to align with the new schema.
Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
District, Shanghai, China (201203)
From: John McDowall
Hi Banszel,
Please see inline.
Thanks,
Cathy
-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com]
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with
multiple
Hi All,
I'd like to add GPT partitioning supporg to DIB. My current understanding
is that the only partitioning in DIB currently is provided by
partitioning-sfdisk, which will not support GPT.
My proposed solution is:
1. Create a new element called partitioning-parted that (surprise
Juno,
I worked on ovs/ovn today and re-structured the schema. I could not figure out
how to make this work without have lport-chains as a child of lswitch. So I
have got the basics working – attached a simple shell script that creates and
shows the port-chains. I tried to merge with the
>which generates an arbitrary name
I'm not a fan of this approach because it requires coordinated assumptions.
With the OVS hybrid plug strategy we have to make guesses on the agent side
about the presence of bridges with specific names that we never explicitly
requested and that we were never
Dear all,
TL;DR: I'd like to propose to start running some of the existing dsvm
check/gate jobs using Tempest pre-provisioned credentials.
Full Text:
Tempest provides tests with two mechanisms to acquire test credentials [0]:
dynamic credentials and pre-provisioned ones.
The current check and
Excerpts from Chris Hoge's message of 2016-06-14 16:19:11 -0700:
>
> > On Jun 14, 2016, at 3:59 PM, Edward Leafe wrote:
> >
> > On Jun 14, 2016, at 5:50 PM, Matthew Treinish wrote:
> >
> >> But, if we add another possible state on the defcore side like
Top posting one note and direct comments inline, I’m proposing
this as a member of the DefCore working group, but this
proposal itself has not been accepted as the forward course of
action by the working group. These are my own views as the
administrator of the program and not that of the working
On 06/14/2016 05:42 PM, Doug Hellmann wrote:
> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
>> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
>>> Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
On Tue, Jun 14, 2016 at 10:57:05AM
> On Jun 14, 2016, at 3:59 PM, Edward Leafe wrote:
>
> On Jun 14, 2016, at 5:50 PM, Matthew Treinish wrote:
>
>> But, if we add another possible state on the defcore side like conditional
>> pass,
>> warning, yellow, etc. (the name doesn't matter) which
On Jun 14, 2016, at 5:50 PM, Matthew Treinish wrote:
> But, if we add another possible state on the defcore side like conditional
> pass,
> warning, yellow, etc. (the name doesn't matter) which is used to indicate that
> things on product X could only pass when strict
On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
> > On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> > > Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > > > On Tue,
Thanks.
Actually, we were looking for lbaas v1 and the linked document seems to mainly
talk about v2, but we are migrating to v2 so I am satisfied.
Best regards,
Hongbin
From: Anne Gentle [mailto:annegen...@justwriteclick.com]
Sent: June-14-16 6:06 PM
To: OpenStack Development Mailing List
Excerpts from Sean Dague's message of 2016-06-14 17:29:06 -0400:
> On 06/14/2016 01:57 PM, Chris Hoge wrote:
>
> >
> > My proposal for addressing this problem approaches it at two levels:
> >
> > * For the short term, I will submit a blueprint and patch to tempest that
> > allows
On Tue, 14 Jun 2016 at 23:04 Daniel P. Berrange wrote:
> On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
>
> [snip]
>
Urgh, thanks for the in-depth analysis :/
> The crux of the problem is that os-brick 1.4 and privsep can't be used
> > without a config file
Let us know if this is what you're looking for:
http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
Thanks Major Hayden for writing it up.
Anne
On Tue, Jun 14, 2016 at 3:54 PM, Hongbin Lu wrote:
> Hi neutron-lbaas team,
>
> Could anyone confirm if
It was pointed out today in IRC that the Virtuozzo CI has been failing
on this change for the libvirt imagebackend refactor:
https://review.openstack.org/#/c/282580/
Diana was having a hard time sorting out the line numbers in the stack
trace though from the logs, because they didn't exist in
Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> > Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> > > > Last year, in
On 06/14/2016 01:57 PM, Chris Hoge wrote:
>
> My proposal for addressing this problem approaches it at two levels:
>
> * For the short term, I will submit a blueprint and patch to tempest that
> allows configuration of a grey-list of Nova APIs where strict response
> checking on additional
On Tue, Jun 14, 2016 at 12:19:54PM -0700, Chris Hoge wrote:
>
> > On Jun 14, 2016, at 11:21 AM, Matthew Treinish wrote:
> >
> > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> >> Last year, in response to Nova micro-versioning and extension updates[1],
> >>
Hi neutron-lbaas team,
Could anyone confirm if there is an operator-facing install guide for
neutron-lbaas. So far, the closest one we could find is:
https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun , which doesn't seem to
be a comprehensive install guide. I asked that because there are
On 06/09/2016 02:27 PM, Tim Bell wrote:
> If we can confirm the dates and location, there is a reasonable chance we
> could also offer remote conferencing using Vidyo at CERN. While it is not the
> same as an F2F experience, it would provide the possibility for remote
> participation for those
Hi team,
As discussed in the team meeting, we are going to choose between Austin and San
Francisco. A doodle pool was created to select the location:
http://doodle.com/poll/2x9utspir7vk8ter . Please cast your vote there. On
behalf of Magnum team, thanks Rackspace for providing the host.
Best
Hi Tim,
Thanks for providing the host. We discussed the midcycle location at the last
team meeting. It looks a significant number of Magnum team members has
difficulties to travel to Geneva, so we are not able to hold the midcycle at
CERN. Thanks again for the willingness to host us.
Best
On 06/14/2016 12:30 PM, Paul Michali wrote:
Well, looks like we figured out what is going on - maybe folks have some
ideas on how we could handle this issue.
What I see is that for each VM create (small flavor), 1024 huge pages
are used and NUMA node 0 used. It appears that, when there is no
> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: June-14-16 3:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap
>
> On 13/06/16 18:46 +, Hongbin Lu wrote:
> >
> >
> >>
Well, looks like we figured out what is going on - maybe folks have some
ideas on how we could handle this issue.
What I see is that for each VM create (small flavor), 1024 huge pages are
used and NUMA node 0 used. It appears that, when there is no longer enough
huge pages on that NUMA node, Nova
On Tue, 14 Jun 2016, Matthew Treinish wrote:
By doing this, even as a temporary measure, we're saying it's ok to call things
an OpenStack API when you add random gorp to the responses. Which is something
we've
very clearly said as a community is the exact opposite of the case, which the
> On Jun 14, 2016, at 11:21 AM, Matthew Treinish wrote:
>
> On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
>> Last year, in response to Nova micro-versioning and extension updates[1],
>> the QA team added strict API schema checking to Tempest to ensure that
>>
Hello team, I want to annonce the following changes to murano core team:
1) I’d like to nominate Alexander Tivelkov for murano core. He has been part of
the project for a very long time and has contributed to almost every part of
murano. He has been fully committed to murano during mitaka cycle
Our midcycle meetup is 2 weeks away! Please propose topics on the etherpad:
https://etherpad.openstack.org/p/newton-manila-midcycle
Depending on how much material we need to cover I'll decide if we need
the third day or not.
-Ben
On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> > > Last year, in response to Nova micro-versioning and extension updates[1],
> > > the QA team
On 06/14/2016 09:52 AM, Chris Friesen wrote:
> On 06/13/2016 01:11 PM, Doug Hellmann wrote:
>> I'm trying to pull together some information about contributions
>> that OpenStack community members have made *upstream* of OpenStack,
>> via code, docs, bug reports, or anything else to dependencies
Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> > Last year, in response to Nova micro-versioning and extension updates[1],
> > the QA team added strict API schema checking to Tempest to ensure that
> > no
On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> Last year, in response to Nova micro-versioning and extension updates[1],
> the QA team added strict API schema checking to Tempest to ensure that
> no additional properties were added to Nova API responses[2][3]. In the
> last year, at
Excerpts from Chris Hoge's message of 2016-06-14 10:57:05 -0700:
> Last year, in response to Nova micro-versioning and extension updates[1],
> the QA team added strict API schema checking to Tempest to ensure that
> no additional properties were added to Nova API responses[2][3]. In the
> last
I think Kyle polled operators and a few mentioned using VPNaaS for
site-to-site IPSec - do a search in this ML for VPNaaS. AFAIK, no one so
far is stepping up to work on VPNaaS.
Regards,
PCM
On Tue, Jun 14, 2016 at 1:40 PM Mark Fenwick
wrote:
> Hi Paul,
>
> On
Rob,
Do you have the source for reference #2 below? I believe the next step was to
produce copies of #2 based upon the special different types of containers in
the system and combine them into one coherent doc.
I think continuing to use sequence diagrams makes sense.
My phone (out of
Last year, in response to Nova micro-versioning and extension updates[1],
the QA team added strict API schema checking to Tempest to ensure that
no additional properties were added to Nova API responses[2][3]. In the
last year, at least three vendors participating the the OpenStack Powered
I committed a small change to systemd-nspawn to ensure kernel modules
could be loaded by IPA hardware managers in an older version of our
CoreOS-based ramdisk (note that we don't use systemd-nspawn anymore, but
instead use a chroot inside the CoreOS ramdisk).
Thanks,
Jay Faulkner
OSIC
On
Hi Paul,
On 06/14/16 10:27, Paul Michali wrote:
Certainly the ciphers and hashes could be enhanced for VPNaaS. This would
require converting the user selections into options for the underlying
device driver, modifying the neutron client (OSC) to allow entry of the new
selections, updating unit
Hi,
There was a short discussion on IRC a few minutes ago [1] about when it would
be acceptable for a patch to be approved with one +2 (as opposed to two +2s).
The few of us that commented (I think all are cores in one or several ironic
projects) agreed that it would be good to do that, but
I just put up a WIP patch in os-brick that tests to see if os-privsep is
configured with
the helper_command. If it's not, then os-brick falls back to using
processutils
with the root_helper and run_as_root kwargs passed in.
https://review.openstack.org/#/c/329586
If you can check this out
On 6/14/2016 11:33 AM, Sean Dague wrote:
On 06/14/2016 09:02 AM, Daniel P. Berrange wrote:
On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
[snip]
The crux of the problem is that os-brick 1.4 and privsep can't be used
without a config file change during the upgrade. Which violates
Certainly the ciphers and hashes could be enhanced for VPNaaS. This would
require converting the user selections into options for the underlying
device driver, modifying the neutron client (OSC) to allow entry of the new
selections, updating unit tests, and likely adding some validators to
reject
Great info Chris and thanks for confirming the assignment of blocks of
pages to a numa node.
I'm still struggling with why each VM is being assigned to NUMA node 0. Any
ideas on where I should look to see why Nova is not using NUMA id 1?
Thanks!
PCM
On Tue, Jun 14, 2016 at 10:29 AM Chris
Please note the details on the midcycle event are updated here:
https://wiki.openstack.org/wiki/VirtualSprints#Glance_Virtual_midcycle_sync
We will be using the etherpad (given in the link above) as a live wiki
for central place of updated info.
On 6/8/16 9:52 AM, Nikhil Komawar wrote:
> This
On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (berra...@redhat.com)
wrote:
>
> On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote:
> > In strategy 2 we just pass 1 bridge name to Nova. That's the one that
> > is ensures is created and plumbs the VM to. Since it's not
On 06/14/2016 09:02 AM, Daniel P. Berrange wrote:
> On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
>
> [snip]
>
>> The crux of the problem is that os-brick 1.4 and privsep can't be used
>> without a config file change during the upgrade. Which violates our
>> policy, because it
On 14/06/2016 17:14, Anita Kuno wrote:
> On 06/14/2016 10:44 AM, Hayes, Graham wrote:
>> On 14/06/2016 15:00, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> I just proposed a new requirement for OpenStack "official" projects,
>>> which I think is worth discussing beyond the governance review:
>>>
Excerpts from Hayes, Graham's message of 2016-06-14 14:44:36 +:
> On 14/06/2016 15:00, Thierry Carrez wrote:
> > Hi everyone,
> >
> > I just proposed a new requirement for OpenStack "official" projects,
> > which I think is worth discussing beyond the governance review:
> >
> >
-Original Message-
From: gordon chung
Reply: OpenStack Development Mailing List (not for usage questions)
Date: June 14, 2016 at 06:51:08
To: openstack-dev@lists.openstack.org
Subject: Re:
On 06/14/2016 10:44 AM, Hayes, Graham wrote:
> On 14/06/2016 15:00, Thierry Carrez wrote:
>> Hi everyone,
>>
>> I just proposed a new requirement for OpenStack "official" projects,
>> which I think is worth discussing beyond the governance review:
>>
>> https://review.openstack.org/#/c/329448/
>>
Hello,
I'd need some help with using the SFC implementation in openstack.
I use liberty version of devstack + liberty branch of networking-sfc.
It's not clear to me if the SFC instance and it's networks should be separated
from the remaining virtual network topology or if it should be connected
We are happy to announce the release of:
os-win 1.0.0: Windows / Hyper-V library for OpenStack projects.
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/os-win
With package available at:
Some counter arguments for keeping them in:
* It gives the developers of the code that's being plugged into a better view
of how the plugin api is used and what might break if they change it.
* Vendors don't tend to support drivers forever. Often they drop support for a
driver once the "new"
I can't wait to try "VLAN Aware VMs"... But it is not there yet... Maybe on
Newton B2...
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
This is *very* important for NFV Instances on OpenStack... Many telcos
needs this...
Cheers!
Thiago
On 14 June 2016 at 07:25, Jeffrey Zhang
I think there's a weird cycle in plugging into nova too...
Say the cloud has no native container support added except for Zun. The
container api Zun provides could be mapped to a Zun plugin that:
1. nova boot --image centos --user-data 'yum install -y docker; yum start
docker; '
2. starts
On Jun 14, 2016 00:46, "Henry Nash" wrote:
>
> On 14 Jun 2016, at 07:34, Morgan Fainberg
> wrote:
>
>
>
> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash wrote:
>
>> So, I think it depends what level of compatibility we are aiming
On Mon, Jun 13, 2016 at 8:57 AM, Emilien Macchi <emil...@redhat.com> wrote:
> Hi Puppeteers!
>
> We'll have our weekly meeting tomorrow at 3pm UTC on
> #openstack-meeting-4.
>
> Here's a first agenda:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20
We are thrilled to announce the release of:
oslo.messaging 5.4.0: Oslo Messaging API
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.messaging
With package available at:
We are glad to announce the release of:
oslo.reports 1.10.0: oslo.reports library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.reports
With package available at:
https://pypi.python.org/pypi/oslo.reports
We are psyched to announce the release of:
taskflow 2.2.0: Taskflow structured state management library.
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/taskflow
With package available at:
We are overjoyed to announce the release of:
oslo.versionedobjects 1.11.0: Oslo Versioned Objects library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.versionedobjects
With package available at:
We are happy to announce the release of:
oslo.log 3.10.0: oslo.log library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.log
With package available at:
https://pypi.python.org/pypi/oslo.log
Please report
We are jubilant to announce the release of:
tooz 1.39.0: Coordination library for distributed systems.
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/tooz
With package available at:
We are glad to announce the release of:
oslo.serialization 2.9.0: Oslo Serialization library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.serialization
With package available at:
We are amped to announce the release of:
oslo.vmware 2.9.0: Oslo VMware library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.vmware
With package available at:
https://pypi.python.org/pypi/oslo.vmware
Please
We are eager to announce the release of:
oslo.policy 1.10.0: Oslo Policy library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.policy
With package available at:
https://pypi.python.org/pypi/oslo.policy
We are delighted to announce the release of:
oslo.privsep 1.8.0: OpenStack library for privilege separation
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.privsep
With package available at:
We are happy to announce the release of:
oslo.middleware 3.13.0: Oslo Middleware library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/oslo.middleware
With package available at:
On 06/13/2016 01:11 PM, Doug Hellmann wrote:
I'm trying to pull together some information about contributions
that OpenStack community members have made *upstream* of OpenStack,
via code, docs, bug reports, or anything else to dependencies that
we have.
If you've made a contribution of that
On 14/06/2016 15:00, Thierry Carrez wrote:
> Hi everyone,
>
> I just proposed a new requirement for OpenStack "official" projects,
> which I think is worth discussing beyond the governance review:
>
> https://review.openstack.org/#/c/329448/
>
> From an upstream perspective, I see us as being in
On 06/13/2016 01:22 AM, Andreas Scheuring wrote:
While reviewing [1] I got hung up on the terms "device" and "interface".
It seems like in sr-iov agent they are used in a different manner than
in the linuxbridge agent.
For Example the lb agent uses a config option
"physical_interface_mappings"
Under normal circumstances a bit of resource tracking error is generally okay.
However in the case of CPU pinning it's a major problem because it's not caught
at instance boot time, so you end up with two instances that both think they
have exclusive access to one or more host CPUs.
If we get
On Jun 14, 2016, at 8:57 AM, Thierry Carrez wrote:
> A few months ago we had the discussion about what "no open core" means in
> 2016, in the context of the Poppy team candidacy. With our reading at the
> time we ended up rejecting Poppy partly because it was interfacing
On 06/13/2016 02:17 PM, Paul Michali wrote:
Hmm... I tried Friday and again today, and I'm not seeing the VMs being evenly
created on the NUMA nodes. Every Cirros VM is created on nodeid 0.
I have the m1/small flavor (@GB) selected and am using hw:numa_nodes=1 and
hw:mem_page_size=2048
Hi all,
This morning I did a quick audit of the launchpad projects for our
various projects, and found some projects that have some incorrect
permissions/ownership things. Can the current maintainers of these
projects please change the "driver" and "maintainer" fields on the home
page to
On 06/14/2016 08:08 AM, Jesse Pretorius wrote:
> That's neat Major! It'd be great to extend it to also do the diffs for the
> included roles, both OpenStack and non-OpenStack to get full coverage.
That shouldn't be too difficult to implement. I'd need to refactor the
comparison code so that it
Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> Hi everyone,
>
> I just proposed a new requirement for OpenStack "official" projects,
> which I think is worth discussing beyond the governance review:
>
> https://review.openstack.org/#/c/329448/
>
> From an upstream
Hi everyone,
I just proposed a new requirement for OpenStack "official" projects,
which I think is worth discussing beyond the governance review:
https://review.openstack.org/#/c/329448/
From an upstream perspective, I see us as being in the business of
providing open collaboration playing
1 - 100 of 152 matches
Mail list logo