Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/18, 11:17 AM, "Matt Riedemann" wrote: On 1/30/2018 9:37 AM, Mathieu Gagné wrote: > So I just discovered this documentation. It's awesome! Great job to > all the ones involved! > Now I wish we had the same in all projects. =) Maybe it's worth

Re: [openstack-dev] [release][searchlight] problem with release job configurations

Hi Doug, Apologies, I was travelling all day yesterday. I've put up https://review.openstack.org/539231 to change the project config and made the release review (https://review.openstack.org/538321) depend on it. Thanks for the detailed information! Steve On 1/29/18, 6:21 PM, "Doug

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/20/17, 5:29 PM, "Matt Riedemann" wrote: On 12/20/2017 3:21 PM, Matt Riedemann wrote: > On 12/20/2017 9:30 AM, Zane Bitter wrote: >> To answer the question from your other mail about user-space >> notifications: >> >>> We (Zaqar team) have

Re: [openstack-dev] [all] connecting nova notification users and developers

As you mention, searchlight consumes notifications from nova and other services. We've been moving towards versioned notifications over the last couple of cycles. Our use case is maybe unusual that we'd prefer notifications to represent the current state of a resource (with a timestamp) though

[openstack-dev] [searchlight] Cancelling searchlight IRC meeting 8/31

Hi, I will not be able to attend the regular searchlight IRC meeting tomorrow so I'm going to cancel it. The next scheduled one is in two weeks but obviously the regular room is always open. Thanks, and apologies for the short notice. Steve

[openstack-dev] [searchlight] Cancelling IRC meeting August 2nd

Hi, Apologies for the short notice, but I'm cancelling the IRC meeting for August 2nd as I have a family commitment tomorrow morning. We'll resume as normal next week. Thanks, Steve __ OpenStack Development Mailing List

Re: [openstack-dev] [nova][searchlight] status of an instance on the REST API and in the instance notifications

Thanks Balazs for noticing and replying to my message! The Status field is quite important to us since it's the indicator of VM state that Horizon displays most prominently and the most simple description of whether a VM is currently usable or not without having to parse the various _state

Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

This is what we envisaged for searchlight; a single endpoint to retrieve information across multiple services and regions to make it easier for a user of horizon (for instance) to ask those kinds of arbitrary questions about the current state of resources. It's unfortunate our swift

[openstack-dev] [searchlight] Cancelling IRC meeting June 8th

Hi, I won't be around tomorrow so I'm cancelling the searchlight IRC meeting. We'll resume next week and apologies for the short notice. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [searchlight] Cancelling searchlight IRC meeting 4/27/17

Hi, There’s nothing on the agenda for today and a few people won’t be able to make it, so I’m inclined to cancel the IRC meeting today to save people staying up late unnecessarily. If anyone has anything they want to discuss, feel free to bring it up in the main channel. I will be in the

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

> > Richard > > > On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com> wrote: >> I concur; option 4 is the only one makes sense to me and was what was >> intended originally. As long as we can do it in one fell swoop in one cyclle >> (preferably

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

I concur; option 4 is the only one makes sense to me and was what was intended originally. As long as we can do it in one fell swoop in one cyclle (preferably sooner than later) there should be no issues. On 3/9/17, 8:35 AM, "Tripp, Travis S" wrote: >Let me get Matt B

Re: [openstack-dev] [nova][searchlight] When do instances get removed from Searchlight?

Storing the data isn't a problem, but one issue we've had with situations like this where there should be a default filter (soft_deleted==false) that can be overridden is that it's quite hard within the context of the query parser to do it, because it involves examining an incoming query to see

[openstack-dev] [searchlight] IRC Meeting Feb 23rd cancelled

Hi, Due to a combination of the PTG and vacations, I'm cancelling the Searchlight IRC meeting for Thursday Feb 23rd. We'll resume as normal the following week. Thanks! Steve __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

On 11/28/16, 9:57 AM, "Zane Bitter" wrote: >On 28/10/16 08:32, Julien Danjou wrote: >>> > 2. Content Format >>> > The info/data forwarded by Aodh is alarm, not the original event. At >>> > here, >>> > I assume most of the users would like to see the original event, not

[openstack-dev] [Searchlight] Weekly IRC meeting cancelled for Thanksgiving

Hi, This week's IRC meeting will be cancelled due to the US Thanksgiving holiday on Thursday. Meetings will resume on Thursday December 1st. Thanks! Steve __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [searchlight] Propose Zhenyu Zheng for Searchlight core

, Oct 20, 2016 at 5:13 PM, Brian Rosmaita <brian.rosma...@rackspace.com<mailto:brian.rosma...@rackspace.com>> wrote: +1 from me, I'll be happy to see Kevin on the core list. On 10/19/16, 10:10 AM, "McLellan, Steven" <steve.mclel...@hpe.com<mailto:steve.mclel...@hpe.com&

[openstack-dev] [searchlight] No IRC meeting Nov 3rd

Hi, Since some people are still traveling back from the summit and I'm out of the office I'm canceling this week's IRC meeting. We'll resume normal service next week. Apologies for the late notice. Steve __ OpenStack

[openstack-dev] [nova] [searchlight] Discrepancies between nova server notifications and API response

Hi, I was unfortunately unable to make the summit but I'm told there were some good discussions around possible integration with searchlight to help some scaling cases with nova cells. One issue we've had with Searchlight is differences between the notifications and API representation of

[openstack-dev] [searchlight] Propose Zhenyu Zheng for Searchlight core

Hi, I'd like to propose Zhenyu Zheng (Kevin_Zheng on IRC) for Searchlight core. While he's most active on Nova, he's also been very active on Searchlight both in commits and reviews during the Newton release and into Ocata on Searchlight. Kevin's participated during the weekly meetings and

[openstack-dev] [api] [searchlight] Duplicate parameter names

Hi, This issue came up during our meeting last week and it was suggested to ask the API working group for its opinion, so any comments welcome. Searchlight was born out of the Glance codebase, and so implemented "offset" and "limit" as paging parameters [1]. Where possible we've tried to map

Re: [openstack-dev] [searchlight] Matt Borland Searchlight UI Core Nomination

+1 - I'm fine with an additional group for ui cores. On 9/19/16, 12:13 PM, "Tripp, Travis S" wrote: >Hello! > >I am nominating Matt Borland for Searchlight UI core. Matt has been >working on searchlight UI since we started it and he is the primary >author of the angular

[openstack-dev] [Searchlight] PTL candidacy

Hi, I am announcing my candidacy for election as Searchlight PTL. I've been a leading contributor and core reviewer since Searchlight's inception as a standalone project in Vancouver. Under Travis' very capable guidance Searchlight has reached a 1.0 Newton release which supports nearly all of

Re: [openstack-dev] [neutron] [searchlight] What do we need in notification payload?

In our (Searchlight's) ideal world, every notification about a resource would contain the full representation of that resource (for instance, equivalent to the API response for a resource), because it means that each notification on its own can be treated as the current state at that time without

Re: [openstack-dev] [searchlight] Rick Aulino core nomination

+1 - Rick's done a lot of good reviews over various parts of the codebase. On 7/25/16, 4:01 PM, "Tripp, Travis S" wrote: >Hello! > >I am nominating Rick Aulino for Searchlight core. Rick has been working >on the core indexing engine throughout Mitaka and Newton. He has

[openstack-dev] [Openstack] [searchlight] Routing for parent/child plugins

Hi, The switch to Elasticsearch 2.x for the gate functional tests revealed a couple of issues that need resolving fairly quickly [1] [2] [3]. Of them, [2] raises a problem regarding routing for documents belonging to child plugins. Once we define a parent/child mapping, index/update/delete

Re: [openstack-dev] [searchlight] Searchlight Core Nomination - Lei Zhang

+1, Lei's made some great contributions. On 5/17/16, 3:56 PM, "Brian Rosmaita" wrote: >+1 > >I second the motion! > >On 5/17/16, 3:42 PM, "Tripp, Travis S" wrote: > >>I am nominating Lei Zhang from Intel (lei-zh on IRC) to join the

[openstack-dev] [searchlight] [ceilometer] [fuel] [freezer] [monasca] Elasticsearch 2.x gate support

Hi, I'm looking into supporting and testing Elasticsearch 2.x in Searchlight's test jobs. Currently I don't know of any other projects that run tests against Elasticsearch in the gate (since we had to add it to Jenkins [1]). Several projects install the python elasticsearch client in

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

Hi, I think Brad's spot on. See inline, but short version - the special case is only required if the KS catalog returns v2.0 endpoints. On 4/7/16, 1:39 PM, "Brad Pokorny" wrote: >Hi Brian, > >Copying to the general list, as this is something I've wondered about, and

Re: [openstack-dev] [Horizon][Searchlight] Plans for Horizon cross-region view

To add to that - Brad, if you're going to be in Austin I'm planning to bring along a prototype, and I know that this use case is of interest to others. If there is still sufficient interest it's something we have as a priority for Newton, and from the few hours I've spent so far setting it up I

Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin

Hi Hiroyuki, It would be worth being certain about what access we have to keypairs before committing to a plugin; if we cannot retrieve the initial list or receive notifications on new keypairs, we likely can't index them at all. If we have partial access we may be able to make a decision on

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

>From the list of versions that are there (https://pypi.python.org/simple/eventlet/), it appears that for a given major version only the most recent release is kept, so this will likely reoccur when/if 0.18.3 is released. Steve On 2/9/16, 10:44 AM, "Markus Zoeller" wrote:

Re: [openstack-dev] [searchlight] Nominating Li Yingjun to Searchlight Core

+1 Li's submitted a number of patches to Searchlight, showed a good understanding of it, and has very actively reviewed patches and specs from other contributors. On 1/22/16, 6:09 PM, "Tripp, Travis S" wrote: >I am nominating Li Yingjun (yingjun on IRC) to join the

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

Hi Alex, Searchlight uses port 9393 (it also made sense to us when we spun out of Glance!), so we would prefer it if there's another one that makes sense. Regarding the three hardest things in computer science, searchlight's already dealing with cache invalidation so I'll stay out of the

[openstack-dev] [searchlight][ceilometer][qa][infra] Elasticsearch 2.0 client release

Hi, The elasticsearch 2.0 python client is not backwards compatible with the 1.x client nor server. Currently global-requirements has no upper cap on it; I've proposed https://review.openstack.org/252075 to cap it under version 2.0 on the basis that devstack installs elasticsearch 1.x and I

Re: [openstack-dev] [searchlight] Feature request and bug workflow

I've already spoken to you about this and I think everyone would agree that for large features blueprints are cumbersome; my preference would be for simple blueprints (uncontroversial and straightforward from a design perspective) to leave a full description in launchpad but for larger ones to

[openstack-dev] [searchlight] Searching admin-only fields

An issue discovered at the end of the Liberty cycle [1] meant that while still present in results (for admins) we had to disable searching of admin-only fields (TL;DR – a non-admin can fish for results to discover values for admin-only fields by searching e.g. "hostId": "a*"). We'd like to fix

[openstack-dev] [nova] [searchlight] Difference in nova notifications versus API

Hi, One of our questions this summit for Searchlight is whether we can reduce the time and effort required to index resources by getting as much information from notifications as possible. Nova's API and notifications provide data in different formats; some information is missing and some is

[openstack-dev] [glance] [swift] [searchlight] Searchlight cross-project session

Hi, As you may know, Searchlight became an Openstack project after the Vancouver summit with the goal of providing a unified search API over many Openstack resources. A big goal for the Mitaka cycle is to add support for more resources (and improve existing support), and to that end we'd love

Re: [openstack-dev] [nova] [searchlight] Difference in nova notifications versus API

e/#session:2bbda0e5e052e5249fa1a118e906df46 Sent from my iPad On 2015. okt. 28., at 15:10, McLellan, Steven <steve.mclel...@hpe.com<mailto:steve.mclel...@hpe.com>> wrote: Hi, One of our questions this summit for Searchlight is whether we can reduce the time and effort required to index resour

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

+1 From: Ekaterina Chernova efedor...@mirantis.commailto:efedor...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 2, 2015 at 2:42 AM To: OpenStack Development

Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

+1 From: Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 2, 2015 at 9:32 AM To: OpenStack Development Mailing List (not

Re: [openstack-dev] [Glance] Experimental API

This would require some changes to how python-glanceclient parses versions. Even if the keystone catalog has a version string in it (which typically is not the case for glance) the version parsing in common/utils only recognizes version strings beginning with 'v'. Would it be sensible to add

[openstack-dev] [Heat] Occasional stack-delete failure with RouterInterface

Hello, We're occasionally (as in occasionally repeatable but not consistent) seeing failures deleting stacks containing a neutron RouterInterface. I'm not sure if it's a bug or the template is to blame. The error we get is: Conflict: Router interface for subnet id on router id cannot be

Re: [openstack-dev] [Heat] Occasional stack-delete failure with RouterInterface

with a floating IP associated to it because it would prevent the floating IP from functioning. On Wed, Aug 13, 2014 at 8:30 PM, McLellan, Steven steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote: Hello, We’re occasionally (as in occasionally repeatable but not consistent) seeing failures deleting

Re: [openstack-dev] [Murano]

Engineer @ Mirantis On Tue, Jul 22, 2014 at 8:05 PM, McLellan, Steven steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote: Hi, This is a little rambling, so I’ll put this summary here and some discussion below. I would like to be able to add heat template fragments (primarily softwareconfig

[openstack-dev] [Murano]

Hi, This is a little rambling, so I'll put this summary here and some discussion below. I would like to be able to add heat template fragments (primarily softwareconfig) to a template before an instance is created by Heat. This could be possible by updating but not pushing the heat template

Re: [openstack-dev] [Murano] Image tagging

Engineer @ Mirantis On Fri, Jul 18, 2014 at 6:46 PM, McLellan, Steven steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote: Hi, Images that can be used for package deployment have to be tagged in glance in order to enable the UI to filter the list of images to present to a user (and potentially

[openstack-dev] [Murano] Image tagging

Hi, Images that can be used for package deployment have to be tagged in glance in order to enable the UI to filter the list of images to present to a user (and potentially preselect). Currently the tags are defined in the dashboard code (images/forms.py) which makes things very inflexible; if

[openstack-dev] [Murano] environment deletion

Is there any reason the system Environment class doesn't implement destroy? Without it, the pieces of the heat stack not owned by other resources get left lying around. It looks like it was once implemented as part of deploy, but that no longer seems to execute.

[openstack-dev] [Murano] Package composition

Hi, I'm trying to figure out what we'll be able to support in the near/far term with regards to packaging applications. My understanding of the DSL is incomplete and I'm trying to fix that :) This isn't so much a usage question as for assistance writing documentation. Taking Wordpress as the