Re: [openstack-dev] [TripleO][CI]

On 15 January 2017 at 20:24, Sagi Shnaidman wrote: > Hi, all > > FYI, the periodic TripleO nonha jobs fail because of introspection > failure, there is opened bug in mistral: > > Ironic introspection fails because unexpected keyword "insecure" > https://bugs.launchpad.net/tripleo/+bug/1656692 >

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

That's a majority of the cores having cast positive votes. Congratulations to Liping Mao and Ilya Chukhnakov! You're now cores and on the hook! On Mon, Jan 16, 2017 at 3:10 AM, Vikas Choudhary wrote: > +1 for both. > > On Sun, Jan 15, 2017 at 12:42 PM, Gal Sagie wrote: > >> +1 for both. >> >>

Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

Regarding the reason for the failing tests: Looks like [1] switches the default for support of managed snapshots to true in devstack. As the default on that was 'false' until friday Quobyte CI did not set that option previously. I'm running tests with a revised config now. Btw, feel free to contact

[openstack-dev] [octavia]redirection and barbican config

Hi, I updated the description accordingly. Please update the status https://bugs.launchpad.net/devstack/+bug/1655656 Thanks, Abed __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-r

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

Fox, Kevin M wrote: > 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 seems to be being made into a place where > each of the silo's can co'exist but not talk

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

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]: https://wiki.openstack.org/wiki/Meteos Another avenue is to use Storlets for either the learn or prediction phase where the data resides in Swift. We

Re: [openstack-dev] [nova] placement/resource providers update 7

On Wed, 11 Jan 2017, Chris Dent wrote: The basis for this conclusion is from three assumptions: * The value of 'local_gb' on the compute_node object is any disk the compute_node can see/use and the concept of associating with shared disk by aggregates is not something that is real yet[0]. *

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

On 14/01/17 04:07, Joshua Harlow wrote: Sometimes I almost wish we just rented out a football stadium (or equivalent, a soccer field?) and put all the contributors in the 'field' with bean bags and some tables and a bunch of white boards (and a lot of wifi and power cords) and let everyone 'have

[openstack-dev] [tripleo][ci] replacing periodic tempest job with quickstart

Hi, as part of an effort to bring success rate of tempest test closer to 100% in tripleo-ci, we propose to replace the current periocic ha tempest job with a one that is using quickstart, but tests in nonha. We pushed a change in infra: https://review.openstack.org/420647 that will replace the cu

Re: [openstack-dev] [TripleO][CI]

On Mon, Jan 16, 2017 at 3:08 AM, Dougal Matthews wrote: > > > On 15 January 2017 at 20:24, Sagi Shnaidman wrote: >> >> Hi, all >> >> FYI, the periodic TripleO nonha jobs fail because of introspection >> failure, there is opened bug in mistral: >> >> Ironic introspection fails because unexpected k

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

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 make the operator's lives simpler. I've been struggling to

[openstack-dev] [barbican] Project Navigator Out of Date?

Hi barbicaneers (I don't actually know what y'all call yourselves :)), Related to the other thread I just started, I was looking at the project navigator [1] for Barbican and found some things that look wrong (to an outsider) and was hoping could be cleared up. First, "Is this project maintained

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

On 13/01/17 06:47 PM, Srikanth Vavilapalli wrote: > So the question is, is there any config that I can use to let > "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in > addition to predefined ones, such that this framework can be extended to > receive meters from non ope

[openstack-dev] [nova] Next notification meeting

Hi, The next notification subteam meeting will be held on 2017.01.17 17:00 UTC [1] on #openstack-meeting-4. Cheers, gibi [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170117T17 __ OpenStack Developmen

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

On 13/01/17 06:47 PM, Srikanth Vavilapalli wrote: > So the question is, is there any config that I can use to let > "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in > addition to predefined ones, such that this framework can be extended to > receive meters from non ope

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

On Mon, Jan 16 2017, Ian Cordasco wrote: > Related to the other thread I just started, I was looking at the > project navigator [1] for Barbican and found some things that look > wrong (to an outsider) and was hoping could be cleared up. Don't worry, we (Telemetry) have already asked for that to

Re: [openstack-dev] [tripleo] tripleoclient release : January 26th

One day I'll read calendars correctly :-) Client releases are next week, so we'll release tripleoclient by January 26th. Sorry for confusion. On Sun, Jan 15, 2017 at 6:41 PM, Emilien Macchi wrote: > https://releases.openstack.org/ocata/schedule.html > > It's time to release python-tripleoclient

[openstack-dev] [mistral] Team meeting - 01/16/2017 (NO MORE REMINDERS)

Hi, We’ll have a team meeting today at 16.00 UTC at #openstack-meeting as usually. IMPORTANT: We discussed it with the team and decided to stop sending out these reminders since we don’t find them much useful anymore. So this is the last one. We agreed to send notifications only in some special

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

From: Yujun Zhang Date: Sunday, 15 January 2017 at 17:53 About fault and alarm, what I was thinking about the causal/deducing chain in root cause analysis. Fault state means the resource is not fully functional and it is evaluated by related indicators. There are alarms on events like power

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

On 01/16/2017 07:55 AM, Ian Cordasco wrote: > Keeping the navigator up-to-date seems (to me) to be a good > way to improve Barbican's image. I would be happy to work with you all > (with what little time I have) to update the navigator to better > reflect Barbican's reality. Part of the reason I'v

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

On Mon, 16 Jan 2017, Ian Cordasco wrote: I really want to understand why so many projects feel the need to implement their own secrets storage. This seems a bit short-sighted and foolish. While these projects are making themselves easier to deploy, if not done properly they are potentially endan

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

On 16/01/2017 14:33, Julien Danjou wrote: > On Mon, Jan 16 2017, Ian Cordasco wrote: > >> Related to the other thread I just started, I was looking at the >> project navigator [1] for Barbican and found some things that look >> wrong (to an outsider) and was hoping could be cleared up. > > Don't wo

Re: [openstack-dev] [nova] placement/resource providers update 7

On 01/11/2017 01:11 PM, Chris Dent wrote: On Fri, 6 Jan 2017, Chris Dent wrote: ## can_host, aggregates in filtering There's still some confusion (from at least me) on whether the can_host field is relevant when making queries to filter resource providers. Similarly, when requesting resource p

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

Thanks Gord Yes, for my quick test, I directly added a new exchange to listen for in meter/notifications.py and verified that the custom metrics are getting processed after that. Thanks Srikanth -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Monday, January 16, 2017

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

On 16/01/2017 13:38, 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 make th

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

On 16/01/17 21:55, Ian Cordasco wrote: Third, "Existence and quality of packages for this project in popular distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and OpenSUSE [5] all have packages (including in stable versions). I can't speak to the quality of the packages, but knowing t

Re: [openstack-dev] [congress][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

Excerpts from Eric K's message of 2017-01-12 14:31:58 -0800: > On a freshly stacked devstack (Jan 12), attempting to access > `cfg.CONF.keystone_authtoken.project_domain_name` gave the error: > NoSuchOptError: no such option project_domain_name in group > [keystone_authtoken] > > I¹m a little conf

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

Hi Tom! -Original Message- From: Tom Fifield Reply: OpenStack Development Mailing List (not for usage questions) Date: January 16, 2017 at 10:02:24 To: openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] [barbican] Project Navigator Out of Date? > On 16/01/17 21:55, Ian Cor

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

-Original Message- From: Hayes, Graham Reply: OpenStack Development Mailing List (not for usage questions) Date: January 16, 2017 at 09:26:00 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are projects trying

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

Ian Cordasco wrote: > From: Tom Fifield >> On 16/01/17 21:55, Ian Cordasco wrote: >>> >>> Third, "Existence and quality of packages for this project in popular >>> distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and >>> OpenSUSE [5] all have packages (including in stable versions). I

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

On 17/01/17 00:14, Thierry Carrez wrote: Ian Cordasco wrote: From: Tom Fifield On 16/01/17 21:55, Ian Cordasco wrote: Third, "Existence and quality of packages for this project in popular distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and OpenSUSE [5] all have packages (includi

[openstack-dev] [barbican] Project Navigator Out of Date

Hi all. Just wanted to throw out that if you have bug reports or issues with the content on the project navigator, please feel free to send them to https://bugs.launchpad.net/openstack-org/ and someone on the Foundation Staff will look into it. I've already fielded a one for Designate this morn

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

Thanks for raising this on the mailing list Ian, I too share some of your consternation regarding this issue. I think the main point has already been hit on, developers don't want to require that Barbican be deployed in order for their service to be used. The resulting spread of badly audited sec

Re: [openstack-dev] [barbican] Project Navigator Out of Date?

Hi Ian-- Thanks for the reminder. As PTL, I know I have some action items to update our project navigator status. Speaking on behalf of the Barbican community, I can say that we do follow the rules of stable branches and deprecation. I'll submit a patch now to state this assertion. I als

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

-Original Message- From: Rob C Reply: OpenStack Development Mailing List (not for usage questions) Date: January 16, 2017 at 10:33:20 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoi

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

On 01/16/2017 10:31 AM, Rob C wrote: I think the main point has already been hit on, developers don't want to require that Barbican be deployed in order for their service to be used. I think that this is a perfectly reasonable stance for developers to take. As long as Barbican is an optional

[openstack-dev] [release][all][ptl][stable] the process for creating stable/ocata branches

As mentioned previously [1], it is now possible for teams to set up stable branches when they are ready. We will be taking advantage of this new capability as we approach the end of the Ocata cycle and start preparing final releases. The release team will not be automatically setting up branches t

Re: [openstack-dev] Pike PTG facilities and remote participation

Brian Rosmaita wrote: > I have a quick facilities question about the PTG. I know of at least > one developer who can't attend physically but will be willing to join > via some type of videoconferencing software (vidyo, or blue jeans, or > google hangout). Do you think it will be possible? The wi

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

On 01/13/2017 10:29 PM, Mike Perez wrote: Hello all, In the spirit of recent Technical Committee discussions I would like to bring focus on how we're doing vendor driver discoverability. Today we're doing this with the OpenStack Foundation marketplace [1] which is powered by the driverlog proje

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

2017-01-13 9:25 GMT-08:00 Ian Cordasco : > -Original Message- > From: Ian Cordasco > Reply: Ian Cordasco > Date: January 13, 2017 at 08:12:12 > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [glance][tempest][api] community images, > te

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

> On Jan 16, 2017, at 11:58 AM, Jay S. Bryant > wrote: > > On 01/13/2017 10:29 PM, Mike Perez wrote: >> The way validation works is completely up to the project team. In my research >> as shown in the Summit etherpad [5] there's a clear trend in projects doing >> continuous integration for vali

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

> > > The last I checked, Rob, they also support DogTag IPA which is purely > a Software based HSM. Hopefully the Barbican team can confirm this. > -- > Ian Cordasco > Yup, that's my understanding too. However, that requires Barbican _and_ Dogtag, an even bigger overhead. Especially as at least hi

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

-Original Message- From: Chris Friesen Reply: OpenStack Development Mailing List (not for usage questions) Date: January 16, 2017 at 11:26:41 To: openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

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

On 1/16/17, 11:52 AM, "Ian Cordasco" wrote: >-Original Message- >From: Rob C >Reply: OpenStack Development Mailing List (not for usage questions) > >Date: January 16, 2017 at 10:33:20 >To: OpenStack Development Mailing List (not for usage questions) > >Subject: Re: [openstack-dev] [al

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

On 2017-01-16 01:19 PM, Jonathan Bryce wrote: On Jan 16, 2017, at 11:58 AM, Jay S. Bryant wrote: On 01/13/2017 10:29 PM, Mike Perez wrote: The way validation works is completely up to the project team. In my research as shown in the Summit etherpad [5] there's a clear trend in projects doing

[openstack-dev] [ironic] this week's priorities and subteam reports

Hi, We are jubilant to present this week's priorities and subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. This Week's Priorities (as of the weekly ironic meeting) 1. nova code for

Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

On Mon, Jan 16, 2017 at 08:52:34AM +0100, Silvan Kaiser wrote: > Apoorva, Sean, > after some time i managed to bring up Quobyte CI last friday which tested > fine [1,2,3] for a short time and then ran into the same issues with > manage_snapshot > related tempest tests Apoorva describes (Starting ch

[openstack-dev] [Congress][Fuel] Fuel plugin for installing Congress

I'd like to introduce you fuel plugin for installing and configuring Congress for Fuel [0]. This plugin was developed by Fuel@Opnfv [1] Community in order to be included to the next release of the Fuel@Opnfv - Danube. We believe that this plugin might be helpful not only for us but also for genera

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

Jesse Pretorius wrote: > Hi Sean, > > Great to see you taking the initiative on this. > > I think the starting point we’d have to work from with the way the builds are > executed now would be to have the upgrade job execute in a periodic pipeline > that has a longer timeout. While it would be i

[openstack-dev] [tosca-parser] [heat-translator] [heat] [tacker] [opnfv] heat-translator and tosca-parser 0.7.0

Hello Everyone, On behalf of the Heat Translator and TOSCA Parser team, I am pleased to announce the 0.7.0 PyPI release of heat-translator and tosca-parser which can be downloaded fromhttps://pypi.python.org/pypi/heat-translator and https://pypi.python.org/pypi/tosca-parser respectively. Thi

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

On 01/16/2017 12:19 PM, Jonathan Bryce wrote: On Jan 16, 2017, at 11:58 AM, Jay S. Bryant wrote: On 01/13/2017 10:29 PM, Mike Perez wrote: The way validation works is completely up to the project team. In my research as shown in the Summit etherpad [5] there's a clear trend in projects doin

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

> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) > wrote: > > On 1/16/17, 11:52 AM, "Ian Cordasco" wrote: > >> -Original Message- >> From: Rob C >> Reply: OpenStack Development Mailing List (not for usage questions) >> >> Date: January 16, 2017 at 10:33:20 >> To: OpenStack De

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

-Original Message- From: Dave McCowan (dmccowan) Reply: OpenStack Development Mailing List (not for usage questions) Date: January 16, 2017 at 13:03:41 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are proje

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

Someone mentioned Castellan, and was exactly correct -- Castellan is supposed to allow for flexibility, so developers can code for the Castellan interface and simply configure it to use Barbican or whatever else they want. The only drawback of Castellan at the moment is that it doesn't directly su

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

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 quality, post big tent, each project reimplements just enough to get away with making someth

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

Seems to me that there are two different audiences here. Developers want something that is easy to set up and develop against. For that, the simple crypto plugin is provided, and it requires essentially no setup. In case Barbican is not available, developers should be coding against castellan. D

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

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 problems don't get fixed as fast. As for operators, If the more common projects all start

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

On 17/01/17 09:21, 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 quality, post big > tent, each project reimpl

[openstack-dev] [refstack] RefStack IRC meeting on January 17, 2017

Hi Everyone, Just a reminder that we will have our weekly RefStack IRC meeting tomorrow January 17, at 19:00 UTC in #openstack-meeting-alt. Thanks! Catherine Diep __ OpenStack Development Mailing List (not for usage ques

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

On Tue, Jan 17, 2017 at 10:09 AM, Fox, Kevin M wrote: > As for operators, If the more common projects all started depending on it, > it would be commonly deployed. Would the operators deploy Barbican just for > Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely . > Would the

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

On 17/01/17 10:09, 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 problems don't get > fixed as fast. > > As

Re: [openstack-dev] [nova] nova-api-metadata managing firewall

Thanks Jens, Is someone able to change the status of the bug from won’t-fix to confirmed so its visible. Cheers, Sam > On 10 Jan 2017, at 10:52 pm, Jens Rosenboom wrote: > > 2017-01-10 4:33 GMT+01:00 Sam Morrison >: >> Hi nova-devs, >> >> I raised a bug about nov

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

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 problems don't get fixed as fast. Agreed co

Re: [openstack-dev] [Congress][Fuel] Fuel plugin for installing Congress

Hi Serg, This is great news! On behalf of the OPNFV Doctor team, thank you Fuel@Opnfv team for this effort! We will certainly test it out as soon as possible, and we'll provide feedback. Cheers, Carlos On Mon, Jan 16, 2017 at 8:33 PM, Serg Melikyan wrote: > I'd like to introduce you fuel plug

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

To give a totally different prospective on why somebody might dislike Barbican (I'm one of those people). Note that I'm working from pretty hazy memories so I don't guarantee I've got everything spot on, and I am without a doubt giving a very one sided view. But hey, that's the side I happen to sit

Re: [openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!

On Thu, Jan 12, 2017, at 03:32 PM, Andre Florath wrote: > Hello! > > > The end result of this would be we have distro-minimal which depends on > > kernel, minimal-userspace, and yum/debootstrap to build a vm/baremetal > > capable image. We could also create a distro-container element which > > onl

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

The "single master token" issue is something I think a lot of services may suffer from, and it's definitely something the Barbican folks are aware of (I've made it a point to personally bring this up many times, including hijacking parts of the keystone and barbican sessions at the Tokyo, Austin, a

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

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 single, objective list of requirements and responsibilities for inclu

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

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 been deemed too hard to deploy? I really want to understand why so many projects feel the

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

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 single, objective list of requirements and resp

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

Inline On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov) wrote: I'm not stating that the big tent should be abolished and we go back to the way things were. But I also know the status quo is not working either. How do we fix this? Anyone have any

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

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 considered many times. We sought input from people who were deploying and operating Trove at scal

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

On 17/01/17 13:00, 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 single, objective

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

Sounds good. Have you created an etherpad page for collecting topics, Ifat? On Mon, Jan 16, 2017 at 10:43 PM Afek, Ifat (Nokia - IL) < ifat.a...@nokia.com> wrote: > > > *From: *Yujun Zhang > *Date: *Sunday, 15 January 2017 at 17:53 > > > > About fault and alarm, what I was thinking about the ca

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

Hi Nova, I just discovered something interesting, the tag has a limited length, and in the current implementation, it is 60 in the tag object definition: http://git.openstack.org/cgit/openstack/nova/tree/nova/objects/tag.py#n18 but 80 in the db model: http://git.openstack.org/cgit/openstack/nova/

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

I need some help troubleshooting a glance_store gate failure that I think is due to a recent change in a tempest test and a configuration problem (or it could be something else entirely). I'd appreciate some help solving this as it appears to be blocking all merges into glance_store, which, as a n

[openstack-dev] [tricircle]Tricircle Pike PTG

As the Ocata stable branch will be created and released soon, it's time to prepare what we need to discuss and implement in Pike release: The etherpad has been created at: https://etherpad.openstack.org/p/tricircle-ptg-pike Please feel free to add the topics, ideas into the etherpad, and let's

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

YEES! -Original Message- From: Tom Fifield [mailto:t...@openstack.org] Sent: Monday, January 16, 2017 3:48 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] PTG? / Was (Consistent Versioned Endpoints) On 14/01/17 04:07, Joshua Harlow wrote: > > Sometimes I almost

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

On 1/16/2017 7:12 PM, Zhenyu Zheng wrote: Hi Nova, I just discovered something interesting, the tag has a limited length, and in the current implementation, it is 60 in the tag object definition: http://git.openstack.org/cgit/openstack/nova/tree/nova/objects/tag.py#n18 but 80 in the db model: h

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

Dougal, I looked at the source code. Seems like it’s already usable enough. Do you think we need to put a section about Ansible actions into Mistral docs? I’m also thinking if we need to move this code into the mistral repo or leave it on github. Maybe a better time for moving it under Mistral umb

[openstack-dev] [neutron][networking_sfc] flow table seems incorrect

Hi ,all I deploy OpenStack mitaka with networking-sfc (-b stable/mitaka) and modify neutron.conf with service_plugins=router,metering,networking_sfc.services.sfc.plugin.SfcPlugin and new section [sfc] drivers=ovs ,and then next mitigrate neutron DB and restart all neutron and nova services，

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

There was a driver thread about snapshot management test failures. It appears there is a config option that changed for devstack from false to true, causing the cinder drivers all sorts of issues. Here is the email that discusses the change and its effects on cinder drivers: http://lists.open

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

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 quality, post big > tent

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

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/ There is discussion going on whether to enable the manage snapshot false by default on devstac

Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

Or how about just disable the flag which will skip snapshot manage tests for CI where it should not run. Flag in Devtsack is TEMPEST_VOLUME_MANAGE_SNAPSHOT which can be set to False on CI. I added the same on ceph gate jobs [1] and similarly can be added on CI side if ok? ..1 https://review.open

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

2017-01-17 10:26 GMT+08:00 Matt Riedemann : > On 1/16/2017 7:12 PM, Zhenyu Zheng wrote: > >> Hi Nova, >> >> I just discovered something interesting, the tag has a limited length, >> and in the current implementation, it is 60 in the tag object definition: >> http://git.openstack.org/cgit/openstack

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

On Tue, Jan 17, 2017 at 2:37 PM, Alex Xu wrote: > > > 2017-01-17 10:26 GMT+08:00 Matt Riedemann : > >> On 1/16/2017 7:12 PM, Zhenyu Zheng wrote: >> >>> Hi Nova, >>> >>> I just discovered something interesting, the tag has a limited length, >>> and in the current implementation, it is 60 in the ta

Re: [openstack-dev] [Cinder] Marking Tintri driver as unsupported

For those interested, this is the required local.conf option to switch off managed snapshot testing: TEMPEST_VOLUME_MANAGE_SNAPSHOT=False 2017-01-16 10:04 GMT+01:00 Silvan Kaiser : > Regarding the reason for the failing tests: > Looks like [1] switches the default for support of managed snapsho

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

I think that it would also be a good idea to have the option to let the CI maintainers add some useful information on the current status. It is very helpful to know that the CI system is under maintenance which is the reason why it hasn't been reporting for the last week or so... Isaac Beckman

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

Hi, folks! I guess I found the reason of the problem. The first spec was created by Jay. At that moment I was just an implementer. In this spec we have a contradiction between lines #74 and #99. https://review.openstack.org/#/c/91444/16/specs/juno/tag-instances.rst Line 74 says "A tag shall be de

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

On 17 Jan 2017, at 01:19, Brandon B. Jozsa mailto:bjo...@jinkit.com>> wrote: Inline On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov) wrote: I'm not stating that the big tent should be abolished and we go back to the way things were. But I also

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

Hi, Sergey! Thanks for the info, but we are now to the point that should it be a microversion bump or not. The users would love to have longer tags of cause. But it seems too late to have a microversion for this cycle. But will the DB migration be a problem? From 80 to 60? On Tue, Jan 17, 2017 a