Re: [Openstack-operators] attaching network cards to VMs taking a very long time

2018-05-31 Thread Matt Riedemann

On 5/30/2018 9:30 AM, Matt Riedemann wrote:


I can start pushing some docs patches and report back here for review help.


Here are the docs patches in both nova and neutron:

https://review.openstack.org/#/q/topic:bug/1774217+(status:open+OR+status:merged)

--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

2018-05-31 Thread Matt Riedemann

+openstack-operators

On 5/31/2018 3:04 PM, Matt Riedemann wrote:

On 5/31/2018 1:35 PM, melanie witt wrote:


This cycle at the PTG, we had decided to start making some progress 
toward removing nova-network [1] (thanks to those who have helped!) 
and so far, we've landed some patches to extract common network 
utilities from nova-network core functionality into separate utility 
modules. And we've started proposing removal of nova-network REST APIs 
[2].


At the cells v2 sync with operators forum session at the summit [3], 
we learned that CERN is in the middle of migrating from nova-network 
to neutron and that holding off on removal of nova-network core 
functionality until Stein would help them out a lot to have a safety 
net as they continue progressing through the migration.


If we recall correctly, they did say that removal of the nova-network 
REST APIs would not impact their migration and Surya Seetharaman is 
double-checking about that and will get back to us. If so, we were 
thinking we can go ahead and work on nova-network REST API removals 
this cycle to make some progress while holding off on removing the 
core functionality of nova-network until Stein.


I wanted to send this to the ML to let everyone know what we were 
thinking about this and to receive any additional feedback folks might 
have about this plan.


Thanks,
-melanie

[1] https://etherpad.openstack.org/p/nova-ptg-rocky L301
[2] https://review.openstack.org/567682
[3] 
https://etherpad.openstack.org/p/YVR18-cellsv2-migration-sync-with-operators 
L30


As a reminder, this is the etherpad I started to document the nova-net 
specific compute REST APIs which are candidates for removal:


https://etherpad.openstack.org/p/nova-network-removal-rocky




--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] [nova] proposal to postpone nova-network core functionality removal to Stein

2018-05-31 Thread melanie witt

Hello Operators and Devs,

This cycle at the PTG, we had decided to start making some progress 
toward removing nova-network [1] (thanks to those who have helped!) and 
so far, we've landed some patches to extract common network utilities 
from nova-network core functionality into separate utility modules. And 
we've started proposing removal of nova-network REST APIs [2].


At the cells v2 sync with operators forum session at the summit [3], we 
learned that CERN is in the middle of migrating from nova-network to 
neutron and that holding off on removal of nova-network core 
functionality until Stein would help them out a lot to have a safety net 
as they continue progressing through the migration.


If we recall correctly, they did say that removal of the nova-network 
REST APIs would not impact their migration and Surya Seetharaman is 
double-checking about that and will get back to us. If so, we were 
thinking we can go ahead and work on nova-network REST API removals this 
cycle to make some progress while holding off on removing the core 
functionality of nova-network until Stein.


I wanted to send this to the ML to let everyone know what we were 
thinking about this and to receive any additional feedback folks might 
have about this plan.


Thanks,
-melanie

[1] https://etherpad.openstack.org/p/nova-ptg-rocky L301
[2] https://review.openstack.org/567682
[3] 
https://etherpad.openstack.org/p/YVR18-cellsv2-migration-sync-with-operators 
L30


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] OpenLab Cross-community Impact

2018-05-31 Thread Melvin Hillsman
Hi everyone,

I know we have sent out quite a bit of information over the past few days
with the OpenStack Summit and other updates recently. Additionally there
are plenty of meetings we all attend. I just want to take time to point to
something very significant in my opinion and again give big thanks to
Chris, Dims, Liusheng, Chenrui, Zhuli, Joe (gophercloud), and anyone else
contributing to OpenLab.

A member of the release team working on the testing infrastructure for
Kubernetes did a shoutout to the team for the following:

(AishSundar)
Shoutout to @dims and OpenStack team for quickly getting their 1.11
Conformance results piped to CI runs and contributing results to
Conformance dashboard !
https://k8s-testgrid.appspot.com/sig-release-1.11-all#Conformance%20-%20OpenStack=

Here is why this is significant and those working on this who I previously
mentioned should get recognition:

(hogepodge)
OpenStack and GCE are the first two clouds that will release block on
conformance testing failures. Thanks @dims for building out the test
pipeline and @mrhillsman for leading the OpenLab efforts that are reporting
back to the test grid. @RuiChen for his contributions to the testing
effort. Amazing work for the last six months.

In other words, if the external cloud provider ci conformance tests we do
in OpenLab are not passing, it will be one of the signals used for blocking
the release. OpenStack and GCE are the first two clouds to achieve this and
it is a significant accomplishment for the OpenLab team and the OpenStack
community overall regarding our relationship with the Kubernetes community.
Thanks again Chris, Dims, Joe, Liusheng, Chenrui, and Zhuli for the work
you have done and continue to do in this space.

Personally I hope we take a moment to really consider this milestone and
work to ensure OpenLab's continued success as we embark on working on other
integrations. We started OpenLab hoping we could make substantial impact
specifically for the ecosystem that builds on top of OpenStack and this is
evidence we can and should do more.

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

2018-05-31 Thread Massimo Sgaravatto
Thanks a lot !!

On Wed, May 30, 2018 at 8:06 PM, Matt Riedemann  wrote:

> On 5/30/2018 9:41 AM, Matt Riedemann wrote:
>
>> Thanks for your patience in debugging this Massimo! I'll get a bug
>> reported and patch posted to fix it.
>>
>
> I'm tracking the problem with this bug:
>
> https://bugs.launchpad.net/nova/+bug/1774205
>
> I found that this has actually been fixed since Pike:
>
> https://review.openstack.org/#/c/449640/
>
> But I've got a patch up for another related issue, and a functional test
> to avoid regressions which I can also use when backporting the fix to
> stable/ocata.
>
> --
>
> Thanks,
>
> Matt
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators