Re: [openstack-dev] [nova] Kilo FeatureFreeze is March 19th, FeatureProposalFreeze has happened

On 11 March 2015 at 12:51, Gary Kotton wrote: > Hi, > Not 100% sure that I understand. This is for the BP¹s and specs that were > approved for Kilo. Basically, yes. No change from previous releases here AFAIK. It shouldn't affect bug fixes, unless they violate one of the freezes (like string fre

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

FYI :) you may take a look at doc/source/devref/api_plugins.rst which was merged recently you can take a look at http://lists.openstack.org/pipermail/openstack-dev/2015-March/058493.html and its follow up discussion Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen C

Re: [openstack-dev] [nova] Enabling VM post-copy live migration

On 12 March 2015 at 08:41, Luis Tomas wrote: > Hi, > > As part of an European (FP7) project, named ORBIT > (http://www.orbitproject.eu/), I'm working on including the possibility of > live-migrating VMs in OpenStack in a post-copy mode. > This way of live-migrating VMs basically moves the computat

Re: [openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2015 12:21 PM, Alan Pevec wrote: > Hi, > > next Icehouse stable point release 2014.1.4 has been slipping last > few weeks due to various gate issues, see "Recently closed" section > in https://etherpad.openstack.org/p/stable-tracker for detai

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

On 03/11/2015 12:53 PM, Sylvain Bauza wrote: >> Reporting on Scheduler Fails >> >> >> Apparently, some time recently, we stopped logging scheduler fails >> above DEBUG, and that behavior also snuck back into Juno as well >> (https://etherpad.openstack.org/p/PHL-ops-nova

[openstack-dev] [Fuel][Plugins] Migration guide from old to new plugin format

Hi, I would like to announce that we've published a simple guide [1], which describes how to migrate plugin from old format to new one, it can be useful for those who develop the plugins on development version of Fuel (6.1). Plugins doc is a bit outdated, it will be updated soon. The biggest cha

Re: [openstack-dev] Deprecation warnings considered harmful?

Thanks for shining the light everyone, https://review.openstack.org/#/c/163756/ Please if you see more let us know (#openstack-oslo or launchpad) ASAP. -- dims On Thu, Mar 12, 2015 at 6:38 AM, Boris Bobrov wrote: > On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote: >> So, assuming that all

Re: [openstack-dev] Deprecation warnings considered harmful?

On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote: > So, assuming that all of the oslo depreciations aren't going to be fixed > before release What makes you think that? In my opinion it's just one component's problem. These particular deprecation warnings are a result of still on-going mig

Re: [openstack-dev] [Kolla] PTL Candidacy

Candidacy confirmed. -Angus On Thu, Mar 12, 2015 at 6:54 PM, Steven Dake (stdake) wrote: > I am running for PTL for the Kolla project. I have been executing in an > unofficial PTL capacity for the project for the Kilo cycle, but I feel it > is important for our community to have an elected PT

[openstack-dev] [neutron] upgrade scenario after advanced service split

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I was asked to point out to upstream community that the way we did advanced service split introduced some challenges on the packaging side. Specifically, to make upgrade scenario from Juno to Kilo smooth for RDO users, we need to introduce a

Re: [openstack-dev] Deprecation warnings considered harmful?

So, assuming that all of the oslo depreciations aren't going to be fixed before release, we want every user out there to file a bug, for something we know about at release time? This seems to be a very broken model... On 12 March 2015 at 11:41, Boris Bobrov wrote: > On Thursday 12 March 2015 12:

Re: [openstack-dev] Deprecation warnings considered harmful?

On Thu, Mar 12, 2015 at 3:41 AM, Boris Bobrov wrote: > On Thursday 12 March 2015 12:24:57 Duncan Thomas wrote: > > ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync > > /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: > > DeprecationWarning: The oslo namespace package is de

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

On 03/11/2015 02:48 PM, Joe Gordon wrote: > Out of sync Quotas > -- > > https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63 > > The quotas code is quite racey (this is kind of a known if you look at > the bug tracker). It was actually marked as a top sof

Re: [openstack-dev] [Solum] Should app names be unique?

I can attest to the customer preference (from the customer survey and research) to working with names (as opposed to UUIDs). My vote would be to optimize for user experience, and then figure out an implementation approach that solves for that. On the question on blue-green deployments, I am not

Re: [openstack-dev] [swift] auth migration and user data migration

Thanks for the info. On Wed, Mar 11, 2015 at 10:50 AM, Clay Gerrard wrote: > > > On Mon, Mar 9, 2015 at 12:27 PM, Weidong Shao > wrote: > >> >> I noticed swauth project is not actively maintained. In my local testing, >> swauth did not work after I upgraded swift to latest. >> >> > Hrm... I thi

Re: [openstack-dev] [cinder] cinder is broken until someone fixes the forking code

Mike Perez wrote: > On 11:49 Wed 11 Mar , Walter A. Boring IV wrote: >> We have this patch in review currently. I think this one should >> 'fix' it no? >> >> Please review. >> >> https://review.openstack.org/#/c/163551/ > > Looks like it to me. Would appreciate a +1 from Mike Bayer bef

Re: [openstack-dev] Deprecation warnings considered harmful?

On Thursday 12 March 2015 12:24:57 Duncan Thomas wrote: > ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync > /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: > DeprecationWarning: The oslo namespace package is deprecated. Please use > oslo_i18n instead. > from oslo import

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

Hi, The 'cloud_admin' policy file requires domain-scoped to work to work. Horizon does not currently support domain scope token yet. So yes, it is a gap in horizon at the moment. There are on-going patches to address this in horizon: - https://review.openstack.org/#/c/141153/ - https://review.op

[openstack-dev] [neutron][sriov] status of neutron sriov passthrough support

Hello, I was looking at the neutron pci sriov integration, to see what's the current state, but I still have a few questions. Maybe one of you could help out. I'm referring to the direct passthrough and not to the macvtap passthrough right now: - Only VLAN for the tenant network is supported. Is

Re: [openstack-dev] [neutron] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer

- Original Message - > Congratulations, well deserved ! > > > On 03/11/2015 07:54 PM, Kyle Mestery wrote: > > On Wed, Mar 4, 2015 at 1:42 PM, Kyle Mestery > > wrote: > > > > I'd like to propose that we add Ihar Hrachyshka to the Neutron core > > rev

[openstack-dev] [oslo] oslo.concurrency runtime dependency on fixtures/testtools

Hi, hijacking this thread to point out something that feels wrong in the dependency chain which jumped out: > Colecting testtools>=0.9.22 (from > fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395) fixtures is imported in oslo_concurrency/fixture/lockutils.py but that's not real

[openstack-dev] Deprecation warnings considered harmful?

ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_i18n instead. from oslo import i18n /opt/stack/cinder/cinder/openstack/common/policy.py:98: Depre

Re: [openstack-dev] Avoiding regression in project governance

Some clarification about Murano: >3. *Maybe*. Not sure about the scope, it is fairly broad and there may be some open ended corners, >such as some references to billing. On the other hand an application catalog sounds really useful >and like a measured progression for OpenStack as a whole. Murano

[openstack-dev] [cinder] cinder is broken until someone fixes the forking code

Hello Cinder - I’d like to note that for issue https://bugs.launchpad.net/oslo.db/+bug/1417018, no solution that actually solves the problem for Cinder is scheduled to be committed anywhere. The patch I proposed for oslo.db is on hold, and the patch proposed for oslo.incubator in the service code

Re: [openstack-dev] [Openstack] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

Hello, Does user_id replaced in cloud_admin rule is id of cloud_admin user ? I don't think you can log in with cloud_admin user in horizon, it seems that without project created for an user, you can't log in in horizon. I'm also interested in this, I also followed the mentioned article, but when

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On Tue, Mar 10, 2015 at 12:06 PM, Ryan Moats wrote: > While I'd personally like to see this be restricted (Carl's position), I > know > of at least one existence proof where management applications are doing > precisely what Gabriel is suggesting - reusing the same address range to > minimize the

Re: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package

Is it using an old version of setuptools? Like <0.6.28. > On Mar 11, 2015, at 11:28 AM, Timothy Swanson (tiswanso) > wrote: > > I don’t have any solution just chiming in that I see the same error with > devstack pulled from master on a new ubuntu trusty VM created last night. > > 'pip install

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

I am pleased to say that we are now in a good position with this patch. The necessary DHCPv6 client changes have been made available in the latest release of Dibbler (1.0.1) and we’re getting some much appreciated assistance from Ihar and Thomas in having this new version packaged for wide availabi

[openstack-dev] [Kolla] PTL Candidacy

I am running for PTL for the Kolla project. I have been executing in an unofficial PTL capacity for the project for the Kilo cycle, but I feel it is important for our community to have an elected PTL and have asked Angus Salkeld, who has no outcome in the election, to officiate the election [1]

[openstack-dev] [nova] Enabling VM post-copy live migration

Hi, As part of an European (FP7) project, named ORBIT (http://www.orbitproject.eu/), I'm working on including the possibility of live-migrating VMs in OpenStack in a post-copy mode. This way of live-migrating VMs basically moves the computation right away to the destination and then the VM sta

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

>The biggest disconnect in the model seems to be that Neutron assumes you want self service networking. Most of these deploys don't. Or even more importantly, they live in an organization where that is never going to be an option. >Neutron provider networks is close, except it doesn't provide for

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

On 03/10/2015 08:52 PM, Joe Gordon wrote: > > On Tue, Mar 10, 2015 at 5:09 PM, Alan Pevec > wrote: > > > The wheel has been removed from PyPI and anyone installing testtools > > 1.7.0 now will install from source which works fine. > > On stable/icehouse devs

Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

Hi, as you have a separate monitoring solution (not Ceilometer), it seems you can use ResourceGroup instead of AutoscalingGroup and issue heatclient/rest calls to do a stack-update with desired size of the group when needed. The group members will be numbered, and as already said you can also cont

[openstack-dev] [nova] readout from Philly Operators Meetup

The last couple of days I was at the Operators Meetup acting as Nova rep for the meeting. All the sessions were quite nicely recorded to etherpads here - https://etherpad.openstack.org/p/PHL-ops-meetup There was both a specific Nova session - https://etherpad.openstack.org/p/PHL-ops-nova-feedback

Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

I am familiar of the removal policies. Thanks! Our use case for parameters on scale out is as follows: Every server has a unique index that identifies it. The first server has an index of 1, the second has an index of 2, etc. The index of each server must exist prior to the configuration phase of

Re: [openstack-dev] [neutron] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer

Congratulations, well deserved ! On 03/11/2015 07:54 PM, Kyle Mestery wrote: > On Wed, Mar 4, 2015 at 1:42 PM, Kyle Mestery > wrote: > > I'd like to propose that we add Ihar Hrachyshka to the Neutron core > reviewer team. Ihar has been doing a great job revie

[openstack-dev] [Murano] PTL Candidacy

Hi folks, I'd like to announce my candidacy as PTL for Murano [1]. I was handling PTL responsibilities in this release cycle so far, after Ruslan Kamaldinov (who was handling them in Juno cycle) hand over them to me on OpenStack Summit in Paris. I am working on Murano since it's kick-off two year

Re: [openstack-dev] Avoiding regression in project governance

Ed Leafe wrote: > [...] > So what is "production-ready"? And how would you trust any such > designation? I think that it should be the responsibility of groups > outside of OpenStack development to make that call. We discussed that particular point at the Ops Summit: how to describe and objectivel

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

I agree with dropping support for the wildcards. It can always be revisited at later. I agree that being locked into backward compatibility with a design that we really haven't thought through is a good thing to avoid. Most importantly (to me anyway) is that this will help in getting subnet al

Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

hi, just to follow-up, thanks for the input, the usability of ceilometer is obviously a concern of ours and something the team tries to address with the resources we have. as a quick help/update, here are some points of interests that i think might help:- if using Juno+, DO use the notifier:// p

Re: [openstack-dev] [stacktach] [oslo] stachtach -> kombu -> pika ??

> We're going to be adding support for consuming from and writing to Kafka as > well and will likely use a kafka-specific library for that too. is the plan to add this support to oslo.messaging? i believe there is interest from the oslo.messaging team in supporting Kafka and in addition to addin

Re: [openstack-dev] Avoiding regression in project governance

Joe Gordon wrote: > On Tue, Mar 10, 2015 at 9:29 AM, Russell Bryant > wrote: >> We now have several new project proposals. However, I propose not >> approving any new projects until we have a tagging system that is at >> least far enough along to represent t

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Blocking the acceptance of new projects seems punitive and against the spirit of the big tent. Classification (tagging) can be done at any point, and is hardly fixed in stone. You can refine tags as needed. To put it harshly: it is a failure of both

Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

+1 > On Mar 9, 2015, at 6:03 PM, Devananda van der Veen > wrote: > > Hi all, > > I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core. > > He's been consistently providing good code reviews, and been in the top five > active reviewers for the last 90 days and top 10 for the las

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 12:47 PM, Doug Hellmann wrote: > > > On Tue, Mar 10, 2015, at 12:46 PM, Doug Hellmann wrote: >> I think we made it pretty clear that we would be taking approvals >> slowly, and that we might not approve any new projects before the >> summit, precisely for the reasons you state here.

Re: [openstack-dev] [neutron][lbaas] v2 vendor drivers

On Tue, Mar 10, 2015 at 12:08 PM, Doug Wiegley wrote: > Hi all, > > LBaaS v2 is going out in Kilo, and we have quite a few vendor drivers > ready to merge, but most are waiting for the tempest tests/job to be done > before they can satisfy their third-party CI requirements. Because that > job is

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 11:46 AM, Doug Hellmann wrote: > > > On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: > > The TC is in the middle of implementing a fairly significant change in > > project governance. You can find an overview from Thierry on the > > OpenStack blog [1]. > > > > Pa

[openstack-dev] [stacktach] [oslo] stachtach -> kombu -> pika ??

Hi all, I saw the following on https://etherpad.openstack.org/p/PHL-ops-rabbit-queue and was wondering if there was more explanation of why? The StackTach team is switching from Kombu to Pika (at the recommendation of core rabbitmq devs). Hopefully oslo-messaging will do the same. I'm won

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 11:29 AM, Russell Bryant wrote: > The TC is in the middle of implementing a fairly significant change in > project governance. You can find an overview from Thierry on the > OpenStack blog [1]. > > Part of the change is to recognize more projects as being part of the > Op

[openstack-dev] [heat] Unknown resource OS::Heat::ScaledResource

Hi, I observed in one of the patch mentioned below, OS::Heat::ScaledResource is reported as unknown, could anyone help here to resolve the issue. Thanks. http://logs.openstack.org/76/157376/8/check/check-heat-dsvm-functional-mysql/c9a1be3/logs/screen-h-eng.txt.gz reports OS::Heat::ScaledResourc

[openstack-dev] [log] Log working group -- Alternate moderator needed for today

Or Cancellation. I'm in the Ops Midcycle meeting and can't guarantee I can join. Meeting meets Wednesdays at 20:00UTC, which is now 11am PDT. --Rocky __ OpenStack Development Mailing List (not for usage questions) Unsubscri

[openstack-dev] [Group-based-policy][GBP] PTL Candidacy

Hi All, I would like to announce my candidacy for the Group Based Policy (GBP) [1] project’s PTL position [2]. I have been involved with GBP for more than a year now. I was responsible for setting it up as a StackForge project across multiple repositories, and have been serving as the de facto le

<    1   2