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

[Tripp, Travis S]

Hi Richard,

I’m headed out for vacation so won’t be able to look through it until I get 
back.  However, can you also please get an install of searchlight-ui running so 
that you can see if anything breaks?  I know you don’t typically use devstack, 
but the searchlight devstack plugin installs searchlight UI. [0]

The one thing I’m not sure about is how the resource registry handles potential 
double registrations.  So, if the resource is registered both code bases, I 
don’t know what would get loaded. 

https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57

[0] https://github.com/openstack/searchlight/tree/master/devstack

Thanks,
Travis

On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:

Thanks, Steve!

I've put together an initial patch
https://review.openstack.org/#/c/444095/ which pulls in the
os-nova-servers module and a little extra to make it work in Horizon's
codebase. I've tried to make minimal edits to the actual code -
predominantly just editing module names. I've tested it and it mostly
works on Horizon's side \o/


 Richard

On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> wrote:
> My expertise in this area is deeply suspect but as long as we maintain the
> mapping from the resource type names that searchlight uses 
(os-nova-servers)
> to the modules we'll be OK. If you or Rob put a patch up against horizon I
> (or a willing victim/volunteer) can test a searchlight-ui patch against 
it.
>
>
>  Original message 
> From: Richard Jones <r1chardj0...@gmail.com>
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type
> implementations
>
> Hey folks,
>
> Another potential issue is that the searchlight module structure and
> Horizon's module structure are different in a couple of respects. I
> could just retain the module structure from searchlight
> ('resources.os-nova-servers') or, preferably, I could rename those
> modules to match the Horizon structure more closely
> ('horizon.app.resources.os-nova-servers') or more strictly
> ('horizon.app.core.instances').
>
> As far as I can tell none of the module names are referenced directly
> outside of the module (apart from resources.module.js of course) so
> moving the modules shouldn't affect any existing usage in searchlight
> ui.
>
> We could bikeshed this for ages, so if I could just get Rob and Steve
> to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>
>
>   Richard
>
>
> On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
>> OK, I will work on a plan that migrates the code into Horizon, thanks
>> everyone!
>>
>> Travis, can the searchlight details page stuff be done through
>> extending the base resource type in Horizon? If not, is that perhaps a
>> limitation of the extensible service?
>>
>>
>>  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 sooner than later) there should be no issues.
>>>
>>>
>>>
>>>
>>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>>
>>>>Let me get Matt B in on this discussion, but basically, option 4 is my
>>>> initial feeling as Rob stated.
>>>>
>>>>One downside we saw with this approach is that we weren’t going to be
>>>> able to take advantage of searchlight capabilities in details pages if
>>>> everything was in native horizon.  Although, I suppose that could be 
done by
>>>> using the hz-if-services directive [0] if horizon will allow 
searchlight
>>>> optimized code to be in the horizon repo.
>>>>
>>>>[0]
>>>> 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

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

[Tripp, Travis S]

Let me get Matt B in on this discussion, but basically, option 4 is my initial 
feeling as Rob stated.

One downside we saw with this approach is that we weren’t going to be able to 
take advantage of searchlight capabilities in details pages if everything was 
in native horizon.  Although, I suppose that could be done by using the 
hz-if-services directive [0] if horizon will allow searchlight optimized code 
to be in the horizon repo.

[0] 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

-Travis

On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:

I tried searching the meeting logs but couldn’t find where we discussed 
this in the Searchlight meeting. The conclusion at the time was option 4 IIRC. 
The main thing is to make sure we get it done within one cycle, even if it 
isn’t default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] End of 2017 meeting schedule

[Tripp, Travis S]

Hello everyone,

Due to the upcoming holidays we have a modified meeting schedule the next few 
weeks.

December 29th meeting is cancelled.

December 22nd meeting is tentative.  Kevin_Zheng, lei-zh, yingjun will 
coordinate deciding whether or not one is needed and if one of them will be 
available to chair the meeting.

Thanks and happy holidays!
-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Draft team mascot

[Tripp, Travis S]

I also like Radomir’s version.

From: "Ramirez, Eddie" 
Reply-To: OpenStack List 
Date: Wednesday, December 7, 2016 at 11:28 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Horizon] Draft team mascot

Very fixed, much color, so right. Wow.

+1 Radomir’s

From: Rob Cresswell (rcresswe) [mailto:rcres...@cisco.com]
Sent: Wednesday, December 7, 2016 4:50 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Horizon] Draft team mascot

Radomir’s version has my vote.

On 7 Dec 2016, at 10:11, Radomir Dopieralski 
> wrote:

Here, fixed.

On Wed, Dec 7, 2016 at 10:54 AM, Radomir Dopieralski 
>wrote:
That looks kinda like a white baboon. It definitely doesn't look like Doge -- 
wrong color, wrong head. I think the legs are too long too.

On Wed, Dec 7, 2016 at 10:31 AM, Timur Sufiev 
> wrote:
I still think this one 
https://wtf.jpg.wtf/0c/10/1479414543-0c1052f7c2f9990b6b0c472076594cb1.jpeg is 
the best :).

On Wed, Dec 7, 2016 at 1:07 AM Jason Rist 
> wrote:
On 12/06/2016 01:48 PM, Richard Jones wrote:
> >> On 6 Dec 2016, at 20:19, Richard Jones 
> >> > wrote:
> >> Please let me know what you think (by December 12) of this draft for
> >> our Horizon team mascot.
> >
> On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
> > wrote:
> > Are we missing an attachment / link ?
>
> Weird! Trying again:
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Much UI, such OpenStack, wow.

--
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

[Tripp, Travis S]

+1

From: Timur Sufiev 
Reply-To: OpenStack List 
Date: Friday, November 18, 2016 at 1:34 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

+1

On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran 
> wrote:
+1 from me. Kenji is also very active in the plugin space.

- Original message -
From: David Lyle >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Cc:
Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
Date: Thu, Nov 17, 2016 11:51 AM

+1

On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
> wrote:
> +1
>
> 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) 
> >:
>>
>> Big +1 from me
>>
>> > On 14 Nov 2016, at 00:24, Richard Jones 
>> > > wrote:
>> >
>> > Hi Horizon core team,
>> >
>> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
>> > solid Horizon contributor for some time, with thoughtful and helpful
>> > reviews showing good judgment and good knowledge of Horizion and
>> > related systems. Please respond with your votes by Friday.
>> >
>> >
>> > Thanks,
>> >
>> >Richard
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

+1 for me!

From: "McLellan, Steven" 
Reply-To: OpenStack List 
Date: Wednesday, October 19, 2016 at 4:10 PM
To: OpenStack List 
Subject: [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 during the week, and his 
reviews have been very high quality as well as numerous. This would also help 
move towards have greater cross-project participation, especially with Nova.

If anyone has any objections, let me know, otherwise I will add Kevin to the 
core list at the weekend.

Thanks!

Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] base node payload for notification

[Tripp, Travis S]

On 9/27/16, 8:23 AM, "Jim Rollenhagen"  wrote:

On Tue, Sep 27, 2016 at 9:57 AM, Loo, Ruby  wrote:
> Hi Yuriy,
>
>
>
> Thanks for bringing this up. I'm good with your list, with the exception 
of
> driver_info and instance_info. I'm on the fence with these two. If we 
assume
> that any secrets will be bleep'd out (configdrives won't be there), is 
there
> other information there that might be useful? I'm not totally sure what
> notifications will be used for; it is somewhat hard to assume.
>
>
>
> I suppose we could look at it this way, since you and Mario are fine 
without
> those two. If no one speaks up wanting them, then we'll do as you propose,
> and not expose those two fields.

On 9/27/16, 8:23 AM, "Jim Rollenhagen"  wrote:

> 2) Searching things with searchlight - the obvious case for driver_info 
is "find
> all nodes with BMCs on the 10.100.0.0/24 network" or similar things.

We’ve done some usability studies on searchlight UI and one of the most useful 
use cases that has emerged is the ability to search based on IP addresses / 
ranges / cidr (all supported by the underlying elastic search engine). In most 
searchlight plugins (e.g. glance / nova), we’ve indexed any data visible via 
the API. For sensitive fields, you can set them to be admin only (or use other 
filtering abilities in the plugin).

In addition, if you guys have any interest in doing some aggregation like 
abilities in addition to search, you can do that using the searchlight 
indexing.  For example, counts, averages, various statistics can be done via 
the aggregation API exposed up via searchlight [0] of the ElasticSearch 
aggregation API [1]. For example, one simple use case we’ve used it for is to 
get a count of images & flavors used across nova instances or hosts.

 [0] 
http://developer.openstack.org/api-ref/search/?expanded=create-an-aggregated-search-detail
 [1] 
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

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 
registration framework in Horizon which Searchlight depends upon. Matt has the 
second most searchlight UI commits in Newton [0], but more impressively, Matt 
has more commits on Horizon than ANY other person in Newton [1]. In addition, 
Matt is a top 5 reviewer on Searchlight UI [2] and a 12 reviewer on horizon [3] 
He has provided thoughtful feedback and valuable insights throughout his time 
on Searchlight.

Searchlight UI core team is currently the combination of Searchlight cores and 
Horizon Cores.  With this change we would make a searchlight UI core group that 
can has core privileges in addition to those two groups.
 
[0] http://stackalytics.com/?metric=commits=searchlight-ui
[1] http://stackalytics.com/?module=horizon=commits
[2] http://stackalytics.com/report/contribution/horizon/180
[3] http://stackalytics.com/report/contribution/searchlight-ui/180

Thanks,
Travis


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Searchlight] PTL Non-candidacy

[Tripp, Travis S]

Hi everybody,

After an amazing ride that I believe has created a solid platform for a rich 
and interactive search experience in OpenStack, I wanted to let everybody know 
that I will not be nominating myself to be the Searchlight PTL for the Ocata 
cycle. I will continue as a core reviewer and will support whoever is the next 
PTL. 

After 4 release cycles of solid and rapid development (Kilo, Liberty, Mitaka, & 
Newton) we will be applying the 1.0 release tag in a few weeks. This marks a 
significant achievement for this project, because we took a very conservative 
approach to release numbering and waited to move past the 0.x release tag until 
we felt like the project was ready for deployers to start using it. We’ve 
achieved that milestone with the Newton release.

With 1.0, Searchlight now provides:

* Unified search and aggregation queries across:
   * Nova instances, flavors, hypervisors, & server groups
   * Glance images, snapshots, metadefs
   * Cinder volumes, snapshots
   * Neutron networks, ports, subnets, routers, security groups, & floating IPs
   * Designate (DNS) Zones, recordsets
   * Swift container and object search (Experimental)
* A horizon search panel (plugin)
* A CLI via an OpenStack client plugin
* Strong deployment management support via documentation and the CLI
   * Including zero downtime re-indexing and migration support

This is all incredibly powerful and really changes the way you interact with 
the cloud when you really start to use it, such as through the Searchlight UI 
plugin for Horizon. Even so, I believe that we’ve barely started to scratch the 
surface of what we can do with the search and aggregation [0] [1] capabilities 
provided by Searchlight.

I’m really excited to see where it goes from here!

-Travis


[0] 
http://docs.openstack.org/developer/searchlight/searchlightapi.html#aggregations
[1] For example, in a couple of hours I was able to use Searchlight to include 
the number of instances that an image is use by in the Horizon images table: 
http://imgur.com/a/l7S00


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][barbican][cinder][cloudkitty][ironic][magnum][monasca][searchlight][senlin][solum][swift][tripleo][watcher][winstackers] tags needed to be considered part of Newton

[Tripp, Travis S]

Thanks, Doug.

We are planning to tag Searchlight and Searchlight-UI later this week.

-Travis


On 8/29/16, 8:50 AM, "Doug Hellmann"  wrote:

We have several projects using the cycle-with-intermediary release
model for which we have not had any releases yet this cycle. Please
consider a release this week, and be aware that we need a release
by the final deadline in order to consider these projects as part
of Newton (see [1] for details).

Thanks,
Doug


python-barbicanclient
python-brick-cinderclient-ext
cloudkitty
cloudkitty-dashboard
python-cloudkittyclient
bifrost
magnum
magnum-ui
monasca-transform
python-searchlightclient
senlin-dashboard
python-solumclient
solum
solum-dashboard
solum-infra-guestagent
python-swiftclient
tripleo-quickstart
tripleo-ui
watcher-dashboard
networking-hyperv

[1] 
http://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html#requirements

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] [glance] Will glance community image sharing make it into Newton?

[Tripp, Travis S]

Hello Glance team,

We’re looking into implementing the Glance Community Image sharing support 
within Searchlight for Newton, but it looks like several patches are 
outstanding. Can you let us know how likely it is that this will land in Newton 
and when you expect them to land?

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] os-capabilities library created

[Tripp, Travis S]

Excerpts from Jay Pipes's message of 2016-08-03 19:47:37 -0400:
>>  Hi Novas and anyone interested in how to represent capabilities in a 
>>  consistent fashion.
>>
>>  I spent an hour creating a new os-capabilities Python library this 
evening:
> 
>>  http://github.com/jaypipes/os-capabilities
>> Anyway, lemme know your initial thoughts please.

   On 8/11/16, 3:52 PM, "Clint Byrum"  wrote:

> Did we ever resolve the similarities between this and Searchlight's
> similar goals of providing consistent metadata to the users?

> http://docs.openstack.org/developer/glance/metadefs-concepts.html

> I understand your library is for operators and developers to
> collaborate, but it seems like there should be some alignment with this
> UI that wants to do the same thing for the end user where appropriate.

The metadefs catalog wasn’t written just as a UI construct, it was actually
a derivative of an effort called graffiti [0] that was entirely about
capability and requirement matching and providing a way for portability
across clouds.

The Graffiti project was proposed at the Atlanta (Juno) OpenStack summit.
Since then quite a bit of the concepts have been adopted and are covered as
part of multiple different OpenStack Projects. 

[0] https://wiki.openstack.org/wiki/Graffiti/Architecture

A key concept is to both support defining standard metadata that can
be attached to various resources as well as providing a common service
for deployers to register their own metadata with visibility restrictions.
This can be anything from “Gold, Silver, Bronze” to “some hardware
capability”. Ultimately it is up to the deployer to activate, publish,
or discover the capabilities in their environment and enable them in the 
catalog.

Glance Metadata Definition Catalog (Box 1 in the workflow diagram)
 * http://docs.openstack.org/developer/glance/metadefs-concepts.html
* https://github.com/openstack/glance/tree/master/etc/metadefs
* https://youtu.be/zJpHXdBOoeM

Horizon features (Box 2 in the diagram – but also CLI)
* An admin UI for managing the catalog
* (Admin —> Metadata Definitions) (Kilo)
* A widget for associating metadata to different resources
* (Update Metadata action on each row item below)
* admin -> images (Juno)
* admin -> flavors (Kilo)
* admin —> Host Aggregates (Kilo)
* project —> images (Liberty)
* project —> instances (Mitaka)
* The ability to add metadata at launch time
* project —> Launch Instance (ng launch instance enabled) (Mitaka)

Searchlight (Box 3 in the workflow diagram)
* http://launchpad.net/searchlight
* https://wiki.openstack.org/wiki/Searchlight

The Searchlight project is primarily intended for high performance
searching across the cloud. Fulfilling the concepts of Graffiti is a side
effect, but did provide some of the original inspiration for the project.
We actually have blueprint we will do in “O” that will provide
data mapping from metadefs to the schemas in ElasticSearch [1].

* [1] 
https://blueprints.launchpad.net/searchlight/+spec/configurable-dynamic-properties

In addition, when this popped up in my mailbox today, a search revealed
This message from last August with a few points that I’d like to help clarify 
below:

On 8/10/15, 8:05 AM, "Jay Pipes"  wrote:

>  The Glance metadefs stuff is problematic in a number of ways:

> 1) It wasn't written with Nova in mind at all, but rather for UI needs.
> This means it introduces a bunch of constants that are different from
> the constants in Nova.

This is actually not the case. This was originally co-sponsored by Intel
to help expose out all the CPU capabilities in Nova. The constants in
the metadef catalog all come from combing through the code in Nova
was a complete maze and were not available at the time from
Nova (or cinder or glance or …) See overview here [2]:

 [2] https://wiki.openstack.org/wiki/Graffiti

> 2) It uses a custom JSON format instead of JSONSchema, so we now need to
> figure out the schema for these metadef documents and keep up to date
> with that schema as it changes.

It uses JSON schema, but surrounds it with a very lightweight envelope.
The envelope is called a namespace and is simply a container of JSON
schema, allowing us to manage it as a programmatic unit and as a way
for cloud deployers to share the capabilities across clouds very easily.

We did place a limitation on it that it cannot support nested objects. This
was primarily due to the extreme difficulty of representing that construct
to users in an easy to understand way:

http://docs.openstack.org/developer/glance/metadefs-concepts.html#catalog-terminology

> 3) It mixes qualitative things -- CPU model, features, etc -- with
> quantitative things -- amount of cores, threads, etc. These two things
> are precisely what we are trying to decouple from each other in the next
> generation of Nova's "flavors".
>
> 4) It is still missing the user-facing 

Re: [openstack-dev] [horizon] [horizon-plugin] AngularJS 1.5.8

[Tripp, Travis S]

+1

On 8/3/16, 5:36 PM, "Thomas Goirand"  wrote:

On 08/03/2016 12:19 PM, Rob Cresswell wrote:
> Hi all,
> 
> Angular 1.5.8 is now updated in its XStatic
> repo: https://github.com/openstack/xstatic-angular
> 
> I've done some manual testing of the angular content and found no issues
> so far. I'll be checking that the JS tests and integration tests pass
> too; if they do, would it be desirable to release 1.5.8 this week, or
> wait until after N is released? It'd be nice to be in sync with current
> stable, but I don't want to cause unnecessary work a few weeks before
> plugin FF.
> 
> Thoughts?
> 
> Rob

Please go ahead. Debian Sid has 1.5.5, so even if we don't want to,
Debian will be using that version. It's better to be in sync.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Hello!

I am nominating Rick Aulino for Searchlight core. Rick has been working on the 
core indexing engine throughout Mitaka and Newton. He has developed a Neutron 
plug-in and has reviewed most of the other plugins in Searchlight.  Since the 
beginning of Mitaka [0] and for the first two Newton milestones [1], Rick is 
consistently in the top 5 for reviews and commits. He has provided thoughtful 
feedback and valuable insights throughout his time on Searchlight.

[0] http://stackalytics.com/report/contribution/searchlight-group/242
[1] http://stackalytics.com/report/contribution/searchlight-group/100

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Tripp, Travis S]

On 22/07/16 10:04, Zane Bitter wrote:
> If we're not to end up with 20 different answers to the those 
> questions, we'll need some cross-project co-ordination and part of 
> that will involve depending on various projects for functionality 
> instead of implementing multiple different one-off solutions. Pick an 
> asynchronous message transport (Zaqar). Pick an event source 
> (Ceilometer? Searchlight?). Maybe pick an event sink (just Mistral? or 
> lots of sinks?).
>
> So it's architecture, but it is in a sense "user-space" architecture, 
> figuring out how services fit together into a cohesive whole, as 
> opposed to the questions you're talking about which are more 
> engineering-focused. I'd be very interested to know if you consider 
> this stuff in scope for your architecture group or if you think it 
> should have its own separate working group.
>

Well said, Zane.

I 100% have felt and continue to feel the pain that Kevin originally mentioned 
with simply being blocked on progress because the projects are often silo’d and 
there is no high level architecture group essentially saying it is okay for 
project X to have a dependency on project Y.

I know at least on Horizon, that summit after summit, cross cutting features 
that could really enhance the end user experience are rejected out of fear of 
adding any additional dependency (even if optional). I probably can’t even 
begin to count the number of times people have asked to add additional dynamic 
user preference customizations but been blocked because Horizon doesn’t want to 
add any kind of a dependency on any kind of a persistence mechanism.

Another problem I see is that project A has a high priority need to land a 
relatively simple patch in project B, but due to the extremely limited amount 
of time to actually get any reviews for non-priority features in project B, 
that only a few weeks into the release cycle you get blocked with -2 and a 
“better luck next time” message. Which effectively means you are barely a month 
or two into the current release and now are faced with the reality that it will 
be *at least* 9 months before you can hope to see your patch be released in the 
next “alphabet letter of your choice” release. In the meantime, the people 
paying the salaries of the developers working on OpenStack decide that progress 
is too slow and pull their people off all together. But don’t worry, the 
community elitists will just declare these to be drive by contributions and are 
happy to essentially pat themselves on the back for preventing those people 
from contributing code.

I am a core reviewer on a couple projects and I can honestly say that I believe 
the core reviewer teams are also a huge part of the bottleneck. This certainly 
isn’t due to cores being lazy, quite the contrary, but that perhaps it is too 
much to expect of core reviewers to essentially perform the product management 
role, the project management role, the architecture role, the evangelist role, 
the developer roles, and finally the quality assurance role (you know, the 
actual code review thing).

One of the most beautiful things about OpenStack is that the developers are 
empowered in a way that they simply are not within the confines of large 
proprietary enterprise software shops.  However, the inability to make progress 
from release to release whenever it comes to cross project integration and 
dependencies is an Achilles heel that I fear may be the downfall of OpenStack.
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Thursday July 21 meeting cancelled

[Tripp, Travis S]

Due to our midcycle hangout today [0], we are cancelling the searchlight IRC 
meeting tomorrow (Thursday July 21).

[0] https://etherpad.openstack.org/p/searchlight-newton-hangout
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Tripp, Travis S]

TL;DR, I’ll be quite happy to get rid of the need for initScope and like 
exploring a common way to share model other than events.

 |From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| I think this is a bad idea because in the angular world "factory" means 
singleton 
| (which is totally opposite to what everyone else in the programming world 
[and the rest]
| thinks "factory" means but hey, angular gonna angular) and we'd be changing 
that, and
| the potential for confusion would be very high.

| Controllers are already not singletons - I see no reason why mutable state 
shouldn't be |
| contained in *them*. We don't need to invent something new to hold that 
mutable state.

As FYI, the way I mentioned for factories is *not* inventing something new and 
is how they were intended and even used in angular in that way.  A factory is a 
singleton object whose job is to create instances of objects.  It is even used 
that way in angular code. See $cacheFactory [0]

[0] https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js

The differentiation of .factory vs .service is still obtuse since they are both 
singletons, but the concept of a factory object whether .service or .factory 
still remains.

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM
|Thus the controller and action service, which are quite independent pieces of 
code,
| must have intimate knowledge of each  other's internal operation. I'm not so 
keen on that ;-)

That is yuck!

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| But the workflow implementation has no concept of an over-arching model for
| the workflow. If that was changed, I believe all the current $scope 
shenanigans
|(which are basically about short-circuiting the workflow not doing its job ;-) 
would
| go away.

The event based mechanism was an attempt originally proposed by Thai to get 
around the essentially hard coded shared model service in launch instance where 
the steps are tightly bound to that model service. There was also some idea 
that some steps could be reusable / recomposable across work flows (such as 
update metadata) if you didn’t tightly bind things.

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| So, here's my rough thought: workflow.model is an object with properties 
named for
| each of the workflow steps - using the step formName as the name (hell, schema
| form could probably make this a doddle). The workflow model is passed to the
| controller for each step, which uses its own named model to store the data 
captured
| by the step - and as a side effect it can poke at (and watch) the data 
captured by other
| steps, which is often useful. Workflow $modal resolution supplies the 
workflow model
| for the consumer of the workflow to then to something with all that data.

We’ve roughly talked about a need for something like this for sometime and I 
think it would be great to explore it. It is similar to some of the Django 
workflow concepts.  Effectively, this boils down to steps declaring with data 
they require and which data they provide.  I’d prefer it if we can disassociate 
the step name from the data name. We want to keep the steps from being tightly 
coupled to each other, but rather be declarative about the data they use.  For 
example, if we later want to split out steps (see History of Launch Instance, 
Chapter 1: Source and Details) or want to combine steps (See History of Launch 
Instance: Chapter Boy it would be nice if we could have a quick launch step as 
the first step), it will be easier to do if we don’t couple the model to the 
current presentation. 

By the way, yes the ability to watch the data or react to changes in the data 
is definitely useful. For example, in Launch Instance if you increase the 
number of instances, this may mean that the flavor you’ve chosen will now go 
over your quota (select smaller), which is a different step. 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Tripp, Travis S]

If we find that there is still a need to send the scope in that can’t be 
reasonably worked around, then the action services could be changed to be a 
factory. The injected action factory should have a factory function called by 
the controller which creates an instance of the action in each controller.  
Then the init scope could be called on the instance of that action. This also 
would then allow actions to have state that is retained for the lifetime of the 
controller, while not worrying about sharing action state with other 
controllers.

-Travis
From: Richard Jones 
Reply-To: OpenStack List 
Date: Friday, July 15, 2016 at 2:28 PM
To: OpenStack List 
Subject: [openstack-dev] [Horizon] Angular action services and initScope

Hi folks,

Something that's been bothering me for a while is that the action services 
break the encapsulation model of Angular Services - that they are singletons, 
and consumable by multiple simultaneous consumers without those consumers 
affecting each other through their use of the Service.

At the moment the initScope() functionality we've included in the action 
services breaks that model - at a minimum it is possible for multiple consumers 
to initScope() with different scopes simultaneously. This is the reason why 
I've been arguing (ok, "debating" :-) for the cessation of using scopes in this 
way.

I think we need to do two things reasonably soon (before patterns become more 
ingrained):

1. Stop passing in $scope to initScope in all cases - the new 
ActionResult-enabled pattern should hopefully replace all those
2. Remove all initScope methods altogether. The only other use of initScope 
that I see is the pre-loading of data used during the execution of action 
allowed() methods. We should move that preloading/caching either into the 
creation of the Service object itself, or into the allowed method.

If there is a use-case of initScope that I've missed (something that needs to 
be execute *after* the Service is created, not something that needs to tie the 
Service to a particular consumer of the service) then please let me know :-)


 Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Tripp, Travis S]

By caching, do you mean not persisting it in local storage or a cookie?  Would 
it be okay to store in a variable in browser memory for the duration of the 
session to be used with subsequent API requests?

Thanks,
Travis

On 7/6/16, 6:36 PM, "David Stanek"  wrote:

On 07/01 at 19:41, Fox, Kevin M wrote:
> Hi David,
> 
> How do you feel about the approach here:
> https://review.openstack.org/#/c/311189/
> 
> Its lets the existing angular js module:
> horizon.app.core.openstack-service-api.keystone
> 
> access the current token via getCurrentUserSession().token
> 

Hey Kevin,

It's hard to tell without a lot of the context. From what I can tell the
token is pulled down as part of the data of an API request. As long as
that's not cached I think you are OK.

-- 
David Stanek
web: http://dstanek.com
blog: http://traceback.org

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Mid Cycle Hangout

[Tripp, Travis S]

At our last IRC meeting, we discussed that there were a few topics which could 
use some high bandwidth conversation, in particular the pipeline architecture 
[0] as well as reviewing progress for the release.  Since we are not having a 
face to face meetup which would exclude people unable to travel, we decided 
that we would try to have a video conference hangout sometime in the next few 
weeks.  We agreed to use doodle to find a time that works for people.  Below is 
the doodle poll:

- http://doodle.com/poll/stxrx9wxq38itnk3

Please expand the accordion to see all the date / time options.

[0] Pipeline architecture https://review.openstack.org/308824

Thank you,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

I am nominating Lei Zhang from Intel (lei-zh on IRC) to join the Searchlight 
core reviewers team. He has been actively participating with thoughtful patches 
and reviews demonstrating his depth of understanding in a variety of areas. He 
also participates in meetings regularly, despite a difficult time zone. You may 
review his Searchlight activity reports below [0] [1].

[1] (~Mitaka + Newton)  
http://stackalytics.com/report/contribution/searchlight-group/200
[0] (~Newton)   
http://stackalytics.com/report/contribution/searchlight-group/40

Please vote for this change in reply to this message.

Thank you,
Travis


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Angular form framework

[Tripp, Travis S]

Yes, it is angular specific. If there is something that can work across all 
frameworks, then that would be good to know.

From: Michael Krotscheck <krotsch...@gmail.com<mailto:krotsch...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 5, 2016 at 8:51 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] Angular form framework

This feels like a thing for AngularJS projects only, yes? What about projects 
like Fuel that use React?

Michael

On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S 
<travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>> wrote:
Hello everybody,

I sent a message about this direclty to a couple of people for their quick 
thoughts. It looks like there is enough interest that I should have just sent 
it to the whole ML from the start. I’d like to keep folks in the loop, so, I’m 
copying it all below with all of the responses To date.

Thanks,
Travis

From: "Borland, Matt" 
<matthew.borl...@hpe.com<mailto:matthew.borl...@hpe.com><mailto:matthew.borl...@hpe.com<mailto:matthew.borl...@hpe.com>>>

That sounds great, it would be good to use something we don’t have to maintain. 
 Timur, thanks for researching that!

Matt

From: Timur Sufiev [mailto:tsuf...@mirantis.com<mailto:tsuf...@mirantis.com>]

Folks,

I was going to research this library as the possible prerequisite to 
angularization murano-dashboard 'dynamic ui' feature. So i'm planning to start 
next week looking into it.

On Mon, 2 May 2016 at 20:21, Thai Q Tran 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com><mailto:tqt...@us.ibm.com<mailto:tqt...@us.ibm.com>>>
 wrote:
I think that it will remove a lot of boilerplate HTML, and is much more 
extensible than the current way of creating forms. But we may need to extend 
the directive to do more things.

The options they provide does not cover the 2 cases that I brought up. 
hz-password and hz-if-* are both directives.
For example: 

This says that if some_rules passes, then show this input, otherwise, hide it. 
Essentially, what we need is the ability to inject additional attrs into each 
form field so that we can include our own directives. If we can somehow extend 
ngSchemaForm to support this, it should work.

Alternately, we can do the policy check in javascript instead. It just means we 
have to use the services directly rather than their directive counterparts 
(most of the directives we have are backed by a service, i.e. hz-if-policy uses 
the policy service). It's less nice but should also work.

Ultimately, I think going this direction is right, as the extensible benefits 
outweighs the declarative readability. There is still a separation of concerns, 
the forms can be declare like how we declare actions today (in a service that 
we can extend).

- Original message -
From: "Rob Cresswell (rcresswe)" 
<rcres...@cisco.com<mailto:rcres...@cisco.com><mailto:rcres...@cisco.com<mailto:rcres...@cisco.com>>>

I’m a pretty big fan of this idea, I’ve mentioned it at basically every meet up 
we’ve had. Building up content like this is a great way of preventing 
duplication.

Thai, the forms can take specific conditions to control their display: 
https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options
 as well as custom form fields, so it looks like that solves both of your 
issues?

Rob

On 27 Apr 2016, at 11:44, 
tsuf...@mirantis.com<mailto:tsuf...@mirantis.com><mailto:tsuf...@mirantis.com<mailto:tsuf...@mirantis.com>>
 wrote:

I recall mentioning model-directed generation of forms layout (since they are 
pretty verbose) at Hillsboro midcycle, the response was that 'mixing 
logic/model and presentation is not the best pattern'.

On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com><mailto:tqt...@us.ibm.com<mailto:tqt...@us.ibm.com>>>
 wrote:
Looks interesting, but I'm not too sure it will work for all cases. I can think 
of a few cases where this might not work.

Case 1. We have custom directives that modify existing input forms such as 
hz-password. Not sure how we will be able to incorporate it if we use an 
auto-generated form.

Case 2. We have things like hz-if that we may use to control which form fields 
to show. Again, not sure how this will work if we are auto-generating the form. 
I suppose you would have to do the check in the controller and modify the JSON 
to reflect this. But that will make it less declarative.

- Original message -
From: "Tripp, Travis S" 
<travis.tr...@hpe.com<mailto:travis.tr...@hpe.com><mailto:travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>>>

Alex Tivelkov at Mirant

[openstack-dev] [horizon] Angular form framework

[Tripp, Travis S]

Hello everybody,

I sent a message about this direclty to a couple of people for their quick 
thoughts. It looks like there is enough interest that I should have just sent 
it to the whole ML from the start. I’d like to keep folks in the loop, so, I’m 
copying it all below with all of the responses To date.

Thanks,
Travis

From: "Borland, Matt" <matthew.borl...@hpe.com<mailto:matthew.borl...@hpe.com>>

That sounds great, it would be good to use something we don’t have to maintain. 
 Timur, thanks for researching that!

Matt

From: Timur Sufiev [mailto:tsuf...@mirantis.com]

Folks,

I was going to research this library as the possible prerequisite to 
angularization murano-dashboard 'dynamic ui' feature. So i'm planning to start 
next week looking into it.

On Mon, 2 May 2016 at 20:21, Thai Q Tran 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com>> wrote:
I think that it will remove a lot of boilerplate HTML, and is much more 
extensible than the current way of creating forms. But we may need to extend 
the directive to do more things.

The options they provide does not cover the 2 cases that I brought up. 
hz-password and hz-if-* are both directives.
For example: 

This says that if some_rules passes, then show this input, otherwise, hide it. 
Essentially, what we need is the ability to inject additional attrs into each 
form field so that we can include our own directives. If we can somehow extend 
ngSchemaForm to support this, it should work.

Alternately, we can do the policy check in javascript instead. It just means we 
have to use the services directly rather than their directive counterparts 
(most of the directives we have are backed by a service, i.e. hz-if-policy uses 
the policy service). It's less nice but should also work.

Ultimately, I think going this direction is right, as the extensible benefits 
outweighs the declarative readability. There is still a separation of concerns, 
the forms can be declare like how we declare actions today (in a service that 
we can extend).

- Original message -
From: "Rob Cresswell (rcresswe)" <rcres...@cisco.com<mailto:rcres...@cisco.com>>

I’m a pretty big fan of this idea, I’ve mentioned it at basically every meet up 
we’ve had. Building up content like this is a great way of preventing 
duplication.

Thai, the forms can take specific conditions to control their display: 
https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options
 as well as custom form fields, so it looks like that solves both of your 
issues?

Rob

On 27 Apr 2016, at 11:44, tsuf...@mirantis.com<mailto:tsuf...@mirantis.com> 
wrote:

I recall mentioning model-directed generation of forms layout (since they are 
pretty verbose) at Hillsboro midcycle, the response was that 'mixing 
logic/model and presentation is not the best pattern'.

On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com>> wrote:
Looks interesting, but I'm not too sure it will work for all cases. I can think 
of a few cases where this might not work.

Case 1. We have custom directives that modify existing input forms such as 
hz-password. Not sure how we will be able to incorporate it if we use an 
auto-generated form.

Case 2. We have things like hz-if that we may use to control which form fields 
to show. Again, not sure how this will work if we are auto-generating the form. 
I suppose you would have to do the check in the controller and modify the JSON 
to reflect this. But that will make it less declarative.

- Original message -
From: "Tripp, Travis S" <travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>>

Alex Tivelkov at Mirantis mentioned this to me.  Has anybody looked at this to 
see if it is something we might want to incorporate. He said it allows using 
JSON schema definitions to generate forms.  As FYI, the Metadata Definitions in 
Glance are in JSON schema format and many of the services actually provide JSON 
schema of their fields.
ar form framework

http://schemaform.io<http://schemaform.io/>



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [swift] [searchlight] Swift Searchlight Integration Austin Summit Recap

[Tripp, Travis S]

Hello Swift team,

I sent out a summary of what I believe was discussed at our joint session to 
just [searchlight] and wanted to copy it to the [swift] thread so that we are 
on the same page.  Please take a look and reply with any comments, corrections, 
questions, etc.  Thanks!

Swift Integration

We agreed on the following components:

* Provide a middleware pipeline plugin with direct injection using ES library
* Provide a hook in the container sync work to also interact with the ES 
injection library

Swift Middleware pipeline plugin

We agreed with the team to continue building out the ES indexing library and it 
is okay to have a dependency on the ES client library.  In discussions about 
OSLO messaging, we explored the idea to build ES as a driver for the messaging 
(instead of rabbit). This would allow deployers with Rabbit to use Rabbit and 
those who don’t to go straight to ES. However, there was concern that the 
dependencies [8] that OSLO messaging pulls in are too much for the Swift-only 
deployers like Swiftstack to handle. Swiftstack in particular spoke of how they 
would have to package and support each of those libraries for 7 different OS 
distributions. They did say that if taking “rabbit” out as a default driver for 
oslo.messaging would remove most the dependencies, then this could be 
reconsidered.

Action: See how much the oslo.messaging dependencies are reduced when the 
rabbit driver isn’t included.

[8] https://pypi.python.org/pypi/oslo.messaging

There was discussion about increasing performance of indexing by only indexing 
in bulk. The idea was suggested to use Green threads to implement a very simple 
batch queuing system.  It would just collect incoming data requests and given a 
certain configurable number (e.g. 20, 200, etc) at which point it would flush 
the queue and send a batch of requests to ES.  It was agreed this could be a 
follow-on patch.

The spec [9] for this library will be updated appropriately.

[9] https://review.openstack.org/#/c/305404/

Swift Container Sync

This is something  which Timur Alperovich is working on and was originally just 
going to do internal swift-y things [10].  However, they’ve decided that they 
would make it a bit smarter and able to handle plugging the direct ES indexer 
library into it. It would then provide backup indexing to the middleware (cache 
coherency kind of concepts).

[10] 
http://docs.openstack.org/developer/swift/overview_container_sync.html#what-s-going-on-behind-the-scenes-in-the-cluster
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Austin summit cells v2 session recap

[Tripp, Travis S]

Thanks for these notes, Matt. Couple of comments inline.





On 5/2/16, 7:32 PM, "Matt Riedemann"  wrote:

>Andrew Laski led a double session for cells v2 on Wednesday afternoon. 
>The full session etherpad is here [1].
>
>Andrew started with an overview of what's done and what's in progress. 
>Note that some of the background on cells, what's been completed for 
>cells v2 and what's being worked on is also in a summit video from a 
>user conference talk that Andrew gave [2].
>
>Pagination
>--
>
>This took a significant portion of the second cells v2 session and is 
>one of the more complicated problems to sort out. There are problems 
>with listing all instances across all cells especially when we support 
>sorting. And we really have a latent bug in the API since we never 
>restricted the list of valid sort keys for listing instances, so you can 
>literally sort on anything in the instances table in the DB.
>
>There were some ideas about how to handle this:
>
>1. Don't support sorting in the API if you have multiple cells. Leave it 
>up to the caller to sort the results on their own. Obviously this isn't 
>a great solution for existing users that rely on this in the API.
>
>2. Each cell sorts the results individually, and the API merge sorts the 
>results from the cells. There is still overhead here.
>
>3. Don't split the database, or use a distributed database like Redis. 
>Since this wasn't brought up in person in the session, or on Friday, it 
>wasn't discussed. There is another thread about this though [4].
>
>4. Use the OpenStack Searchlight project for doing massive queries like 
>this. This would be optional for a cell of one but recommended/required 
>for anyone running multiple cells. The downside to this is it's a new 
>dependency, and requires Elasticsearch (but many deployments are 
>probably already running an ELK stack for monitoring their logs). It's 
>also unclear at an early stage how easy this would be to integrate into 
>Nova. Plus deployers would need to setup Searchlight to listen to 
>notifications emitted from Nova so the indexes are updated in ES. It is, 
>however, arguably a better tool for the job than Nova trying to deal 
>with filtering and sorting with python. There is general agreement 
>within the core team that this is the path forward, but it's going to 
>require investigation and testing before we get a better idea of how 
>feasible this is.


I’ve spoken about this with some members of the Searchlight team and we
would like to do whatever we can to support this effort, so please let us
know how we can best help out here.

From our standpoint, versioned notifications with enough data that we
don’t have to do any callbacks to fill in the gaps at indexing time has
been placed among our top priorities for Newton. We had a fishbowl
at the summit on notifications and Jay introduced a couple of us to
Gibi. So, we’ll be getting involved as consumers of that effort very
shortly.


>
>Related to paging, we also have an existing problem with the marker that 
>will need to be sorted out before we can support multiple cells with v2. 
>Flavors are now in the API DB, and we return a marker for paging, but it 
>doesn't have the cell context, so we have to work that in. The good news 
>is we control the marker and we never documented anywhere that it's a 
>specific resource uuid (although for instances it is the last instance 
>uuid processed). So this is fixable, but is a known issue right now.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Austin summit versioned notification

[Tripp, Travis S]

Thanks, Jay! We’re looking through everything and will be attending these 
meetings moving forward.

-Travis



On 5/3/16, 6:17 AM, "Jay Pipes"  wrote:

>cc'ing Travis and Steve directly, since they will likely be very 
>interested in this effort from the Project Searchlight perspective. :)
>
>On 05/03/2016 04:10 AM, Balázs Gibizer wrote:
>> Hi,
>>
>> Last week Friday in Austin we discussed the way forward with the versioned
>> notification transformation in Nova.
>>
>> We agreed that when we separate the object model use for notifications from
>> the nova object model we still use the NovaObject as a base class to avoid
>> change in the wire format and the major version bump it would cause.
>> However we won't register the notification object into the 
>> NovaObjectRegistry.
>> In general we agreed that we move forward with the transformation according
>> to the spec [1].
>>
>> Regarding the schema generation for the notifications we agreed to
>> propose a general JSON Schema generation implementation to
>> oslo.versionedobjects [2] that can be used in Nova later to generate
>> schemas for the notification object model.
>>
>> To have a way to synchronize our effort I'd like to restart the weekly
>> subteam meeting [5]. As the majority of the subteam is in US and EU I propose
>> to continue the currently existing time slot UTC 17:00 every Tuesday.
>> I proposed the frequency increase from biweekly to weekly here [3].
>> This means that we can meet today 17:00 UTC [4] on #openstack-meeting-4.
>>
>> Cheers,
>> Gibi
>>
>> [1] https://review.openstack.org/#/c/286675/ Versioned notification 
>> transformation
>> [2] https://review.openstack.org/#/c/311194/ versionedobjects: add json 
>> schema generation
>> [3] https://review.openstack.org/#/c/311948/
>> [4] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160503T17
>> [5] https://wiki.openstack.org/wiki/Meetings/NovaNotification
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] OpenStack Newton Austin Summit

[Tripp, Travis S]

Hello everybody,

Below is my summary of the Searchlight related discussions and results from the 
Austin Summit. I apologize for the length, but just decided to include all the 
session summaries in a single email. As always, please correct, add, etc!

5 Sessions (3 Searchlight Session, 1 joint Swift Team Session, 1 Horizon 
Session)

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=SearchLight%3A



Searchlight Notifications (Fishbowl)

This had good attendance with at least 25 people in the room. We used the 
following etherpad to communicate and share:

https://etherpad.openstack.org/p/searchlight-newton-summit-notifications

Nova notifications:

Jay Pipes and another person (didn’t catch his name) provided a lot of help 
with pointers on using versioned notifications. Jay said that they (Nova) are 
working towards providing an API where we can get a schema [0] for the 
versioned notifications and then can extract the data we need based on the 
version of the Nova data that we need.

[0] http://eavesdrop.openstack.org/#Nova_Notification_Meeting

Jay later introduced us to Balazs Gibizer (gibi - the Nova versioned 
notification sub-team lead). Balazs said he’d love to help us get any data in 
that we need and he gave us the pointer that they are restarting the weekly 
versioned notification meetings [1].
  

[1] https://review.openstack.org/#/c/311194/

It was mentioned that we also we should take a look at “Stackdistiller” [2].

[2] https://github.com/openstack/stacktach-stackdistiller

Jay also mentioned that he has brought up the topic of the Nova team to stop 
trying to do their own search and proxy the Nova list API to Searchlight [3].

[3] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093482.html


Ironic notifications: Three people from Ironic attended and expressed a lot of 
interest in supporting Searchlight. They noted that Ironic is currently working 
on adding notifications and their feedback was "Please look at the 
notifications patch and just tell us what you need.” [4]

[4] https://bugs.launchpad.net/searchlight/+bug/1526408


Designate notifications: Graham Hayes noted that we need to consider v1 
deprecated and can do that as soon as Horizon moves to v2.

Cinder notifications: Duncan Thomas says that the changes Searchlight needs for 
notifications should be available within a few weeks.

Heat notifications: Several people expressed interest in Heat, but there 
weren’t any concrete actions taken from this session.


Searchlight Priorities

I communicated that the most important theme for Newton is production 
readiness. We will be targeting moving from 0.x to 1.x this release (Kilo was 
an experimental glance feature, Liberty was Searchlight 0.1, and Mitaka was 
Searchlight 0.2). So scalability, security, and performance are all top 
priority. This includes moving to ElasticSearch 2.x, which is nearly complete. 
Our ongoing theme of adding plugins for additional resources will continue, but 
reviews related to production readiness should have higher priority. Richard 
Jones mentioned using OSIC for testing and would talk to somebody about 
creating OSAD scripts to deploy Searchlight in OSIC.

The session was unfortunately a bit short, leaving us with only time to walk 
the list of all blueprints listed as High and give people an opportunity to 
voice an opinion whether or not any high priorities should be bumped down and 
whether or not we were missing any high priorities. Here are a few notes from 
that session:

Melissa, the Rackspace Public Cloud control panel program manager attended and 
said that they are looking into using Searchlight to fill the API gaps. They 
have tried to handle quite a few things on the front end (javascript), but 
still have some troubles getting what they need out of the APIs. She said her 
highest priority for Searchlight are servers (instances) and doing anything we 
can to ensure there is no impact to Nova when deploying Searchlight. We 
mentioned the versioned notification work and I also proposed that we add a 
configuration option to disable API callbacks for any data not received via 
notifications.  I have opened a bug on this, and we’ll have to look further 
into this idea [5].

[5] https://bugs.launchpad.net/searchlight/+bug/1577947

We dropped the priority of adding support for Neutron policy based sharing to 
medium [6]. Brad Pokorny (Symantec – had a main conference presentation on 
securing APIs via policy) told us that he thought this should be a lower 
priority than our other blueprints. He also said he’d be willing to look over 
our current Policy controls on searchlight to look for holes.

[6] https://blueprints.launchpad.net/searchlight/+spec/neutron-tenant-rbac

We added back a story to further improve developer docs.  Several people asked 
how they could create a plugin and said they wanted more help. Steve has 
already started on this request [7].

[7] 

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

[Tripp, Travis S]

Sorry the for delayed response on this message. Finishing out Mitaka has been 
quite time consuming!

Cross region searching is a high priority item for Searchlight in Newton.  
Steve has begun work on the spec [1] with initial prototyping. We also are 
considering this as a likely candidate for the design summit.  Please take a 
look and help us work through the design!

[1] https://review.openstack.org/#/c/301227/

Thanks,
Travis

From: Brad Pokorny >
Reply-To: OpenStack List 
>
Date: Thursday, February 25, 2016 at 3:17 PM
To: OpenStack List 
>
Subject: [openstack-dev] [Horizon][Searchlight] Plans for Horizon cross-region 
view

The last info I've found on the ML about a cross-region view in Horizon is [1], 
which mentions making asynchronous calls to the APIs. Has anyone done further 
work on such a view?

If not, I think it would make sense to only show the view if Searchlight is 
enabled. One of the Searchlight use cases is cross-region searching, and only 
using the searchlight APIs would cut down on the slowness of going directly to 
the service APIs for what would potentially be a lot of records. Thoughts?

[1] http://openstack.markmail.org/message/huk5l73un7t255ox
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] mitaka mid-cycle report

[Tripp, Travis S]

Hello everybody,

I know this is a bit late, but I just now came across a blog that our very own 
Cindy Lu wrote about the Mitaka Horizon mid-cycle. It looks to me as though 
this never made it out to the mailing list. So, I just wanted to send it along 
to the ML. Thanks, Cindy!

https://developer.ibm.com/opentech/2016/03/03/horizon-mitaka-midcycle-sprint-recap/

-Travis

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Hiroyuki,

Thanks for the update. That sounds like the best course of action. As FYI, Li 
Yingjun also has a spec up on Nova to get notifications on hypervisors [0], 
which we briefly discussed in the IRC meeting this morning [1]. The two of you 
might be able to work together in getting nova specs and patches up. For most 
simple plugins to searchlight, we don’t need to do a full spec on the 
searchlight side in addition to the launchpad blueprint. But, if you could add 
a couple of bullet points on key pairs the etherpad below [2], it would be 
helpful. We are just trying to get a quick inventory started on that status of 
various notifications in OpenStack and may use that at the summit for 
discussions. Later, we may move this to wiki in table form, but I’m just hoping 
to get the basic info captured for now.

[0] https://review.openstack.org/#/c/299807/
[1] 
http://eavesdrop.openstack.org/meetings/openstack_search/2016/openstack_search.2016-03-31-15.01.log.html
[2] https://etherpad.openstack.org/p/search-team-meeting-agenda

Thanks,
Travis




On 3/31/16, 8:05 PM, "Hiroyuki Eguchi"  wrote:

>Hi Steve
>
>Thank you for your advice.
>Currently It's impossible to sync keystone information between DB and 
>ElasticeSearch.
>And no useful notification will be send for kaypair state change.(only 
>key_name) 
>So, I try to propose improving keypair notifications against nova-specs.
> 
>Thanks.
>Hiroyuki
>
>
>差出人: McLellan, Steven [steve.mclel...@hpe.com]
>送信日時: 2016年3月31日 5:49
>宛先: OpenStack Development Mailing List (not for usage questions)
>件名: 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 whether it will be good 
>enough. Please feel free to get in touch in IRC (#openstack-searchlight) if 
>that would be useful.
>
>Steve
>
>From: Hiroyuki Eguchi >
>Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>>
>Date: Tuesday, March 29, 2016 at 7:13 PM
>To: "OpenStack Development Mailing List (not for usage questions)" 
>>
>Subject: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi Lakshmi,
>
>Thank you for your advice.
>I'm trying to index the public keys.
>I'm gonna try to discuss in searchlight-specs before starting development.
>
>Thanks
>Hiroyuki.
>
>
>
>差出人: Sampath, Lakshmi [lakshmi.samp...@hpe.com]
>送信日時: 2016年3月29日 2:03
>宛先: OpenStack Development Mailing List (not for usage questions)
>件名: Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi Hiroyuki,
>
>For this plugin what data are you indexing in Elasticsearch. I mean what do 
>you expect users to search on and retrieve? Are you trying to index the public 
>keys?
>Talking directly to DB is not advisable, but before that we need to discuss 
>what data is being indexed and the security implication of it (RBAC) to users 
>who can/cannot access it.
>
>I would suggest start a spec in openstack/searchlight-specs under newton for 
>reviewing/feedback.
>https://github.com/openstack/searchlight-specs.git
>
>
>Thanks
>Lakshmi.
>
>From: Hiroyuki Eguchi [mailto:h-egu...@az.jp.nec.com]
>Sent: Sunday, March 27, 2016 10:26 PM
>To: OpenStack Development Mailing List (not for usage questions) 
>[openstack-dev@lists.openstack.org] 
>>
>Subject: [openstack-dev] [searchlight] Add Nova Keypair Plugin
>
>Hi.
>
>I am developing this plugin.
>https://blueprints.launchpad.net/searchlight/+spec/nova-keypair-plugin
>
>However I faced the problem that a admin user can not retrieve a keypair 
>information created by another user.
>So it is impossible to sync the keypair between OpenStack DB and 
>Elasticsearch, unless connect to OpenStack DB directly.
>Is there any suggestions to resolve it ?
>
>thanks.
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Mitaka PTL Candidacy

[Tripp, Travis S]

Hello Friends,

We are now going into the Newton cycle of Searchlight and I would be honored
if you’ll allow me to continue serving in the PTL role.

Searchlight has come a long way in the Mitaka cycle and it is certainly due
to some passionate work from a small, but expanding team of contributors.

With the release of Mitaka, we will have:

* Unified search across:
  * Nova instances
  * Glance images, snapshots, metadefs
  * Cinder volumes, snapshots
  * Neutron networks, ports, subnets, routers
  * Designate (DNS) Zones, recordsets
  * Swift container and object search (Experimental)
* Horizon search panel (plugin)
* CLI via an OpenStack client plugin
* Zero downtime re-indexing

In Newton, I believe our goals are to:

* Do everything we can to make Searchlight performant and production ready.

We need to work with other service teams to improve the notifications they
send so that we can reduce the number of API callbacks. In addition, we need
to improve the functional and integration test coverage. Finally, this also
means that we need to make tough decisions regarding features.

* Make search a central part of the Horizon UI experience.

In Mitaka, the Horizon Searchlight panel introduced an entirely
new experience for Horizon which opened a lot of eyes to how
impactful search can be to the entire development paradigm. At the
OpenStack bug smash day, I delivered a presentation detailing
this direction and I encourage everybody interested in Searchlight and
Horizon to watch it.

https://www.youtube.com/watch?v=ExzULavwvNQ

* Expand our searchable content

* Finish the notification forwarding work

* Enable new contributors and build build our core team

Last cycle I posted my thoughts on what being a PTL meant. Others, such as
Flavio have very eloquently written about the PTL role. In this email,
I will simply say that I am not the only person on the team who could do
a great job as PTL for the Newton cycle, but I thank you for your consideration
in allowing me to continue serving in this role.

Thank you,
Travis

[0] Candidacy patch: https://review.openstack.org/#/c/293865/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][taas] [ux] Proposal of Dashboard for TaaS

[Tripp, Travis S]

Hello Everybody,

The #openstack-ux project specifically has been setup to help with user 
experience designs.

We use a tool called invision [0] for visual design commenting and 
interactions. In addition,
The UX repo has been setup to help facilitate this process and Piet (the PTL) 
is looking
Into OpenSource opportunities. [1]

[0] https://openstack.invisionapp.com/d/main#/projects
[1]

>From Piet:
MOCK REVIEW TOOLS
There has been some discussion around replacing Invision because of the
speed, not being open source, etc.  I was hoping you could take a look at
a couple of alternatives.

To set expectations, it will need to be an open source project and be
hosted by either the OpenStack Infrastructure project or a specific
company.

Phabricator Pholio
http://phacility.com/phabricator/pholio/

Review board
https://www.reviewboard.org/



Thanks,
Travis




On 3/15/16, 9:30 PM, "Soichi Shigeta"  wrote:

>
>  Hi,
>
>  Please find attached file.
>Yet another design of the Network Topology Tab.
>
># I couldn't upload pdf files to the Wiki.
>  When I tried, a message ".pdf file is not permitted"
>  was shown.
>
>Regards,
>Soichi
>
>>
>>   Hi Anil, and folks,
>>
>> Thank you for your comments.
>>
>>> Thanks Soichi and Kaz for your work on implementing Horizon
>>> (dashboard) support for TaaS. The proposal (with screen shots)
>>> discussed in our recent IRC meeting look very nice. Here are some
>>> additional suggestions for improvement.
>>>
>>>
>>>
>>> 1.   General
>>>
>>> a.   When a port is being selected (for a tap-service instance or
>>> a tap-flow) it would be nice to also provide some extra information
>>> associated with that port, such as the VM it belongs to and the IP
>>> address.  This will look very similar to what is being done today when
>>> associating a floating IP with a VM vNIC. The extra context will allow
>>> users to identify their source and destination end-points with more
>>> ease. If a VM is not currently associated with a port then the extra
>>> information is not necessary.
>>
>> I agree with you.
>> It is difficult for users to select an appropriate port
>> by seeing only uuid.
>>
>> I didn't explain in the submitted document, in the current
>> implementation, not only uuid but also name is also shown
>> if a port is given a name.
>>
>> I agree to show IP address.
>> i.e., name, uuid, and IP address are shown for each port.
>> Please refer p.1 of the attached file.
>>
>> On the other hand, in terms of modification cost, I'd like
>> to disagree to show associated VM.
>> Because Neutron doesn't know association between a port and
>> a VM, we need to send a query to Nova.
>> Of course, I agree to implement this if requested from field.
>>
>>
>>> b.  When selecting the traffic monitoring direction, it would be
>>> nice to provide two check boxes, one for 'ingress' and the other for
>>> 'egress'. A user wishing to monitor a port in both directions can
>>> select both check boxes. I feel this looks better than having an
>>> option  called 'both'.
>>
>> In terms of consistency with the option in CLI, I prefer to
>> chose one of the both/ingress/egress from pull down menu.
>>
>> To avoid confusions, it had better to say something like
>> "ingress (to instance)" and "egress (from instance)".
>>
>>
>>> 2.   Using the Tap Services Tab
>>>
>>> a.   Allow tap-flow-create and tap-flow-delete operations to also
>>> be carried out from here. This will let users who prefer working in
>>> this fashion get everything done from the same place.
>>
>> I will plan to add "tap-flow-create" and "tap-flow-delete" button
>> on the tap-service tab.
>>
>> But, I'm afraid that a lot of ports will be listed as candidates
>> when a user starts tap-flow-create from here.
>> Because no instance (VM) is selected here, we can not filter to
>> list.
>>
>>
>>> b.  Provide a way to list tap flows currently associated with a
>>> tap service.
>>
>> Excuse me, I didn't mention about it on the submitted document.
>> This is done on the overview of a tap-service.
>> Please refer p.2 of the attached file.
>>
>>
>>> c.   Allow multiple tap-flows to be created at the same time. Let
>>> the user pick multiple source ports (and traffic monitoring
>>> directions) and have all of them attached to a designated tap-service.
>>
>> I'd like to consider this in the future.
>> Because it seems taking larger man-hour cost to realize.
>> (consideration with man-hour we have)
>> Additionally, I think we need to take care of error cases
>> such as a part of tap-flow creation failed.
>>
>>
>>> 3.   Using the Network Topology Tab
>>>
>>> a.   Allow tap-create and tap-delete operations to be also carried
>>> out from here. This will allow users who prefer working in this
>>> fashion get everything done from the same place. 

Re: [openstack-dev] [horizon] PTL noncandidacy

[Tripp, Travis S]

David,

Thank you so much for the patience and wisdom you’ve demonstrated over the 
years.
I always appreciate sense of humor you bring to IRC.

For the love of all that is OpenStack, please stay active on Horizon!

-Travis




On 3/11/16, 10:19 AM, "David Lyle"  wrote:

>After five cycles as PTL of Horizon, I've decided not to run for the
>Newton cycle.
>
>I am exceptionally proud of the things we've accomplished over this
>time. I'm amazed by how much our project's community has grown and
>evolved.
>
>Looking at the community now, I believe we have a tremendous group of
>contributors for moving forward. There are several people capable of
>becoming great PTLs and overall the community will be healthier with
>some turnover in the PTL role. I feel honored to have had your trust
>over this time and lucky to have worked with such great people.
>
>I will still be around and will help the next PTL make a smooth
>transition where requested.
>
>David
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Tripp, Travis S]

> On 03/09/2016 04:43 PM, Serg Melikyan wrote:

>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

> Say there are two xstatic libraries, a and b. B depends on a. Horizon depends 
> only on a. Plugin-foo depends on b. Horizon updates to a version of a that 
> the version of b consumed by plugin-foo is not compatible with.

> Rob

Just FYI, this topic came up in the horizon IRC today at the 20:30:45 minute 
mark.:  
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-03-09-20.00.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Tripp, Travis S]

Hi Michael,

The problem is that the warnings are so great that is really hard to read.

What if we amended the recently added lintq to do some inline filtering of the 
doc warnings?  This is just a bandaid of course.

I also am opposed to any major linting changes until Mitaka closes. They cause 
too many merge conflicts when the fix goes in, making the real bugs harder to 
get through.

-Travis

From: Michael Krotscheck >
Reply-To: OpenStack List 
>
Date: Wednesday, March 9, 2016 at 12:49 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Horizon] Javascript linting and documentation

+1 to what Rob said.

I guess I don't see what problems is being solved by turning the rule off, and 
I also don't see the harm in having more check. It does generate a lot of 
warnings, but invoking `npm run lint -- --quiet` gets rid of those. Also, from 
my experience, sphinx-based doc builds are notoriously permissive about bad 
formatting. Eslint's stricter jsdoc checks would add an additional safety net.

However, if you're working on this with the docs team, then the result should 
be applicable to the entirety of openstack - meaning that once your work is 
complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
> wrote:
If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
> wrote:

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and 
quickly noticed that about 85% of the "linting" warnings were about jsdoc. We 
have significant issues around jsdoc anyway and we're supposed to be using 
Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating 
publishable documentation for our Javascript code for some time. Most of the 
tools either don't work (dgeni) or produce pretty unusable output for a project 
our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx in 
collaboration with the docs team.

Regardless, I believe that the documentation generation should generate errors 
about that documentation, not the code linter. Once we actually get a 
documentation generator going. Until then, we don't even know what syntax the 
documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the moment, 
it is less than useful (the noise drowns out any other, legitimate linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

[Tripp, Travis S]

+1, no questions asked. It is rare to find somebody with the passion that Diana 
has shown.

From: Lin Hua Cheng >
Reply-To: OpenStack List 
>
Date: Tuesday, March 8, 2016 at 3:48 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to 
horizon-core

big +1 from me.

She made a lot of contribution in making theming better for horizon and also 
prevented potential issues through reviews.
Thanks for all the hard work, Diana.

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle 
> wrote:
I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [searchlight] Horizon, Search, and Composability

[Tripp, Travis S]

Hello everybody,

At the Horizon mid-cycle we had a lot of discussion on UI composability and 
searchability. Matt and Tyr provided a short presentation and demo at the 
mid-cycle. This morning I gave a more detailed presentation and demo via 
hangouts on air regarding Searchlight and Horizon. The audience this morning 
was broader, so I started with content based on Matt and Tyr’s presentation and 
included an extended demo, additional information about Searchlight, and some 
status information about what was discussed at the Horizon mid-cycle. Since 
both of these have recordings, I wanted to share them both with you.

[Full Presentation (Travis)]

https://www.youtube.com/watch?v=ExzULavwvNQ

[Horizon Mid-Cycle Presentation (Matt and Tyr)]

https://www.youtube.com/watch?v=jr5iIs4zvbY

Thanks,
Travis

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Dynamically adding Extra Specs

[Tripp, Travis S]

Dhvanan,

I admittedly only just saw the subject and skimmed the thread (so might be 
missing something), but have you looked into taking advantage of scheduler 
hints from a custom filter from the API / CLI?  As FYI, horizon has a patch up 
adding support for them [1].

[1] https://review.openstack.org/#/c/272635/

Travis

From: Dhvanan Shah >
Reply-To: OpenStack List 
>
Date: Sunday, February 7, 2016 at 8:34 PM
To: "Jay com>" >, OpenStack List 
>
Subject: Re: [openstack-dev] Dynamically adding Extra Specs

Hey Jay!

I was looking at implementing a few scheduling algorithms of my own natively 
into OpenStack, and for that I went through the nova-scheduler. After going 
through the scheduler, I felt that it was not very easy to implement or extend 
and add new scheduling algorithms to the scheduler. The only things that I felt 
that I could change or maybe was provisioned for adding or extending were the 
filters and weighers and implementing new scheduling algorithms with just these 
2 knobs was a little hard. I did change the code in the filter_scheduler to get 
some basic algorithms running like the first and next fit apart from the 
spreading and stacking which was already present. But to go beyond and to 
implement more complex algorithms was much harder and I would have to change a 
lot of code in different places that could as a side effect also break things 
and didn't seem clean. I might be wrong and might have not understood things 
right, please correct me if so.

To give an example of what I mean by a little complex scheduling algorithms: a 
subset matching algorithm - that schedules multiple heterogeneous requests by 
picking out a subset from the requests that best fit a host/s, so this would 
improve the utilization. The prerequisite for this is that I have multiple 
heterogeneous requests lined up to be scheduled. So for this kind of an 
algorithm it isnt easy to implement into OpenStack.

So a workaround that I'm working on for implementing different scheduling 
algorithms is by building a scheduling wrapper outside of the OpenStack 
architecture, where the user interacts with this wrapper and in the wrapper I 
get the host details from the database and based on the algorithm I want, the 
scheduler chooses the host for the request and gives out a VM : Host mapping 
(The wrapper does the sanity checks that the filters do to check if the host 
can accommodate or handle the request). Along with the request, I also want to 
pass this mapping that the scheduler can use to assign the request to the host 
passed in the mapping. I've written a filter that filters all the hosts apart 
from the host that I sent and this is how I make sure that the request gets 
placed on the host that I had passed. I have come up with a hack to pass the 
host to the scheduler, but it is not quite elegant.

Would be great to have your input on the same!

On Mon, Feb 8, 2016 at 12:51 AM, Jay Pipes 
> wrote:
Apologies for the delayed responses. Comments inline.

On 01/27/2016 02:29 AM, Dhvanan Shah wrote:
Hey Jay!

Thanks for the clarification. There was another thing that I wanted to
know, is there any provision to pass extra arguments or some extra
specifications along with the VM request to nova. To give you some
context, I wanted to pass a host:vm mapping to the nova scheduler for
its host selection process, and I'm providing this mapping from outside
of the openstack architecture.

Why do you want to do this? The scheduler is the thing that sets the host -> vm 
mapping -- that's what the process of scheduling does.

> So I need to send this information along
with the request to the scheduler. One way of doing this was creating
new flavors with their extra specification as different hosts, but that
would lead to as you pointed out earlier a "flavor explosion" problem.

So is there a way to pass some extra arguments or some additional
information to nova.

Depends what exactly you are trying to pass to Nova. Could you give some more 
information about your use case?

Thanks!
-jay



--
Dhvanan Shah
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

I am nominating Li Yingjun (yingjun on IRC) to join the Searchlight core 
reviewers team. We are a young project and he has already made a noticeable 
impact with his contributions. You may review his Searchlight [0] and 
cross-project [1] activity reports below. He has been participating in meetings 
regularly, despite a difficult timezone. He also has a broad base of exposure 
in OpenStack in terms of commits (26 different projects /repos) and reviews (23 
different projects / repos). This cross project knowledge is important to 
Searchlight’s charter.

[0] http://stackalytics.com/report/contribution/searchlight-group/90
[1] http://stackalytics.com/report/users/liyingjun

Please vote for this change in reply to this message.

Thank you,
Travis




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] [horizon] Metadata definitions catalog concept demo

[Tripp, Travis S]

Hi Glance & Horizon team,

This past week I had 3 people from different companies contact me asking for a 
few pointers on where to find more about the metadata definitions catalog and 
its usage. While trying to grab some links and screenshots to send along, I 
just decided to record a quick video and post to youtube. Its nothing fancy 
since I only had time to do 1 take, but here you go:

https://youtu.be/zJpHXdBOoeM

I hope this is at least somewhat useful to a few folks!

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Routing in Horizon

[Tripp, Travis S]

Rajat,

Thanks for starting some discussion here.  I think your target=“_self” is taken 
care of now, right?

Re: ng-route vs ui-router - everything I have ever seen or been told supports 
using ui-router instead of ng-route.  I know a quick google search supports 
that, but let me google that for all of us and give several references:

http://www.funnyant.com/angularjs-ui-router/
http://www.amasik.com/angularjs-ngroute-vs-ui-router/
http://stackoverflow.com/questions/21023763/angularjs-difference-between-angular-route-and-angular-ui-router
http://www.pearpages.com/javascript/angularjs/routing/2015/10/13/ngroute-vs-ui-router.html
http://stackoverflow.com/questions/32523512/ui-router-vs-ngroute-for-sinlge-page-app

So, I’m wondering if there’d been any discussion I missed on why not bring in 
ui-router?

Of course there is question using the new router in angular vs ui-router, but 
finding many pros- cons- on that seems to be a bit more difficult. Since it is 
1.5 / 2.0 and neither are past rc / beta, it doesn’t seem like something we can 
debate too well.

https://angular.github.io/router/getting-started
http://www.angulardaily.com/2015/12/angularintroduction-to-ngnewrouter-vs.html

Thanks,
Travis

From: Rajat Vig >
Reply-To: OpenStack List 
>
Date: Thursday, January 7, 2016 at 1:53 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Horizon] Routing in Horizon

Hi Everyone

One of my recent patches which enabled HTML5 based routing via Angular merged, 
some interesting things spun out.
I'd to scramble a few patches to get things
​​ back the same way
for all new Angular Panels.

I also realized that getting Horizon to an SPA with Angular requires more 
thought than mere fixing the current burning issue.
This mail's intent is to spur a direction on how we do routing in Angular and 
how do Angular Panels go back/forth between themselves and older Django panels.

The patch https://review.openstack.org/#/c/173885/ is possibly the first of 
many to use Angular based routing.
It currently uses ngRoute as the library was included in the xstatic-angular 
package.

What I'm roughly thinking to solve some of the immediate issues (there's 
possbily much more that I'm not)

1. If we are going to go with the SPA route, then all Panels need to indicate 
that they are Angular based.
For panels that are Angular, they need to declare routes they'd like to manage.

2. All tags on Angular Panels (including header, sidebar, footer) which don't 
route to Angular Panels will need the attribute target="_self" else Angular 
will not allow navigation to those links.

All sidebar links currently have the attribute set but headers and footers 
don't.
Sidebar links for Angular shouldn't have the attribute else SPA like behavior 
will not happen.
This will need to be documen
​tation​
​
​
​
.

3. That implies yet another problem with the Spinner Modal which gets activated 
on all sidebar clicks.
It'll need to be done differently for Angular routing vs hrefs still with 
Django.
The current spinner relies on a browser page refresh to disappear.

Then there's ngRoute.
Routing needs in Angular may need to handle route conflicts and maybe nested 
routes.
There are other, possibly better options that we could consider
1. https://github.com/angular-ui/ui-router
2. https://angular.github.io/router/

I've been part of the community for not long enough yet and I'm not yet 
completely aware of what exists outside the Horizon codebase so I might be 
missing somethings as well.

Regards
Rajat
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Weekly IRC meeting cancelled December 17th & 24th

[Tripp, Travis S]

After some more conversation, it sounds like New Years eve also is a bad day 
for most people. Are next meeting will be Thursday, December 7th.




On 12/15/15, 5:42 PM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:

>We will not be holding our weekly IRC meeting this week due to the
>busy holiday season with many people out.  Our regular meeting will
>resume Thursday, December 31st.
>
>As always, you can find the meeting schedule and agenda here:
>http://eavesdrop.openstack.org/#Searchlight_Team_Meeting
>
>
>Thanks,
>Travis
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Weekly IRC meeting cancelled December 17th & 24th

[Tripp, Travis S]

We will not be holding our weekly IRC meeting this week due to the
busy holiday season with many people out.  Our regular meeting will
resume Thursday, December 31st.

As always, you can find the meeting schedule and agenda here:
http://eavesdrop.openstack.org/#Searchlight_Team_Meeting


Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-core

[Tripp, Travis S]

Definite +1 for me.  I think they are great additions to the team!

-Travis





On 12/2/15, 11:57 AM, "David Lyle"  wrote:

>Let's try that again.
>
>I propose adding Richard Jones[1] to horizon-core.
>
>Over the last several cycles Richard has consistently been providing
>great reviews, actively participating in the Horizon community, and
>making meaningful contributions around angularJS and overall project
>stability and health.
>
>Please respond with comments, +1s, or objections within one week.
>
>Thanks,
>David
>
>[1] 
>http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
>On Wed, Dec 2, 2015 at 11:56 AM, David Lyle  wrote:
>> I propose adding Richard Jones[1] to horizon-core.
>>
>> Over the last several cycles Timur has consistently been providing
>> great reviews, actively participating in the Horizon community, and
>> making meaningful contributions around angularJS and overall project
>> stability and health.
>>
>> Please respond with comments, +1s, or objections within one week.
>>
>> Thanks,
>> David
>>
>> [1] 
>> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] [release] Searchlight client launchpad project

[Tripp, Travis S]

Hello all,

We have started building out the python client and OpenStack client plugin for 
Searchlight. We’ve now encountered the question of whether or not to manage the 
client change tracking through another Launchpad project specific to the client 
[2] or continue to manage it through the current Searchlight launchpad project 
[3]. It seems that with some of the recent changes that Doug has been sending 
out regarding the release notes process [4] that perhaps having another 
launchpad project to manage is not necessary anymore.

The dedicated project gives us somewhere to track releases of the client 
independently, but it also means yet another place to go to try to track 
everything. With the current launchpad project, the client repo, the specs 
repo, the release notes process, it is starting to feel like a lot to manage 
for what is still a small project. My preference would be to try to keep it as 
simple as possible. However, we do want to ensure that we have setup the 
process management toolchain to best support us now and in the future.

So, I’m asking for input on whether or not we should start using the new 
launchpad searchlight client project or just manage bugs and BPs in the main 
searchlight project.

Thank you!
Travis

[1] https://review.openstack.org/#/c/247565/
[2] https://launchpad.net/python-searchlightclient
[3] https://launchpad.net/searchlight
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Weekly IRC meeting cancelled

[Tripp, Travis S]

We will not be holding our weekly IRC meeting this week due to the
US Thanksgiving holiday.  Our regular meeting will resume Thursday,
December 3rd.

As always, you can find the meeting schedule and agenda here:
http://eavesdrop.openstack.org/#Searchlight_Team_Meeting


Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Searchlighters,

When we began this project, we had many discussions about process and made a 
conscious decision to support as lightweight of a workflow for feature requests 
as possible. We all discussed how we want to encourage contribution from 
everybody by supporting both developers and non-developers who want to provide 
input, requests for features, and bug fixes. Specifically, we decided that we 
did not want to immediately use a separate spec repo and to try to better 
incorporate our normal documentation repo into the feature request process 
whenever Launchpad didn’t meet our needs.

We did not formally document any of the above, mostly because we didn’t have 
time in Liberty, but also because the concept was still a little nebulous on 
how we would better incorporate our normal documentation processes into the 
feature request process.

Now that we are starting Mitaka, I’ve already encountered a couple of features 
where I felt that we needed a better review tool (e.g. gerrit) than launchpad. 
So, I’ve made an attempt [1] at documenting how we can still follow our 
original intents that I mention above. I also have a dependent feature review 
that follows this process as an example [2].

Please take a look at the workflow proposal review and provide comments. We 
also will discuss this in our weekly meeting. I recommend starting with this 
file: doc/source/feature-requests-bugs.rst

[1] Workflow Proposal - https://review.openstack.org/#/c/243881/
[2] Zero Downtime Feature - https://review.openstack.org/#/c/243386/


Steve,

Regarding you email [3] below.  I feel that the associated blueprint is an 
example of a blueprint that could benefit from a similar Gerrit review as 
described above. What do you think?

[3] Admin indexing - 
http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/68685

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Mitaka Priorities discussion mapped to launchpad

[Tripp, Travis S]

Hello Searchlighters,

I just wanted to let everybody know that I’ve captured the results of our 
priorities discussion on the Searchlight launchpad blueprints page.  In some 
cases, this meant creating a new blueprint (sometimes with only a little 
information).  Next week, it would be great if we can review this in our weekly 
meeting.

Thanks,
Travis



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Today's IRC meeting

[Tripp, Travis S]

Hello all,

The US time change while many of us were still getting home from Japan threw 
myself and several others off with today’s meeting time. Sorry about that! 
We’ll pick back up next week.  Next week’s agenda can be found at the below 
link.  Please feel free to add to to it / modify it and let’s talk in the IRC 
room more prior to it. Primarily, we need to continue reviewing and 
prioritizing Mitaka work.

https://etherpad.openstack.org/p/search-team-meeting-agenda

Thanks,
Travis

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Thank, Gibi!

A key aspect for notifications for Searchlight would be able to have the 
notification produce the same data that you’d get from the API.  So, with micro 
versions, it would probably need to be configurable for the notifications 
emitted on perhaps a certain topic to be able to be emitted according to a 
specified API version.

Like most summits, there is a timing conflict for me, but at least a couple of 
us Searchlighters should be able to make that time.

Thanks,
Travis

From: Balázs Gibizer 
>
Reply-To: OpenStack List 
>
Date: Wednesday, October 28, 2015 at 6:50 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [nova] [searchlight] Difference in nova 
notifications versus API

Hi,

There is a spec up [3] in nova to version notifications and also there will be 
a half session [4] tomorrow aftrenoon on the nova track to discuss it.

Cheers,
Gibi

[3] https://review.openstack.org/#/c/224755/
[4] 
https://mitakadesignsummit.sched.org/mobile/#session:2bbda0e5e052e5249fa1a118e906df46



Sent from my iPad
On 2015. okt. 28., at 15:10, McLellan, Steven 
> wrote:

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 in different formats (1). In addition, 
notification information isn't versioned and can change at will. Currently 
we've taken the approach of treating the notification as a sign that something 
has happened and that we should get current state from the API.

We'd love to be able to process notifications directly, and have some assurance 
that the format won't change drastically without warning. Michael suggested i 
start a mailing thread, but we also have a session tomorrow set aside for these 
kinds of discussions with other projects (2). If anyone's available to join us 
that would be splendid.

Steve (apologies if this ends up getting sent twice)

(1) For instance, 'accessIPv4' vs 'access_ip_v4', 'name' vs 'displayname'; 
extension information and some networking info like security groups generally 
isn't in notifications; notifications return more image information than the API

(2) 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.VjBRWK4rJE4

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Tripp, Travis S]

On 10/28/15, 11:43 AM, "Flavio Percoco"  wrote:

>On 26/10/15 17:20 +, Ian Cordasco wrote:
>>Hi everyone,
>>
>>
>>Today I'm removing myself from the core reviewer (and driver)
>>teams for the
>>
>>
>>following projects:
>>
>>- Bandit (bandit-core and transitively security-specs-core)
>>
>>- Glance (glance-core and glance-specs-core)
>>
>>- OpenStack Ansible (openstack-ansible-core)
>>
>>- Searchlight (searchlight-core)
>>
>>Recent events both in my position at Rackspace and my personal
>>life mean I no longer have sufficient time to properly act as a core reviewer 
>>for
>>These projects. My personal life has suffered from attempts to continue
>>to uphold my responsibilities to OpenStack and the other open source projects 
>>I
>>develop, maintain, and direct. Changing responsibilities in my current role
>>in the last 8-10 months mean that I don't have sufficient time during the
>>normal 0900-1700 period to accurately and thoroughly conduct reviews. I'm 
>>confident
>>this is only a temporary hiatus and that sometime next year, I will be
>>able to fully rejoin the OpenStack community.
>>
>
>Ian,
>
>I can't stress enough how sorry I am to see you go from the team. Your
>reviews, comments and contributions have always been excelent and of
>huge help to our community.
>
>I look forward for that time when you'll be able to come back and as a
>*member* of the community I'd be more than happy to have you back.
>
>Thanks for all the time you've spent on these projectes, for your
>honest and clear email on your situation and availability.
>
>Take good care and, please, come back :)
>Flavio
>
>-- 
>@flaper87
>Flavio Precook


Ian,

Your core status on all of these projects is a true testament to your
abilities, dedication, and character.  All of which we greatly
appreciate about having you on the searchlight team and are why
you will always be welcome on our team. In the meantime, I fully
support you making decisions that are best for you and your family.
I hope that you will be able to find a balance which works for you.


Thank you for all that you have done and contributed!

-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Searchlight] Mitaka summit schedule

[Tripp, Travis S]

Hello Search Enthusiasts,

Our conference and summit schedule events are now loaded into the system.

Main conference presentation and demo:


 [1] Introducing OpenStack Searchlight - Search your cloud at the speed of 
light!

Design Summit:

 [2] Prioritizing Search Integrations and Capabilities (Nova, Neutron, Cinder, 
Swift, etc) 
[3] Cross Region Searching

Etherpads are created and linked from the design summit sessions for your 
viewing and editing pleasure.

 
 [1] http://sched.co/49ub
 [2] 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.Vh7mEhNVhBc
 [3] 
http://mitakadesignsummit.sched.org/event/b30bb4203a490efe1370ecfda5e4aaee#.Vh7mFhNVhBc


See you there!

Travis


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Suggestions for handling new panels and refactors in the future

[Tripp, Travis S]

Hi Doug!

I think the is a great discussion topic and you summarize your points very 
nicely!

 I wish you’d responded to this thread, though:  
https://openstack.nimeyo.com/58582/openstack-dev-horizon-patterns-for-angular-panels,
 because it is talking about the same problem. This is option 3 I mentioned 
there and I do think this is still a viable option to consider, but we should 
discuss all the options.

Please consider that thread as my initial response to your email… and let’s 
keep discussing!

Thanks,
Travis

From: Douglas Fish
Reply-To: OpenStack List
Date: Friday, October 9, 2015 at 8:42 AM
To: OpenStack List
Subject: [openstack-dev] [Horizon] Suggestions for handling new panels and 
refactors in the future

I have two suggestions for handling both new panels and refactoring existing 
panels that I think could benefit us in the future:
1) When we are creating a panel that's a major refactor of an existing it 
should be a new separate panel, not a direct code replacement of the existing 
panel
2) New panels (include the refactors of existing panels) should be developed in 
an out of tree gerrit repository.

Why make refactors a separate panel?

I was taken a bit off guard after we merged the Network Topology->Curvature 
improvement: this was a surprise to some people outside of the Horizon 
community (though it had been discussed within Horizon for as long as I've been 
on the project). In retrospect, I think it would have been better to keep both 
the old Network Topology and new curvature based topology in our Horizon 
codebase. Doing so would have allowed operators to perform A-B/ Red-Black 
testing if they weren't immediately convinced of the awesomeness of the panel. 
It also would have allowed anyone with a customization of the Network Topology 
panel to have some time to configure their Horizon instance to continue to use 
the Legacy panel while they updated their customization to work with the new 
panel.

Perhaps we should treat panels more like an API element and take them through a 
deprecation cycle before removing them completely. Giving time for customizers 
to update their code is going to be especially important as we build angular 
replacements for python panels. While we have much better plugin support for 
angular there is still a learning curve for those developers.

Why build refactors and new panels out of tree?

First off, it appears to me trying to build new panels in tree has been fairly 
painful. I've seen big long lived patches pushed along without being merged. 
It's quite acceptable and expected to quickly merge half-complete patches into 
a brand new repository - but you can't behave that way working in tree in 
Horizon. Horizon needs to be kept production/operator ready. External 
repositories do not. Merging code quickly can ease collaboration and avoid this 
kind of long lived patch set.

Secondly, keeping new panels/plugins in a separate repository decentralizes 
decisions about which panels are "ready" and which aren't. If one group feels a 
plugin is "ready" they can make it their default version of the panel, and 
perhaps put resources toward translating it. If we develop these panels in-tree 
we need to make a common decision about what "ready" means - and once it's in 
everyone who wants a translated Horizon will need to translate it.

Finally, I believe developing new panels out of tree will help improve our 
plugin support in Horizon. It's this whole "eating your own dog food" idea. As 
soon as we start using our own Horizon plugin mechanism for our own development 
we are going to become aware of it's shortcomings (like quotas) and will be 
sufficiently motivated to fix them.

Looking forward to further discussion and other ideas on this!

Doug Fish

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Liberty release finalization

[Tripp, Travis S]

On 10/6/15, 2:28 AM, "Thierry Carrez"  wrote:

>
>The "intermediary" model requires the project following it to be mature
>enough (and the project team following it to be disciplined enough) to
>internalize the QA process.
>
>In the "with-milestones" model, you produce development milestones and
>release candidates to get the features out early and progressively get
>more and more outside testing on proposed artifacts. It's "ok" if a
>development milestone is revealed to be unusable: that shows lack of
>proper testing coverage, and there is still time to fix things before
>the "real" release.
>
>In the "intermediary" model, you deliver fully-usable releases that you
>recommend production deployments to upgrade to. There is no alpha, beta
>or RC. You directly tag a release. That means you need to be confident
>enough in your own testing and testing coverage. Mistakes can still
>happen (in which case we rush a subsequent point release) but should
>really be exceptional, otherwise nobody will trust your deliverables.
>
>This is why we recommend the "intermediary" model to mature projects and
>project teams -- that model requires excellent test coverage and
>discipline inside the team to slow down development as you get closer to
>a release tag and spend time on testing.
>
>-- 
>Thierry Carrez (ttx)

Thierry,

Thanks again for the information. After quite a bit of discussion in our IRC 
channel this morning, we think it does make sense to start with the milestones 
as recommended.  So, I’ve gone ahead and applied the rc1 tag and will follow up 
with you in the openstack-relmgr-office for next steps!

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Mitaka Summit Sessions

[Tripp, Travis S]

Hi Searchlighters,

We need to have our summit sessions decided by October 15.

I’ve put up an ether pad capturing some of the initial ideas we had discussed 
previously in IRC.

https://etherpad.openstack.org/p/searchlight-mitaka-summit

Please jump on there and add comments, suggestions, alternate proposals and 
let’s see if we can finalize the sessions in our IRC meeting this week.

Thanks!
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Liberty release finalization

[Tripp, Travis S]

Note: I sent a message to Thierry and Doug for help with the specifics of 
running the release and after Theirry’s response it seemed we should include 
the mailing list.

>Tripp, Travis S wrote:
>>Theirry and Doug,
>>We are down to a single patch that needs one more +2 and then we believe 
>>we’ll be ready to run the first Searchlight RC. We have a core reviewer who 
>>will be done going through it by Monday AM US. Can you please let me know 
>>what will be needed from us to run the release?
>>https://launchpad.net/searchlight/+milestone/liberty-rc1
>>(note, the BP under code review and bug in progress are both solved in the 
>>same patch).
>



On 10/5/15, 1:35 AM, "Thierry Carrez" <thie...@openstack.org> wrote:

>Hi Travis,
>
>Searchlight is currently registered in the governance as following the
>release cycle with intermediary releases (rather than milestones and
>RCs). It is also *not* directly managed by the release team (yet).
>
>That means you have two options. You can stay with the intermediary
>releases model and just push a tag (1.0.0 or 0.1.0 or...) when you're
>ready for release.
>
>You can switch to a milestone-based model and do a RC: in which case you
>should push a 1.0.0.0rc1 tag.
>
>In both cases you should cut a stable/liberty branch from that (we can
>help with that part).
>
>Then in the milestone-based model case you would re-tag the 1.0.0.0rc1
>with a 1.0.0 tag as we get nearer to final release day. In the
>intermediary model you would only reissue a tag if you detect an issue
>which warrants a 1.0.1 (or 0.1.1) point release.
>
>Try first to decide which model you'd like to follow: the one registered
>in the governance (intermediary) or the one with RCs that you seem to
>follow (milestone-based). Those are described in the project team guide:
>
>http://docs.openstack.org/project-team-guide/release-management.html
>
>-- 
>Thierry Carrez (ttx)
>



Hi Thierry,

Thanks for the info! We had discussed the release models a couple times in our 
IRC meeting and we thought that the release cycle with intermediary releases 
sounded good to us.  One reason is that we actually wanted to be able to 
release more frequently if needed support deployers and developers interested 
in moving searchlight into production more quickly. Possibly we would be 
looking to release whenever we improve an integration with an existing project, 
support an integration with a new project, enable a new feature, address major 
bugs, or to address UI integration needs.

As far as the version number, we feel that we have a good basis for the 
functionality and API at this point. We’re wanting to start getting deployer 
feedback and want to be able to make changes needed without getting too hung up 
on major vs minor version changes. So we’ve voted to go with 0.1.0 to allow us 
time to solidify based on that with a goal of going to 1.0 by the end of the 
Mitaka release cycle.

 
However, in reading the page you sent below it says the following about common 
cycle with intermediary releases.

"This is especially suitable to more stable projects which add a limited set of 
new features and don’t plan to go through large architectural changes. Getting 
the latest and greatest out as often as possible, while ensuring stability and 
upgradeability."

This description of the release model sounds a bit dissimilar from our ideas 
above, so is this okay with you that we stay on that release model?


Thanks,
Travis








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Horizon Productivity Suggestion

[Tripp, Travis S]

Things always move more quickly at the end of a cycle because people feel 
release pressure, but I do think this is a good idea. 2 - 3 minutes isn’t very 
realistic. It would need to be planned for longer.





On 9/28/15, 3:57 AM, "Rob Cresswell (rcresswe)"  wrote:

>Hi folks,
>
>I¹m wondering if we could try marking out a small 2-3 minute slot at the
>start of each weekly meeting to highlight Critical/ High bugs that have
>code up for review, as well as important blueprints that have code up for
>review. These would be blueprints for features that were identified as
>high priority at the summit.
>
>The thought here is that we were very efficient in L-RC1 at moving code
>along, which is nice for productivity, but not really great for stability;
>it would be good to do this kind of targeted work earlier in the cycle.
>I¹ve noticed other projects doing this in their meetings, and it seems
>quite effective.
>
>Rob
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] PTL Candidacy

[Tripp, Travis S]

Hello friends,

We are now going into our first official PTL election for Searchlight and I
would be honored if you’ll allow me to continue serving in the PTL role.

Searchlight became a new project in Liberty after being split out from its
initial experimental days in Glance. Since then we’ve been we’ve been moving
at a relatively fast pace towards fulfilling our mission: To provide advanced
and scalable indexing and search across multi-tenant cloud resources.

It would be a huge understatement to say that accomplishing this mission is
important to me. I believe that search is critical to enabling a better
experience for OpenStack users and operators alike.

In Liberty, we have made tremendous progress thanks to a small, but
passionate team who believes in the vision of Searchlight. At the Mitaka
summit we’ll be able to demonstrate a Horizon panel plugin able to search
across Glance, Nova, and Designate.

I believe that the PTL role is a commitment to the community to act as a
steward for the project. As PTL for an early stage project like searchlight,
I believe that some of these responsibilities are to:

* Evangelize the project across the OpenStack ecosystem
* Provide technical guidance and contribution
* Facilitate collaboration across the community
* Enable all developers to contribute effectively
* Grow a community of potential future project PTLs
* And perhaps most importantly, enable the project to release

I believe software must be developed with a clear demonstration of its
value. With Searchlight, I do believe that a UI is one of the most effective
ways to bring the value of Searchlight to OpenStack users. This is why
from day 1, I have been actively evangelizing Searchlight with Horizon. Once
users are able to actually take advantage of Searchlight, I believe
Searchlight will become a must have component of any OpenStack deployment.

From a feature standpoint, I believe all of the following are great
candidate goals for us to pursue in Mitaka and I look forward to working
with the community as establish priorities.

* (Obviously) Extend search indexing to as many projects as possible
** With a priority on the original integrated release projects
* Provide reference deployment architectures and deployment tooling as needed
* Establish performance testing
* Work towards cross-region search support
* Enable pre-defined quick queries for the most common searches
* Release the horizon search panel either in Horizon master or on its own
* Enable horizon top nav search to become a reality [0]

Thank you for your consideration in allowing me to continue serving as PTL
for the Mitaka cycle.

Thank you,
Travis

[0] https://invis.io/6Z3T72NXW
[1] https://review.openstack.org/#/c/223805/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Patterns for Angular Panels

[Tripp, Travis S]

"A pattern, apart from the term's use to mean Template is a discernible 
regularity in the world or in a manmade design. As such, the elements of a   
pattern repeat in a predictable manner." -https://en.wikipedia.org/wiki/Pattern


Hello horizon-eers,

We have made some progress towards angular development in horizon, but much of 
it is still invisible. During Kilo, enough effort was put forth on angular work 
to help us recognize the deficiencies of the existing horizon angular code 
structure, style, localization, and even directory layout. 

A lot of effort went into Liberty to improve all of those areas, which has now 
enabled a much more serious discussion on producing angular based panels for 
horizon. And we actually have quite a few panels pretty far along in the patch 
process, but pretty much stuck in a holding pattern. Why? Primarily because 
there isn’t agreement on the coding pattern to be used for the panels.

Everybody seems to agree that we want a good enough pattern to base all the 
panels on. And most people would like a pattern that provides enough reusable 
widgets / services / etc that replicating the pattern requires a minimal amount 
of code with a maximum amount of flexibility.

However, one problem is that no single panel on its own constitutes a pattern. 
And within any line of patches for a particular panel, the attempts to extract 
out reusable pieces into separate patches often get blocked because they are 
only used in a single panel. This creates an impasse where the ability to 
effectively work on panels stagnates.

So, right now, the most recognizable pattern for angular panels is release 
after release of horizon having zero angular panels implemented.

That is a pattern that I believe must be broken.

So what can we do about it? Here are a few options:

1) Formalize a status of "experimental" and allow a limited number of disabled 
panels to merge with refactoring allowed
2) Immediately create a relatively short lived "Angular Panel" feature branch 
for some cross panel work.
3) Establish a new angular repo with additional cores for angular based 
features with a separate release mechanism


One argument says that merging in code that is initially disabled (panel 
disabled, workflow disabled) at least provides some real examples to draw from 
and actually can better enable external plugin developers, such as the app 
catalog work being done. It also can help to identify bugs and usability 
problems that may not otherwise be discovered (such as hard coded static urls 
and webroots) because deployers will have access to the feature. If a 
particular deployer wants to use it, they can enable it, potentially at their 
own risk. If another deployer does not want to use it until the feature has 
more time to bake, they do not have to use it and don’t have to block other 
deployers that do want to use it.

A counter argument is that allowing the merge of disabled code allows 
undesirable patterns to replicate quickly, causing way too much time to be 
wasted with having to refactor everything.

The idea of a feature branch has been brought up before, but I think it was not 
accepted for a number of reasons. A few being that the scope and goal of such a 
feature branch was not clear (too narrow or too broad) and with a lack of 
belief that there would be a reasonable timeline for acceptance back to master. 

We could also just create a separate repo for the angular based work 
(framework, dashboards, panels) and perhaps provide that as its own xstatic 
package (synced up to the main horizon release). A deployer desiring the 
angular work would deploy that package along with the base horizon release and 
still be able to selectively enable / disable the angular features they want. 
The argument against this is that it is more complicated to manage and even 
more likely that we could break things.


In my opinion the most effective route forward is something like this:

 1) Immediately create a feature branch for Angular Panel Pattern Establishment
 2) Allow 3 - 5 panels and their patches to be eagerly merged
 3) Use the panels to establish cross panel patterns and to find ways to 
simplify code re-use
 4) Extract out patches to be proposed to master as we see fit
 5) Set a goal of Mitaka M1 for at least a few panels to be merged back to 
master

While on the feature branch, the goal is to promote co-existence and pattern 
development allowing for easier collaboration between developers. This means 
allowing incomplete features on the branch. When merged back to master, the 
reviews would enforce the more stringent standards for merge guidelines, but 
could still allow for panels to be merged and still initially be disabled if 
desired.

I believe that this would create a pattern of visible progress.

Remember, perfection is the enemy of... http://pasteboard.co/zq44Y8f.png

-Travis
__
OpenStack Development 

Re: [openstack-dev] [Horizon] Update on Angular Identity work

[Tripp, Travis S]

I definitely think the two panel tables in tree now (images and users) should 
be reduced down in the number of html partials.  On initial glance, it seemed 
pretty easy to just look at the files and know where things are.  However, in 
practice, it makes it error prone and harder to see everything when the header 
file is separated from the row file. I will put up a patch that at least 
collapses the HTML fragments down on images, so that can be seen.

I also think that more sections of the html should be reduced to additional 
fine grained directives, such as the table footer directive Cindy has nearly 
ready. And these finer grained sections could be combined into a template used 
by a *basic* full table directive as mentioned below in option 1.

Option 1’s primary strength actually is that it is more rigid and more contract 
like. The data and the html are mostly separated, meaning you change the data 
inputs and can centrally control the template. I think for very simple tables, 
option 1 is probably better. However, that also becomes a firewall of sorts for 
customizability and ease of making changes.

When it comes to composability, reusability, extensibility, customizability, 
and readability I don’t think option 1 handles all those aspects better.  To 
achieve simple results, I think it actually can later lead to a lot of 
complexity in JS that could be solved directly by modifying html.

When I looked at the option 1 below, and thought about how we have different 
representations of data that should go in table cells that would need to be 
handled. I also did not see any mention of how the collapse / expand details 
drawer would be handled and I actually have a lot of concerns on how that would 
really work or be simple to use or achieve, because the collapse expand details 
may differ quite a bit on what we want to display.

We’ve already used the table drawer in a number of ways based on the data we 
want to show (horizontal property listings, vertical property listings, qutoa 
charts, nested tables, metadata display widgets) and it was easy to do for each 
case because we had direct control of the HTML and could directly pass the data 
needed for the various widgets to them. So, with option 1, we’d have to figure 
out how to make that really easy to do.

Below is something I just sketched out in the last few minutes to maybe help 
explain it.  I’ve also put in a reference to a number of the existing details 
drawers following that:

