I would personally like to see Keystone get transitioned first, but it
really doesn't matter where we start if we reach the right goal in the end.
Since Emelien's work on refactoring all the providers for puppet-keystone,
it has become a test bed for project-wide features. I'm really excited to
see
Hello All,
We will have an IRC meeting tomorrow (Monday, 25/4) at 0900 UTC
in #openstack-meeting-4
Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow
You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dra
Hi neutrinos,
A kind reminder for next week's meeting.
Being the meeting right after the milestone was cut, I'd like to take most
of the hour to talk about blueprints/specs, i.e. the beefy workload that
has merged, and has yet to merge.
We'll be brief on announcements and bugs, and skip the othe
On 01/22/2016 09:01 AM, Dan Prince wrote:
I gave a couple of ad-hoc demo's of my Mistral dev environment this
week. For those interested in tinkering with TripleO Mistral actions in
tripleo-common here are links to the code I used for those. Still a
rough prototype but hopefully demonstrates how
Something about the eventlet 0.18 release is failing the cloudpipe
functional tests, as well as our docs job (which is really really odd).
An eventlet pin has been posted - https://review.openstack.org/271809 -
once landed it should let the spice flow again. If someone could look
into it deeper it
On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote:
> Something about the eventlet 0.18 release is failing the cloudpipe
> functional tests, as well as our docs job (which is really really odd).
>
> An eventlet pin has been posted - https://review.openstack.org/271809 -
> once landed it should
On 01/24/2016 08:01 PM, Jeremy Stanley wrote:
On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote:
Something about the eventlet 0.18 release is failing the cloudpipe
functional tests, as well as our docs job (which is really really odd).
An eventlet pin has been posted - https://review.opens
yep. we should be all better now :)
-- dims
On Sun, Jan 24, 2016 at 2:48 PM, Andreas Jaeger wrote:
> On 01/24/2016 08:01 PM, Jeremy Stanley wrote:
>>
>> On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote:
>>>
>>> Something about the eventlet 0.18 release is failing the cloudpipe
>>> function
And here's the upstream bug for the functional test failures:
https://github.com/eventlet/eventlet/issues/291
https://bugs.launchpad.net/nova/+bug/1537450
It was also fixed in eventlet 0.18.1.
--diana
>> Dims reported a related bug upstream:
>>
>> https://github.com/eventlet/eventl
Just an official notice - there will be no weekly meeting
January 27th due to the Mitaka Midcycle. Regular weekly
meetings will continue the first week of February.
Thanks!
Sean McGinnis (smcginnis)
__
OpenStack Development
Excerpts from Dan Prince's message of 2016-01-22 16:19:07 -0800:
> On Fri, 2016-01-22 at 11:24 -0600, Ben Nemec wrote:
> > So I haven't weighed in on this yet, in part because I was on
> > vacation
> > when it was first proposed and missed a lot of the initial
> > discussion,
> > and also because I
Just FYI.
Docker support multi log driver now[0].
Version New Logging Drivers
1.6.0 json-file, syslog, none
1.7.0 journald
1.8.0 fluentd, gelf
1.9.0 awslogs
For the stdout from container, we can use gelf/syslog driver to forward.
[0] https://docs.docker.com/engine/reference/logging/overview/
O
hello,
I have build a 2 node devstack environment with ovn enabled by following
http://docs.openstack.org/developer/networking-ovn/testing.html with 2
physical machine
on one blade server.
Then I created 3 instances, one in the controller node and other two in the
compute node, same as :
http:/
Hey, so I'd like to propose Sachi - one of my HPE colleages who has
been helping out with pbr for a while now, for oslo core. pbr is
pretty quiet as you know, so its a bit hard to assess her work based
on reviews done - but I think her error rate will be
approximately the same as mine - pbr is such
+1 Robert. Here's hoping Sachi can expand her horizon to all of Oslo.
Thanks,
Dims
On Sun, Jan 24, 2016 at 9:51 PM, Robert Collins
wrote:
> Hey, so I'd like to propose Sachi - one of my HPE colleages who has
> been helping out with pbr for a while now, for oslo core. pbr is
> pretty quiet as you
I wrote the spec for the MTU work that's in the Neutron API today. It
haunts my nightmares. I learned so many nasty corner cases for MTU, and
you're treading that same dark path.
I'd first like to point out a few things that change the implications of
what you're reporting in strange ways. [1] p
On 23 January 2016 at 11:27, Adam Lawson wrote:
> For the sake of over-simplification, is there ever a reason to NOT enable
> jumbo frames in a cloud/SDN context where most of the traffic is between
> virtual elements that all support it? I understand that some switches do
> not support it and tr
I believe the issue is that the default is unspecified, which leads to
nothing being advertised to VMs via dhcp/ra. So VMs end up using 1500,
which leads to a catastrophe when running on an overlay on a 1500 underlay.
On Jan 24, 2016 20:48, "Ian Wells" wrote:
> On 23 January 2016 at 11:27, Adam L
One thing that might be tough for operators is dealing with different
versions of openstack projects which require different versions of oslo.
Right now we have some stuff on Liberty, some stuff not. As we containerize
more services that's going to get even more true. Right now we can solve
this by
+1 from me,
Go Sachi! Have no fear (paranoia) oslo is here!
-Josh
On 01/24/2016 06:51 PM, Robert Collins wrote:
Hey, so I'd like to propose Sachi - one of my HPE colleages who has
been helping out with pbr for a while now, for oslo core. pbr is
pretty quiet as you know, so its a bit hard to as
On 24 January 2016 at 20:18, Kevin Benton wrote:
> I believe the issue is that the default is unspecified, which leads to
> nothing being advertised to VMs via dhcp/ra. So VMs end up using 1500,
> which leads to a catastrophe when running on an overlay on a 1500 underlay.
>
That's not quite the p
>The reason for that was in the other half of the thread - it's not
possible to magically discover these things from within Openstack's own
code because the relevant settings span more than just one server
IMO it's better to have a default of 1500 rather than let VMs automatically
default to 1500
On 22 January 2016 at 10:35, Neil Jerram wrote:
> * Why change from ML2 to core plugin?
>
> - It could be seen as resolving a conceptual mismatch.
> networking-calico uses
> IP routing to provide L3 connectivity between VMs, whereas ML2 is
> ostensibly
> all about layer 2 mechanisms.
You've
On 24 January 2016 at 22:12, Kevin Benton wrote:
> >The reason for that was in the other half of the thread - it's not
> possible to magically discover these things from within Openstack's own
> code because the relevant settings span more than just one server
>
> IMO it's better to have a defaul
Actually, I note that that document is Juno and there doesn't seem to be
anything at all in the Liberty guide now, so the answer is probably to add
settings for path_mtu and segment_mtu in the recommended Neutron
configuration.
On 24 January 2016 at 22:26, Ian Wells wrote:
> On 24 January 2016 a
At a minimum I think we should pick a default in devstack and dump a
warning in neutron if operators don't specify it.
I would still be preferable to changing the default even though it's a
behavior change considering the current behavior is annoying. :)
On Jan 24, 2016 23:31, "Ian Wells" wrote:
Moshe, awesome and handy tool!!! Especially hear about completed
this in 24 hours Hackathon session. :)
Lin Yang
@Intel
> On Jan 17, 2016, at 08:25, Stan Lagun wrote:
>
> Very cool, indeed! Even myself (developer of yaql) often use yaqluator
> instead of yaql CLI :)
>
> Finally took a time to s
I like both of those ideas.
On 24 January 2016 at 22:37, Kevin Benton wrote:
> At a minimum I think we should pick a default in devstack and dump a
> warning in neutron if operators don't specify it.
>
> I would still be preferable to changing the default even though it's a
> behavior change con
*Hi every one, *
*When trying to execute this command:*
* neutron --debug port-update 51ae49c8-d360-488e-badb-7bee31585471
--allowed-address-pairs action=clear*
*I am getting the following error:*
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/neutronclient/shell.p
On 2016-01-24 22:35, Diana Clarke wrote:
> And here's the upstream bug for the functional test failures:
>
> https://github.com/eventlet/eventlet/issues/291
> https://bugs.launchpad.net/nova/+bug/1537450
>
> It was also fixed in eventlet 0.18.1.
Diana, Thanks for investigating and report
Cancelling the upcoming keystone since most of the regular attendees will
be flying out that day to attend the keystone midcycle that starts on on
the 27th.
Thanks,
Steve Martinelli
Keystone PTL
__
OpenStack Development Mail
+1, no objections from my side.
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.
Skype: dark_harlequine1
2016-01-22 18:48 GMT+03:00 Serg Melikyan :
> I would like to nominate Rong Zhu (zhurong on IRC) join to the Murano
> core-reviewers team. He has been an active member of the Murano
+1, no objections.
Well deserved, Victor.
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.
Skype: dark_harlequine1
2016-01-22 20:33 GMT+03:00 Serg Melikyan :
> I would like to nominate Victor Ryzhenkin (freerunner on IRC) join to the
> Murano
> core-reviewers team. He has been an activ
On 22 January 2016 at 10:35, Neil Jerram wrote:
> networking-calico [1] is currently implemented as an ML2 mechanism
> driver, but
> I'm wondering if it might be better as its own core plugin, and I'm
> looking for
> input about the implications of that, or for experience with that kind of
> chan
34 matches
Mail list logo
