Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Esra Celik]

Maxim, Matt, 

Thanks a lot we will try Virtuozzo soon, I will share the results, 

Best regards, 
ecelik 

- Orijinal Mesaj -

> Kimden: "Matt Riedemann" 
> Kime: openstack-dev@lists.openstack.org
> Gönderilenler: 29 Aralık Perşembe 2016 17:37:33
> Konu: Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

> On 12/29/2016 8:25 AM, Maxim Nestratov wrote:
> > Hi Esra,
> >
> > Take a look at Virtuozzo, which is supported in Nova via libvirt
> > virt_type=parallels. It provides both VMs and OS Containers similar to
> > lxc except our containers have beed in production for more than 10 years
> > already. Though
> > http://docs.openstack.org/developer/nova/support-matrix.html looks a bit
> > outdated, you still can use Libvirt Virtuozzo CT column to understand
> > what features are supported.
> >
> > Best,
> >
> > Maxim
> >

> I was going to say, of the in-tree container support in Nova, the
> Virtuozzo container driver (part of the libvirt driver) is the most well
> maintained and actually has CI testing. We don't have regular CI testing
> for the LXC driver, we have an experimental queue job for it but it has
> rolling failures that no one has been able to figure out so it's never
> been made voting.

> --

> Thanks,

> Matt Riedemann

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

[Jeffrey Zhang]

Checked more failed gate, here is the more info:

1. only rax-iad has such issue
2. the failed and successful gates have the same rpm installed.

So the only difference between failed gate and successful gate is the xen
hypervisor.

On Sun, Jan 1, 2017 at 6:33 AM, Steven Dake (stdake) 
wrote:

> Jeffrey,
>
>
>
> rax-iad uses xen as a base virtualization layer iiuc.  Perhaps kvm on xen
> is not a technical feature rax-iad supports or perhaps libvirt was modified
> and now fails with xen?  Whatever the case is, rax-iad has been a
> semi-constant source of hassle with Kolla’s gate jobs; I think partly
> because Kolla’s gate scripts need to special-case rax-iad in some way.
>
>
>
> Just one of many possibilities.
>
>
>
> Happy new year J
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Jeffrey Zhang 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Saturday, December 31, 2016 at 6:22 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed
> during launching qemu progress
>
>
>
> I checked more than ten error gates, all of them happened in rax-iad.
>
>
>
> On Sat, Dec 31, 2016 at 12:06 PM, Steven Dake (stdake) 
> wrote:
>
> Jeffrey,
>
>
>
> Have you detected any pattern to any specific cloud provider in the logs?
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Jeffrey Zhang 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, December 30, 2016 at 12:41 AM
> *To: *OpenStack Development Mailing List  openstack.org>
> *Subject: *Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed
> during launching qemu progress
>
>
>
> Found this nova bug[0] and another talk in openstack-dev[1].
>
>
>
> The question is: why this happens now and then? sometimes the gate is OK.
> and others not.
>
>
>
> [0] https://bugs.launchpad.net/nova/+bug/1649527
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/
> 2016-December/109401.html
>
>
>
> On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang 
> wrote:
>
> Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version.
>
>
>
> But in kolla's gate. the nova_libvirt container failed now and then.
>
>
>
> What i found is:
>
>
>
> 1. Simple start nova_libvirt container is OK.
>
> 2. When launching a new instance, libvirt is killed without any logs in
> libvirtd.log file.
>
> 3. in system messages log, i found following line.
>
> Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip 
> 7f9fee072823 sp 7f9fe52dd1c0 error 4 in 
> libvirt.so.0.2000.0[7f9fedf1f000+353000]
>
> No idea why and how this happen. Any idea on this?
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] project specific question for the next user survey

[Rabi Mishra]

Hi All,

We have an opportunity to submit a heat adoption related question (for
those who are USING, TESTING, or INTERESTED in heat) to be included in the
User Survey.

Please provide your suggestions/questions.*The deadline for this is 9th
Jan.*

-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Python routes

[Matt Riedemann]

On 1/1/2017 10:33 AM, Matt Riedemann wrote:

On 1/1/2017 2:59 AM, Gary Kotton wrote:

Please see https://review.openstack.org/415947

Happy new year!




That doesn't appear to be working. Someone else already reported the
issue upstream:

https://github.com/bbangert/routes/issues/76

It's pretty crazy they did a release on 1/1 when most of the world is on
vacation (or hungover), but whatever I guess.



We should be good again in OpenStack CI land because the 2.3.1 wheels 
are available on pypi.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Consistency in versioned notification payloads

[Balazs Gibizer]

On Sat, Dec 31, 2016 at 5:08 PM, Doug Hellmann  
wrote:

Excerpts from Matt Riedemann's message of 2016-12-30 16:23:24 -0600:
 While reviewing patches today to add versioned notifications for 
CRUD
 operations on aggregates and flavors I've come across some 
inconsistency.


 The existing non-versioned notification for aggregate.delete just 
sends
 the aggregate id, but the versioned notification is sending the 
whole

 aggregate object in the payload:

 
https://review.openstack.org/#/c/394512/9/doc/notification_samples/aggregate-delete-end.json


 But with the flavor-delete versioned notification, it's just 
sending the

 flavorid:

 
https://review.openstack.org/#/c/398171/16/doc/notification_samples/flavor-delete.json


 So which should we be doing? Either way you can correlate the id on 
the

 resource in the notification back to the full record if needed, but
 should we be sending the full object in the versioned notification
 payload while we have it? I don't much care either way which we do 
as

 long as we're consistent.


Thanks Matt for taking this up. I agree that we need to make a 
consistent solution.
The instance.delete notification also uses the same 
InstanceActionPayload as the instance.create. I think this is a good 
precedent to send the full payload at delete as well.




When we originally wrote ceilometer's notification consumption code,
we ran into issues processing the data for delete notifications
that only included identifiers.  IIRC, the primary issue at the
time was with some of the CRUD operations in neutron, and we asked
them to add all known data about objects to all notifications so
the consumer could filter notifications based on those properties
(maybe the receive wants to only pay attention to certain tenants,
for example) and ensure it has the most current settings for an
object as it is being deleted (useful for ensuring that a billing
record includes the right flavor, for example).


Thanks Doug for adding the historic background. I think the use case 
you described are still valid so I propose to make a recommendation to 
emit a full payload at entity delete.


I proposed this recommendation to the notification devref [1].

[1]  https://review.openstack.org/415991

Cheers,
gibi





Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All] Python routes

[Gary Kotton]

Hi,
It appears that the version 2.3.1 is no longer around. Any idea?
Do we need to upgrade to 2.4.0?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev