Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Nicely put, Doug, you gave me laughs :) I can't see how a CR could hang for a month without anyone paying attention if it worths merging. If this really happens (which I'm not aware of), auto-abandon definitely won't make things any worse. -- Best regards, Oleg Gelbukh On Fri, Jul 17, 2015 at 6:

[openstack-dev] What's Up, Doc? 17 July 2015

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I'm very pleased to announce that we finally have a name for our M release: Mitaka (三鷹)! Accordingly, the Tokyo Summit for the Mitaka release is only just over 100 days away. CFP closed a couple of days ago, and I've noticed that the firs

Re: [openstack-dev] [Nova] Device names supplied to the boot request

> Date: Thu, 16 Jul 2015 20:10:45 +0100 > From: ndipa...@redhat.com > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova] Device names supplied to the boot request > > On 07/16/2015 06:35 PM, Matt Riedemann wrote: > > > > > > On 7/16/2015 11:47 AM, Nikola Đipanov wrote

Re: [openstack-dev] [kolla] image bloat

On 17 July 2015 at 15:49, Steven Dake (stdake) wrote: > > > From: Robert Collins > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Thursday, July 16, 2015 at 6:48 PM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [kolla] image bloat >

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

Sean, I agreed with you. But after I read Yan's user case. I think the FWaaS API may become too complex for that case. By extending security group is better option. On Thu, Jul 16, 2015 at 11:48 AM, Sean M. Collins wrote: > On Tue, Jul 14, 2015 at 03:31:49AM PDT, Kevin Benton wrote: > > Unfort

Re: [openstack-dev] [kolla] image bloat

From: Robert Collins mailto:robe...@robertcollins.net>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, July 16, 2015 at 6:48 PM To: OpenStack Development Mailing List mailto:openstack-dev@lists.openstack.org>>

Re: [openstack-dev] [Congress] New IRC meeting time

Wonderful! I don't need to stay up late. Thank everybody. 2015-07-15 10:28 GMT+08:00 Masahito MUROI : > I'm happy to see that. > > btw, is the day on Tuesday? > > best regard, > masa > > On 2015/07/15 9:52, Zhou, Zhenzan wrote: > >> Glad to see this change. >> Thanks for the supporting for devel

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Just adding an experience from another project, Neutron. We had similar debates, and prepping for the long apocalyptic winter of changeset death, Kyle decimated the world and ran the abandon script. The debates were far more intense than the reality, and my large stockpile of Rad-X and Nuka Col

Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination

+1 On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk wrote: > +1 > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov < > vshars...@mirantis.com> wrote: > >> Hi, >> >> we have created separate project for fuel-nailgun

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

I'm with Stanislaw on this one: abandoning reviews just to make numbers *look* better will accomplish nothing. The only benefit I can see is cleaning up reviews that we *know* don't need to be considered, so that it's easier for reviewers to find the reviews that still need attention. I don't see

Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?

Hi Fox and Adrian, Let me summarize, 1) We all agree to replace 'platform' word to 'server_type' (let's not discuss this anymore) 2) For bay-creation now in magnum, We pass it to baymodel. Cloud Operators created lots of baymodels, maybe, like kubernets-vm-baymodel, kubernetes-baremetal-bay

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

For example, in usecase of VM is a LVS (Linux Virtual Server), to make any client's ip outgoing, we need configure allowed_address_pairs to 0.0.0.0/0, or disable security-group on port by setting "port-security-enable" false. After that, mac-level rules are needed to protect other VMs. Does a

Re: [openstack-dev] [kolla] image bloat

On 17 Jul 2015 12:30, "Steven Dake (stdake)" wrote: > > Hey folks, > > > The bloat on the from-source comes from the C toolchain. The bloat on the binary images comes from our common dependency layer. We can probably just get rid of all the Python dependency installs that occur in the common la

[openstack-dev] [glance] V3 authentication to swift

Glancers, A while ago I wrote an email outlining a couple of ways we could support keystone v3 authentication when using swift as a backend for glance_store. In the long term it would be best to transition swiftclient to use sessions as this would allow us to do more extensive (kerberos, ssl e

[openstack-dev] [Neutron] Concern about networking-sfc and community process

Hi Cathy, You recently merged the following patch, by +2'ing and then Workflow+1'ing it, without allowing reviewers the chance to look at the changes between the patchset where there were -1's and the newer patchsets. https://review.openstack.org/#/c/192933/ I do see that you were asking on -inf

[openstack-dev] [kolla][magnum] PTO July 20-24th

I likely will not be making the team meetings the following week as I’m taking a week of PTO. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.

[openstack-dev] [kolla] image bloat

Hey folks, Playing with from source builds and comparing them to from binary builds, I noticed our binary images are much larger: >From source: kollaglue/centos-source-magnum-api latest f822f446c882About a minute ago 510.8 MB kollaglue/centos-sourc

Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?

Adrian, I know for sure you can attach key=value metadata to the flavors. I just looked up in the admin guide, (http://docs.openstack.org/admin-guide-cloud/content/customize-flavors.html) and it mentions that the extra_specs key=value pairs are just used for scheduling though. :/ So, Nova wou

Re: [openstack-dev] [glance] Progress of the Python 3 port

On Wed, Jul 15, 2015 at 10:39:11AM +0200, Victor Stinner wrote: > Hi, > Any update on this release? This has now been released in glance_store 0.7.0 Cheers, Louis signature.asc Description: Digital signature __ OpenStack De

Re: [openstack-dev] [qa] Status of account creds in the [identity] section of tempest.conf

On Fri, Jun 19, 2015 at 10:30 AM Matthew Treinish wrote: > On Thu, Jun 18, 2015 at 02:13:56PM -0400, David Kranz wrote: > > We had a discussion about this at the qa meeting today around the > following > > proposal: > > > > tl;dr The test accounts feature provides the same functionality as the >

Re: [openstack-dev] [QA][Tempest] Proposing Jordan Pittier for Tempest Core

I'm late in my reply, but I can still give my +1 and say welcome to the team Jordan! On Mon, Jun 29, 2015 at 4:26 PM Jordan Pittier wrote: > Thanks a lot ! > I just want to say that I am happy about this and I look forward to > continue working on Tempest with you all. > > Cheers, > Jordan > > O

Re: [openstack-dev] [qa] identity v3 issue causing non-admin job to fail

Hi David, admin_domain_name is used at the moment to fill in the domain when missing in a few cases. The get_credentials method is one of them. Another two are setting the default domain for the users in tempest.conf [0], and setting the domain for credentials loaded from a YAML file [1]. [0] htt

Re: [openstack-dev] [neutron] What does flavor mean for a network?

Neil, flavor:network is for Metaplugin. It is unrelated to flavor framework. FYI, Metaplugin will be removed in liberty. https://review.openstack.org/#/c/192056/ Thanks. Itsuro Oda (oda-g) On Thu, 16 Jul 2015 10:44:01 +0100 Neil Jerram wrote: > Thanks everyone for your responses... > > On 1

Re: [openstack-dev] [nova] Exposing provider networks in network_data.json

On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: > So it looks like there is a missing part in this feature. There should > be a way to "hide" this information if the instance does not require to > configure vlan interfaces to make network functional. I just commented on the review, bu

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Kevin, You make a really good point. Reducing required inputs from users in exchange for a little more setup by cloud operators is a well justified tradeoff. I'm pretty sure flavors in Nova can have tag Metadata added without a nova extension, right? Can someone check to be sure? If we do have

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Hi, Let's put openstack.yaml to package if it requires for master node upgrade. Environment update part should be removed as it never reached production state. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 8:07 AM, Matthew Mosesohn wrote: > One item th

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko wrote: > Hi, > > guys, what if we "simplify" things a bit? All we need is: > >1. Remove all the community modules from fuel-library. >2. Create 'Puppetfile' with list of community modules and their >versions that we currently us

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Good point. +1 on server_type. it seems reasonable. As for the need, I'd really rather not have my users have to know how to map flavors to server_types themselves. Its something they will get wrong at times, and we'll get emails about/spend time explaining. The lack of heat conditionals has b

[openstack-dev] [sahara] keystone session upgrade

hi all, i've been researching, and coding, about how to upgrade sahara to use keystone sessions for authentication instead of our current method. i'm running into some issues that i believe might make the current proposed approach[1] unfeasible. one issue i'm running into is the nature of ho

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

On 07/16/2015 05:19 PM, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: >> Hi all, >> >> I ended up here: >> https://github.com/linsomniac/python-memcached/issues/54 >> https://github.com/linsomniac/python-memcached/pull/67 >> >> while chasing a

[openstack-dev] [neutron][fwaas] Usecase classification

Hi all, Over the past day at the Advanced Services midcycle in Seattle[1], a group of us gathered to try and categorize the usecases collected in the etherpad[2] into more specific buckets. The work product of that effort is located at https://trello.com/b/TIWf4dBJ/fwaas-usecase-categorization T

[openstack-dev] [nova] Exposing provider networks in network_data.json

Hi, I stubble on this review [1] which proposes adding info about provider networks in network_data.json. Concerns were raised by Kevin Benton about how those information shouldn't be exposed to virtual instances for various reasons you can read in the review and I totally agree with those concer

[openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from thi

Re: [openstack-dev] [fuel] Meeting July 16

Meeting minutes are available at http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-16-16.00.html On Wed, Jul 15, 2015 at 3:36 PM Andrew Woodward wrote: > Please note the IRC meeting is scheduled for 16:00 UTC in > #openstack-meeting-alt > > Please review meeting agenda and update i

[openstack-dev] [fuel] NodeGroups vs network-templates and static routes

In 6.0 we added nodegroups as part of the multiple-cluster-networks features. With these you can add additional sets of networks with so that the nodes can exist on different network segments. When these are used you will also need to set the gateway for each of your networks. When you do this, you

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

To be clear we have two pursuits on this thread: 1) What to rename bay.blatform to. 2) How we might eliminate the attribute, or replace it with something more intuitive We have a consensus now on how to address #1. My direction to Kannan is to proceed using server_type as the new attribute name

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 06:35 PM, Matt Riedemann wrote: > > > On 7/16/2015 11:47 AM, Nikola Đipanov wrote: >> On 07/16/2015 11:24 AM, Sean Dague wrote: >>> On 07/15/2015 01:41 PM, Andrew Laski wrote: On 07/15/15 at 12:19pm, Matt Riedemann wrote: >>> > The other part of the discussion is around th

Re: [openstack-dev] [Fuel] Nominate Denys Klepikov for fuel-docs core

+1 On Thu, Jul 16, 2015 at 8:40 AM Miroslav Anashkin wrote: > +1 > > -- > > *Kind Regards* > > *Miroslav Anashkin**L2 support engineer**,* > *Mirantis Inc.* > *+7(495)640-4944 (office receptionist)* > *+1(650)587-5200 (office receptionist, call from US)* > *35b, Bld. 3, Vorontsovskaya St.* > *Mo

Re: [openstack-dev] [Fuel Zabbix in deployment tasks

I thought it was done... Stas - do you know anything about it? On Thu, Jul 16, 2015 at 9:18 AM Sergii Golovatiuk wrote: > Hi, > > Working on granular deployment, I realized we still call zabbix.pp in > deployment tasks. As far as I know zabbix was moved to plugin. Should we > remove zabbix from

[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 07/16/2015

Hi Everyone, Thanks for joining the service chaining project meeting on 7/16/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ OpenStack Development M

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

On 16/07/2015 12:05 AM, Angus Salkeld wrote: Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? yes, we discussed this last week during our midcycle. the plan going forward is to allow current existing Ceilometer alarm f

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

On 07/14/2015 11:58 AM, Luigi Toscano wrote: On Tuesday 14 of July 2015 10:33:18 Ihar Hrachyshka wrote: On 07/14/2015 01:46 AM, Perry, Sean wrote: -Original Message- From: Doug Hellmann I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be ma

[openstack-dev] Barbican : Need help as to how to test the integration of Barbican with the HSM

Hi All , I would need help to test the integration of Barbican with HSM. Have configured the Barbican client to connect to HSM server by registering barbican IP to the HSM server and have assigned the partition. Have modified the barbican.conf file with the following changes : #

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 7/16/2015 11:47 AM, Nikola Đipanov wrote: On 07/16/2015 11:24 AM, Sean Dague wrote: On 07/15/2015 01:41 PM, Andrew Laski wrote: On 07/15/15 at 12:19pm, Matt Riedemann wrote: The other part of the discussion is around the API changes, not just for libvirt, but having a microversion that

Re: [openstack-dev] [all][ptl][release] New library release request process

Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500: > On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann > wrote: > > > Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > > > Doug, > > > > > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > >

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/16/2015 05:08 PM, Thomas Goirand wrote: > On 07/16/2015 03:29 PM, Ihar Hrachyshka wrote: >> Working on upstream gate stability obviously does not invalidate >> any effort to introduce distribution CI votes in gerrit, and I >> would be happy to

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On 7/16/2015 4:57 AM, Sean Dague wrote: On 07/15/2015 08:12 PM, GHANSHYAM MANN wrote: On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague wrote: On 07/15/2015 01:44 PM, Matt Riedemann wrote: The osapi_v3.enabled option is False by default [1] even though it's marked as the CURRENT API and the v2 AP

[openstack-dev] [rpm-packaging] Meeting minutes IRC meeting July 16th

Hi, extraction of the meeting minutes from https://etherpad.openstack.org/p/openstack-rpm-packaging we agreed to switch to the standard way of doing meeting minutes once the infra review got merged. its a bit of a short minutes, feel free to reach out to number80 or me in case you have questions.

[openstack-dev] [all][api] New API Guidelines read for cross project review

hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 3. Adds guidance on request bodies with different Methods htt

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 05:47 PM, Nikola Đipanov wrote: > > Also, not being able to specify device names would make it impossible to > implement certain features that EC2 API can provide, such as overriding > the image block devices without significant effort. > I forgot to add links that explain this in

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 11:24 AM, Sean Dague wrote: > On 07/15/2015 01:41 PM, Andrew Laski wrote: >> On 07/15/15 at 12:19pm, Matt Riedemann wrote: > >>> The other part of the discussion is around the API changes, not just >>> for libvirt, but having a microversion that removes the device from >>> the reques

[openstack-dev] [Fuel Zabbix in deployment tasks

Hi, Working on granular deployment, I realized we still call zabbix.pp in deployment tasks. As far as I know zabbix was moved to plugin. Should we remove zabbix from 1. Deployment graph 2. fixtures 3. Tests 4. Any other places Are we going to clean up zabbix code as part of migration to plugin?

[openstack-dev] [nova] Non-Priorty Feature Proposal Freeze has happened

Hi, Just a quick heads up about today's blueprint activities. The main aims here are: * focus on the agreed priorities (including bug fixes) during liberty-3 * optimise for max number of complete blueprints * focus review effort on the things that are already being reviewed now The following doc

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Wait... so the issue is if you were to just use nova flavor, you don't have enough information to choose a set of templates that may be more optimal for that flavor type (like vm's or bare metal)? Is this a NaaS vs flatdhcp kind of thing? I just took a quick skim of the heat templates and it was

Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination

+1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov wrote: > Hi, > > we have created separate project for fuel-nailgun-agent. At now moment > only i have core-reviewer rights.We hardly need more core reviewers here. > > I want t

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

On Tue, Jul 14, 2015 at 03:31:49AM PDT, Kevin Benton wrote: > Unfortunately the security groups API does not have mac-level rules right > now. There is also the fact that the Security Group API is limited (by design) to do fairly simple things, and also that the model has similar fields to the AWS

Re: [openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

On Thu, Jul 16, 2015 at 10:29 AM, Davanum Srinivas wrote: > Adam, > > For 1, do we let user configure max_active_keys? what's the default? > The default in keystone is 3, simply to support having one key in each of the three phases of rotation. You can increase it from there per your desired rot

Re: [openstack-dev] [Fuel] Nominate Denys Klepikov for fuel-docs core

+1 -- *Kind Regards* *Miroslav Anashkin**L2 support engineer**,* *Mirantis Inc.* *+7(495)640-4944 (office receptionist)* *+1(650)587-5200 (office receptionist, call from US)* *35b, Bld. 3, Vorontsovskaya St.* *Moscow**, Russia, 109147.* www.mirantis.com manash...@mirantis.com

Re: [openstack-dev] [os-ansible-deployment] [openstack-ansible] Using commit flags appropriately

+1 - I think we should start doing this immediately. -- Kevin Carter Racker, Developer, Hacker @ The Rackspace Private Cloud. From: Ian Cordasco Sent: Thursday, July 16, 2015 10:12 AM To: OpenStack Development Mailing List (not for usage questions) Subj

Re: [openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

Adam, For 1, do we let user configure max_active_keys? what's the default? Please note that there is a risk that an active token may be invalidated if Fernet key rotation removes keys early. So that's a potential issue to keep in mind (relation of token expiry to period of key rotation). thanks,

Re: [openstack-dev] [Neutron]Request for help to review a patch

Hi Neil, Nice suggestion :-) Thanks, Wei Wang 2015-07-16 15:46 GMT+08:00 : > As it is a bug fix, perhaps you could add this to the agenda for the next > Neutron IRC meeting, in the Bugs section? > > Regards, > Neil > > > *From: *Damon Wang > *Sent: *Thursday, 16 July 2015 07:18 > *To: *

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

+1, seems like the best choice. Ton Ngo, From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 06:33 AM Subject:Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? I am O

[openstack-dev] [Fuel] Nailgun agent core reviewers nomination

Hi, we have created separate project for fuel-nailgun-agent. At now moment only i have core-reviewer rights.We hardly need more core reviewers here. I want to nominate Vladimir Kozhukalov to fuel-nailgun-agent core. At now moment Vladimir is one of the main contributor in nailgun-agent. Please r

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: > Hi all, > > I ended up here: > https://github.com/linsomniac/python-memcached/issues/54 > https://github.com/linsomniac/python-memcached/pull/67 > > while chasing a keystone py34 CI problem since memcached is running

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Hi, Le 16/07/2015 17:00, Davanum Srinivas a écrit : I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 Oh, that's my pull request :-) Multiple peoples asked to merge my pull request, and I pinged explicitly the main

[openstack-dev] [os-ansible-deployment] [openstack-ansible] Using commit flags appropriately

Hey everyone, Now that the project is starting to grow and has some amount of documentation. We should really start using flags in our commits more appropriately, e.g., "UpgradeImpact", "DocImpact", etc. For example, my own recent change to upgrade our keystone module to use v3 should have also h

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/16/2015 03:29 PM, Ihar Hrachyshka wrote: > Working on upstream gate stability obviously does not invalidate any > effort to introduce distribution CI votes in gerrit, and I would be > happy to see RDO or Ubuntu meaningfully voting on backports. It's my > belief though that distribution CI vot

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassi

[openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Hi all, I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 while chasing a keystone py34 CI problem since memcached is running in our CI VM: https://review.openstack.org/#/c/177661/ and got word from @zigo that this li

Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?

In re: Normalized units. I agree that this is dependent upon benchmarking and there are many issues with the reliability of benchmarks. Having said that, I think normalized units is a much better metric to be using than CPU frequency. The reality is that the end user doesn't care about CPU fr

[openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

Hi Folks, Keystone supports Fernet tokens which have payload encrypted by AES 128 bit key. Although AES 128 bit key looks secure enough for most OpenStack deployments [2], one may would like to rotate encryption keys according to already proposed 3 step key rotation scheme (in case keys get comprom

[openstack-dev] [Mercador] Meeting this week

The Mercador meeting this week will be a break-out from the Keystone sprint (as well as on IRC). See https://wiki.openstack.org/wiki/Meetings/MercadorTeamMeeting Geoff

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, guys, what if we "simplify" things a bit? All we need is: 1. Remove all the community modules from fuel-library. 2. Create 'Puppetfile' with list of community modules and their versions that we currently use. 3. Make sure all our customizations are proposed to the upstream modules

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/16/2015 03:27 AM, Alex Xu wrote: > >> Honestly, we should probably deprecate out osapi_v3.enabled make >> it osapi_v21 (or osapi_v2_microversions) so as to not confuse >> people further. > > +1 for renaming it to osapi_v21 (or osapi_v2_microv

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/16/2015 03:06 PM, Thomas Goirand wrote: > What we discussed was that distributions would run their own CI > and validate patches away from upstream CI, then we would agree on > a patch and share it. > That's fine. I think a good start would b

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: "Balle, Susanne" mailto:susanne.ba...@hp.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.ope

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

I am OK with server_type as well. From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: July-16-15 3:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? + 1 about server_type. I also

Re: [openstack-dev] [all][ptl][release] New library release request process

On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann wrote: > Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > > Doug, > > > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > > How do you want to handle these? > > There are some tools in the repository to

Re: [openstack-dev] [Fuel] Getting rid of launchpad group fuel-astute

Hi, Agree, most of the python developers are familiar with Astute. But at the same time it can look strange when we assign Astute (which is written in Ruby) bugs to the group which is called fuel-python :) Thanks, On Thu, Jul 16, 2015 at 2:21 PM, Alexander Kislitsky < akislit...@mirantis.com> wr

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/15/2015 12:37 PM, Ihar Hrachyshka wrote: > On 07/14/2015 09:14 PM, Thomas Goirand wrote: >> On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote: >>> On 07/14/2015 12:33 AM, Thomas Goirand wrote: I missed this announce... >>> On 07/02/2015 05:32 AM, Jeremy Stanley wrote: > Per the Iceh

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

One item that will impact this separation is that fuel_upgrade implicitly depends on the openstack.yaml release file from fuel-nailgun. Without it, the upgrade process won't work. We should refactor fuel-nailgun to implement this functionality on its own, but then have fuel_upgrade call this piece.

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/15/2015 12:05 PM, Thierry Carrez wrote: > The "cost" of keeping stable branches around without CI is more a > branding cost than a technical cost, I think. Which is why I suggested to rename the branches, if it poses a problem. For example eol/icehouse would have been fine. > An OpenStack u

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, Good, thank you for extended answer. -- Best regards, Oleg Gelbukh On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Oleg, > > Yes, you are right. At the moment all docker containers are packaged into > a single rpm package. Yes, it would be gre

Re: [openstack-dev] [neutron][db] online-schema-migrations patch landed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/15/2015 04:03 PM, Salvatore Orlando wrote: > Do you reckon that the process that led to creating a migration > like [1] should also be documented in devref? https://review.openstack.org/202534 -BEGIN PGP SIGNATURE- Version: GnuPG v2 i

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Oleg, Yes, you are right. At the moment all docker containers are packaged into a single rpm package. Yes, it would be great to split them into several one-by-one rpms, but it is not my current priority. I'll definitely think of this when I'll be moving so called "late" packages (which depend on o

[openstack-dev] [nova] Nova API Meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Friday UTC1200. In other timezones the meeting is at: EST 08:00 (Fri) Japan 21:00 (Fri) China 20:00 (Fri) United Kingdom 13:00 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/wi

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

I think it is better to block PUT for device_owner/device_id by regular users. It can be controlled by policy.json. If we do this change, we need to do it carefully because nova calls neutron port operations with regular user privilege if port binding extension is not supported. I agree that it is

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, Thank you, now it sounds concieving. My understanding that at the moment all Docker images used by Fuel are packaged in single RPM? Do you plan to split individual images into separate RPMs? Did you think about publishing those images to Dockerhub? -- Best regards, Oleg Gelbukh On Th

Re: [openstack-dev] [all][ptl][release] New library release request process

Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > Doug, > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > How do you want to handle these? There are some tools in the repository to extract the history from a repo. I'll see what I can do for those 2

Re: [openstack-dev] FW: [nova] schedule instance based on CPU frequency ?

From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: Thursday, July 16, 2015 8:07 AM > > On 07/15/2015 04:57 PM, Dugger, Donald D wrote: >> In re: Static CPU frequency. For modern Intel CPUs this really isn't true. >> Turbo Boost is a feature that allows certain CPUs in certain >> condit

[openstack-dev] [Ironic] ENROLL node state is introduced - next steps [ACTION RECOMMENDED]

Hi all! Today we landed a patch [1] that switches (starting with API version 1.11) node creation API to default to ENROLL node state instead of AVAILABLE. Nothing to worry about right now: we don't default to this API version (yet?) in our clients. But read on to figure out how not to get bro

Re: [openstack-dev] [nova] Proposal for an Experiment

On 15 July 2015 at 19:25, Robert Collins wrote: > On 16 July 2015 at 02:18, Ed Leafe wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 > ... >> What I'd like to investigate is replacing the current design of having >> the compute nodes communicating with the scheduler via message queue

[openstack-dev] [Fuel] Getting rid of launchpad group fuel-astute

Dear colleagues, I'd like to get rid of group fuel-astute on launchpad. In group only 2 active members. Actually they are members of fuel-python team. Bugs for fuel-astute project always concern to fuel-web project. Bugs assigned to fuel-astute can stay without attention for a long time. Thus I pr

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Oleg, All docker containers currently are distributed as rpm packages. A little bit surprising, isn't it? But it works and we can easily deliver updates using this old plain rpm based mechanism. The package in 6.1GA is called fuel-docker-images-6.1.0-1.x86_64.rpm So, upgrade flow would be like thi

[openstack-dev] [Freezer] Proposing new core reviewers

All, At the Freezer Team, we think it's time to revisit the core reviewers for the Project. The idea behind this would be add as core reviewer the engineers that delivered a complete feature in the Project and actively participated to the other reviews, meetings and conversations on the IRC cha

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/15/2015 01:41 PM, Andrew Laski wrote: > On 07/15/15 at 12:19pm, Matt Riedemann wrote: >> The other part of the discussion is around the API changes, not just >> for libvirt, but having a microversion that removes the device from >> the request so it's no longer optional and doesn't provide s

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhanc

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, I am fully support moving fuel-upgrade-system into repository of its own. However, I'm not 100% sure how docker containers are going to appear on the upgraded master node. Do we have public repository of Docker images already? Or we are going to build them from scratch during the upgrade

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On 07/15/2015 08:12 PM, GHANSHYAM MANN wrote: > On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague wrote: >> On 07/15/2015 01:44 PM, Matt Riedemann wrote: >>> The osapi_v3.enabled option is False by default [1] even though it's >>> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and >>>

Re: [openstack-dev] [neutron] What does flavor mean for a network?

Thanks everyone for your responses... On 15/07/15 21:01, Doug Wiegley wrote: That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug On Jul 15, 2015, at 12:38 PM, Kev

  1   2   >