Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/1/2017 4:07 PM, Matt Riedemann wrote: On 4/1/2017 12:17 PM, Jay Bryant wrote: Matt, I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking

Re: [openstack-dev] [all] BOS Forum - User/Dev Feedback session for your project?

On 3/30/2017 10:28 PM, Tom Fifield wrote: Hi all, Forum topic submission closes in 2 days (Sunday 23:59 UTC). One of the types of topics you could consider submitting is a user/dev feedback session for your project. I see Swift, Keystone and Kolla have already done this - thanks! From

[openstack-dev] [cloudkitty] IRC Meeting

Dear OpenStackers, With Pike developmet being started for some time now, it is a great time to have a meeting to coordinate our efforts ! That is why we will have an IRC meeting Tuesday 11th of April 12:30 UTC on #cloudkitty. I hope to see many of you All the best Christophe

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/1/2017 12:17 PM, Jay Bryant wrote: Matt, I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking point) was doing a rescan of the SCSI bus in

Re: [openstack-dev] [tripleo] Idempotence of the deployment process

At our site, we've seen bugs in idempotence break our system too. In once case, it was an edge case of the master server going uncontactable at just the wrong time for a few seconds, causing the code to (wrongly) believe that keys didnt exist and needed to be recreated, then network

[openstack-dev] [nova] Removing BDM devices from POST requests

I know we've talked about this over and over and another bug [1] reminded me of it. We have long talked about removing the ability to specify a block device name when creating a server or attaching a volume because we can't honor the requested device name anyway and trying to do so just causes

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

Now the system is up. Just push a recheck. It must be fine. Thanks, Trinath Somanchi | HSDC, GSD, DN | NXP – Hyderabad –INDIA. From: ChangBo Guo [mailto:glongw...@gmail.com] Sent: Saturday, April 01, 2017 7:17 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Matt, I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking point) was doing a rescan of the SCSI bus in the node that had the extended volume

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 3/31/2017 8:55 PM, TommyLike Hu wrote: There was a time when this feature had been both proposed in Cinder [1] and Nova [2], but unfortunately no one (correct me if I am wrong) is going to handle this feature during Pike. We do think extending an online volume is a beneficial and mostly

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

On 2017-04-01 15:28, Davanum Srinivas wrote: > Andreas, > > looks like we are past the POST_FAILURE's. However the log links seem > to redirect to a 404. > > example in https://review.openstack.org/#/c/451964/, the log link is: >

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

Never mind :) looks like it was a transient issue from last night. logs show up correctly with a recheck Thanks, Dims On Sat, Apr 1, 2017 at 9:28 AM, Davanum Srinivas wrote: > Andreas, > > looks like we are past the POST_FAILURE's. However the log links seem > to redirect to

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

Andreas, looks like we are past the POST_FAILURE's. However the log links seem to redirect to a 404. example in https://review.openstack.org/#/c/451964/, the log link is: http://logs.openstack.org/64/451964/7/check/gate-k8s-cloud-provider-golang-dsvm-conformance-ubuntu-xenial/569f22a/ which

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

Here comes the all-green again ;) On 2017-03-31 20:28, Andreas Jaeger wrote: > Since this morning, part of logs.openstack.org is corrupt due to a > downtime of one of the backing stores. The infra admins are currently > running fsck and then will take everything back in use. > > Right now, we

[openstack-dev] [Cinder] [Nova] Extend attached volume

There was a time when this feature had been both proposed in Cinder [1] and Nova [2], but unfortunately no one (correct me if I am wrong) is going to handle this feature during Pike. We do think extending an online volume is a beneficial and mostly supported by venders feature. We really don't

Re: [openstack-dev] [all][infra] logs.o.o corrupt - indicated by POST_FAILURE results

Thanks for the reminder! 2017-04-01 2:28 GMT+08:00 Andreas Jaeger : > Since this morning, part of logs.openstack.org is corrupt due to a > downtime of one of the backing stores. The infra admins are currently > running fsck and then will take everything back in use. > > Right now,

Re: [openstack-dev] [Openstack] [infra] lists.openstack.org maintenance Friday, March 31 20:00-23:00 UTC

On Tue, Mar 28, 2017, at 05:14 PM, Jeremy Stanley wrote: > The Mailman listserv on lists.openstack.org will be offline for an > upgrade-related maintenance for up to 3 hours (but hopefully much > less) starting at 20:00 UTC March 31, this coming Friday. This > activity is scheduled for a

[openstack-dev] [tripleo] Idempotence of the deployment process

Hey folks, I wanted to raise awareness of the concept of idempotence[0] and how it affects deployment(s). In the puppet world, we consider this very important because since puppet is all about ensuring a desired state (ie. a system with config files + services). That being said, I feel that it

Re: [openstack-dev] [oslo]Introduction of new driver for oslo.messaging

Great idea, happy to try it out for Trove. We love o.m.rpc :) But it needs to be secure; other comment has been posed in review, I'm doing a talk about o.m use by trove in Boston anyway, maybe we can get Melissa to join me for that? -amrith -Original Message- From: Deja, Dawid