ctrl.columns = [
{
name : '1’,

“displayName: gettext('column 1’),

“headerClasses: extraClassesHere to add”,

rowClasses: extraClassesHere to add,

permissions: blah, blah

data: What goes here? How should this be formatted? Is it HTML? Is 
it a list?”,

dataType: I guess we need a field to specify the format of the data”,

template: Or maybe this column needs it own custom formatting, so we 
have to pass in the template here.”,

responsivePriority: “5”,

responsiveHandling: Need some strategy for what to do when columns 
appear / disappear. - Do they go in the collapsible table drawer? Where should 
they be placed? What format should they be placed in? How should it interact 
with what else is in the detail drawer?,


},

{etc : etc}
]

details-drawer: How is the detail drawer handled? This can be everything 
from quota charts, to metadata display widgets, to raw properties, to an inner 
table (security group detail drawer is actually in inner table of the security 
group rules). How do we have control over what is in here and what the data 
looks like in here? And should all the data be preloaded or fetched upon 
expansion?,

div ng-controller=table.controller.js as ctrl
horizon-table
   columns =ctrl.columns
   batch-actions=ctrl.batchActionList
   row-actions=“ctrl.rowActionList”
   details=“Ummm, how do I pass through all the various detail formats?
/horizon-table
/div

A few detail table drawer examples:

Flavors: Quota charts and Metadata Display

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/flavor/select-flavor-table.html#L101-L120

Security Groups: Nested security groups

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/security-groups/security-group-details.html

Keypairs: Raw output

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/keypair/keypair-details.html

NG Images: Responsive columns mixed with additional data

https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/images/table/images-table-row-details.html



From: Thai Q Tran
Reply-To: OpenStack List
Date: Friday, August 21, 2015 at 1:38 PM
To: OpenStack List
Subject: Re: [openstack-dev] [Horizon] Update on 

[openstack-dev] [searchlight] Liberty release planning video conference

[Tripp, Travis S]

At our last weekly IRC meeting we decided that we should have a short video 
conference meetup to talk about the Liberty 3 release. The purpose will be to 
walk through the Liberty Blueprints / Bugs and finalize the list for Liberty 3. 
I promised to create a doodle poll for choosing the time, so here it is:

http://doodle.com/99kzigdbmed57g7s

Please note, one time I set is the same time as the normal IRC meeting.  If 
that is what works best for everybody, we’ll start the IRC meeting normally, 
but share a video link in the meeting room for people to join.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Liberty release planning video conference

[Tripp, Travis S]

Hello Anita,

Thank you for the email and for checking into the Postman open ness! There 
might be some mis-comunication here. Postman is not an official part of the 
project and never will be. Neither will any non-open source code base. As 
mentioned in the IRC logs, I personally like to perform additional manual tests 
of APIs when doing code reviews. I use both curl and also sometimes find the 
Postman browser plugin to be helpful, so was sharing that with others who might 
use it. If you do already have an open source browser plugin that has similar 
functionality I would very much like to take advantage of it for my personal 
testing, because you are certainly right that we don’t want to seem as thought 
we are endorsing non-open tool sets!

Thank you!
Travis



On 8/10/15, 5:34 PM, Anita Kuno ante...@anteaya.info wrote:

On 08/10/2015 06:28 PM, Tripp, Travis S wrote:
 At our last weekly IRC meeting we decided that we should have a short video 
 conference meetup to talk about the Liberty 3 release. The purpose will be 
 to walk through the Liberty Blueprints / Bugs and finalize the list for 
 Liberty 3. I promised to create a doodle poll for choosing the time, so here 
 it is:
 
 http://doodle.com/99kzigdbmed57g7s
 
 Please note, one time I set is the same time as the normal IRC meeting.  If 
 that is what works best for everybody, we’ll start the IRC meeting normally, 
 but share a video link in the meeting room for people to join.
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

Hello:

Part of being an OpenStack project listed in the governance repo, as you
are [0], is agreeing to conduct your business in an open manner. Had you
not done so prior to now I would not have known that you are using
Postman for testing [1], as you linked in your meeting log [2]. If
Postman is open source licensed I couldn't find it in their
documentation [3].

Now I'm certainly not going to waste my time telling you how you should
operate your project. I am simply going to take the time to tell you
that currently your tool choices aren't in keeping with the 4 opens [4].
If this is by design, power to you, and please don't let me hold you back.

If this is by accident and you really do want to ensure you stay an
OpenStack project, do reach out to a member of the technical committee
as I feel you could benefit from some tool choice and workflow guidance.

Thank you,
Anita.


[0]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2011
[1] https://www.getpostman.com/collections/8c0b1e05875c7c58e967
[2]
http://eavesdrop.openstack.org/meetings/openstack_search/2015/openstack_search.2015-08-06-15.01.log.html
[3] https://www.getpostman.com/docs
[4]
http://git.openstack.org/cgit/openstack/governance/tree/reference/new-projects-requirements.rst#n17

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Liberty Mid Cycle Meetup

[Tripp, Travis S]

Hello everybody,

Just a reminder about the mid-cycle next week.  If you haven’t already, please 
add your name to the list[0] of people coming so we have a final head count on 
ordering morning / afternoon snacks. If your name is on the list and you aren’t 
coming, please remove it or indicate that you’d try to attend remotely. We’ll 
try to have webex or something via a laptop, which hopefully will be better 
than nothing.

The mid-cycle is intended to be a lot of pairing up sessions on priorities 
established at the summit [2]. However, if you have specific topics to discuss, 
just add them somewhere on the agenda list[0] so they are tracked and we can 
cover them. The times for sessions on the agenda likely won’t be followed too 
closely as small group break outs happen.

For Tuesday evening, if anybody is interested we might do a short hike in the 
nearby foothills before dinner. If so, bring some comfortable walking shoes.

And a reminder that location info is at link [2] below.


[0] Agenda / Attendance List: 
https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=1788841692

[1] Liberty Priorities:
https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities

[2] Info on location is here:
https://etherpad.openstack.org/p/horizon-liberty-midcycle


Thanks,
Travis




On 6/19/15, 10:14 AM, Tripp, Travis S travis.tr...@hp.com wrote:

Hi everybody,

I got confirmation for hosting the mid cycle meetup at the HP Office in Fort 
Collins on July 21st - 23rd.  I’ve put details on the location with a couple 
nearby hotels on the following ether pad.  The room we have reserved can hold 
about 40 people, but I’ve requested for it to be setup so that we can have a 
couple different work areas in the room. There will be a u-shape configuration 
at the front of the room for 20 and another u-shape at the back of the room 
for 10 to be used for breakout discussions.

https://etherpad.openstack.org/p/horizon-liberty-midcycle

A question I have is whether we’ll want to have lunch catered or if we’ll want 
to let everybody out for an hour to get lunch from one of the nearby 
restaurants.  There is a cafeteria on site as well.  If we decide to have it 
catered, I’ll have to know of any special dietary requests.

Thanks,
Travis

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard

[Tripp, Travis S]

In my opinion there is only one major actual bug left on Launch Instance.  That 
is the webroot bug [0] and this actually affects all of the angular work, not 
just Launch Instance.  There was a working fix for it ready earlier this week, 
but then additional considerations for the approach on it were brought up.  
This fix is definitely Liberty specific and we need a version of it prepared 
specifically for Kilo as it has affected some community members wanting to use 
angular APIs in Kilo.  You can see them at the URL listed below [1]. Some 
stalled out due to lack of reviews, so clearly not considered very major.  Once 
that is fixed, I believe we need to make the angular based launch instance 
enabled by default so that we have more opportunity to find any more bugs 
before the end of Liberty.

All of that said, the highest priority effort going on is that we learned that 
the way the angular code was structured in horizon was not conducive for 
sustainable development or for plug-ins. So there has been a lot of effort to 
create a structure more friendly to angular development here in Liberty.  That 
effort is starting to wind down and hopefully will be wrapped up within a few 
weeks. There is a horizon mid cycle in a week and half where this will all be 
discussed / worked on [2].  If you are able to join, you should add your name 
to the list and join us!

[0] https://bugs.launchpad.net/horizon/+bug/1451681
[1] 
https://bugs.launchpad.net/horizon?field.searchtext=%5BLaunch+Instance+Fix%5Dsearch=Searchfield.status%3Alist=NEWfield.status%3Alist=INCOMPLETE_WITH_RESPONSEfield.status%3Alist=INCOMPLETE_WITHOUT_RESPONSEfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDfield.status%3Alist=INPROGRESSfield.status%3Alist=FIXCOMMITTEDfield.assignee=field.bug_reporter=field.omit_dupes=onfield.has_patch=field.has_no_package=
[2] 
https://openstack.nimeyo.com/49599/openstack-dev-horizon-liberty-mid-cycle-meetup


From: Rajat Vig
Reply-To: OpenStack List
Date: Thursday, July 9, 2015 at 9:51 AM
To: OpenStack List
Subject: Re: [openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard

What bugs exist on the Launch Instance based off Angular?
I'd like to help fix some.

-Rajat

On Tue, Jul 7, 2015 at 8:29 AM, Rob Cresswell (rcresswe) 
rcres...@cisco.commailto:rcres...@cisco.com wrote:
The current issue is that we can’t force Angular when we have so little code 
ourselves. The framework is fairly solid now, but there is little in the way of 
code examples; launch instance, which last I checked has a few major bugs, the 
unfinished (?) identity dashboard and a few metadata modals IIRC.

I strongly advise people to write new code with AngularJS, but I don’t support 
enforcing it as a hard requirement for Horizon/ Horizon plugins… yet :)

Rob


From: niuzhenguo niuzhen...@huawei.commailto:niuzhen...@huawei.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 7 July 2015 08:16
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard

Hi folks,

As Horizon is moving towards an Angular application, I think it’s high time 
that we should make a standard for other projects which want to horizon 
compatible on  whether they should based on Angular Dashboard or the current 
Horizon framework. For new project, I think it makes more sense to build the 
dashboard on Angular. But for “old” project like Mistral-Dashboard and 
Tuskar-UI, they works fine with Django framework now, do they have to move 
towards Angular also, and when that should be done.

-zhenguo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] Liberty Mid Cycle Meetup

[Tripp, Travis S]

Hi everybody,

I got confirmation for hosting the mid cycle meetup at the HP Office in Fort 
Collins on July 21st - 23rd.  I’ve put details on the location with a couple 
nearby hotels on the following ether pad.  The room we have reserved can hold 
about 40 people, but I’ve requested for it to be setup so that we can have a 
couple different work areas in the room. There will be a u-shape configuration 
at the front of the room for 20 and another u-shape at the back of the room for 
10 to be used for breakout discussions.

https://etherpad.openstack.org/p/horizon-liberty-midcycle

A question I have is whether we’ll want to have lunch catered or if we’ll want 
to let everybody out for an hour to get lunch from one of the nearby 
restaurants.  There is a cafeteria on site as well.  If we decide to have it 
catered, I’ll have to know of any special dietary requests.

Thanks,
Travis

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

[Tripp, Travis S]

I’m copying and pasting from the other thread some info below.

I think agreeing on rules is the bigger problem here and I don’t think all
the projects should have to agree on rules. We’ve spent a good portion of
liberty 1 getting the code base cleaned up to meet the already adopted
horizon rules and it is still in progress.

My preference would be to see if we can use eslint to accomplish all of
our currently adopted horizon rules [3][4] AND to also add in the angular
specific plugin [1][2]. But we can’t do this at the expense of the entire
liberty release.

― My previously email below:

We¹ve adopted the John Papa style guide for Angular in horizon [0]. On
cursory inspection ES lint seems to have an angular specific plugin [1]
that could be very useful to us, but we¹d need to evaluate it in depth. It
looks like there was some discussion on the style guide on this not too
long ago [2]. The jscs rules we have [3] are very generic code formatting
type rules that are helpful, but don't really provide any angular specific
help. Here are the jshint rules [4]. It would be quite nice to put all
this goodness across tools into a single tool configuration if possible.

[0] 
http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty
le-guide
[1] https://www.npmjs.com/package/eslint-plugin-angular
[2] https://github.com/johnpapa/angular-styleguide/issues/194
[3] https://github.com/openstack/horizon/blob/master/.jscsrc
[4] https://github.com/openstack/horizon/blob/master/.jshintrc


From:  Rob Cresswell   (rcresswe) rcres...@cisco.com
Reply-To:  OpenStack List openstack-dev@lists.openstack.org
Date:  Tuesday, June 16, 2015 at 1:40 AM
To:  OpenStack List openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack]
Javascript Linting


So my view here is that I don’t particularly mind which plugin/ set of
plugins Horizon uses, but the biggest deterrent is the workload. We’re
already cleaning everything up quite productively, so I’m reluctant to
swap. That said, the cleanup from JSCS/
 JSHint should be largely relevant to ESLint. Michael, do you have any
ideas on the numbers/ workload behind a possible swap?

With regards to licensing, does this mean we must stop using JSHint, or
that we’re still okay to use it as a dev tool? Seems that if the former is
the case, then the decision is made for us.

Rob



From: Michael Krotscheck krotsch...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Tuesday, 16 June 2015 00:36
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack]
Javascript Linting


I'm restarting this thread with a different subject line to get a broader
audience. Here's the original thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html


The question at hand is What will be OpenStack's javascript equivalent of
flake8. I'm going to consider the need for common formatting rules to be
self-evident. Here's the lay of the land so far:

* Horizon currently uses JSCS.
* Refstack uses Eslint.
* Merlin doesn't use anything.
* StoryBoard (deprecated) uses eslint.
* Nobody agrees on rules.


JSCS

JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style
guide, yet it does not check for potential bugs, variable overrides, etc.
For those tests, the team usually defers to (preferred) JSHint, or ESLint.

JSHint
Ever since JSCS was extracted from JSHint, it has actively removed rules
that enforce code style, and focused on findbug style tests instead.
JSHint still contains the Do no evil license, therefore is not an option
for OpenStack, and has been disqualified.

ESLint
ESLint's original mission was to be an OSI compliant replacement for
JSHint, before the JSCS split. It wants to be a one-tool solution.

My personal opinion/recommendation: Based on the above, I recommend we use
ESLint. My reasoning: It's one tool, it's extensible, it does both
codestyle things and bug finding things, and it has a good license. JSHint
is disqualified because of the license.
 JSCS is disqualified because it is too focused, and only partially useful
on its own.

I understand that this will mean some work by the Horizon team to bring
their code in line with a new parser, however I personally consider this
to be a good thing. If the code is good to begin with, it shouldn't be
that difficult.

This thread is not there to argue about which rules to enforce. Right now
I just want to nail down a tool, so that we can (afterwards) have a
discussion about which rules to activate.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [javascript] Linters

[Tripp, Travis S]

Michael,

Maybe you should start this thread again with a link to the full thread but add 
all the projects into subject (e.g. [horizon]).  Otherwise quite a few people 
may not see it.

You are right that the John Papa guidelines are definitely targeted at angular 
and not general style.  They are community driven (and endorsed by the angular 
team).  We discussed it quite a bit at the summit and we agreed that we wanted 
to spend less time arguing personal preferences for formatting in patches and 
his guidelines helped to do that for angular style.

Thanks,
Travis

From: Michael Krotscheck krotsch...@gmail.commailto:krotsch...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, June 10, 2015 at 9:29 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [javascript] Linters



On Tue, Jun 9, 2015 at 3:37 PM Robert Collins 
robe...@robertcollins.netmailto:robe...@robertcollins.net wrote:
On 10 June 2015 at 04:01, Michael Krotscheck 
krotsch...@gmail.commailto:krotsch...@gmail.com wrote:
 Well, it looks like everyone has disqualified jslint and jshint, so let's
 just make a decision there and remove them from the running. Unless I hear a
 compelling reason to use something that has the infamous do no evil
 license in it, let's dump it.
...
 As for how this is synchronized, a brief discussion in the infra channel
 proposed that we put global javascript requirements in the
 global-requirements repo, and then update the update.py script in that repo
 to also handle bower.json and package.json. Then, if we build an eslint/jscs
 plugin similar to our hacking rules, we can just update that when we want to
 modify the linting rules. Any objections?

Yes, I think this should live in openstack/requirements.

bower.json is clearly js specific; package.json isn't AFAICT - can you
give me some sane pointers to go level up on that?

There are two package managers in the JavaScript world right now, one that 
focuses on node.js/server dependencies (karma, lint, express, etc), and one 
that focuses on in-browser dependencies (angular, bootstrap, etc). They're both 
required for thick browser clients, but for server apps you only really need 
package.json

https://docs.npmjs.com/files/package.json
https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json
https://github.com/angular-ui/bootstrap/blob/master/package.json
https://github.com/openstack/horizon/blob/master/package.json

In the absence of information I'm assuming we should make a subdir
'js' and put bower.json and package.json in there (and do the same for
the python things in a subdir called python for symmetry, though
backwards compat and tooling considerations may mean that we have to
prepare for that. The reason being that if package.json is js
specific, its just confusing to have it live at the top level. Also we
may want to call them global-$thing, since if we do have js in the
requirements repo itself at some point, it would be good not to
conflict on names.

FYI, it looks like the monasca team may want to start doing similar things with 
Java. More information after I hunt them down this morning :)

I'm not at all sure that update.py should handle the json files per
se; will the policy for those files be the same as we use for python?

Add linting rule sets to this list, contained either in .jscsrc or .eslintrc. 
Javascript does not have the privilege of pep8 being baked into the language 
tooling, so we have to sync it ourselves.

If not it might be cleaner to have a new entry point. OTOH I'll need
to look closely at a few real {bower,package}.json files to proffer an
useful opinion. [Perhaps you covered this in IRC - it didn't come
through in your summary].

It depends on what you think update.py is supposed to do. If I look at that 
repository, I would argue that the purpose is to Synchronize common files and 
properties across registered openstack projects. In this case, a requirement 
is defined as something required to meet a minimum set of project sanity 
standards.

Also, I'm in the middle of rearranging update.py to handle PEP 426 and so we 
should probably coordinate so we don't tromp on each other.

Do you have a patch?

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TC] [All] [searchlight] Proposal for Project Searchlight

[Tripp, Travis S]

Thank you TC and fellow stackers for voting Project Searchlight into the
Big Tent today and for the words of encouragement in the TC meeting!

We are really excited to move forward on this journey with you!

-Travis


On 6/3/15, 8:15 AM, Tripp, Travis S travis.tr...@hp.com wrote:

Hello TC members and fellow stackers!

We have just submitted a review for project Searchlight to the OpenStack
governance projects list [1]. Searchlight is a new project being split out
of Glance based on the Glance Catalog Index Service, which was developed
and released in Kilo [2]. We received community and operator feedback that
this would be very useful for more than just Glance. At the Liberty Summit
it was decided to broaden the scope and make it its own project with a
mission to provide advanced and scalable search across multi-tenant cloud
resources. This was presented and discussed at both Glance and Horizon
fishbowl sessions dedicated to this topic where it was enthusiastically
received.

A narrated screencast of the demo shown at the summit is available at the
project wiki [3].

Thank you,
Travis Tripp
Nikhil Komawar

[1] https://review.openstack.org/188014
[2] 
http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-index
-
service.html
[3] https://wiki.openstack.org/wiki/Searchlight







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [javascript] Linters

[Tripp, Travis S]

We¹ve adopted the John Papa style guide for Angular in horizon [0]. On
cursory inspection ES lint seems to have an angular specific plugin [1]
that could be very useful to us, but we¹d need to evaluate it in depth. It
looks like there was some discussion on the style guide on this not too
long ago [2]. The jscs rules we have [3] are very generic code formatting
type rules that are helpful, but don't really provide any angular specific
help. Here are the jshint rules [4]. It would be quite nice to put all
this goodness across tools into a single tool configuration if possible.

[0] 
http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty
le-guide
[1] https://www.npmjs.com/package/eslint-plugin-angular
[2] https://github.com/johnpapa/angular-styleguide/issues/194
[3] https://github.com/openstack/horizon/blob/master/.jscsrc
[4] https://github.com/openstack/horizon/blob/master/.jshintrc

On 6/8/15, 9:59 PM, gustavo panizzo (gfa) g...@zumbi.com.ar wrote:



On 2015-06-06 03:26, Michael Krotscheck wrote:
 Right now, there are several JS linters in use in OpenStack: JSHint,
 JSCS, and Eslint. I really would like to only use one of them, so that I
 can figure out how to sanely share the configuration between projects.

 Can all those who have a strong opinion please stand up and state their
 opinions?

what about https://bitbucket.org/dcs/jsmin/ it's license is free


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TC] [All] [searchlight] Proposal for Project Searchlight

[Tripp, Travis S]

Hello TC members and fellow stackers!

We have just submitted a review for project Searchlight to the OpenStack
governance projects list [1]. Searchlight is a new project being split out
of Glance based on the Glance Catalog Index Service, which was developed
and released in Kilo [2]. We received community and operator feedback that
this would be very useful for more than just Glance. At the Liberty Summit
it was decided to broaden the scope and make it its own project with a
mission to provide advanced and scalable search across multi-tenant cloud
resources. This was presented and discussed at both Glance and Horizon
fishbowl sessions dedicated to this topic where it was enthusiastically
received.

A narrated screencast of the demo shown at the summit is available at the
project wiki [3].

Thank you,
Travis Tripp
Nikhil Komawar

[1] https://review.openstack.org/188014
[2] 
http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-index-
service.html
[3] https://wiki.openstack.org/wiki/Searchlight







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] dashboard-app split in horizon

[Tripp, Travis S]

Hi all,

I just added my 2 cents to a couple of these patches, but in my opinion all of 
the existing patches in gerrit for angular tests that were written as part of 
the launch instance effort should be finalized and merged prior to any further 
reorganization patches going through.

Creating a nice phased chain of patches is nice for seeing the steps, but as we 
saw earlier this week with a breakage, even with smaller steps the 
reorganization is making a lot of changes that require a lot of verification. I 
would be a lot more comfortable if we could get the outstanding test patches 
into the system.  I would like to see the tests passing at each stage of the 
reorganization to help avoid corner case breakages. Can we make a concerted 
effort to review those and get them in prior to more reorganization?

I realize file globbing, etc will make the listing of patches easier to do, but 
maybe the outstanding test patches should get a chain of dependencies to avoid 
merge conflicts themselves?

Thanks,
Travis

From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 28, 2015 at 12:55 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon] dashboard-app split in horizon

I have now submitted the patch to do the html shenanigans as a new step in the 
current ngReorg pipeline (inserted because it should fix a test failure popping 
up in the dashboard-app move final step).

https://review.openstack.org/#/c/186295/

Ryan's API reorg should probably depend on this patch also as that should fix 
*its* test failures also.

And before anyone says anything, no I'm not particularly thrilled about the new 
horizon/test/templates/base.html but frankly I'm not sure how else to make it 
work. We could probably cull the JS from that file though. I'm pretty sure none 
of the django unit tests exercise JS, and I believe Selenium works off a 
different interface (but I've run out of time today to investigate).


 Richard


On Thu, 28 May 2015 at 02:15 Thai Q Tran 
tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote:
Yes Rob, you are correct. ToastService was something Cindy wrote to replace 
horizon.alert (aka messages). We can't remove it because legacy still uses it.

-Rob Cresswell (rcresswe) rcres...@cisco.commailto:rcres...@cisco.com 
wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
From: Rob Cresswell (rcresswe) rcres...@cisco.commailto:rcres...@cisco.com
Date: 05/26/2015 11:29PM

Subject: Re: [openstack-dev] [Horizon] dashboard-app split in horizon

Went through the files myself and I concur. Most of these files define pieces 
specific to our implementation of the dashboard, so should be moved.

I’m not entirely sure on where _messages should sit. As we move forward, won’t 
that file just end up as a toast element and nothing more? Maybe I’m 
misinterpreting it, I’m not familiar with toastService.

Rob


From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 26 May 2015 01:35
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Johanson, Tyr H t...@hp.commailto:t...@hp.com
Subject: Re: [openstack-dev] [Horizon] dashboard-app split in horizon

As a follow-up to this [in the misguided hope that anyone will actually read 
this conversation with myself ;-)] I've started looking at the base.html split. 
At the summit last week, we agreed to:

1. move base.html over from the framework to the dashboard, and
2. move the _conf.html and _scripts.html over as well, since they configure the 
application (dashboard).

Upon starting the work it occurs to me that all of the other files referenced 
by base.html should also move. So, here's the complete list of base.html 
components and whether they should move over in my opinion:

- horizon/_custom_meta.html
  Yep, is an empty file in horizon, intended as an extension point in 
dashboard. The empty file (plus an added comment) should move.
  - horizon/_stylesheets.html
  Is just a dummy in horizon anyway, should move.
- horizon/_conf.html
  Yep, should move.
- horizon/client_side/_script_loader.html
  Looks to be a framework component not intended for override, so we should 
leave it there.
- horizon/_custom_head_js.html
  Yep, is an empty file in horizon, intended as an extension point in 
dashboard. Move, with a comment added.
- horizon/_header.html
  There is a basic implementation in framework but the real (used) 
implementation is in dashboard, so should move.
- horizon/_messages.html
  This is a 

Re: [openstack-dev] [Horizon]Informal Pre-summit get together

[Tripp, Travis S]

Just to double check, there was some IRC discussion about Monday.  So is
it still Sunday?

On 5/14/15, 3:41 PM, Douglas Fish drf...@us.ibm.com wrote:


The Horizon team will be meeting on Sunday night informally over a beer
and
dinner:
Sunday 6pm @  The Charles Bar http://thecharlesbar.ca/

Hope to see you there!

Doug


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Core Reviewer Update

[Tripp, Travis S]

Thank you for the warm welcome, everyone!

I'm excited to be on the team and am really looking forward to everything
coming in Liberty!

-Travis

On 4/29/15, 6:16 AM, Ana Krivokapić akriv...@redhat.com wrote:



On 04/29/2015 12:57 AM, David Lyle wrote:
 I am pleased to announce the addition of Doug Fish, Rob Cresswell and
 Travis Tripp to the Horizon Core Reviewer team.

 Doug Fish has been an active reviewer and participant in Horizon for a
 few releases now. He represents a strong customer focus and has provided
 high quality reviews.

 Rob Cresswell has been providing a high number of quality reviews, an
 active contributor and an active participant in the community.

 Travis Tripp has been contributing to Horizon for the past couple of
 releases, an active participant in the community, a critical angularJS
 reviewer, and played a significant role in driving the angular based
 launch instance work in Kilo.

 Thank you all for your contributions and welcome to the team!

 David


 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Welcome Doug, Rob and Travis, and thanks for all your contributions so
far!

-- 
Regards,
Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Tripp, Travis S]

Thanks, I’ll have to read! Do you have a quick summary on what role domains are 
intended to play in this?  Has the following statement been decided?


  1.  Domains may be modified to exist as top-level projects, or they may still 
exist solely as containers for users with the project hierarchy remaining 
separate.


From: Geoff Arnold ge...@geoffarnold.commailto:ge...@geoffarnold.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 28, 2015 at 12:10 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and 
Glance?

Use cases:
https://wiki.openstack.org/wiki/HierarchicalMultitenancy

Blueprints:
(Kilo):
https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
https://blueprints.launchpad.net/keystone/+spec/reseller
(Liberty):
https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management
https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api
(Pending):
https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects
https://blueprints.launchpad.net/horizon/+spec/inherited-roles

As for adoption, it’s hard to say. The HMT work in Keystone was a necessary 
starting point, but in order to create a complete solution we really need the 
corresponding changes in Nova (quotas), Glance (resource visibility), Horizon 
(UI scoping), and probably Ceilometer (aggregated queries). We (Cisco) are 
planning to kick off a Stackforge project to knit all of these things together 
into a complete “reseller” federation system. I’m assuming that there will be 
other system-level compositions of the various pieces.

Geoff

On Apr 27, 2015, at 9:48 PM, Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote:

Geoff,

Getting a spec on HMT would be helpful, as Nikhil mentioned.

As a general question, what it the current adoption of domains / vs
hierarchical projects? Is there a wiki or something that highlights what
the desired path forward is with regard to domains?

Thanks,
Travis

On 4/27/15, 7:16 PM, Geoff Arnold 
ge...@geoffarnold.commailto:ge...@geoffarnold.com wrote:

Good points. I¹ll add some details. I¹m sure the Reseller guys will have
some comments.

Geoff

On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
nikhil.koma...@rackspace.commailto:nikhil.koma...@rackspace.com wrote:

Thanks Geoff. Added some notes and questions.

-Nikhil


From: Geoff Arnold ge...@geoffarnold.commailto:ge...@geoffarnold.com
Sent: Monday, April 27, 2015 5:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy
and   Glance?

In preparation for Vancouver, I¹ve been looking for blueprints and
design summit discussions involving the application of the Keystone
hierarchical multitenancy work to other OpenStack projects. One obvious
candidate is Glance, where, for example, we might want domain-local
resource visibility as a default. Despite my searches, I wasn¹t able to
find anything. Did I miss something obvious?

I¹ve added a paragraph to
https://etherpad.openstack.org/p/liberty-glance-summit-topics to make
sure it doesn¹t get overlooked.

Cheers,

Geoff

_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Tripp, Travis S]

Geoff,

Getting a spec on HMT would be helpful, as Nikhil mentioned.

As a general question, what it the current adoption of domains / vs
hierarchical projects? Is there a wiki or something that highlights what
the desired path forward is with regard to domains?

Thanks,
Travis

On 4/27/15, 7:16 PM, Geoff Arnold ge...@geoffarnold.com wrote:

Good points. I¹ll add some details. I¹m sure the Reseller guys will have
some comments.

Geoff

 On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
nikhil.koma...@rackspace.com wrote:
 
 Thanks Geoff. Added some notes and questions.
 
 -Nikhil
 
 
 From: Geoff Arnold ge...@geoffarnold.com
 Sent: Monday, April 27, 2015 5:50 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy
and   Glance?
 
 In preparation for Vancouver, I¹ve been looking for blueprints and
design summit discussions involving the application of the Keystone
hierarchical multitenancy work to other OpenStack projects. One obvious
candidate is Glance, where, for example, we might want domain-local
resource visibility as a default. Despite my searches, I wasn¹t able to
find anything. Did I miss something obvious?
 
 I¹ve added a paragraph to
https://etherpad.openstack.org/p/liberty-glance-summit-topics to make
sure it doesn¹t get overlooked.
 
 Cheers,
 
 Geoff
 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Call to action, revisit CIS state

[Tripp, Travis S]

On 4/27/15, 05:39, Kuvaja, Erno kuv...@hp.com wrote:

The spec bluntly states that
there is no security impact from the implementation
 and the concerns should have been brought up so reviewers would have had
better chance to catch possible threats.

 
I would like you to look back into those two specs and the comments, look
back into the implementation and raise any urgent concerns and please
lets try to have good and healthy base for discussion in the Vancouver
Summit how we will continue
 forward from this!
 



Any thoughts on improving security are always welcome.  As you¹ll find in
the original service spec, in the comments on it, and in the code,
security was one of the number one topics with the CIS service. Getting
input on this was a driving reason to initially target a single OpenStack
service (Glance). Security was also discussed in all three of the summit
discussions leading to the creation of this service (pre-Kilo virtual
summit, Kilo summit, Kilo mini-summit). Without security, this becomes an
admin only service of limited interest and could be done completely
outside of OpenStack as a native, possibly proprietary plugin to Elastic
Search itself. In that scenario, it also would not have any input from the
community and would not provide benefit to the broader community.

https://review.openstack.org/#/c/138051/


On 4/27/15, 10:52 AM, Ian Cordasco ian.corda...@rackspace.com wrote:




There¹s a slight problem with this though. We load the plugins dynamically
https://github.com/openstack/glance/blob/582f8563e866f167ae1de1a2309c1a1e2
4
84442a/glance/common/utils.py#L735 (as anyone really would expect us to)
which means new plugins can be created for any service that is willing to
create one and install it properly. With that done, we /could/ have CIS
become a centralized Elasticsearch API in OpenStack as managed by Glance.

The solution that seems obvious for this is to disallow plugins to declare
their index name (using PluginClass.get_index_name) but I don¹t think that
warrants an RC3 or will necessarily make it into 2015.1.1.


Thank you Ian for your continued thoughtful reviews. As Kamil pointed out,
the index name also is a point of customization for deployers that might
be using their elastic search cluster for multiple indexes.  If they want
to change the index for any reason such as avoiding collisions, this
allows that flexibility.


If CIS is going to become a fully supported (or non-experimental) Glance
API in Liberty, I think we should really make sure that it is a service
that can only create documents for Glance. Since the API is Experimental,
I think it¹s safe to say the API for the Plugins will be considered
experimental and so removing get_index_name from plugin classes will not
break the world.


I have a summit session proposed on discussing the catalog index service
at the summit and I specifically want to cover the scope and logistics of
it moving forward. This includes discussing whether or not it should be
proposed as its own project or if it might make sense for it to move to
its own repo as part of the glance project for technical and logistical
concerns. I¹ve started populating the linked discussion etherpad for that
session proposal with a few thoughts. There appears to be another highly
related session from Stuart, Flavio, and Brian that should be logically
arranged so that the timing / coordination between the two sessions makes
sense.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Angular in Liberty

[Tripp, Travis S]

Hi everyone!

In Kilo we made some very nice progress with adopting AngularJS in
Horizon. The launch instance workflow is available as a beta level feature
that can be optionally enabled now in Kilo [1]. Together with the identity
panel, detail pages, and magic search workstreams we were able to
encounter a well rounded set of challenges. These have helped us to start
establishing a number of base components and concepts.

Of course, there is more work to be done. In Liberty we want to solidify
the components, concepts, and patterns to give us a solid foundation for
mainstream AngularJS development across Horizon. There is plenty of work
to go around and we would like to enable everybody to be able to
contribute.

Based on the many discussions and learnings that we had in the Kilo
angular scrums, I¹ve started the following etherpad to help organize some
thoughts going into Liberty. I hope this also provides some insight for
those that haven¹t been able to attend the virtual scrums during Kilo.
Thanks to all the participants of the angular scrums for the input you
have already had on the ether pad.

https://etherpad.openstack.org/p/horizon-liberty-angular


Finally, I will send out a message to operators, but we are looking for
feedback on launch instance [1][2]. There are already a few improvements
being discussed, but additionally we would appreciate functional testing
in various deployment environments. If you have a fun environment to test
this against, please do!


[1] Launch Instance in Kilo: https://youtu.be/e6MYAUzZZag
[2] https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign

Thank you,
Travis


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Horizon] Insufficient (?) features in current Nova API

[Tripp, Travis S]

This discussion is actually rather timely. In Kilo, we just added a new
experimental API in Glance called the Catalog Index Service [1].
Basically, it provides multi-tenant elastic search based caching and
indexing for various resources using a plugin mechanism.

We proposed it and built it initially to be targeted specifically at
Glance resources for a number of reasons including constraining the scope
and ensuring that we had proper guidance over some RBAC aspects.

Not surprisingly, quite a few people expressed a very strong interest in
this service providing search and indexing for many OpenStack services
including Nova. There is also debate on where it should reside.
Ultimately, the decision was to address this during liberty and to have at
least one session at the Vancouver summit on it in the Glance track. I
also have proposed it as a topic on the Horizon summit planning ether pad
and plan to provide more details shortly (finishing out Kilo was the top
priority).

The current experimental service was built with a resource plugin
architecture so that the actual indexing (with notification listening) and
RBAC handling for different resource types is handled via plugins. In
addition, when deployed it is registered in Keystone as a service of type
³search² with its own endpoint.

The basic idea for Horizon has been that we can check to see if the search
service is enabled for the current user¹s logged in region. If so, we will
add support in the API layers to leverage the search service for resources
indexed by the service when appropriate.
 
We also will be able to take better advantage of advanced search faceting
with near real-time results and autocompletion using an angular UI
component called Magic Search [2] that Eucalyptus open sourced and which
IBM / HP have been working on to enable in Horizon [3]. We want to also
discuss this at the summit in the Horizon track.

We are currently investigating and prototyping out a number of things
related to all of the above and will provide more info and results very
shortly. We¹ll definitely be looking for feedback and help on how to
approach a number of topics!

Thank you,
Travis

[1] 
http://docs-draft.openstack.org/51/138051/9/check/gate-glance-specs-docs/d9
ad1b8//doc/build/html/specs/kilo/catalog-index-service.html

[2] https://www.youtube.com/watch?v=FTjqFddBJBA

[3] https://review.openstack.org/#/c/157481/



On 4/10/15, 11:30 AM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Attila Fazekas's message of 2015-04-10 06:20:02 -0700:
 I think the Nova API (list) needs to be extended by custom attribute
 filtering and with multiple `server` get by uuid (up to 128+).
  
 The basic list usually does not shows what I need.
 nova processing more data than it is really needs just for a basic list.
 
 The detailed list is very slow.
 
 Maybe the attribute filtering or the multi item get(/POST) is not too
RESTish thing,
 but it can be very efficient!
 

Multi-get is a good idea anyway, as it will help with workloads that
need it. However, it won't really be much better than the detail list for
things like Horizon. It will just break the problem up into a less-slow
list, and a less-slow fetch, instead of one slow list.

This is related to the discussion about how OpenStack should talk
to users. It would make a lot more sense for Horizon to poll a high
speed but not 100% consistent Atom feed that is updated by a daemon
listening to notifications, than always asking for the details from the
realtime-accurate API. I believe rackspace has something in place called
'yagi'[1] that does this for them, but I don't know what UI's they have
that use it.

Another option is for the listing API to just cache aggressively on its
backend, with users being given the option to add a request option that
means go slow and get me up to date information. However, one must be
careful to avoid thundering herds and other problems that backend caches
tend to mask until the worst moment. For instance, if the cache starts
getting invalidated faster than users are querying it because there are
too many users asking for the slow version, then you are suddenly back
in the sinking boat without a bucket to bail water anymore.

[1] https://github.com/rackerlabs/yagi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Tripp, Travis S]

I can do either.  Small preference for 1500.

On 3/12/15, 9:45 AM, Okuma, Wayne wayne.ok...@hp.com wrote:

My vote is for 1500.

-Original Message-
From: Hemanth Makkapati [mailto:hemanth.makkap...@rackspace.com]
Sent: Thursday, March 12, 2015 8:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
time.

+1 to consistent time.
Both 1400 and 1500 work me.

-Hemanth

From: Ian Cordasco ian.corda...@rackspace.com
Sent: Wednesday, March 11, 2015 10:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
time.

I have no opinions on the matter. Either 1400 or 1500 work for me. I
think there are a lot of people asking for it to be at 1500 instead
though.
Would anyone object to changing it to 1500 instead (as long as it is one
consistent time for the meeting)?

On 3/11/15, 01:53, Inessa Vasilevskaya ivasilevsk...@mirantis.com
wrote:

+1


On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov
ativel...@mirantis.com wrote:

Works for me, but the previous one worked as well. So, consider my vote
as +1 unless the majority is against this :)


--
Regards,
Alexander Tivelkov




On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang
feil...@catalyst.net.nz wrote:

Oh, it means 3:00AM for me :-(


On 09/03/15 09:07, Nikhil Komawar wrote:






Hi all,


Currently, we've alternating time for Glance meetings. Now, with the
Daylight savings being implemented in some parts of the world, we're
thinking of moving the meeting time to just one slot i.e. earlier in
the day(night). This solves the original conflicting  times issue that
a subset of the individuals had; to add to that the schedule is less
confusing and unified.



So, the new proposal is:
Glance meetings [1] to be conducted
weekly on
Thursdays at 1400UTC [2] on
#openstack-meeting-4



This would be implemented on Mar 19th, given there are no major
objections.


Please vote with +1/-1 here.



[1]
https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
[2]
http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=
0 
http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec
=0


Thanks,
-Nikhil






___
___ OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists
.
openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Cheers  Best regards,
Fei Long Wang (王飞龙)
---
---
Senior Cloud Software Engineer
Tel: +64-48032246 tel:%2B64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
---
---


___
___ OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev









___
___ OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Rethinking the launch-instance wizard model

[Tripp, Travis S]

Richard,

I have been thinking for some time that each step controller should be able to 
define the data it needs as well as manipulating it.  Perhaps in the morning 
before you get up in Australia I could take a pass at converting that for 
access  security.  I’ll talk it over with Sean, since there are some cross 
step dependencies it may complicate things a little and better understand his 
initialization states.

Travis

From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, March 9, 2015 at 10:59 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Horizon] Rethinking the launch-instance wizard model

Hi folks,

Currently the launch instance model file does all the fetching of various bits 
of data. Combined with all of the controllers also being loaded at wizard 
startup, this results in some very difficult synchronisation issues*.

An issue I've run into is the initialisation of the controller based on model 
data. Specifically, loading the allocated and available lists into the 
security groups transfer table. I can load a reference to the model 
securityGroups array as the available set, but since that data is generally 
not loaded (by some other code) when the controller is setting up, I can't also 
select the first group in the array as the default group in allocated.

So, I propose that the model data for a particular pane be loaded *by that 
pane*, so that pane can then attach a callback to run once the data is loaded, 
to handle situations like this (which will be common, IIUC). Or the model needs 
to provide promises for the pane controllers to attach callbacks to.


  Richard

* one issue is the problem of the controllers running for the life of the 
wizard and not knowing when they're active (having them only be temporarily 
active would solve the issue of having to watch the transfer tables for changes 
of data - we could just read the allocated lists when the controller exits).

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Kilo angular virtual sprint

[Tripp, Travis S]

Hi everyone,

The virtual sprint[1] has been going really well. Last Thursday in the virtual 
sprint we got 3 patches reviewed and merged! (156810, 157128, 160093)  We also 
had good discussion on the transfer tables and and spinner. With the transfer 
tables, we decided to make them a parent dependency of launch instance so that 
we could ensure that the updates worked for the steps.  There also has been 
discussion on how to best style the data in the columns (translations, etc), 
but I’m not sure we had a final outcome other than making the steps depend on 
table changes from Richard / Kelly.  With the spinner, Tyr demo’d the look and 
feel after which David and the other folks on the call felt that it makes sense.

Can we do another 22:00 UTC meeting Tuesday (US March 10)?  This would be 2 – 
4:00 PM PDT. This seems to be the time that accommodates the most active 
developers on the features.

I’d like an opportunity for discussion on launch instance steps to happen if 
needed.  Primarily, there has been concern on table data integration and 
styling.

I went through the ether pad and propose the following patches for review and 
discussion in the next session.  Thai, if there are any other dependency 
patches you need to discuss for user tables, please let us know.

  *   Transfer tables update (warning icons, drag and drop enabled) - 
https://review.openstack.org/#/c/159541/ - Kelly Domino
 *   Discussion on how to style / translate data
  *   Metadata display widget - https://review.openstack.org/#/c/151745/ (note 
has dependency on https://review.openstack.org/#/c/136437 )(Szymon)
  *   Magic Search angular widget - under dev by Eucalyptus, XStatic under 
review, creating demo on Users, then on to Instances (Randy, Nikunj)
  *   Password match validation (tqtran) 
https://review.openstack.org/#/c/161344/
  *   Wait spinner on wizard-based launch instance submit: 
https://review.openstack.org/#/c/158819/ - Tyr Johanson
 *   Lower priority, but just discussed on Thursday, so wrap up.

In addition, I have been working on ways to break the model patch out into 
different injectable service dependencies that I would like to get some input.

[1] https://etherpad.openstack.org/p/horizon-kilo-virtual-sprint

Thanks,
Travis

For reference:

From: David Lyle dkly...@gmail.commailto:dkly...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 16, 2015 at 11:19 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [horizon]

A couple of high priority items for Horizon's Kilo release could use some 
targeted attention to drive progress forward. These items are related to 
angularJS based UX improvements, especially Launch Instance and the conversion 
of the Identity Views.

These efforts are suffering from a few issues, education, consensus on 
direction, working through blockers and drawn out dev and review cycles. In 
order to help insure these high priority issues have the best possible chance 
to land in Kilo, I have proposed a virtual sprint to happen this week. I 
created an etherpad [1] with proposed dates and times. Anyone who is interested 
is welcome to participate, please register your intent in the etherpad and 
availability.

David



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The constraints from flavor and image metadata

[Tripp, Travis S]

JYH,

Are you asking for this to be a blanket rule?  It seems to me that this
could be a case by case basis, but I question making it a blanket rule.

For example, the os_shutdown_timeout property [1] seems very workload
specific. In your proposal, this would mean that the operator would have
to add that property with a max value to every single flavor in order for
it to be taken advantage of, right? Is that really the desired behavior?

Or what about the watchdog behavior (hw_watchdog_action)?  It supports an
enum of possibilities:

disabled,reset,poweroff,
   pause,none²

If the flavor provides a default value what would it even mean for an
image to specify something different?

[1](https://review.openstack.org/#/c/89650/12)


George,

Regarding constraints, you should take a look at this:
http://docs.openstack.org/developer/glance/metadefs-concepts.html

Almost all of the available nova properties with constraint enforcement
can be viewed by getting a current devstack, going into horizon, and
launching the Update Metadata action on flavors / Host Aggregates, or
Images.

-Travis


On 1/17/15, 7:41 AM, George Shuklin george.shuk...@gmail.com wrote:

When I played with metadata, I had have constant feeling it had mess
together few things:

1. H/W requirements for images.
2. Accounting requirements (good CPU for good price, HDD for cheap)
3. Licensing restrictions (run this one only on the hosts with licenses)
4. Administrative management (like 'flavors of tenant X should be run
only on hosts Y')
5. OS information (like inherited metadata on images)

All that together is called 'metadata'. Some metadata have special
meaning in one context (like 'availability_zone' for hosts, or CPU
limitation), some is used by administrator in other context.

All together it looks like pre-datastructure code (if someone remembers
that). No data types, no type restrictions, you can assign letter to
instruction address and pointer to string to float.

Same with current metadata in nova/glance. Raw namespace of key-value
items without any meaningful restriction and specific expression. It
gives flexibility, but cause a huge strain on operators.

I think it needs more expressive representation.

On 01/13/2015 11:39 PM, Jiang, Yunhong wrote:
 Hi,
  There are some discussion and disagreement on the requirement from
flavor and image metadata at nova spec
https://review.openstack.org/#/c/138937/ and I want to get more input
from the community.
  When launch a VM, some requirements may come from image metadata and
flavor. There are a lot of such cases like serial_port_count,
memory_pagesize, hw_numa_nodes, hw:cpu_max_sockets etc. Most of them are
done in nova/virt/hardware.py.

  Both the nova-spec and the current implementation seems agree that if
flavor has the requirement, the image's metadata should not require more
than the flavor requirement.

  However, the disagreement comes when no requirement from flavor, i.e.
only image has the resource requirement. For example, for
serial_port_count, If flavor extra specs is not set, then any image
meta value is permitted. For hw_mem_page_size, it's forbidden if only
image request and no flavor request
(https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L873
 ), and hw_numa_nodes will fail if both flavor and image metadata are
specified 
(https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L852
 ).

  As to this nova spec at https://review.openstack.org/#/c/138937/ ,
someone (Don, Malini) think if image requires some feature/resource that
is not specified in flavor, it should be ok, while I think it should be
forbidden.

  I discussed with Jay Pipe on IRC before and he thought if flavor has
no requirement, image requirement should be failed, and I created a bug
at https://bugs.launchpad.net/nova/+bug/1403276 at that time.  But
according to the discussion on this BP, seems this is not always
accepted by others.

  I hope to get feedback from the mailing list on the relationship of
requirement from image/flavor. Possibly we should take different policy
for different resource requirement, but some general rule and the reason
for those rules will be helpful.

  BTW, This topic was sent to the operator ML yesterday by Malini at
   This 
http://lists.openstack.org/pipermail/openstack-operators/2015-January/005
882.html and I raise it here to cover both lists.

 Thanks
 --jyh

 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [horizon] static files handling, bower/

[Tripp, Travis S]

Thanks, Radomir.

I originally started a patch on Horizon and was going to do that, but was
guided to update global requirements first.

I¹ll go ahead and redo that patch on Horizon.

-Travis

On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:

On 06/01/15 01:39, Tripp, Travis S wrote:
 What Radomir proposes looks like it would greatly ease the process I am
still going through to get the latest angular available to Horizon for
current development.  At the time of writing this, I¹m still trying to
get the updated library through.  I hit a rather difficult workflow:
 
 
   1.  Packaged the latest into Xstatic-Angular-1.3.7
   2.  Submitted patch which deprecated the separate older
xstatic-angular-cookies and xstatic-angular-mock packages
   3.  Reviewed and approved (after correcting an initial
mis-repackaging)
   4.  Radomir released to Pypi
 
 This was pretty easy and not too hard. Not too much to complain about.
 
 However, now, to get Horizon to use it, I have to get that into global
requirements.  Since I¹m deprecating old packages I got stuck in a sort
of ugly dependency path.  I couldn¹t remove the cookies and mock
libraries from the global requirements patch that added the new 1.3.7
package because of horizon still referencing the deprecated packages.
And, when I did it anyway, the integration tests failed due to horizon
being dependent on something not in global requirements.  So, now, as
far as I can tell we have to jump through the following hoops:
 
 
   1.  Global requirements patch to add angular 1.3.7
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   2.  Horizon patch to update to angular 1.3.7 and remove deprecated
mock and cookies packages
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   3.  Global requirements patch to remove deprecated mock and cookies
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
 
 Don¹t get me wrong, I really do think the gate is brilliant and am all
for a review / approval process, but this does seem excessive for a UI
library that should only be used by Horizon. Is there some other reason
that this should have to go through global requirements?

You can do it much easier, since the current version of Angular already
packages what is in the deprecated modules. So just:

1. Patch Horizon to remove the xstatic dependencies to the mock and
cookies packages.
2. Patch global-requirements to remove them, and add newer Angular.
3. Patch Horizon to use the newer Angular.

-- 
Radomir Dopieralski

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] static files handling, bower/

[Tripp, Travis S]

What Radomir proposes looks like it would greatly ease the process I am still 
going through to get the latest angular available to Horizon for current 
development.  At the time of writing this, I’m still trying to get the updated 
library through.  I hit a rather difficult workflow:


  1.  Packaged the latest into Xstatic-Angular-1.3.7
  2.  Submitted patch which deprecated the separate older 
xstatic-angular-cookies and xstatic-angular-mock packages
  3.  Reviewed and approved (after correcting an initial mis-repackaging)
  4.  Radomir released to Pypi

This was pretty easy and not too hard. Not too much to complain about.

However, now, to get Horizon to use it, I have to get that into global 
requirements.  Since I’m deprecating old packages I got stuck in a sort of ugly 
dependency path.  I couldn’t remove the cookies and mock libraries from the 
global requirements patch that added the new 1.3.7 package because of horizon 
still referencing the deprecated packages.  And, when I did it anyway, the 
integration tests failed due to horizon being dependent on something not in 
global requirements.  So, now, as far as I can tell we have to jump through the 
following hoops:


  1.  Global requirements patch to add angular 1.3.7
 *   Verify check / recheck fun
 *   Reviewed and approved
 *   Gate check / recheck fun
  2.  Horizon patch to update to angular 1.3.7 and remove deprecated mock and 
cookies packages
 *   Verify check / recheck fun
 *   Reviewed and approved
 *   Gate check / recheck fun
  3.  Global requirements patch to remove deprecated mock and cookies
 *   Verify check / recheck fun
 *   Reviewed and approved
 *   Gate check / recheck fun

Don’t get me wrong, I really do think the gate is brilliant and am all for a 
review / approval process, but this does seem excessive for a UI library that 
should only be used by Horizon. Is there some other reason that this should 
have to go through global requirements?

Thanks,
Travis

From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/



On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski 
openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote:
On 05/01/15 00:35, Richard Jones wrote:
 On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
 openst...@sheep.art.plmailto:openst...@sheep.art.pl 
 mailto:openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote:

 On 20/12/14 21:25, Richard Jones wrote:
  This is a good proposal, though I'm unclear on how the
  static_settings.py file is populated by a developer (as opposed to a
  packager, which you described).

 It's not, the developer version is included in the repository, and
 simply points to where Bower is configured to put the files.
 So just to be clear, as developers we:

 1. have a bower.json listing the bower component to use,
 2. use bower to fetch and install those to the bower_components
 directory at the top level of the Horizon repos checkout, and
 3. manually edit static_settings.py when we add a new bower component to
 bower.json so it knows the appropriate static files to load from that
 component.

 Is that correct?

 The above will increase the burden on those adding or upgrading bower
 components (they'll need to check the bower.json in the component for
 the appropriate static files to link in) but will make life easier for
 the re-packagers since they'll know which files they need to cater for
 in static_settings.py

Well, I expect you can tell Bower to put the files somewhere else than
in the root directory of the project -- a directory like ``bower_files``
or something (that directory is also added to ``.gitignore`` so that you
don't commit it by mistake). Then only that directory needs to be added
to the ``static_settings.py``. Of course, you still need to make all the
``script`` links in appropriate places with the right URLs, but you
would have to do that anyways.

Bower installs into a directory called bower_components in the current 
directory, which is equivalent to your bower_files above.


Let's look at an example. Suppose you need to a new JavaScript library
called hipster.js. You add it to the ``bower.json`` file, and run
Bower. Bower downloads the right files and does whatever it is that it
does to them, and puts them in  ``bower_files/hipster-js``. Now you edit
Horizon's templates and add ``script src={{ STATIC_URL
}}/hipster-js/hipster.js`` to ``_scripts.html``. That's it for you.
Since your ``static_settings.py`` file already has a line:

  ('', os.path.join(BASE_DIR, '/bower_files')),

