Re: [openstack-dev] [OpenStack-Dev][DevStack][Neutron] facing problem in devstack install - No Network found for private

Without looking into the details you're specifying Q_USE_PROVIDER_NETWORKING=True in your local.conf - usually this results in the creation of a single provider network called "public". But the manila devstack plugin seems not to be able to deal with provider networks as it's expecting

[openstack-dev] [kolla] Contributors welcome to kolla-kubernetes 0.5.0

Hey folks, The release team released kolla-kubernetes 0.4.0 Sunday January 15th. Now we are in 0.5.0 development which lasts one month. The general architecture of OpenStack based deployments with a Kubernetes underlay is taking form. There are 5 blueprints in 0.5.0 which we expect should

Re: [openstack-dev] [kuryr] Ocata cycle ending and proposing new people as Kuryr cores

Thanks for all, It's pleasure to work with all of you. Regards, Liping Mao 发件人: Antoni Segura Puimedon 日期: 2017年1月16日 星期一 16:34 至: OpenStack List 抄送: "Liping Mao (limao)" , Ilya Chukhnakov ,

Re: [openstack-dev] [ironic] [infra] Nested KVM + the gate

Clark is right, trove does detect and try to use kvm where possible. The performance has been well worth the change (IMHO). -amrith On Jan 17, 2017 6:53 PM, "Clark Boylan" wrote: > On Tue, Jan 17, 2017, at 03:41 PM, Jay Faulkner wrote: > > Hi all, > > > > Back in late

Re: [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

Hello, I read the meeting log and etherpad, and find that you mentioned OPNFV Multisite and Kingbird project. Some comment on these multi-site related projects: OPNFV multisite, kingbird, tricircle. Multisite is a requirement project in OPNFV to identify the gap and requirement in OpenStack

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

Tony, I have some observations on the new client based on a short term test and a long running test. For short term use it uses 2x the memory compared to the older client. The logic that deals with receiving partial messages from Kafka was completely rewritten in the 1.x series and with logging

Re: [openstack-dev] [ironic] [infra] Nested KVM + the gate

On Tue, Jan 17, 2017, at 03:41 PM, Jay Faulkner wrote: > Hi all, > > Back in late October, Vasyl wrote support for devstack to auto detect, > and when possible, use kvm to power Ironic gate jobs > (0036d83b330d98e64d656b156001dd2209ab1903). This has lowered some job > time when it works, but has

[openstack-dev] [ironic] [infra] Nested KVM + the gate

Hi all, Back in late October, Vasyl wrote support for devstack to auto detect, and when possible, use kvm to power Ironic gate jobs (0036d83b330d98e64d656b156001dd2209ab1903). This has lowered some job time when it works, but has caused failures — how many? It’s hard to quantify as the log

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On 01/17/2017 09:57 AM, mathieu bultel wrote: On 01/17/2017 04:42 PM, Emilien Macchi wrote: On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: Hi Adriano On 01/17/2017 03:05 PM, Adriano Petrich wrote: So I want to make a backwards compatibility job upstream so from

Re: [openstack-dev] openstacksdk and compute limits for projects

On Tue, Jan 17, 2017 at 4:23 PM, Michael Gale wrote: > Hello, > > Does anyone know what the equivalent of the following command would be > via the API? > `openstack limits show --absolute --project ` > > I am using an admin account to pull stats and information from a

[openstack-dev] [tripleo] short term roadmap (actions required)

I'm trying to dress a list of things important to know so we can successfully deliver Ocata release, please take some time to read and comment if needed. == Triaging Ocata & Pike bugs As we discussed in our weekly meeting, we decided to: * move ocata-3 low/medium unassigned bugs to pike-1 *

[openstack-dev] openstacksdk and compute limits for projects

Hello, Does anyone know what the equivalent of the following command would be via the API? `openstack limits show --absolute --project ` I am using an admin account to pull stats and information from a Mitaka environment, now I can run the above command in bash, looping over each project

Re: [openstack-dev] [security] FIPS compliance

-Original Message- From: Doug Hellmann Reply: OpenStack Development Mailing List (not for usage questions) Date: January 17, 2017 at 10:53:06 To: openstack-dev Subject:  Re: [openstack-dev]

Re: [openstack-dev] [devstack][keystone] DRaaS for Keystone

Hi Wasiq! On Tue, Jan 17, 2017 at 1:34 PM, Wasiq Noor wrote: > Hello, > > I am Wasiq from Namal College Mianwali, Pakistan. Following the link: > https://wiki.openstack.org/wiki/DisasterRecovery, I have developed a > disaster recovery solution for Keystone for various

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

-Original Message- From: Jay Pipes Reply: OpenStack Development Mailing List (not for usage questions) Date: January 17, 2017 at 12:31:21 To: openstack-dev@lists.openstack.org Subject:  Re:

[openstack-dev] [release][ptl] final reminder about non-client library releases

The deadline for non-client library releases is Thursday 19 Jan. We do not grant Feature Freeze Extensions for any libraries, so that is a hard freeze date. Any feature work that requires updates to non-client libraries should be prioritized so it can be completed by that time. We have quite a

[openstack-dev] [devstack][keystone] DRaaS for Keystone

Hello, I am Wasiq from Namal College Mianwali, Pakistan. Following the link: https://wiki.openstack.org/wiki/DisasterRecovery, I have developed a disaster recovery solution for Keystone for various recovery mechanism. I have the code with me. Can anybody help how can I make it into the devstack

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 01/16/2017 07:19 PM, Joshua Harlow wrote: Fox, Kevin M wrote: Your right, it is not what the big tent was about, but the big tent had some unintended side affects. The list, as you stated: * No longer having a formal incubation and graduation period/review for applying projects * Having a

Re: [openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

Excerpts from Dmitry Tantsur's message of 2017-01-17 18:48:59 +0100: > On 01/17/2017 04:55 PM, Doug Hellmann wrote: > > In this review for the ironic-inspector-client newton release [1], Alan > > pointed out that the new release was pulled into our master requirements > > because the constraints

Re: [openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

Excerpts from Jeremy Stanley's message of 2017-01-17 18:15:59 +: > On 2017-01-17 18:48:59 +0100 (+0100), Dmitry Tantsur wrote: > [...] > > In theory there is nothing wrong with this, as 1.10 is the latest > > release indeed. In practice, that means pulling in something with > > stable/newton

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 01/17/2017 07:57 AM, Ian Cordasco wrote: On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar wrote: Ian, This is a fascinating conversation. Let me offer two observations. First, Trove has long debated the ideal solution for storing secrets. There have been many

Re: [openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

From: Jeremy Stanley Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Tuesday, January 17, 2017 at 10:15 AM To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

On 2017-01-17 18:48:59 +0100 (+0100), Dmitry Tantsur wrote: [...] > In theory there is nothing wrong with this, as 1.10 is the latest > release indeed. In practice, that means pulling in something with > stable/newton requirements into master, which is concerning, I > agree. [...] I don't really

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17 2017, Jeremy Stanley wrote: > Others have already answered most of your questions in this thread, > but since nobody from the VMT has chimed in yet I'll just state on > our behalf that we're generally happy to consult privately or > publicly on any suspected vulnerability report

Re: [openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

On 01/17/2017 04:55 PM, Doug Hellmann wrote: In this review for the ironic-inspector-client newton release [1], Alan pointed out that the new release was pulled into our master requirements because the constraints bot saw it as a newer release. That doesn't seem like something we want to have

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

I would consider that to be something that spans further than just barbican and keystone. The ability to restrict a token to a single service/operation/resource is a super interesting problem especially when you start to consider operational dependencies between the services. If the approach spans

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 1/17/17, 5:37 AM, "Thierry Carrez" wrote: >I think the focus question is an illusion, as Ed brilliantly explained >in https://blog.leafe.com/openstack-focus/ > >The issue here is that it's just a lot more profitable career-wise and a >lot less risky to work first-level

[openstack-dev] Attempting to proxy websockets through Apache or HAProxy for Zaqar

Hi - In an attempt to work on [0], I've been playing around with proxying all the service API endpoints that the UI needs to communicate with, through either haproxy or Apache to avoid a bug[1] around how non-Chrome browsers handle SSL connections to different ports on the same domain. The

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On 2017-01-17 13:26:02 +0100 (+0100), Julien Danjou wrote: > I've asked on #openstack-security without success, so let me try here > insteead: > > We, Telemetry, have a security bug and we're not managed by VMT, any > hint as how to handle our bug? Or how to get covered by VMT?  Others have

Re: [openstack-dev] [security] FIPS compliance

I completely agree that this shall be upstream first. So the main effort will be on landing this python patch first. This has been up since 2010, so more effort in terms of code contribution and reviews is needed, I'm happy to collaborate in amending the patch as the reviews are requesting. But

Re: [openstack-dev] [devstack] issues with requiring python3 only tool?

Excerpts from Sean Dague's message of 2017-01-17 11:50:39 -0500: > On 01/17/2017 11:46 AM, Victor Stinner wrote: > > Le 17/01/2017 à 17:36, Sean Dague a écrit : > >> When putting the cli interface on it, I discovered python3's argparse > >> has subparsers built in. This makes building up the cli

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Is this a Barbican problem or a Keystone one? The inability to restrict a token to go only to one service but instead any hacked service can be used to get tokens that can be used on any other service seems to to me to be a more general Keystone architectural problem to solve? Thanks, Kevin

Re: [openstack-dev] [security] FIPS compliance

Excerpts from Ian Cordasco's message of 2017-01-17 05:59:13 -0600: > On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota > wrote: > > Hi, in previous threads, there have been discussions about enabling FIPS, > > and the problems we are hitting with md5 inside OpenStack: > >

Re: [openstack-dev] [devstack] issues with requiring python3 only tool?

On 01/17/2017 11:46 AM, Victor Stinner wrote: > Le 17/01/2017 à 17:36, Sean Dague a écrit : >> When putting the cli interface on it, I discovered python3's argparse >> has subparsers built in. This makes building up the cli much easier, and >> removes pulling in a dependency for that. (Currently

Re: [openstack-dev] [devstack] issues with requiring python3 only tool?

Le 17/01/2017 à 17:36, Sean Dague a écrit : When putting the cli interface on it, I discovered python3's argparse has subparsers built in. This makes building up the cli much easier, and removes pulling in a dependency for that. (Currently the only item in requirements.txt is pbr). This is

Re: [openstack-dev] [security] FIPS compliance

On 2017-01-17 05:59:13 -0600 (-0600), Ian Cordasco wrote: [...] > I think people should work on the Python patches *first*. Once they're > merged, *then* we should potentially create a wrapper (if it's still > necessary at that point) to do this. Yes, I encourage everyone to think back to the

[openstack-dev] [devstack] issues with requiring python3 only tool?

In attempting to get local.conf support into devstack-gate and grenade, some of the more advanced merging scenarios of local.conf fragments have surpassed anyone's desire and ability to do this in awk. So I started down the path of moving the ini file and local.conf manipulation code into a python

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On 01/17/2017 05:19 PM, Emilien Macchi wrote: > On Tue, Jan 17, 2017 at 10:57 AM, mathieu bultel wrote: >> On 01/17/2017 04:42 PM, Emilien Macchi wrote: >>> On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: Hi Adriano On 01/17/2017

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On Tue, Jan 17, 2017 at 10:42:18AM -0500, Emilien Macchi wrote: > On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: > > Hi Adriano > > > > On 01/17/2017 03:05 PM, Adriano Petrich wrote: > > > > So I want to make a backwards compatibility job upstream so from last scrum >

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On Tue, Jan 17, 2017 at 02:48:27PM +, Adriano Petrich wrote: >Mathieu, >    That sounds exactly what we need. Do we run tempest or something on >those to validate it? It doesn't currently run tempest, only some basic sanity tests (crud operations where we create some resources

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On Tue, Jan 17, 2017 at 10:57 AM, mathieu bultel wrote: > On 01/17/2017 04:42 PM, Emilien Macchi wrote: >> On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: >>> Hi Adriano >>> >>> On 01/17/2017 03:05 PM, Adriano Petrich wrote: >>> >>> So I want to

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On 01/17/2017 04:42 PM, Emilien Macchi wrote: > On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: >> Hi Adriano >> >> On 01/17/2017 03:05 PM, Adriano Petrich wrote: >> >> So I want to make a backwards compatibility job upstream so from last scrum >> I got the feeling that

[openstack-dev] [release][requirements] disable constraint bot updates for our own libraries

In this review for the ironic-inspector-client newton release [1], Alan pointed out that the new release was pulled into our master requirements because the constraints bot saw it as a newer release. That doesn't seem like something we want to have happen, as a general case. Should we update the

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

On Tue, Jan 17, 2017 at 9:34 AM, mathieu bultel wrote: > Hi Adriano > > On 01/17/2017 03:05 PM, Adriano Petrich wrote: > > So I want to make a backwards compatibility job upstream so from last scrum > I got the feeling that we should not be adding more stuff to the >

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 01/16/2017 08:35 AM, Ian Cordasco wrote: > Hi everyone, > > I've seen a few nascent projects wanting to implement their own secret > storage to either replace Barbican or avoid adding a dependency on it. > When I've pressed the developers on this point, the only answer I've > received is to

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17 2017, Ian Cordasco wrote: > Or, perhaps the last time people complained that the process > documentation was too detailed and the telemetry project decided it > didn't want to have to follow it? If that's the case, following the > embargoed procedures might not be what you want as

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17, 2017 at 8:02 AM, Julien Danjou wrote: > On Tue, Jan 17 2017, Adam Heczko wrote: > >> Hi Julien, I think that you should follow this [1] workflow. >> >> TL;DR: Pls make sure that if the bug is serious make it private on LP so >> that only core team members can

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

Mathieu, That sounds exactly what we need. Do we run tempest or something on those to validate it? On Tue, Jan 17, 2017 at 2:34 PM, mathieu bultel wrote: > Hi Adriano > > On 01/17/2017 03:05 PM, Adriano Petrich wrote: > > So I want to make a backwards compatibility job

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On Tue, Jan 17, 2017 at 8:04 AM, Duncan Thomas wrote: > controls than this, but they never showed up AFAIK. And that's just the > problem - people think 'Oh, barbican is storing the cinder volume secrets, > great, we're secure' when actually barbican has made the security

Re: [openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

Hi Adriano On 01/17/2017 03:05 PM, Adriano Petrich wrote: > So I want to make a backwards compatibility job upstream so from last > scrum I got the feeling that we should not be adding more stuff to the > experimental jobs due to lack of resources (and large queues) > What kind of "test" do you

[openstack-dev] [neutron] [classifier] Common Classification Framework meeting

Hi all, Common Classification Framework developers and interested parties are invited for today's meeting. The agenda is below, feel free to add more topics. https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_17_January_2017 1700 UTC @ #openstack-meeting. Best

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 11/01/17 09:21, Zane Bitter wrote: From that run, total memory usage by Heat was 2.32GiB. That's a little lower than the peak that occurred near the end of Newton development for the legacy path, but still more than double the current legacy path usage (0.90GiB on the job that ran for that

[openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

Hi all, The agenda is available at: https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 82) Please feel free to add items to the agenda. The meeting while take place on #openstack-meeting. Cheers, Anthony signature.asc Description: Message signed with OpenPGP

[openstack-dev] [TripleO] Upstream backwards compatibility job for Newton oooq

So I want to make a backwards compatibility job upstream so from last scrum I got the feeling that we should not be adding more stuff to the experimental jobs due to lack of resources (and large queues) Is that so? I was thinking about using nonha-multinode-oooq that seems to be working. Is that

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 17 January 2017 at 13:41, Dave McCowan (dmccowan) wrote: > > I don't know everything that was proposed in the Juno timeframe, or > before, but the Nova and Cinder integration has been done now. The > documentation is at [1]. A cinder user can create an encryption key >

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17 2017, Rob C wrote: > Ian has provided advice on how you might become security managed, which > is a good aspiration for any team to have. > > However, if you have a serious security issue that you need help mitigating > the security project can help. We can work with you on the

Re: [openstack-dev] [yaql] Yaql validating performance

Hi Kirill, Thank you for you information. I hope we will have more information about it. Just keep in touch when you guys in Mirantis have some performance results about Yaql. Br, @Nokia/Tuan On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev wrote: > I think fuel team

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17 2017, Adam Heczko wrote: > Hi Julien, I think that you should follow this [1] workflow. > > TL;DR: Pls make sure that if the bug is serious make it private on LP so > that only core team members can access it and propose patches. Please do > not send patches to Gerrit review queue

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 1/16/17, 3:06 PM, "Ian Cordasco" wrote: >-Original Message- >From: Dave McCowan (dmccowan) >Reply: OpenStack Development Mailing List (not for usage questions) > >Date: January 16, 2017 at 13:03:41 >To:

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

From: Duncan Thomas > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Monday, January 16, 2017 at 5:33 PM To: "OpenStack

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

You've done the right thing by posting here with the [Security] tag. Ian has provided advice on how you might become security managed, which is a good aspiration for any team to have. However, if you have a serious security issue that you need help mitigating the security project can help. We

Re: [openstack-dev] [infra][qa][glance] gate-tempest-dsvm-full-ceph-plugin-src-glance_store-ubuntu-xenial failures

On 1/17/17 12:10 AM, GHANSHYAM MANN wrote: > Yea, manage snapshot tests should be skipped on ceph backend. > > I disabled those tests for *-ceph-* jobs and glance-store will be unblocked > after that merged. > > - https://review.openstack.org/#/c/421073/ Thanks for getting the patches up so

Re: [openstack-dev] [yaql] Yaql validating performance

I think fuel team encountered similar problems, I’d advice asking them around. Also Stan (author of yaql) might shed some light on the problem =) -- Kirill Zaitsev Murano Project Tech Lead Software Engineer at Mirantis, Inc On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com)

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Just a quick note on Castellan, at the moment it's not a particularly strong abstraction for key management in general, just the openstack key management interface. The reason this is important is because if I recall correctly, Castellan requires a keystone token for auth. It should be no suprise

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

Hi Julien, I think that you should follow this [1] workflow. TL;DR: Pls make sure that if the bug is serious make it private on LP so that only core team members can access it and propose patches. Please do not send patches to Gerrit review queue but rather attach it to LP bug ticket and discuss

Re: [openstack-dev] [security] [telemetry] How to handle security bugs

On Tue, Jan 17, 2017 at 6:26 AM, Julien Danjou wrote: > Hi, > > I've asked on #openstack-security without success, so let me try here > insteead: > > We, Telemetry, have a security bug and we're not managed by VMT, any > hint as how to handle our bug? Or how to get covered by

[openstack-dev] [neutron] vhost-user server mode and reconnect

Hi everyone I first proposed a series of patches to enable vhost-user with a Qemu server/ ovs client topology last july before the relevant changes To enable this configuration had been release in ovs with dpdk. Since then ovs 2.6 is out and shipping, (2.7 will be out soon) And all of the

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar wrote: > Ian, > > This is a fascinating conversation. Let me offer two observations. > > First, Trove has long debated the ideal solution for storing secrets. There > have been many conversations, and Barbican has been

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On Mon, Jan 16, 2017 at 6:11 PM, Joshua Harlow wrote: >> Is the problem perhaps that no one is aware of other projects using >> Barbican? Is the status on the project navigator alarming (it looks >> like some of this information is potentially out of date)? Has >> Barbican

Re: [openstack-dev] Yaql validating performance

. On Tue, Jan 17, 2017 at 1:10 PM, lương hữu tuấn wrote: > Hi, > > We are now using yaql in mistral and what we see that the process of > validating yaql expression of input takes a lot of time, especially with > the big size input. Do you guys have any information about

[openstack-dev] [security] [telemetry] How to handle security bugs

Hi, I've asked on #openstack-security without success, so let me try here insteead: We, Telemetry, have a security bug and we're not managed by VMT, any hint as how to handle our bug? Or how to get covered by VMT?  Cheers, -- Julien Danjou /* Free Software hacker https://julien.danjou.info

[openstack-dev] Yaql validating performance

Hi, We are now using yaql in mistral and what we see that the process of validating yaql expression of input takes a lot of time, especially with the big size input. Do you guys have any information about performance of yaql? Br, @Nokia/Tuan

Re: [openstack-dev] [security] FIPS compliance

On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota wrote: > Hi, in previous threads, there have been discussions about enabling FIPS, > and the problems we are hitting with md5 inside OpenStack: > http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html >

Re: [openstack-dev] [nova] Different length limit for tags in object definition and db model definition

OK, added to my todo for the next cycle. On Tue, Jan 17, 2017 at 7:08 PM, Matt Riedemann wrote: > On 1/17/2017 3:31 AM, Roman Podoliaka wrote: > >> Hi all, >> >> Changing the type of column from VARCHAR(80) to VARCHAR(60) would also >> require a data migration (i.e.

Re: [openstack-dev] [security] FIPS compliance

On Tue, Jan 17, 2017 at 10:11 AM, Yolanda Robla Mota wrote: > Hi, in previous threads, there have been discussions about enabling FIPS, > and the problems we are hitting with md5 inside OpenStack: > http://lists.openstack.org/pipermail/openstack-dev/2016- >

Re: [openstack-dev] [nova] Different length limit for tags in object definition and db model definition

On 1/17/2017 3:31 AM, Roman Podoliaka wrote: Hi all, Changing the type of column from VARCHAR(80) to VARCHAR(60) would also require a data migration (i.e. a schema migration to add a new column with the "correct" type, changes to the object, data migration logic) as it is not an "online" DDL

Re: [openstack-dev] PTG? / Was (Consistent Versioned Endpoints)

On 13/01/17 14:50 -0800, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2017-01-13 19:44:23 +: Don't want to hijack the thread too much but... when the PTG was being sold, it was a way to get the various developers in to one place and make it cheaper to go to for devs. Now it

Re: [openstack-dev] [TripleO][Mistral][Ansible] Calling Ansible from Mistral workflows

On 12/01/17 15:27 +, Dougal Matthews wrote: Hey all, I just wanted to share a quick experiment that I tried out. I had heard there was some interest in native Ansible actions for Mistral. After much dragging my heels I decided to give it a go, and it turns out to be very easy. This code is

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 16/01/17 16:57 -0500, Jay Pipes wrote: On 01/16/2017 04:09 PM, Fox, Kevin M wrote: If the developers that had issue with the lack of functionality, contributed to Barbican rather then go off on their own, the problem would have been solved much more quickly. The lack of sharing means the

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 17 Jan 2017, at 11:28, Maish Saidel-Keesing > wrote: Please see inline. On 17/01/17 9:36, Tim Bell wrote: ... Are we really talking about Barbican or has the conversation drifted towards Big Tent concerns? Perhaps we can flip this thread

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Qiming Teng wrote: > On Mon, Jan 16, 2017 at 08:21:02PM +, Fox, Kevin M wrote: >> IMO, This is why the big tent has been so damaging to OpenStack's progress. >> Instead of lifting the commons up, by requiring dependencies on other >> projects, there by making them commonly deployed and high

[openstack-dev] [sahara] Pike's PTG etherpad

Hello team, Let’s start collecting ideas for Pike’s PTG in the etherpad [0]. For reference there is a collection of the etherpads for other teams [1]. So, feel free to add topics for discussion, but don’t forget to add some contact information about you. Thanks. [0]

Re: [openstack-dev] [nova] Different length limit for tags in object definition and db model definition

Hi all, Changing the type of column from VARCHAR(80) to VARCHAR(60) would also require a data migration (i.e. a schema migration to add a new column with the "correct" type, changes to the object, data migration logic) as it is not an "online" DDL operation according to [1]. Adding a new API

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Please see inline. On 17/01/17 9:36, Tim Bell wrote: > >> On 17 Jan 2017, at 01:19, Brandon B. Jozsa > > wrote: >> >> Inline >> >> On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov >> ) wrote: >> >>> >>>

[openstack-dev] [security] FIPS compliance

Hi, in previous threads, there have been discussions about enabling FIPS, and the problems we are hitting with md5 inside OpenStack: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html It is important from a security perspective to enable FIPS, however OpenStack cannot

Re: [openstack-dev] [tricircle]Tricircle Pike PTG

Hello, As only few of us may go to Atlanta, the etherpad has been renamed to reflect the fact of our "virtually distributed PTG" https://etherpad.openstack.org/p/tricircle-pike-design-topics We will discuss this in the weekly meeting, "What date and time and venu during the PTG, and meetup

Re: [openstack-dev] [nova] Different length limit for tags in object definition and db model definition

OK, then, lets try to work this out. On Tue, Jan 17, 2017 at 4:19 PM, Sergey Nikitin wrote: > Hi, Zhenyu! > > I think we should ask DB guys about migration. But my personal opinion is > that DB migration is much painful than new microversion. > > But it seems too late to

Re: [openstack-dev] [machine learning] Question: Why there is no serious project for machine learning ?

Thank you Eran. This is a rather interesting replay. Thank you very much. 于2017年1月16日周一 下午6:07写道： > > Not sure what you mean by serious. > > > > Maybe you could have a look at Meteos[1]. It is a young project but > surely > > focuses on machine learning. > > > > [1]:

Re: [openstack-dev] [nova] Different length limit for tags in object definition and db model definition

Hi, Zhenyu! I think we should ask DB guys about migration. But my personal opinion is that DB migration is much painful than new microversion. But it seems too late to have a microversion for this cycle. > Correct me if I'm wrong but I thought that Feature Freeze will be in action Jan 26.