in it, it will just work.

Yep, except s/bower_files/bower_components :)


Now, suppose that a 

Re: [openstack-dev] [horizon] REST and Django

[Tripp, Travis S]

 webpage generated client-side, two very different things. We have 
essentially striped out the rendering logic from Django templating and replaced 
it with Angular.


-Tihomir Trifonov t.trifo...@gmail.commailto:t.trifo...@gmail.com 
wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
From: Tihomir Trifonov t.trifo...@gmail.commailto:t.trifo...@gmail.com
Date: 12/12/2014 04:53AM
Subject: Re: [openstack-dev] [horizon] REST and Django

Here's an example: Admin user Joe has an Domain open and stares at it for 15 
minutes while he updates the description. Admin user Bob is asked to go ahead 
and enable it. He opens the record, edits it, and then saves it. Joe finished 
perfecting the description and saves it. Doing this action would mean that the 
Domain is enabled and the description gets updated. Last man in still wins if 
he updates the same fields, but if they update different fields then both of 
their changes will take affect without them stomping on each other. Whether 
that is good or bad may depend on the situation…


That's a great example. I believe that all of the Openstack APIs support PATCH 
updates of arbitrary fields. This way - the frontend(AngularJS) can detect 
which fields are being modified, and to submit only these fields for update. If 
we however use a form with POST, although we will load the object before 
updating it, the middleware cannot find which fields are actually modified, and 
will update them all, which is more likely what PUT should do. Thus having full 
control in the frontend part, we can submit only changed fields. If however a 
service API doesn't support PATCH, it is actually a problem in the API and not 
in the client...



The service API documentation almost always lags (although, helped by specs 
now) and the service team takes on the burden of exposing a programmatic way to 
access the API.  This is tested and easily consumable via the python clients, 
which removes some guesswork from using the service.

True. But what if the service team modifies a method signature from let's say:

def add_something(self, request,
​ field1, field2):


to

def add_something(self, request,
​ field1, field2, field3):


and in the middleware we have the old signature:

​def add_something(self, request,
​ field1, field2):

we still need to modify the middleware to add the new field. If however the 
middleware is transparent and just passes **kwargs, it will pass through 
whatever the frontend sends. So we just need to update the frontend, which can 
be done using custom views, and not necessary going through an upstream change. 
My point is why do we need to hide some features of the backend service API 
behind a firewall what the middleware in fact is?







On Fri, Dec 12, 2014 at 8:08 AM, Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote:
I just re-read and I apologize for the hastily written email I previously
sent. I’ll try to salvage it with a bit of a revision below (please ignore
the previous email).

On 12/11/14, 7:02 PM, Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote
(REVISED):

Tihomir,

Your comments in the patch were very helpful for me to understand your
concerns about the ease of customizing without requiring upstream
changes. It also reminded me that I’ve also previously questioned the
python middleman.

However, here are a couple of bullet points for Devil’s Advocate
consideration.


  *   Will we take on auto-discovery of API extensions in two spots
(python for legacy and JS for new)?
  *   The Horizon team will have to keep an even closer eye on every
single project and be ready to react if there are changes to the API that
break things. Right now in Glance, for example, they are working on some
fixes to the v2 API (soon to become v2.3) that will allow them to
deprecate v1 somewhat transparently to users of the client library.
  *   The service API documentation almost always lags (although, helped
by specs now) and the service team takes on the burden of exposing a
programmatic way to access the API.  This is tested and easily consumable
via the python clients, which removes some guesswork from using the
service.
  *   This is going to be an incremental approach with legacy support
requirements anyway.  So, incorporating python side changes won’t just go
away.
  *   Which approach would be better if we introduce a server side
caching mechanism or a new source of data such as elastic search to
improve performance? Would the client side code have to be changed
dramatically to take advantage of those improvements or could it be done
transparently on the server side if we own the exposed API?

I’m not sure I fully understood your example about Cinder.  Was it the
cinder client that held up delivery of horizon support, the cinder API or
both?  If the API isn’t in, then it would hold up delivery of the feature
in any case

Re: [openstack-dev] [horizon] REST and Django

[Tripp, Travis S]

']:​

​
​​responses
​.append(​
​
getattr(controller, cmd['action']
​)(**
cmd['​payload']
​)​)

​return responses​


​and the frontend(JS) will just send batches of simple commands, and will 
receive a list of responses for each command in the batch. The error handling 
will be done in the frontend​(JS) as well.

​

For the more complex example of 'put()' where we have dependent objects:

project = api.keystone.tenant_get(request, id)
kwargs = self._tenant_kwargs_from_DATA(request.DATA, enabled=None)
api.keystone.tenant_update(request, project, **kwargs)


In practice the project data should be already present in the frontend(assuming 
that we already loaded it to render the project form/view), so

​
​
POST --json --data {
​batch
:
​[
{​

​
action
​ : tenant_update​
,
​payload: ​
{project: js_project_object.idhttp://js_project_object.id, name: some 
name, prop1: some prop, prop2: other prop, etc.}
​
​ ] ​
​
​
}​

So in general we don't need to recreate the full state on each REST call, if we 
make the Frontent full-featured application. This way - the frontend will 
construct the object, will hold the cached value, and will just send the needed 
requests as single ones or in batches, will receive the response from the API 
backend, and will render the results. The whole processing logic will be held 
in the Frontend(JS), while the middleware will just act as proxy(un/packer). 
This way we will maintain just the logic in the frontend, and will not need to 
duplicate some logic in the middleware.




On Tue, Dec 2, 2014 at 4:45 PM, Adam Young 
ayo...@redhat.commailto:ayo...@redhat.com wrote:
On 12/02/2014 12:39 AM, Richard Jones wrote:
On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran 
tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote:

I agree that keeping the API layer thin would be ideal. I should add that 
having discrete API calls would allow dynamic population of table. However, I 
will make a case where it might be necessary to add additional APIs. Consider 
that you want to delete 3 items in a given table.

If you do this on the client side, you would need to perform: n * (1 API 
request + 1 AJAX request)
If you have some logic on the server side that batch delete actions: n * (1 API 
request) + 1 AJAX request

Consider the following:
n = 1, client = 2 trips, server = 2 trips
n = 3, client = 6 trips, server = 4 trips
n = 10, client = 20 trips, server = 11 trips
n = 100, client = 200 trips, server 101 trips

As you can see, this does not scale very well something to consider...

This is not something Horizon can fix.  Horizon can make matters worse, but 
cannot make things better.

If you want to delete 3 users,   Horizon still needs to make 3 distinct calls 
to Keystone.

To fix this, we need either batch calls or a standard way to do multiples of 
the same operation.

The unified API effort it the right place to drive this.







Yep, though in the above cases the client is still going to be hanging, waiting 
for those server-backend calls, with no feedback until it's all done. I would 
hope that the client-server call overhead is minimal, but I guess that's 
probably wishful thinking when in the land of random Internet users hitting 
some provider's Horizon :)

So yeah, having mulled it over myself I agree that it's useful to have batch 
operations implemented in the POST handler, the most common operation being 
DELETE.

Maybe one day we could transition to a batch call with user feedback using a 
websocket connection.


 Richard

[cid:994faa67a8e28335_0.0.1.1]Richard Jones ---11/27/2014 05:38:53 PM---On Fri 
Nov 28 2014 at 5:58:00 AM Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote:

From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
To: Tripp, Travis S travis.tr...@hp.commailto:travis.tr...@hp.com, 
OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: 11/27/2014 05:38 PM
Subject: Re: [openstack-dev] [horizon] REST and Django





On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote:

Hi Richard,

You are right, we should put this out on the main ML, so copying thread out to 
there.  ML: FYI that this started after some impromptu IRC discussions about a 
specific patch led into an impromptu google hangout discussion with all the 
people on the thread below.

Thanks Travis!



As I mentioned in the review[1], Thai and I were mainly discussing the possible 
performance implications of network hops from client to horizon server and 
whether or not any aggregation should occur server side.   In other words, some 
views  require several APIs to be queried before any data can displayed and it 
would eliminate some extra network requests from client to server if some of 
the data was first collected on the server side across service APIs.  For 
example, the launch instance wizard will need to collect data from quite a few 
APIs before even the first step

[openstack-dev] [horizon] REST and Django

[Tripp, Travis S]

Hi Richard,

You are right, we should put this out on the main ML, so copying thread out to 
there.  ML: FYI that this started after some impromptu IRC discussions about a 
specific patch led into an impromptu google hangout discussion with all the 
people on the thread below.

As I mentioned in the review[1], Thai and I were mainly discussing the possible 
performance implications of network hops from client to horizon server and 
whether or not any aggregation should occur server side.   In other words, some 
views  require several APIs to be queried before any data can displayed and it 
would eliminate some extra network requests from client to server if some of 
the data was first collected on the server side across service APIs.  For 
example, the launch instance wizard will need to collect data from quite a few 
APIs before even the first step is displayed (I’ve listed those out in the 
blueprint [2]).

The flip side to that (as you also pointed out) is that if we keep the API’s 
fine grained then the wizard will be able to optimize in one place the calls 
for data as it is needed. For example, the first step may only need half of the 
API calls. It also could lead to perceived performance increases just due to 
the wizard making a call for different data independently and displaying it as 
soon as it can.

I tend to lean towards your POV and starting with discrete API calls and 
letting the client optimize calls.  If there are performance problems or other 
reasons then doing data aggregation on the server side could be considered at 
that point.  Of course if anybody is able to do some performance testing 
between the two approaches then that could affect the direction taken.

[1] 
https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py
[2] https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign

-Travis

From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Date: Wednesday, November 26, 2014 at 11:55 PM
To: Travis Tripp travis.tr...@hp.commailto:travis.tr...@hp.com, Thai Q 
Tran/Silicon Valley/IBM tqt...@us.ibm.commailto:tqt...@us.ibm.com, David 
Lyle dkly...@gmail.commailto:dkly...@gmail.com, Maxime Vidori 
maxime.vid...@enovance.commailto:maxime.vid...@enovance.com, Wroblewski, 
Szymon szymon.wroblew...@intel.commailto:szymon.wroblew...@intel.com, 
Wood, Matthew David (HP Cloud - Horizon) 
matt.w...@hp.commailto:matt.w...@hp.com, Chen, Shaoquan 
sean.ch...@hp.commailto:sean.ch...@hp.com, Farina, Matt (HP Cloud) 
matthew.far...@hp.commailto:matthew.far...@hp.com, Cindy Lu/Silicon 
Valley/IBM c...@us.ibm.commailto:c...@us.ibm.com, Justin 
Pomeroy/Rochester/IBM jpom...@us.ibm.commailto:jpom...@us.ibm.com, Neill 
Cox neill@ingenious.com.aumailto:neill@ingenious.com.au
Subject: Re: REST and Django

I'm not sure whether this is the appropriate place to discuss this, or whether 
I should be posting to the list under [Horizon] but I think we need to have a 
clear idea of what goes in the REST API and what goes in the client (angular) 
code.

In my mind, the thinner the REST API the better. Indeed if we can get away with 
proxying requests through without touching any *client code, that would be 
great.

Coding additional logic into the REST API means that a developer would need to 
look in two places, instead of one, to determine what was happening for a 
particular call. If we keep it thin then the API presented to the client 
developer is very, very similar to the API presented by the services. Minimum 
surprise.

Your thoughts?


 Richard


On Wed Nov 26 2014 at 2:40:52 PM Richard Jones 
r1chardj0...@gmail.commailto:r1chardj0...@gmail.com wrote:
Thanks for the great summary, Travis.

I've completed the work I pledged this morning, so now the REST API change set 
has:

- no rest framework dependency
- AJAX scaffolding in openstack_dashboard.api.rest.utils
- code in openstack_dashboard/api/rest/
- renamed the API from identity to keystone to be consistent
- added a sample of testing, mostly for my own sanity to check things were 
working

https://review.openstack.org/#/c/136676


  Richard

On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S 
travis.tr...@hp.commailto:travis.tr...@hp.com wrote:
Hello all,

Great discussion on the REST urls today! I think that we are on track to come 
to a common REST API usage pattern.  To provide quick summary:

We all agreed that going to a straight REST pattern rather than through tables 
was a good idea. We discussed using direct get / post in Django views like what 
Max originally used[1][2] and Thai also started[3] with the identity table 
rework or to go with djangorestframework [5] like what Richard was prototyping 
with[4].

The main things we would use from Django Rest Framework were built in JSON 
serialization (avoid boilerplate), better exception handling, and some request 
wrapping.  However, we all weren’t sure about the need for a full new framework 
just for that. At the end

[openstack-dev] [horizon] Somewhere to host mockups

[Tripp, Travis S]

David,

In the Horizon team meeting on the 14th[1], we had some discussion about where 
we should host additional items like mockups that are associated with a 
blueprint.  Numerous suggestions came up but there wasn't any official clear 
answer, so you said you'd check with the infra team.  Were you able to do that?

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-10-14-16.00.log.html

Thanks,
Travis

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

[Tripp, Travis S]

 On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S
 wrote:
  
 
  From Jamie Lennox:
   We handle this in the keystoneclient Session object by just 
   printing
  REDACTED or something similar.
   The problem with using a SHA1 is that for backwards compatability 
   we
  often use the SHA1 of a PKI token
   as if it were a UUID token and so this is still sensitive data. 
   There
  is working in keystone by morganfainberg
   (which i think was merged) to add a new audit_it which will be 
   able to
  identify a token across calls without
   exposing any sensitive information. We will support this in 
   session
  when available.
 
  From Sean Dague
   So the problem is that means we are currently leaking secrets and 
   making
  the logs unreadable.
 
   It seems like we should move forward with the {SHA1} ... and if 
   that is
  still sensitive, address that later.
   Not addressing it basically keeps the exposure and destroys 
   usability of
  the code because there is so much garbage printed out.
 
  I understand Sean's point about debugging. Right now the 
  glanceclient is just printing ***. So it isn't printing a lot of 
  excess and isn't leaking anything sensitive. The other usability 
  concern with the *** that Sean previously mentioned was having a 
  short usable string might be useful for debugging.
 
  Morgan and Jamie, You think switching to SHA1 in actually adds a 
  potential security vulnerability to glanceclient that doesn't exist 
  now. If that is true, I think it would override the additional 
  debugging concern of using
  SHA1 for now. Can you please confirm?
 
  If only for consistency sake, I could switch to TOKEN_REDACTED 
  like the code sample Morgan sent. [1]
 
  [1]
  https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee
  8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131
 
  
 As the person who proposed the change to print TOKEN_REDACTED, I'd be 
 happy to see it printed as {SHA1} instead. I only had it print 
 TOKEN_REDACTED because I was concerned that we were still logging 
 tokens and wanted to get something merged that didn't do that rather 
 than waiting for the perfect solution to come along.
  
 Since we have configurable token hashing algorithm support in keystone 
 and auth_token middleware, it's possible that someone could lose their 
 sanity and decide to use sha1 as the hash algorithm (it defaults to 
 MD5, which some security standards say is inadequate), and now your 
 logs have usable token IDs instead of an unusable hash, ***, 
 TOKEN_REDACTED, or whatever. We could accept this as a risk, and we 
 could mitigate the risk some by changing keystone to reject sha1 as a hashing 
 algorithm.
  
 - Brant

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Ideally, I want to see the use of the audit_ids (in each token as of Juno)
 as the end goal. If we can get there as fast as changing to the {SHA1}, 
I’d advocate for that. Brant nicely outlined why we didn’t go with SHA1 
earlier on in the cycle.

 I think we are close to solving this in a better way than using sha1,
 but if we need a stop-gap we can go towards that for the short term (and 
 disallow sha1 as a hash for Keystone).

Thanks for all the input.  Stuart McLaren pointed out the patches in Nova and 
Swift clients where using the SHA1 was done in place of the token, so I've gone 
ahead and posted up a glanceclient patch using the same approach.

https://review.openstack.org/#/c/121692/

Hopefully this at least makes these client work similarly for now and we can 
switch everything to the audit ID soon.

Thanks,
Travis
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

[Tripp, Travis S]

From Jamie Lennox:
 We handle this in the keystoneclient Session object by just printing 
 REDACTED or something similar. 
 The problem with using a SHA1 is that for backwards compatability we often 
 use the SHA1 of a PKI token
 as if it were a UUID token and so this is still sensitive data. There is 
 working in keystone by morganfainberg
 (which i think was merged) to add a new audit_it which will be able to 
 identify a token across calls without
 exposing any sensitive information. We will support this in session when 
 available. 

From Sean Dague
 So the problem is that means we are currently leaking secrets and making the 
 logs unreadable.

 It seems like we should move forward with the {SHA1} ... and if that is still 
 sensitive, address that later. 
 Not addressing it basically keeps the exposure and destroys usability of the 
 code because there is so much garbage printed out.

I understand Sean's point about debugging.  Right now the glanceclient is just 
printing ***.  So it isn't printing a lot of excess and isn't leaking anything 
sensitive.  The other usability concern with the ***  that Sean previously 
mentioned was having a short usable string might be useful for debugging.

Morgan and Jamie, You think switching to SHA1 in actually adds a potential 
security vulnerability to glanceclient that doesn't exist now. If that is true, 
I think it would override the additional debugging concern of using SHA1 for 
now.  Can you please confirm?  

If only for consistency sake, I could switch to TOKEN_REDACTED like the code 
sample Morgan sent. [1]

[1] 
https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] masking X-Auth-Token in debug output - proposed consistency

[Tripp, Travis S]

Hi All,

I'm just helping with bug triage in Glance and we've got a bug to update how 
tokens are redacted in the glanceclient [1].  It says to update to whatever 
cross-project approach is agreed upon and references this thread:

http://lists.openstack.org/pipermail/openstack-dev/2014-June/037345.html

I just went through the thread and as best as I can tell there wasn't a 
conclusion in the ML.  However, if we are going to do anything, IMO the thread 
leans toward {SHA1}sha1oftoken, with Morgan Fainberg dissenting.  However, he 
references a patch that was ultimately abandoned.

If there was a conclusion to this, please let me know so I can update and work 
on closing this bug.

[1] https://bugs.launchpad.net/python-glanceclient/+bug/1329301

Thanks,
Travis
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Review priorities

[Tripp, Travis S]

Thanks for sending out, Arnaud. I added two to the etherpad for metadefs: the 
glance client and related tempest patch.  

Without the client, we can't get the related Horizon patches landed.

Glance Client: https://review.openstack.org/#/c/105231/ 
Tempest: https://review.openstack.org/113632/ 

For anybody looking at metadefs, I added a script to the etherpad[1] that can 
be run on a fresh devstack to get all of the Glance patches + the first Horizon 
patch will enable this for image metadata.  (Go to Admin dashboard -- Images 
-- Update Metadata (row action).  Please ensure that all code is committed or 
stashed before running the script (or snapshot your vm).

[1] https://etherpad.openstack.org/p/j3-glance-patches

Thanks,
Travis

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com] 
Sent: Thursday, August 21, 2014 4:27 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Review priorities

On 08/21/2014 11:59 PM, Arnaud Legendre wrote:
 Greetings,
 
 The Juno-3 feature freeze is not far away (September 4th). See [1] for 
 more information.
 We have a bunch of outstanding patches that need to get reviewed. We 
 are trying to come with a list of the most important features/bugs [2].
 So far, we have the following:
 
 
 Features
 
 
 
 https://review.openstack.org/#/c/44355/ | Introduces eventlet
 executor for Glance Tasks
 
 https://review.openstack.org/#/c/80182/ | Add GPFS support as image
 store
 
 https://review.openstack.org/#/c/98737/ | Restrict users from
 downloading protected image
 
 https://review.openstack.org/111441 | Glance Metadata Definitions
 Catalog - DB
 
 https://review.openstack.org/111483 | Glance Metadata Definitions
 Catalog - Seed
 
 https://review.openstack.org/111455 | Glance Metadata Definitions
 Catalog - API
 

I'd like to add to this list the adoption of glance.store. The patch is not 
passing the gate because it depends on some changes that still need to happen 
in the gate and devstack. However, the work there is pretty much done and the 
patch is ready to be reviewed. The sooner we start addressing comments there, 
the better.

https://review.openstack.org/#/c/100636/

Flavio

 
 Bugs
 
 
 
 https://review.openstack.org/#/c/103959/ | Changes HTTP response
 code for unsupported methods
 
 https://review.openstack.org/#/c/115111/ | Add swift store upload
 recover
 
 https://bugs.launchpad.net/glance/+bug/1316233 | image data not
 deleted while deleting image in v2 api
 
 https://bugs.launchpad.net/glance/+bug/1316234 | Image delete calls
 slow due to synchronous wait on backend store delete
 
 Please edit the etherpad [2] if you think something is missing.
 I will add the J-3 tag to the bugs later today.
 
 Thanks,
 Arnaud
 
 
 [1]https://wiki.openstack.org/wiki/Juno_Release_Schedule
 [2]https://etherpad.openstack.org/p/j3-glance-patches
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tripp, Travis S]

Thank you Serg,

Yes, what you are discussing in this thread is actually directly related to 
many of the original reasons we worked on the Graffiti concept POC and then 
revised into the metadata definitions catalog we are working on for Glance.
Basically, you can define objects and properties that you care about in the 
definitions catalog and then use the UI to apply metadata to things like 
images. The UI of course is pulling from a REST API, so this isn’t limited to 
UI use only.  The catalog ensures consistency of applying the metadata so that 
the metadata is useable for users as well as tool automation.  We’ve got 
multiple sets of code in progress which I’ve highlighted below and we have a 
session at the Glance mini-summit this week to talk about it further.

The below are work in progress, but you probably would be able to fetch the 
horizon ones to get an idea of where things currently are.

Glance Metadata Definitions Catalog: https://review.openstack.org/#/c/105904/
Python Glance Client support: https://review.openstack.org/#/c/105231/
Horizon Metadata Tagging Widget: https://review.openstack.org/#/c/104956/
Horizon Admin UI: https://review.openstack.org/#/c/104063/

For Juno, we’ve scaled back some of our original Graffiti concepts (which 
included inheritance, elastic search, etc) to help get things landed in this 
iteration, but then we want to build out from there and would love to work with 
you to help this meet your needs.

Thanks,
Travis

From: Serg Melikyan [mailto:smelik...@mirantis.com]
Sent: Wednesday, July 23, 2014 9:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Murano] Image tagging
Importance: High

I would also suggest to look at 
Graffitihttps://wiki.openstack.org/wiki/Graffiti project, I think Graffiti is 
designed to solve problems related to our with images however I don't know how 
well it is fit for us. They work very hard to make project functionality 
available as parthttps://review.openstack.org/98554 of Glance.

If it's really can solve our problem we can design solution that expose 
functionality compatible in capabilities with Graffiti and have limited 
short-term implementation that eventually can be replaced by Glance [with 
Metadata Definitions Catalog feature].

On Wed, Jul 23, 2014 at 1:52 AM, Stan Lagun 
sla...@mirantis.commailto:sla...@mirantis.com wrote:
How do you like alternate design: uses can chose any image he wants (say any 
Linux) but the JSON that is in image tag has enough information on what 
applications are installed on that image. And not just installed or not but the 
exact state installation was frozen (say binaries are deployed but config files 
are need to be modified). The deployment workflow can peak that state from 
image tag and continue right from the place it was stopped last time. So if 
user has chosen image with MySQL preinstalled the workflow will just 
post-configure it while if the user chosen clean Linux image it will do the 
whole deployment from scratch. Thus it will become only a matter of 
optimization and user will still be able to to share instance for several 
applications (good example is Firewall app) or deploy his app even if there is 
no image where it was built in.

Those are only my thoughts and this need a proper design. For now I agree that 
we need to improve tagging to support yours use case. But this need to be done 
in a way that would allow both user and machine to work with. UI at least needs 
to distinguish between Linux and Windows while for user a free-form tagging may 
be appropriate. Both can be stored in a single JSON tag.

So lets create blueprint/etherpad for this and both think on exact format that 
can be implemented right now

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

On Tue, Jul 22, 2014 at 10:08 PM, McLellan, Steven 
steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote:
Thanks for the response.

Primarily I’m thinking about a situation where I have an image that has a 
specific piece of software installed (let’s say MySQL for the sake of 
argument). My application (which configures mysql) requires a glance image that 
has MySQL pre-installed, and doesn’t particularly care what OS (though again 
for the sake of argument assume it’s linux of some kind, so that configuration 
files are expected to be in the same place regardless of OS).

Currently we have a list of three hardcoded values in the UI, and none of them 
apply properly. I’m suggesting instead of that list, we allow free-form text; 
if you’re tagging glance images, you are expected to know what applications 
will be looking for. This still leaves a problem in that I can upload a package 
but I don’t necessarily have the ability to mark any images as valid for it, 
but I think that can be a later evolution; for now, I’m focusing on the 
situation where an admin is both uploading glance images and murano packages.

As a slight side note, we do have 

Re: [openstack-dev] [cinder][glance] Update volume-image-metadata proposal

[Tripp, Travis S]

From: Brian Rosmaita [mailto:brian.rosma...@rackspace.com]
Or you can just use it as the basis of a Cinder property protection config 
file,
because I wonder whether in the general case, you'll always want volume
properties protected exactly the same as image properties.  If not, the new
API call strategy will force you to deal with differences in the code, whereas
the config file strategy would move dealing with differences to setting up the 
config file.

Once an instance is launched, the image properties are treated the same and 
lose distinction of whether they came from an image or a bootable volume in 
Nova. I agree with Facundo that maintaining a consistency between configuration 
files sounds like a configuration drift risk to me opening the opportunity to 
bypass protected properties. Also, commands in Cinder like upload-to-image may 
fail because a bootable volume is created with image properties that Glance 
doesn't actually allow.

Why not have a single source of truth for protected properties coming from 
Glance? A small possible downside I see is that the Glance API will get hit 
more often, but maybe we can optimize that?

This does sound like a good topic for the Glance meeting, but since it is a 
Cinder topic as well, it would be good to get Cinder team feedback.

-Travis

From: Maldonado, Facundo N [mailto:facundo.n.maldon...@intel.com]
Sent: Wednesday, June 25, 2014 7:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][glance] Update volume-image-metadata 
proposal

Thanks for the response, I'll be there this Thursday.

Having the file in more than one place could me a nightmare if we have to 
maintain consistency between them.
It could be good if we want to protect different properties than Glance.

Thanks,
Facundo

From: Brian Rosmaita [mailto:brian.rosma...@rackspace.com]
Sent: Tuesday, June 24, 2014 7:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][glance] Update volume-image-metadata 
proposal

Hi Facundo,

Can you attend the Glance meeting this week at 20:00 UTC on Thursday in 
#openstack-meeting-alt ?

I may be misunderstanding what's at stake, but it looks like:
- Glance holds the image metadata (some user-modifiable, some not)
- Cinder copies the image metadata to use as volume metadata (none is 
user-modifiable)
- You want to implement user-modifiable metadata in Cinder, but you don't know 
which items should be mutable and which not.
- You propose to add glance API calls to allow you to figure out property 
protections on a per-property basis.

It looks like the only roles for Glance here are (1) as the original source of 
the image metadata, and then (2) as the source of truth for what image 
properties can be modified on the volume metadata.  For (1), you've already got 
an API call.  For (2), why not use the glance property protection configuration 
file directly?  It's going to be deployed somehow to your glance nodes, you can 
deploy it to your cinder nodes at the same time.  Or you can just use it as the 
basis of a Cinder property protection config file, because I wonder whether in 
the general case, you'll always want volume properties protected exactly the 
same as image properties.  If not, the new API call strategy will force you to 
deal with differences in the code, whereas the config file strategy would move 
dealing with differences to setting up the config file.  So I'm not convinced 
that a new API call is the way to go here.

But there may be some nuances I'm missing, so it might be easier to discuss at 
the Glance meeting.  The agenda looks pretty light for Thursday if you want to 
add this topic:
https://etherpad.openstack.org/p/glance-team-meeting-agenda

cheers,
brian

From: Maldonado, Facundo N [facundo.n.maldon...@intel.com]
Sent: Tuesday, June 24, 2014 2:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder][glance] Update volume-image-metadata proposal
Hi folks,

I started working on this blueprint [1] but the work to be done 
is not limited to cinder python client.
Volume-image-metadata is immutable in Cinder and Glance has 
RBAC image properties and it doesn't provide any way to find out which are 
those protected properties in advance [2].

I want to share this proposal and get feedback from you.

https://docs.google.com/document/d/1XYEqGOa30viOyZf8AiwkrCiMWGTfBKjgmeYBptaCHlM/


Thanks,
Facundo

[1] 
https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata
[2] 
http://openstack.10931.n7.nabble.com/Cinder-Confusion-about-the-respective-use-cases-for-volume-s-admin-metadata-metadata-and-glance-imaga-td39849.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

[Tripp, Travis S]

FYI: We now have the initial Glance spec up for review.  
https://review.openstack.org/#/c/98554/

We generalized a few concepts and will look at how to bring a few of those 
concepts back in potentially via a future spec.

Thanks,
Travis

From: Tripp, Travis S
Sent: Friday, May 30, 2014 4:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for 
Capabilities and Tags
Importance: High

Thanks, Zane and Georgy!

We’ll begin getting all the expected sections for the new Glance spec repo into 
this document next week and then will upload in RST format for formal review. 
That is a bit more expedient since there are still several people editing. In 
the meantime, we’ll take any additional comments in the google doc.

Thanks,
Travis

From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Sent: Friday, May 30, 2014 1:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for 
Capabilities and Tags
Importance: High

I think this is a great feature to have it in Glance. Tagging mechanism for 
objects which are not owned by Glance is complimentary to artifact 
catalog\repository in Glance. As soon as we keep tags and artifacts metadata 
close to each other the end-user will be able to use them seamlessly.
Artifacts also can use tags to find objects outside of artifact repository 
which is always good to have.
In Murano project we use Glance tags to find correct images which are required 
by specific applications. It will be great to extend this to other objects like 
networks, routers and flavors so that application write can specify kind of 
object are required for his application.

Thanks,
Georgy

On Fri, May 30, 2014 at 11:45 AM, Zane Bitter 
zbit...@redhat.commailto:zbit...@redhat.com wrote:
On 29/05/14 18:42, Tripp, Travis S wrote:
Hello everyone!

At the summit in Atlanta we demonstrated the “Graffiti” project
concepts.  We received very positive feedback from members of multiple
dev projects as well as numerous operators.  We were specifically asked
multiple times about getting the Graffiti metadata catalog concepts into
Glance so that we can start to officially support the ideas we
demonstrated in Horizon.

After a number of additional meetings at the summit and working through
ideas the past week, we’ve created the initial proposal for adding a
Metadata Catalog to Glance for capabilities and tags.  This is distinct
from the “Artifact Catalog”, but we do see that capability and tag
catalog can be used with the artifact catalog.

We’ve detailed our initial proposal in the following Google Doc.  Mark
Washenberger agreed that this was a good place to capture the initial
proposal and we can later move it over to the Glance spec repo which
will be integrated with Launchpad blueprints soon.

https://docs.google.com/document/d/1cS2tJZrj748ZsttAabdHJDzkbU9nML5S4oFktFNNd68

Please take a look and let’s discuss!

Also, the following video is a brief recap of what was demo’ d at the
summit.  It should help to set a lot of understanding behind the ideas
in the proposal.

https://www.youtube.com/watch?v=Dhrthnq1bnw

Thank you!

Travis Tripp (HP)

Murali Sundar (Intel)
*A Few Related Blueprints *


https://blueprints.launchpad.net/horizon/+spec/instance-launch-using-capability-filtering

https://blueprints.launchpad.net/horizon/+spec/tagging

https://blueprints.launchpad.net/horizon/+spec/faceted-search

https://blueprints.launchpad.net/horizon/+spec/host-aggregate-update-metadata

https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata

+1, this is something that will be increasingly important to orchestration. The 
folks working on the TOSCA (and others) - HOT translator project might be able 
to comment in more detail, but basically as people start wanting to write 
templates that run on multiple clouds (potentially even non-OpenStack clouds) 
some sort of catalog for capabilities will become crucial.

cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.comhttp://www.mirantis.com/
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

[Tripp, Travis S]

Thanks, Zane and Georgy!

We’ll begin getting all the expected sections for the new Glance spec repo into 
this document next week and then will upload in RST format for formal review. 
That is a bit more expedient since there are still several people editing. In 
the meantime, we’ll take any additional comments in the google doc.
Thanks,
Travis

From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Sent: Friday, May 30, 2014 1:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for 
Capabilities and Tags
Importance: High

I think this is a great feature to have it in Glance. Tagging mechanism for 
objects which are not owned by Glance is complimentary to artifact 
catalog\repository in Glance. As soon as we keep tags and artifacts metadata 
close to each other the end-user will be able to use them seamlessly.
Artifacts also can use tags to find objects outside of artifact repository 
which is always good to have.
In Murano project we use Glance tags to find correct images which are required 
by specific applications. It will be great to extend this to other objects like 
networks, routers and flavors so that application write can specify kind of 
object are required for his application.

Thanks,
Georgy

On Fri, May 30, 2014 at 11:45 AM, Zane Bitter 
zbit...@redhat.commailto:zbit...@redhat.com wrote:
On 29/05/14 18:42, Tripp, Travis S wrote:
Hello everyone!

At the summit in Atlanta we demonstrated the “Graffiti” project
concepts.  We received very positive feedback from members of multiple
dev projects as well as numerous operators.  We were specifically asked
multiple times about getting the Graffiti metadata catalog concepts into
Glance so that we can start to officially support the ideas we
demonstrated in Horizon.

After a number of additional meetings at the summit and working through
ideas the past week, we’ve created the initial proposal for adding a
Metadata Catalog to Glance for capabilities and tags.  This is distinct
from the “Artifact Catalog”, but we do see that capability and tag
catalog can be used with the artifact catalog.

We’ve detailed our initial proposal in the following Google Doc.  Mark
Washenberger agreed that this was a good place to capture the initial
proposal and we can later move it over to the Glance spec repo which
will be integrated with Launchpad blueprints soon.

https://docs.google.com/document/d/1cS2tJZrj748ZsttAabdHJDzkbU9nML5S4oFktFNNd68

Please take a look and let’s discuss!

Also, the following video is a brief recap of what was demo’ d at the
summit.  It should help to set a lot of understanding behind the ideas
in the proposal.

https://www.youtube.com/watch?v=Dhrthnq1bnw

Thank you!

Travis Tripp (HP)

Murali Sundar (Intel)
*A Few Related Blueprints *


https://blueprints.launchpad.net/horizon/+spec/instance-launch-using-capability-filtering

https://blueprints.launchpad.net/horizon/+spec/tagging

https://blueprints.launchpad.net/horizon/+spec/faceted-search

https://blueprints.launchpad.net/horizon/+spec/host-aggregate-update-metadata

https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata

+1, this is something that will be increasingly important to orchestration. The 
folks working on the TOSCA (and others) - HOT translator project might be able 
to comment in more detail, but basically as people start wanting to write 
templates that run on multiple clouds (potentially even non-OpenStack clouds) 
some sort of catalog for capabilities will become crucial.

cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.comhttp://www.mirantis.com/
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

[Tripp, Travis S]

Hello everyone!

At the summit in Atlanta we demonstrated the Graffiti project concepts.  We 
received very positive feedback from members of multiple dev projects as well 
as numerous operators.  We were specifically asked multiple times about getting 
the Graffiti metadata catalog concepts into Glance so that we can start to 
officially support the ideas we demonstrated in Horizon.

After a number of additional meetings at the summit and working through ideas 
the past week, we've created the initial proposal for adding a Metadata Catalog 
to Glance for capabilities and tags.  This is distinct from the Artifact 
Catalog, but we do see that capability and tag catalog can be used with the 
artifact catalog.

We've detailed our initial proposal in the following Google Doc.  Mark 
Washenberger agreed that this was a good place to capture the initial proposal 
and we can later move it over to the Glance spec repo which will be integrated 
with Launchpad blueprints soon.

https://docs.google.com/document/d/1cS2tJZrj748ZsttAabdHJDzkbU9nML5S4oFktFNNd68

Please take a look and let's discuss!

Also, the following video is a brief recap of what was demo' d at the summit.  
It should help to set a lot of understanding behind the ideas in the proposal.

https://www.youtube.com/watch?v=Dhrthnq1bnw


Thank you!

Travis Tripp (HP)
Murali Sundar (Intel)


A Few Related Blueprints
https://blueprints.launchpad.net/horizon/+spec/instance-launch-using-capability-filtering
https://blueprints.launchpad.net/horizon/+spec/tagging
https://blueprints.launchpad.net/horizon/+spec/faceted-search
https://blueprints.launchpad.net/horizon/+spec/host-aggregate-update-metadata
https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session

[Tripp, Travis S]

Hello Horizon team,

We've been working on some concepts that we'd like to see be incorporated in 
the launch instance workflow new UI or existing UI.  We have a related design 
session at the summit and would love to get feedback! We'll be showing some 
early prototyping work that we've been doing.

http://junodesignsummit.sched.org/event/61439e8187a25985473ea53cc078#.U2-w3ldLpT5

https://etherpad.openstack.org/p/juno-summit-graffiti

Thanks,
Travis

From: Liz Blanchard [mailto:lsure...@redhat.com]
Sent: Friday, May 09, 2014 3:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability 
Testing and plan for Summit session

One last addition, I promise :)

Another item that we would like to tackle in Juno based on the Usability 
Testing results is to make some improvements to the way we give our users 
inline help in forms. I've put together a doc that includes our current 
solution and some suggestions for improvements. If there is time, we will be 
discussing this during the session as well:
http://people.redhat.com/~lsurette/OpenStack/ImprovementstoInlineHelpinHorizon.pdf

See you all next week!

Liz
On May 7, 2014, at 3:50 PM, Liz Blanchard 
lsure...@redhat.commailto:lsure...@redhat.com wrote:


Hi All,

Another topic on the agenda for this session is to talk a bit about creating 
some guidelines around Error messaging in Horizon, and hopefully this will 
trickle through other components as needed. I've put together some initial 
thoughts around this topic and want to get it out to the list so folks might 
have some time to take a look before discussing at the session. If you have any 
feedback, feel free to respond before summit and I can update this doc.

http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf

Thanks,
Liz
On Apr 30, 2014, at 2:50 PM, Jacki Bauer 
jacki.ba...@rackspace.commailto:jacki.ba...@rackspace.com wrote:


Hi everyone,
As Liz mentioned, we did some testing and one of the big findings was that the 
Launch Instance form had some usability issues. I took a stab at mocking up a 
launch instance process that addresses some of these issues. You can read the 
usability findings 
herehttps://wiki.openstack.org/wiki/Horizon-usability-test-findings.

So, I know some of you will ask about work that is already being done around 
improving the launch instance form - 
herehttps://www.youtube.com/watch?v=CO62UUQPTCM and 
herehttps://blueprints.launchpad.net/horizon/+spec/launch-instance-ux-enhancement.
  That work is represented here too! I took what I felt to be what was best 
about the current form and best about the new work, addressed the usability 
issues, and tried to come up with something that wasn't too different from 
either of these.

If you are interested in any of the design thinking/reasoning behind the 
mockups, go ahead and keep reading below, otherwise, just take a look at the 
attachment.  Feedback is welcome!

Cheers,
Jacki

Why I did things the way I did:

  *   I used a multi-step form for a few reasons. 1-The Horizon people are 
interested in wizard patterns that could be used for launching instances and 
other step by step workflows. 2-The current launch instance divides the config 
options into tabs, but users often didn't notice the tabs until they tried to 
launch the instance and got an error. The * indicating required fields on 
each tab confused users as well. Since all but one tab contained required 
fields, the tabs didn't do anything to reduce the number of clicks a user had 
to make in order to complete the form.

  *   A best practice for wizards is to never reveal specific steps to the user 
if the number or names of those steps can change.  So, I settled on four steps. 
Some users might not want to visit all these steps, and this is maybe a flaw. 
Maybe we can think about a way to allow users to skip steps.
  *   I decided to stack all fields vertically with labels to the left. I did 
this because I wanted the layout of form fields to be consistent throughout. 
This layout is very readable and pretty standard. It saves vertical space too.
  *   I changed the network selection to checkboxes. Users thought the drag and 
drop style control was inconsistent with the rest of Horizon.
  *   Users really liked the graphs that show their quota when they are 
selecting a flavor. But this didn't really work with the new layout, so I 
settled on a different way of presenting the same information. It's not as 
visually appealing as the graphs were, but it's more flexible - could be used 
throughout Horizon to show quota information on demand and in context.
  *   I added the ability to create key pairs. This was a big finding from the 
usability study.
  *   I did not add the ability to create a network on the fly. Another big 
finding from the usability study was that users were frustrated by the fact 
that they had to have at least one network 

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Tripp, Travis S]

 We're suffering from a total overload of the term 'metadata' here, and there 
 are
 3 totally separate things that are somehow becoming mangled

Thanks for the summary. The term metadata definitely gets overloaded. I've 
been experimenting with the metadata to see what happens with all of it.

Glance image properties == ALL properties are copied to volume_image_metadata 
in Cinder
Cinder volume_metadata == Disappears when uploaded to image in Glance
Cinder volume_image_metadata == Core image properties are copied. Rest are 
lost.

One thing I did was create an image and added properties.  Then I created 
bootable volume from it.  Then I uploaded the bootable volume to Glance.  When 
it got back to Glance all the non-core properties were gone.

Was this the intended design? This doesn't seem right.  

Aside from pure user properties, this also would be a problem in Trump's 
original scenario where you may change options on a volume needed for Nova 
scheduling or driver settings like hw_scsi_mode. You lose all those properties 
set when uploading to image. 

Regarding the property protections in Glance, it looks to use RBAC.  It seems 
to me that if a volume is being uploaded to glance with protected properties 
and the user doing the copying doesn't have the right roles to create those 
properties that Glance should reject the upload request. 

Based on the etherpads, the primary motivation for property protections was for 
an image marketplace, which doesn't seem like there would be the same need for 
volumes. If property protections were needed for other reasons like restricting 
properties that are picked up by the scheduler or a driver, then that is a 
another use case which may affect the cinder client blueprint [1], but seems 
like it would need to be handled by the Cinder API.

We are trying to work out some concepts on all of this as part of the Graffiti 
project [2] and a related Horizon blueprint [3] for metadata management. If we 
put in a UI element for handling the metadata, where should the cinder metadata 
go? Would it be reasonable to just use volume_image_metadata if the volume is 
bootable?  Otherwise, use the volume_metadata? 

[1] 
https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata
  
[2] 
https://wiki.openstack.org/wiki/Graffiti/Architecture#Proposed_Horizon_Concepts 
 
[3] https://blueprints.launchpad.net/horizon/+spec/tagging 

 -Original Message-
 From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
 Sent: Wednesday, May 07, 2014 7:57 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Cinder] Confusion about the respective use cases
 for volume's admin_metadata, metadata and glance_image_metadata
 
 On 7 May 2014 09:36, Trump.Zhang zhangleiqi...@gmail.com wrote:
  @Tripp, Thanks for your reply and info.
 
  I am also thinking if it is proper to add support for updating the
  volume's glance_image_metadta to reflect the newest status of volume.
 
  However, there may be alternative ways to achieve it:
  1. Using the volume's metatadata
  2. Using the volume's admin_metadata
 
  So I am wondering which is the most proper method.
 
 
 We're suffering from a total overload of the term 'metadata' here, and there 
 are
 3 totally separate things that are somehow becoming mangled:
 
 1. Volume metadata - this is for the tenant's own use. Cinder and nova don't
 assign meaning to it, other than treating it as stuff the tenant can set. It 
 is
 entirely unrelated to glance_metadata 2. admin_metadata - this is an internal
 implementation detail for cinder to avoid every extension having to alter the
 core volume db model. It is not the same thing as glance metadata or
 volume_metadata.
 
 An interface to modify volume_glance_metadata sounds reasonable, however it
 is *unrelated* to the other two types of metadata. They are different things, 
 not
 replacements or anything like that.
 
 Glance protected properties need to be tied into the modification API somehow,
 or else it becomes a trivial way of bypassing protected properties. Hopefully 
 a
 glance expert can pop up and suggest a way of achieving this integration.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Tripp, Travis S]

A few days ago I entered a client blueprint on the same topic [1], but maybe it 
has a server side dependency as well?

When it comes to scheduling, as far as I have been able to tell from looking at 
Nova code, the scheduler is only getting volume_image_metadata and not the 
regular cinder_metadata.  So, if you want to add some volume_image_metadata for 
scheduler filtering or for passing compute driver options through after 
creating a volume, there doesn't seem to be a way to do this from the 
python-cinderclient.  If I'm wrong, please correct me.

[1] 
https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata
 

 -Original Message-
 From: Mike Perez [mailto:thin...@gmail.com]
 Sent: Tuesday, May 06, 2014 9:10 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Cinder] Confusion about the respective use cases
 for volume's admin_metadata, metadata and glance_image_metadata
 
 On 06:31 Wed 07 May , Trump.Zhang wrote:
  Thanks for your further instructions.
 
  I think the situations I mentioned are the reasonable use cases. They
  are similar to the bootable volume use cases, user can create an
  empty volume and install os in it from an image or create bootable
  volume from instance ([1]).
 
  If volume metadata is not intended to be interpreted by cinder or nova
  as meaning anything, maybe Cinder needs to add support for updating
  some of glance_image_metadata of volume or introduce new property for
  volume like bootable ? I don't think these two methods are good either.
 
  [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option
 
 Volume already has a bootable field:
 
 https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/model
 s.py#L122
 
 --
 Mike Perez
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev