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

2016-11-17 Thread Thai Q Tran
+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 coreDate: Thu, Nov 17, 2016 11:51 AM 
+1On 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:unsubscribehttp://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] ui-cookiecutter

2016-11-15 Thread Thai Q Tran
Great! I'll be sure to bring it up on your behalf (if you are not there).
 
- Original message -From: Shuu Mutou <shu-mu...@rf.jp.nec.com>To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>Cc: Haruhiko Katou <har-ka...@ts.jp.nec.com>Subject: Re: [openstack-dev] [Horizon] ui-cookiecutterDate: Mon, Nov 14, 2016 7:07 PM 
Hi Thai,I created new blueprint[1], and added the BP to next IRC meeting agenda[2]. I hope the topic will be discussed in the meeting.[1]https://blueprints.launchpad.net/horizon/+spec/ui-cookiecutter[2]https://wiki.openstack.org/wiki/Meetings/HorizonBest regards,Shu Muto> -----Original Message-> From: Thai Q Tran [mailto:tqt...@us.ibm.com]> Sent: Tuesday, November 15, 2016 4:30 AM> To: openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Horizon] ui-cookiecutter>> Hi Shuu,>> Sorry for the delay again, I just got back from vacation. I think your> cookiecutter will be useful in a number of ways.>> 1. We can use it to easily generate plugins for beginners> 2. We can use it in Horizon's startdash command (have to look into this)> for internal use>> Ideally, the project should be under an OpenStack repo so horizon drivers> can maintain it. Lets make it a point and bring it up at the horizon weekly> meeting. We can proceed after community feedback.>>> - Original message -> From: Shuu Mutou <shu-mu...@rf.jp.nec.com>> To: "openstack-dev@lists.openstack.org"> <openstack-dev@lists.openstack.org>> Cc: Haruhiko Katou <har-ka...@ts.jp.nec.com>> Subject: [openstack-dev] [Horizon] ui-cookiecutter> Date: Tue, Nov 8, 2016 1:24 AM>> Hi Horizoners,>> Thanks for picking up ui-cookiecutter[1] and setting Ocata-2> milestone at summit[2].> Thai or Cindy? Thank you!!>> I'm maintaining ui-cookiecutter, but I'm ready for transferring> it as Horizon subproject.>> Can I start to create subproject for ui-cookiecutter?> Or please let me know what I should do.>> [1] https://github.com/shu-mutou/ui-cookiecutter> [2] https://etherpad.openstack.org/p/horizon-ocata-priorities>> Regards,>> Shu Muto>>> __> > 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:unsubscribehttp://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] ui-cookiecutter

2016-11-14 Thread Thai Q Tran
Hi Shuu,
 
Sorry for the delay again, I just got back from vacation. I think your cookiecutter will be useful in a number of ways.
 
1. We can use it to easily generate plugins for beginners
2. We can use it in Horizon's startdash command (have to look into this) for internal use
 
Ideally, the project should be under an OpenStack repo so horizon drivers can maintain it. Lets make it a point and bring it up at the horizon weekly meeting. We can proceed after community feedback.
 
- Original message -From: Shuu Mutou To: "openstack-dev@lists.openstack.org" Cc: Haruhiko Katou Subject: [openstack-dev] [Horizon] ui-cookiecutterDate: Tue, Nov 8, 2016 1:24 AM 
Hi Horizoners,Thanks for picking up ui-cookiecutter[1] and setting Ocata-2 milestone at summit[2].Thai or Cindy? Thank you!!I'm maintaining ui-cookiecutter, but I'm ready for transferring it as Horizon subproject.Can I start to create subproject for ui-cookiecutter?Or please let me know what I should do.[1] https://github.com/shu-mutou/ui-cookiecutter[2] https://etherpad.openstack.org/p/horizon-ocata-prioritiesRegards,Shu Muto__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 
 


__
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-plugin]

2016-08-24 Thread Thai Q Tran
Hi Jason,
 
You should have access to it already. Just import from horizon the code you need. What you're looking for resides in the (request.user) object. Here are some usage examples, https://github.com/openstack/horizon/blob/master/openstack_dashboard/templatetags/context_selection.py
 
- Original message -From: Jason Pascucci To: "openstack-dev@lists.openstack.org" Cc:Subject: [openstack-dev] [horizon] [horizon-plugin]Date: Wed, Aug 24, 2016 12:05 PM    
Hi, 
  
What is the best method of obtaining the (name preferred) selected project (tenant) from the UI to pass to a plugin? 
  
-JRP 
  
  
__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
 


__
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

2016-07-20 Thread Thai Q Tran
You all sort of touched on what I am about to reiterate:
 
1. The scope was intended to be used as a way to propagate events up and down the chain (from table controller to step controller) since there was no real way to share information between controllers (remember that a modal dialog launches an entirely different fragment of HTML with no relationship to the current controller). Furthermore, we needed to use initScope to explicitly set the scope so that $modal does not use the $rootScope (which it does by default if scope is not set). As a side bonus, we were also able to use events to share data between the steps. The idea behind was to make steps independent and reusable in multiple workflows. The reality is that the event propagation required both an $emit and a $broadcast to actually share data between steps, this makes it much less desirable.
 
The root of the problem is, how does my table know to update once the form is submitted? Since then, a lot more work has been done in this area and I have not followed all of them (Matt and Tyr, feel free to chime in). I understand that Tyr made it so that events were no longer required, instead we can depend on promises via the result-handler function. This function gets triggered once the action is completed and would allow the table controller to do something after the action goes through. With the introduction of the generic table and registry, I am no longer certain how the data is updated in tables. If tables are notified of changes without the use of events, then the first step is to make this the standard.
 
2. Going with Richards idea of a shared workflow.model idea.
 
"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."
 
Event if we get rid of the events model completely, how are we planning on watching objects without scope? The main reason initScope existed is to act as a glue to allow sharing of data between the various controllers. This is the direct result of us using the $modal widget. While I agree that this introduces a sticky situation concerning the purity of services, I am unsure how we can resolve this.
 
I believe that the workflow should just be a list of steps. The model should instead reside in the create-volume service where it truly belongs. Each step can store a reference to the model and we are still able to poke/watch the data as Richard suggested.
 
To me there are two questions we should answer before we jump and do another rewrite.
1. How are we going to glue the various controllers together if we don't use scope.
2. How is data between the steps going to be shared.
 
I agree the solution we have isnt perfect, but at some point, we have to ask, is it good enough? And if it is, is it worth the cost of a rewrite when it can potentially break plugins and external code? To be clear, I am not against it, just adding my 2c.
 
- Original message -From: Richard Jones To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [Horizon] Angular action services and initScopeDate: Mon, Jul 18, 2016 3:05 PM 
On 18 July 2016 at 11:49, Rob Cresswell  wrote:

Maybe I'm missing the point, but the schema stuff just defines a model and passes it to the schema directive via ctrl; doesn't that remove any issues with workflows? ui-bootstraps modal and modalinstance already provides a way to pass that data back to the initial location (table etc) again
 
In a nutshell, yes this is the goal I'm aiming for, though some of the details might vary.
 
 
      Richard 
__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
 


__
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

2016-07-01 Thread Thai Q Tran
I am not sure if this is a valid concern. If I am using a CLI and someone gets access to my computer, they can do whatever they well please. If I am using Horizon and someone gets access, its going to be the same story, they can still do damage even without knowing the token (at least until the web session or token expires). This is just the nature of using token-based authentication, if someone steals it, they will get access for a brief time to do whatever they want. So the notion that hiding the token from the front-end is somehow going to make it safer does not make sense to me.
 
 
- Original message -From: Timur Sufiev To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS clientDate: Wed, Jun 29, 2016 2:11 PM 
Hello, vigilant folks of OpenStack Security team!
 
The commit(s) I'd like you to take a look at introduces a new Horizon feature, Create (Glance) Image using CORS (AKA Cross-Origin Resource Sharing) [1]. 
 
The main idea is to bypass Horizon web-server when uploading large local image and to send it directly to Glance server, thus saving network bandwidth and disk space on the controller node where Horizon web-server is deployed. However there is one possible security trade-off I had to make so that Glance service would allow me to upload an image - I'm passing the Keystone token to the Horizon JS runtime [2], and then pass it to Glance service [3] or [4] (different links here correspond to different versions of new Create Image - Django and Angular). This trade-off made Horizon community somewhat hesitant if we should push these changes forward, but nobody yet voiced a viable alternative, so here I'm writing this letter to you.
 
The usual Horizon workflow for working with Keystone tokens is the following: retrieve scoped token and put it into web-server session, which is itself not exposed to browser (unless SESSION_STORAGE signed_cookies backend was chosen, but even in that case session contents are encrypted in some way), but is kept on web-server and referenced using the session key which is kept in browser cookies - so one may say that in existing setup keystone token never leaks to browser.
 
On the other hand, in some not so far (I hope) future, when more logic is moved to client-side UI (i.e. browser), the issue of browser authenticating to some OpenStack services directly would become more widespread, it just happened that this work on Create Image in Horizon is pioneering this area (AFAIK). So, what do you think of possible security implications of this setup?
 
Just for the reference, three patches mentioned in [1-3] implement most of the logic of new Create Image feature.
 
[1] https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
[2] https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
[3] https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
[4] https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151
__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
 


__
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] [zaqar][zaqar-ui] Nomating Shu Muto for Zaqar-UI core

2016-06-07 Thread Thai Q Tran


Hello all,

I am pleased to nominate Shu Muto to the Zaqar-UI core team. Shu's reviews
are extremely thorough and his work exemplary. His expertise in angularJS,
translation, and project infrastructure proved to be invaluable. His
support and reviews has helped the project progressed. Combine with his
strong understanding of the project, I believe his will help guide us in
the right direction and allow us to keep our current pace.

Please vote +1 or -1 to the nomination.

Thanks,
Thai (tqtran)
__
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][keystone] Using JSON as future ACL format

2016-06-06 Thread Thai Q Tran


Hello all,

Hope everyone had a good weekend, and hope this email does not ruin your
next.
We had a small internal discussion at IBM and here are some of the findings
that I will present to the wider community.

1. The ":" separator that swift currently uses is not entirely safe since
LDAP can be configured to allow special characters in user IDs. It
essentially means no special characters are safe to use as separators. I am
not sure how practical this is, but its something to consider.

2. Since names are not guaranteed to be immutable, we should store
everything via IDs. Currently, for backward compatibility reasons, Swift
continues to support names for for V2. Keep in mind that V2 does not
guarantee that names are immutable either. Given this fact and what we know
from #1, we can say that names are mutable for both V2 and V3, and that any
separators we use are fallible. In other words, using a separator for names
or ids will not work 100% of the time.

3. Keystone recently enabled URL safe naming of project and domains for
their hierarchal work. As a by product of that, if the option is enabled,
Swift can essentially use the reserved characters as separators. The list
of reserved characters are listed below. The only question remaining, how
does Keystone inform Swift that this option is enabled? or Swift can add an
separator option that is a subset of the characters below and leave it to
the deployer to configure it.

";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | ","

https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284
http://www.ietf.org/rfc/rfc2396.txt

3. As mentioned in the KeystoneAuthACL write up in Atlanta, JSON format is
one of the option going forward. The article goes on to mention that we
should store only user IDs (avoiding the mutable names issue). It outlined
a process and reverse-process that would allow names to be use but
mentioned an overhead cost to Keystone. I personally think is the right
approach going forward since it negate the use of a separator altogether.

Whether we chose to store the user IDs or names as metadata is another
issue. But on a side note, I have tested this the changing names in V2 and
it has the same exact problem as V3. If we are allowing V2 to store names
[{ project, name }], I do not see why we should not allow the same for V3
[{ domain, project, name }].  This would remove the overhead cost to
Keystone. And of course, you still have the option to store things as IDs
[{ domain, project, id }].

https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3

My intention is to spark discussion around this topic with the goal of
moving the Swift community toward accepting the JSON format. Whether we
store it as names or ids can be a discussion for another time. If you made
it this far, thanks for reading! Your thoughts will be much appreciated.

Thanks,
Thai (tqtran)

__
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] Async file uploads in anew JS-centric UI

2016-05-17 Thread Thai Q Tran

Thanks for the great explanation Timur. I have bookmarked both and will
look into it shortly.



From:   Timur Sufiev 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   05/17/2016 10:38 AM
Subject:Re: [openstack-dev] [horizon] [javascript] Async file uploads
in anew JS-centric UI



Since 10 lines of code > 1000 words, here are references to 2 patch chains:

* New Swift UI file upload https://review.openstack.org/#/c/316143/
* New Angular Create Image file upload
https://review.openstack.org/#/c/317456/

I like Create Image solution more because it doesn't use Django csrf_exempt
and single FileField form hacks just to accept a binary stream on Django
side. So CORS offers us a shorter and more elegant solution to the task of
file uploads.

I got an off-ML feedback that the question / intention of original mail is
not clear. My intention / proposal is to adopt the approach used for
uploading files in Create Image workflow as the standard way for other
interactions (which include file uploads) between Web Clients and OpenStack
services.

On Sat, May 14, 2016 at 2:48 AM Timur Sufiev  wrote:
  Hello, fellow web developers!

  I'd like to share some of my thoughts and findings that I made during
  playing with ng-file-upload [1] for file uploads in Swift UI and Create
  Image wizard in Horizon (both Angular). Sorry for a long letter, couldn't
  put it shorter (TL;DR => go to CONCLUSION section).

  As a foreword: it's a really useful library, both for customizing
  stubborn  widget appearance (hello, themability!) and
  behavior and for the actual file transfer. More on the file transfer
  below, since it's the topic that really interests me.

  MAIN PART

  First, in modern browsers (by modern I mean HTML5 support and
  particularly FileReader API) you don't need a single-purposed library to
  upload file asynchronously, both jQuery $.ajax() and vanilla Angular
  $http calls support it - just pass File()/Blob() object as data (no
  wrapping {} please) and it works - browser transparently reads data chunk
  by chunk  from a local file system and sends it to the server. There is
  even a working solution for Django and jQuery-based 'Create Image' form
  [2]. There are a few subtleties though. Most importantly, there should be
  no other data (like other key-value pairs from form fields), just the
  file blob - and then the server endpoint must support raw byte stream as
  well. This rules out Django views which expect certain headers and body
  structure.

  (Second,) What ng-file-upload offers us to solve the challenge of file
  transfers? There are 2 methods in Upload service: .http() and .upload().
  First one is a very thin wrapper around Angular $http, with one
  difference that it allows to notify() browser of file upload progress
  (when just a single file blob is passed in .http(), as in case of $http()
  as well). The second method offers more features, like
  abortable/resumable uploads and transparent handling of data like {key1:
  value1, key2: value2, file: FileBlob}. Uploading such data is implemented
  using standard multipart/form-data content type, so actually, it's just a
  convenient wrapper around facilities we've already seen. Anyways it's
  better to just feed the data into Upload.upload() than to construct
  FormData() on your own (still the same is happening under the bonnet).

  Third, and most important point, we still have to couple Upload.http() /
  Upload.upload() with a server-side machinery. If it's a single file
  upload with Upload.http(), then the server must be able to work with raw
  binary stream (I'm repeating myself here). If it's a form data including
  file blob, it's easily handled on front-end with Upload.upload(), then
  the server must be able to parse multipart/form-data (Django perfectly
  does that). What's bad in this situation is that it also needs to store
  any sufficiently sized file in a web server's file system - which is both
  bug-prone [4] and suboptimal from performance POV. First we need to send
  a file (possibly GB-sized) from browser to web server, then from web
  server to the Glance/Swift/any other service host. So, blindly using
  Upload.upload() won't solve our _real_ problems with file uploads.

  CONCLUSION

  What can be done here to help JS UI to handle really large uploads? Split
  any API calls / views / whatever server things we have into 2 parts:
  lightweight JSON metadata + heavyweight binary stream. Moreover, use CORS
  for the second part to send binary streams directly to that data
  consumers (I know of 2 services atm - Glance & Swift, maybe there are
  more?). That will reduce the processing time, increasing the possibility
  that an operation will complete successfully before Keystone token
  expires :). IMO any new Angular wizard in Horizon should be designed with
  this thing in 

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

2016-03-11 Thread Thai Q Tran
Thanks David for your commitment and leadership. I learned a lot from you and your perspective on things. Looking forward to learn more from you and to work along side you into the foreseeable future. You are sticking around right? I still have TONS of questions to ask, JK :P
 
- Original message -From: Anita Kuno To: openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [horizon] PTL noncandidacyDate: Fri, Mar 11, 2016 1:18 PM 
On 03/11/2016 12:19 PM, 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>It has been a delight and honour to work with you in your role asHorizon PTL. I look forward to continuing to work with you as HorizonnonPTL.Thanks for your many cycles of hard work and dedication to the project.I really appreciate it.Thank you,Anita.__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 
 


__
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 tohorizon-core

2016-03-09 Thread Thai Q Tran
Big +1 from me, thanks for all the hard work Diana!
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-coreDate: Tue, Mar 8, 2016 2:07 PM 
I propose adding Diana Whitten[1] to horizon-core.Diana is an active reviewer, contributor and community member. Overthe past couple of releases, Diana has driven extensive changes aroundtheme-ability in Horizon and drastically increased the standardizationof our use of bootstrap. During this time, Diana has also providedvaluable reviews to keep us on the straight and narrow preventing ourcontinued 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:unsubscribehttp://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][Trove] Horizon-Trove External Repository

2016-02-15 Thread Thai Q Tran
Great article Andreas!
 
For angular translation to work, you'll need to reference https://github.com/openstack/horizon/blob/master/horizon/utils/babel_extract_angular.py which the guide already covers.
 
To use it, see https://angular-gettext.rocketeer.be/dev-guide/annotate/ for examples.
 
 
- Original message -From: Andreas Jaeger To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External RepositoryDate: Mon, Feb 15, 2016 2:44 AM 
On 2016-02-15 11:32, Omer (Nokia - IL) Etrog wrote:> Hi,> Is there proper documentation how to add localization for external plugins that use AngularJS?http://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructureNote that the translation team only translates official projects - andprioritizes there on what they do,Andreas-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany   GF: Felix Imendörffer, Jane Smithard, Graham Norton,       HRB 21284 (AG Nürnberg)    GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126__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
 


__
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] Handling 401 in new REST API

2016-01-28 Thread Thai Q Tran
I am assuming that you meant redirecting on the server side. We already have a similar one in place on the client side. https://github.com/openstack/horizon/blob/master/horizon/static/framework/framework.module.js#L65
 
Currently, you're not able to hit the REST layer directly anyway, You get a "request must be ajax" message. You have to login and then use a REST client if you want data. So here's my noob question of the day, what are we gaining in addition if we redirect on the server side? Totally not meant to be a show stopper, just wondering what the benefits are.
 
- Original message -From: David Lyle To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [Horizon] Handling 401 in new REST APIDate: Thu, Jan 28, 2016 8:46 AM 
I think that's the sane thing to do.DavidOn Thu, Jan 28, 2016 at 2:55 AM, Richard Jones  wrote:> Hi fellow angular/REST Horizon developers,>> I'd like to propose that we handle HTTP 401 responses at the core of the new> angular code interfacing to our new REST API so that *any* 401 just does> basically what the Django code used to: redirect to the login page with a> "from".>> What do y'all think?>>>     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:unsubscribehttp://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] Angular Views overriding

2016-01-25 Thread Thai Q Tran
Hello,
 
When we designed the architecture for the angular work, we had extension in mind. We have pretty good support for extending a workflow (see links below). We have a bunch of patches that when put together will do what you want, but no guide on how to do it. The documentation in Horizon is stalling because some of us prefer to nit pick then see any real progress.
 
https://review.openstack.org/#/c/252014/
This patch allows you to declare your columns inside of a controller instead of the HTML. It doesn't get you where you want yet, it still requires you to modify a static file.
 
https://review.openstack.org/#/c/214306/
This patch has already merged so it is available now. It allows you to arbitrarily inject your plugin/extension into a container. See video below on how to use it for a workflow. This same architecture can be applied to table columns.
 
Basically, most of what you want is there, but not currently documented. Currently, you will need do a bit more work on your end to get it working. Feel free to reach out to me on IRC (tqtran) or email (tqt...@us.ibm.com) if you are stuck somewhere.
 
Links below provide a more detailed explanation of how to extend a workflow.
 
Video tutorial on extending the workflow about 22 minute in:
https://www.youtube.com/watch?v=Km99BCHfBdk
 
And the patch containing the docs for it:
https://review.openstack.org/#/c/244407/2/doc/source/tutorials/workflow_extend.rst
 
 
- Original message -From: Yves-Gwenaël Bourhis To: openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [horizon] Angular Views overridingDate: Mon, Jan 25, 2016 7:50 AM 
Le 25/01/2016 12:27, Yves-Gwenaël Bourhis a écrit :> Hello All,>> I have a question regarding Horizon Angular views.>> My question is "Is there a way (and if so "a doc") of customizing (overriding) the current angular views without modifying the current static js and html files?"> With http://docs.openstack.org/developer/horizon/topics/customizing.html people who deploy horizon can easily modify some views without touching the horizon code, but what I would like to know if there is a provided mechanism to add some company specific columns in the angular launch-instance form (I want to add the prices of an instance per flavor, plus some extra flavor specific info, plus some flavor categories, plus category tabs for the images, etc...).s/what I would like to know if/what I would like to know is if/> For the moment the only method I found was either to be intrusive in the horizon code, either I had to have my app come first in installed apps and have the same static path and copy + modify all the angular specific html... :-/>> Is there a better way of doing so?>> If not, maybe a Blue-Print could be welcomed, because it's often necessary to have deployment specific overrides of the angular views made as easy as the python/django/horizon ones.>> Thanks all.>--Yves-Gwenaël Bourhis__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
 


__
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] Mid-cycle Sprint

2016-01-04 Thread Thai Q Tran
FYI, Cindy and I will put in a request for travel approval. Also, I have spoken to Mariam and would be willing to mentor David.
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [Horizon] Mid-cycle SprintDate: Mon, Dec 28, 2015 11:22 AM 
The Horizon mid-cycle sprint is in Hillsboro, Oregon Feb 23-25 andhosted at the Intel site in Hillsboro just west of Portland.The wiki for the mid-cycle sprint ishttps://wiki.openstack.org/wiki/Sprints/HorizonMitakaSprintPlease note your intention to attend on the wiki page.Thanks,David__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 
 


__
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 tohorizon-core

2015-12-03 Thread Thai Q Tran
An equally BIG +1 from me! Thanks for all the reviews and patches from your minions Richard!
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-coreDate: Wed, Dec 2, 2015 10:57 AM 
I propose adding Richard Jones[1] to horizon-core.Over the last several cycles Timur has consistently been providinggreat reviews, actively participating in the Horizon community, andmaking meaningful contributions around angularJS and overall projectstability 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:unsubscribehttp://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 Timur Sufiev tohorizon-core

2015-12-03 Thread Thai Q Tran
BIG +1 for me. Thanks for all of the great work Timur!
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-coreDate: Wed, Dec 2, 2015 10:54 AM 
I propose adding Timur Sufiev[1] to horizon-core.Over the last several cycles Timur has consistently been providinggreat reviews, actively participating in the Horizon community, andmaking meaningful contributions particularly around testing andstability.Please respond with comments, +1s, or objections within one week.Thanks,David[1] http://stackalytics.com/?module=horizon-group_id=tsufiev-x=all__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 
 


__
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][Trove] Horizon-Trove External Repository

2015-12-03 Thread Thai Q Tran
Hello Trovers and Horizoneers,
 
The intention of this email is to get everyone on the same page so we are all aware of what is going on. As many of you are probably already aware, Horizon is moving toward the plugin model for all of its dashboards (including existing dashboards). This release cycle, we are aiming to move Sahara and Trove into their own repository with joint ownership of the respective project. I have spoken to interested parties, Craig, and David about it and we are all in agreement. Ideally, this should help speed up the review process for Trove, as you now own part of the code and ownership.
 
Horizon still have some things we need to tidy up on our end to make sure we have full support for testing and localization for external plugins. We expect this to get resolve within the next few weeks. Work on excising the Trove code will begin this week so expect a patch for that soon! It would be ideal if we can merge existing Trove code before the excision happens. David has agreed to let these patches merge with one core vote if we have enough Trovers reviewing/reverifying them. So please help us help you.
 
David and Craig, if I left anything else out, feel free add to this. Otherwise, have a good xmas everyone. Looking to working with you all in the coming weeks.
 
Regard,
Thai (tqtran)
 


__
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] Update on Angular Identity work

2015-08-24 Thread Thai Q Tran
ns/actions on the table class.Option 1 seems better to me due to I find it closer to the current pattern. As long as we can reduce the duplicate code (not having to write 9 files to create one table), I'm good with that. :)My main concern is really to polish first the initial table implementation before folks jump into implementing the tables in all other panels. So we can avoid re-work, don't want another cycle of clean-up/refactor. :)I think we already have 2 angular tables out, should be enough data to figure out what duplicate code can be abstracted out based from those two implementation.-LinOn Thu, Aug 20, 2015 at 4:36 PM, Doug Fish the.doug.f...@gmail.commailto:the.doug.f...@gmail.com wrote:It appears to me that option 1 would be better prepared to be extensible ... That is if a plugin needed to add an action or a column, we could make that happen with pattern 1 (possibly after adding in a service) I'm not sure how plugins ever add these things with pattern 2.On Aug 20, 2015, at 1:41 PM, "Thai Q Tran" tqt...@us.ibm.commailto:tqt...@us.ibm.com wrote:Hi Lin,Let me draw on some examples to help clarify what I mean.Option 1:table.controller.jsctrl.headers = {gettext('column 1'),gettext('column 2')};ctrl.noItemMessage = gettext('You no longer have any items in your table. You either lack the sufficient priveledges or your search criteria is not valid');ctrl.batchActionList = [{ name: 'create', onclick: somefunction, etc }{ name: 'delete', onclick: somefunction, etc }];ctrl.rowActionList = [{ name: 'edit', onclick: somefunction, etc }{ name: 'delete', onclick: somefunction, etc }];table.html---div ng-controller="table.controller.js as ctrl"horizon-table headers="ctrl.headers" batch-actions="ctrl.batchActionList" row-actions="ctrl.rowActionList"/horizon-table/divSo now your controller is polluted with presentation and translation logic. In addition, we will have to live with long gettext messages and add eslint ignore rules just to pass it. The flip side is that you do have a simple directive that points to a common template sitting somewhere. It is not that much "easier" to the example below. What we're really doing is defining the same presentation logic, but in the HTML instead. Lastly, I'll bring up the customization again because many products are going to want to customize their tables. They maybe the minority but that doesn't mean we shouldn't support them.Option 2:table.htmltable ng-controller="table.controller.js as ctrl"theadtr action-list  action callback="someFunc" translateCreate/action  action callback="someFunc" translateDelete/action /action-list/trtr th translateColumn 1/th th translateColumn 2/th/tr/theadtbodytr ng-repeat="items in ctrl.items" td/td tdaction-list  action callback="someFunc" translateEdit/action  action callback="someFunc" translateDelete/action /action-list/td/tr/tbody/tableHere, your table.controller.js worries ONLY about data and data manipulation. The presentation logic all resides in the HTML. If I want to add icons in the table header, I can do that easily. Remember that this is plain HTML, this is a lot easier for someone new to come in and learn this than our special horizon-table directive. It is definitely easier to USE, but I would argue that it is harder to learn.--If you compare the two options above, you'll see that all we've really done is move presentation logic from the controller into the HTML. You have to define that logic somewhere, why not in the HTML? This makes it easier to read and know what you're going to see in the browser (something HTML5 spec is evangelizing), and you get the bonus benefit of customization.I'd like to point out that we aren't getting rid of directives, we're still using directives them (like action-list, action, magic-search, etc..) in our tables. The pattern is, you build your panels using smaller components instead of having one giant component that encapsulates everything. Of course, there isn't a right or wrong answer, in fact there are two very different implementations of a table directive out there right now:http://ng-table.com(more inline with option 1)http://lorenzofox3.github.io/smart-table-website/(more inline with option 2)Basically, what I'm trying to say is: let's build something simple and easy to understand first (small components that we work), then we can build something more complex on top of it so that it easier to use. I don't think there is a right or wrong answer, just two very different ways of thinking and implementation. But if we start with smaller components first, we get the goods of both world. The guys that want to customize will have a way to do it by bypassing the horizon-table directive, and the guys that just want a simple table can use the more complex directive.-Lin Hua Cheng os.lch...@gmail.commailt

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

2015-08-21 Thread Thai Q Tran
Hi Doug,I think your point is valid, but it would basically move the point of conflict from the HTML page to the controller. You could alleviate that problem by having services, aka service for headers, service for table batch action, etc that could then follow similar to the angular workflow plugin pattern we discussed at the midcycle https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin (Lin, this is how angular does inheritance).We would also need to follow up this work by enhancing some of the existing directives. Let's take the action-list directive as an example. Currently, you will have to list those actions out manually, so we would have to enhance it by allowing users to add in their own JSON list and have the directive render the full content. Theoretically, that should get us to a point where you can extend actions, workflows, and possibly even columns.Hi Lin,Basically, the problem that I am seeing is: we are trading semantic readability, customizability, and ease of LEARNING vs extensibility, complexity, and ease of USE. I agree that we should set a solid example before we let the flood gate open. This is a great discussion, now I'm more resolved to find a pattern that could give us more without the tradeoffs. We have a great community with many smart folks, I'm sure we'll figure something out.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 08/20/2015 09:45PMSubject: Re: [openstack-dev] [Horizon] Update on Angular Identity workHi Thai,From your example, option 1 seems closer to the *current pattern* not option 2. :) Where the user define a list of action separately from the table presentation (HTML template) rather than embedding it in the HTML. And if the user wants to extend it, they just add it to the list of columns/actions on the table class.Option 1 seems better to me due to I find it closer to the current pattern. As long as we can reduce the duplicate code (not having to write 9 files to create one table), I'm good with that. :)My main concern is really to polish first the initial table implementation before folks jump into implementing the tables in all other panels. So we can avoid re-work, don't want another cycle of clean-up/refactor. :)I think we already have 2 angular tables out, should be enough data to figure out what duplicate code can be abstracted out based from those two implementation.-LinOn Thu, Aug 20, 2015 at 4:36 PM, Doug Fish the.doug.f...@gmail.com wrote:It appears to me that option 1 would be better prepared to be extensible ... That is if a plugin needed to add an action or a column, we could make that happen with pattern 1 (possibly after adding in a service) I'm not sure how plugins ever add these things with pattern 2.On Aug 20, 2015, at 1:41 PM, "Thai Q Tran" tqt...@us.ibm.com wrote:Hi Lin,Let me draw on some examples to help clarify what I mean.Option 1:table.controller.jsctrl.headers = { gettext('column 1'), gettext('column 2')};ctrl.noItemMessage = gettext('You no longer have any items in your table. You either lack the sufficient priveledges or your search criteria is not valid');ctrl.batchActionList = [ { name: 'create', onclick: somefunction, etc } { name: 'delete', onclick: somefunction, etc }];ctrl.rowActionList = [ { name: 'edit', onclick: somefunction, etc } { name: 'delete', onclick: somefunction, etc }];table.html---divng-controller="table.controller.js as ctrl" horizon-table  headers="ctrl.headers"  batch-actions="ctrl.batchActionList"  row-actions="ctrl.rowActionList" /horizon-table/divSo now your controller is polluted with presentation and translation logic. In addition,we will have to live with long gettext messages and add eslint ignore rules just to pass it.The flip side is that you do have a simple directive that points to a common template sitting somewhere.It is not that much "easier" to the example below. What we're really doing is defining the same presentation logic, but in the HTML instead. Lastly,I'll bring up the customization again because many products are going to want to customize their tables. They maybe the minority but that doesn't mean we shouldn't support them.Option 2:table.htmltable ng-controller="table.controller.js as ctrl"thead tr  action-list   action callback="someFunc" translateCreate/action   action callback="someFunc" translateDelete/action  /action-list /tr tr  th translateColumn 1/th  th translateColumn 2/th /tr/theadtbody tr ng-repeat="items in ctrl.items"  td/td  tdaction-list   action callback="someFunc" translateEdit/action   action callback="someFunc" translateDelete/action  /action-list/td /tr/tbody/tableHere, your table.controller.js worries ONLY abou

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

2015-08-20 Thread Thai Q Tran
Hi Lin,Let me draw on some examples to help clarify what I mean.Option 1:table.controller.jsctrl.headers = { gettext('column 1'), gettext('column 2')};ctrl.noItemMessage = gettext('You no longer have any items in your table. You either lack the sufficient priveledges or your search criteria is not valid');ctrl.batchActionList = [ { name: 'create', onclick: somefunction, etc } { name: 'delete', onclick: somefunction, etc }];ctrl.rowActionList = [ { name: 'edit', onclick: somefunction, etc } { name: 'delete', onclick: somefunction, etc }];table.html---divng-controller="table.controller.js as ctrl" horizon-table  headers="ctrl.headers"  batch-actions="ctrl.batchActionList"  row-actions="ctrl.rowActionList" /horizon-table/divSo now your controller is polluted with presentation and translation logic. In addition,we will have to live with long gettext messages and add eslint ignore rules just to pass it.The flip side is that you do have a simple directive that points to a common template sitting somewhere.It is not that much "easier" to the example below. What we're really doing is defining the same presentation logic, but in the HTML instead. Lastly,I'll bring up the customization again because many products are going to want to customize their tables. They maybe the minority but that doesn't mean we shouldn't support them.Option 2:table.htmltable ng-controller="table.controller.js as ctrl"thead tr  action-list   action callback="someFunc" translateCreate/action   action callback="someFunc" translateDelete/action  /action-list /tr tr  th translateColumn 1/th  th translateColumn 2/th /tr/theadtbody tr ng-repeat="items in ctrl.items"  td/td  tdaction-list   action callback="someFunc" translateEdit/action   action callback="someFunc" translateDelete/action  /action-list/td /tr/tbody/tableHere, your table.controller.js worries ONLY about data and data manipulation. The presentation logic all resides in the HTML. If I want to add icons in the table header, I can do that easily. Remember that this is plain HTML, this is a lot easier for someone new to come in and learn this than our special horizon-table directive. It is definitely easier to USE, but I would argue that it is harder to learn.--If you compare the two options above, you'll see that all we've really done is move presentation logic from the controller into the HTML. You have to define that logic somewhere, why not in the HTML? This makes it easier to read and know what you're going to see in the browser (something HTML5 spec is evangelizing), and you get the bonus benefit of customization.I'd like to point out that we aren't getting rid of directives, we're still using directives them (like action-list, action, magic-search, etc..) in our tables. The pattern is, you build your panels using smaller components instead of having one giant component that encapsulates everything. Of course, there isn't a right or wrong answer, in fact there are two very different implementations of a table directive out there right now:http://ng-table.com (more inline with option 1)http://lorenzofox3.github.io/smart-table-website/ (more inline with option 2)Basically, what I'm trying to say is: let's build something simple and easy to understand first (small components that we work), then we can build something more complex on top of it so that it easier to use. I don't think there is a right or wrong answer, just two very different ways of thinking and implementation. But if we start with smaller components first, we get the goods of both world. The guys that want to customize will have a way to do it by bypassing the horizon-table directive, and the guys that just want a simple table can use the more complex directive.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 08/19/2015 05:15PMSubject: Re: [openstack-dev] [Horizon] Update on Angular Identity workHi Thai,Thanks for investigating the two options.Option 2 might be better. Folks have to learn the new pattern of writing multiple files, so I think the learning curve for a new table directive is not that much of a difference.I think option 2 is going to be easier to maintain, since we have a layer of abstraction. It might even also increase adoptability since it would be easier to use. It might be harder to customize, but that would probably not be done often. The table directive would be used as is most of the time.My thought is design the code to be easy to use for the use case that will be used most of the time rather than the customization case which maybe harder to do. Which leads me to preferring option 2.Thanks,LinOn Wed, Aug 19, 2015 at 12:16 PM, Thai Q Tran tqt...@us.ibm.com wrote:

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

2015-08-19 Thread Thai Q Tran
Hi Lin,I agree with you and Eric that we have a lot of HTML fragments. Some of them I think make sense as directives:The table footer is a good example of something we can convert into a directive:https://review.openstack.org/#/c/207631/The table header on the other hand is something more specific to your table:https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table/table-header.htmlSo there are two approaches we can take here:1. Keep some of the presentation related data in the HTML: mainly things like table headers, column definitions, translated texts, etc... I like this approach a bit more because it allow us to read the HTML and know exactly what we are expecting to see. This table.html is compose of smaller directives like hz-table-footer and regular html tags like th and td etc... I think as we have more of these smaller directives available, we can combine the fragments into one file.2. We could create a more general table directive with a common template. This is more inline with what we have currently for legacy. BUT the presentation logic like translations, definitions would now have to reside in the table controller AND we lose the semantic readability part. Doing it this way could potentially introduce more complexity as it now requires people to learn the table directive, which could be very complex if it does not use smaller directives. Another common problem we encountered with this pattern was a lack of customization. In legacy, it was pretty hard to add an icon into a table cell. If we go down this route, I believe we might start to encounter the same issues.In summary, we are working on addressing the HTML fragments, but I think we as a community should go with option 1 and stay away from option 2.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 08/18/2015 02:36PMCc: Vince Brunssen/Austin/IBM@IBMUSSubject: Re: [openstack-dev] [Horizon] Update on Angular Identity workI think the table setup pattern have some opportunity for reducing code duplication before it gets re-used by other panels.. We used to just need to write one file to define a table, now we have to write 9 files [1]. Can we have a table directive to reduce the duplicated code before moving forward to other panels?-Lin[1] https://github.com/openstack/horizon/tree/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/tableOn Tue, Aug 18, 2015 at 11:49 AM, Thai Q Tran tqt...@us.ibm.com wrote:Hi everyone,Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements:1. reusable and possibly pluggable2. easy to understand3. reduce code duplicationThese requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work.a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch:https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin.b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature.c. I believe we have a pretty good pattern setup for tables. The final piece of the puzzle was the patterns for various actions. We have wizard (create user), form (edit user), confirmation dialog (delete user), and actions with no modal dialog (enable user). We wanted a general pattern that would address the requirements mentioned above. There were some discussions around extensibility at the midcycle that I think will fit well here as well ( https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ). The actions can follow a similar pattern to workflow. I believe this pattern would address #1 and #3 but making it easy to understand is a bit challenging - I think this is where documentation could help.https://review.openstack.org/#/c/202315/ and a few other patches are going to be ready for review soon (sometime end of this week)!Item #c is the most important piece, it is going to be the general pattern that people will us

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

2015-08-18 Thread Thai Q Tran
Hi everyone,Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements:1. reusable and possibly pluggable2. easy to understand3. reduce code duplicationThese requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work.a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch:https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin.b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature.c. I believe we have a pretty good pattern setup for tables. The final piece of the puzzle was the patterns for various actions. We have wizard (create user), form (edit user), confirmation dialog (delete user), and actions with no modal dialog (enable user). We wanted a general pattern that would address the requirements mentioned above. There were some discussions around extensibility at the midcycle that I think will fit well here as well ( https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ). The actions can follow a similar pattern to workflow. I believe this pattern would address #1 and #3 but making it easy to understand is a bit challenging - I think this is where documentation could help.https://review.openstack.org/#/c/202315/ and a few other patches are going to be ready for review soon (sometime end of this week)!Item #c is the most important piece, it is going to be the general pattern that people will use to build their angular panels with, so the more eyes we can get on it, the better.My aim is to get it in before the feature freeze and I think that is entirely possible with your help. So please help review even if you are not a core!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


Re: [openstack-dev] [Keystone] [Horizon] Federated Login

2015-08-05 Thread Thai Q Tran
 text/html; charset=UTF-8: Unrecognized 
__
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] [Openstack][Horizon] Sharable Angular mock

2015-07-20 Thread Thai Q Tran

Love the idea, great explanation! I see value in this going forward.
Definitely interested.



From:   Chen, Shaoquan sean.ch...@hp.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   07/19/2015 05:34 PM
Subject:[openstack-dev] [Openstack][Horizon] Sharable Angular mock



Currently random mock objects are created inside of spec files to make
writing unit tests easier. This approach works but has some drawback:

  *   mocks are not sharable between specs.
  *   mocks are usually too simple.
  *   mocks may not be consistent between spec files.
  *   mocks are not tested theme self.
  *   hard to maintain and manage.

In order to make it easy for developers to write high quality unit tests
and e2e test, we want a set of high-quality mock objects. To make its easy
to maintain:

  *   mocks should reside in ``.mock.js`` files and be loaded only in test
runner page
  *   mocks should be loaded after production code files, before spec code
files.
  *   mocks should be sharable between specs.
  *   mocks are not belong to specs, they should have a 1:1 relationship
with the object it try to mock.
  *   mocks should be at a level as low as possible, maybe where JavaScript
cannot reach directly.
  *   mocks must be tested theme self.
  *   mocks should be easy to find, use and manage.

I drafted a simple BP at
https://blueprints.launchpad.net/horizon/+spec/horizon-angular-mocks to
summaries the issue existing in Horizon IMO and how I could see to fix
them. I also setup two patches to prove the concept at:

  *   https://review.openstack.org/#/c/202817/
  *   https://review.openstack.org/#/c/202830/

This mock is for the window object and another could be
OpenStackHtttpBackend which mimic all the behaviors of Horizon Web
services. As you can see, the window mock object can be easily applied to a
bug Tyr fixed recently so that the spec code do not need to create an
inline mock object. Because those shared mock are independent from specs,
they can be more neutral and can have much more features than a over
simplified mock for a specific test.

Please let me know if this interested you.

Thanks,
Sean

__
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] Angular dependencies and the hz.dashboard namespace

2015-06-19 Thread Thai Q Tran
Heres a summary of what we talked about:1.Need to retain the same file structure so that pluggins continue to work.Example:https://github.com/stackforge/monasca-ui/tree/master/monitoringBasically we have existing pluggins that use this file structure, we need to honor it.This is not directly related to what we are talking about, but it does mean that we need to move static files out of/openstack_dashboard/static/MYDASHBOARD/* and into/openstack_dashboard/dashboards/MYDASHBOARD/static/*2.Auto-discovery of static resources will need to also honor the pluggin model above, hence the file structure above.You will still need to manually define the ADD_ANGULAR_MODULES in your enabled file, auto-discovery doesn't know what you want enabled.Sean's patch is going to do that, but having some issues with SCSS.https://review.openstack.org/#/c/191592/3.hz.dashboard module will be empty because the hz.dashboard.MYDASHBOARD module will live at the app level viaADD_ANGULAR_MODULES. I would argue that it makes no sense to have an empty module, my preference is to just delete it.Constants are globally available in the app, something I think actually should be avoided, not encouraged.4.Having hz.dashboard.tech-debt and workflow in the enabled file is not correct.They are core components needed by all dashboards and should be loaded by default, not via the pluggin mechanism.https://review.openstack.org/#/c/193401/4/openstack_dashboard/enabled/_10_project.pyLets say I have my own dashboard call MYDASHBOARD, and I decided to disable all other dashboards except mine,all of a sudden, things will break horribly because tech-debt and workflow are not loaded. I would have to either:a. load the _10_project enabled fileb. copy/paste over the dependencies from _10_projectFurthermore, if I have hz.dashboard module, where do I load that, in _10_project or _x_MYDASHBOARD?Same issue when I disable entire dashboards.Tyr's patch will address this problem by having a core module.https://review.openstack.org/#/c/193681/-Richard Jones r1chardj0...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Richard Jones r1chardj0...@gmail.comDate: 06/19/2015 03:49PMSubject: [openstack-dev] Angular dependencies and the hz.dashboard namespaceThe "Adding Angular Identity Dashboard"[1] patch exposed an issue I saw previously that worried me[2].I believe during recent Horizon work the concept of angular module namespaces and dependencies have been conflated. There's this idea that if you create a submodule inside a module namespace you *must* have that module depend on that submodule. I believe that is incorrect - just look at the angular codebase itself, and how it is used. If you want the ngCookies module in a couple of places then you have those modules depend on ngCookies (or, more likely, you just add it as a dependency to the app). The point is it's not just added automatically to the "ng" module as a dependency. If you need to use a module's functionality, you depend on the module. You don't just have all your modules *automatically* pulled in as dependencies. I have proposed a patch to remedy this for the existing "optional"[3] project dashboard[4].I believe it is unnecessary to add extension of the hz.dashboard dependency list[5] since we already have an extensible dependency list for the application itself (which the hz.dashboard dependency list just extends).To answer the question explicitly raised "what is the point of having the hz.dashboard module if it has no dependencies?" It does two things: it defines the namespace in a formal manner (by itself unnecessary, but it's still nice to do) and it defines a constant which is used by other code. Eventually it may define more. There is an important difference between Python modules and Angular modules here - using a Python module like hz.dashboard in this way could cause problems because of the way Python sub-module namespaces and import ordering work. Angular's modules work very differently, and are not burdened by the same issues. In Python that constant would most likely have to be pushed out to a sub-module to avoid import loops.  Richard[1]https://review.openstack.org/190852[2]https://bugs.launchpad.net/horizon/+bug/1466713[3] There may be other issues that prevent the project dashboard being optional - there are dependencies in Python-land from the admin dashboard hard-coded over to the project dashboard, for example. It might be a good idea to remedy that, since I think it probably exposes some other structural issues in the plugin mechanism we're providing to deployers.[4]https://review.openstack.org/#/c/193401/[5]https://review.openstack.org/193671
__OpenStack Development Mailing List (not for usage questions)Unsubscribe: 

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

2015-06-17 Thread Thai Q Tran
I agree with Rob in terms of tooling and with Travis on rules.Any linting tool is fine with me as long as it does not break the rules we currently have set in Horizon. I believe the rules right now are general enough, so switching to eslint might not be an issue, but its something to look into. And we are still early in the JSCS stages, so this is actually opportune timing. I don't have a strong opinion on which tool so as long as it gets the job done and does not stall work in Horizon for liberty.-Michael Krotscheck krotsch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Michael Krotscheck krotsch...@gmail.comDate: 06/16/2015 12:30PMSubject: Re: [openstack-dev] [_javascript_] [horizon] [merlin] [refstack] _javascript_ LintingOn Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S travis.tr...@hp.com wrote:I think agreeing on rules is the bigger problem here and I dont think all
the projects should have to agree on rules.I believe we agree there, mostly. I personally feel there is some benefit to setting some rules, likely published as an openstack linting plugin, which enforce things like "Do not use fuzzy versions in your package.json" and other things that make things unstable. That should be a very carefully reserved list of rules though.I've created an eslint configuration file that includes every single rule, it's high level purpose, and a link to the details on it, and provided it in a patch against horizon. The intent is that it's a good starting point from which to activate and deactivate rules that make sense for horizon.https://review.openstack.org/#/c/192327/Weve spent a good portion ofliberty 1 getting the code base cleaned up to meet the already adoptedhorizon rules and it is still in progress.As a side note, the non-voting horizon linting job for _javascript_ things is waiting for review here:https://review.openstack.org/#/c/16/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 cant do this at the expense of the entire
liberty release.Again, I agree. The patch I've provided above sets up the horizon eslint build, and adds about... 10K additional style violations. Since neither of the builds pass, it's difficult to see the difference, yet either way you should probably tweak the rules to match horizon's personal preferences.Michael
__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


__
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][i18n] Ordering of PO files

2015-06-09 Thread Thai Q Tran
Ok, thats good to hear! Thanks Akihiro for the clarification.Andreas, I believe we can rewire the --makemessages command to use Babel, so script update will not be required.-Andreas Jaeger a...@suse.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Andreas Jaeger a...@suse.comDate: 06/09/2015 12:03AMSubject: Re: [openstack-dev] [horizon][i18n] Ordering of PO filesOn 06/09/2015 01:28 AM, Thai Q Tran wrote: Hi folks, In the midst of shifting to angular, we are making use of babel for extracting messages. This would then allow us to write a custom extractor for angular templates. Here's the patch that compare PO files: https://review.openstack.org/#/c/189502/ It looks worse than reality, if you compare the django vs babel makemessages, they are nearly identical, only the ordering is different. Which leads me to my next point. If the ordering of the translatable strings are not the same, how does that affect translation (if at all)?It doesn't.Our tools always sort the entries, we call for all files:msgattrib --translated --no-location --sort-output "$i" \  --output="${i}.tmp"Please use the same commands for generation as our tools. For horizon see http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/propose_translation_update_horizon.shAndreas-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,   HRB 21284 (AG Nürnberg)  GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126__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


__
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][i18n] Ordering of PO files

2015-06-08 Thread Thai Q Tran
Hi folks,In the midst of shifting to angular, we are making use of babel for extracting messages. This would then allow us to write a custom extractor for angular templates.Here's the patch that compare PO files:https://review.openstack.org/#/c/189502/It looks worse than reality, if you compare the django vs babel makemessages, they are nearly identical, only the ordering is different.Which leads me to my next point. If the ordering of the translatable strings are not the same, how does that affect translation (if at 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


Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

2015-06-04 Thread Thai Q Tran
I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions.-"Steven Dake (stdake)" std...@cisco.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: "Steven Dake (stdake)" std...@cisco.comDate: 06/04/2015 11:03AMSubject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Hey folks,


I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work.


I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors.  If your interested, please chime in on this thread.


As far as how to get patches approved, there are two models we can go with.


Option #1:
We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission.


Option #2:
We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isnt large enough to get reviews in. I suspect Option #2 will be difficult to execute.


Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results.


Regards
-steve
__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


__
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] Prioritize tests over JSCS

2015-06-04 Thread Thai Q Tran
Hi folks,I know a lot of people are tackling the JSCS stuff, and thats really great. But it would be extra nice to see JSCS stuff along with JP's guidelines in your patches. Furthermore, if the file you are working on doesn't have an accompanying spec file, please make sure that the tests for it exists. If it is not there, please prioritize and spend some time reviewing patches with the tests you need, or create a spec file and get that merge first.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-dev] [horizon] Angular-Django i18n

2015-05-28 Thread Thai Q Tran
Hi folks,Just drafted a blueprint on this topic so that we can all be on the same page. Its quite long, but hopefully you will take some time to read through it and provide some meaningful feedback. In the mean time, I will do some more investigation and keep you all posted. If you have questions or concerns, please contact me in IRC or post it in the comment section of the blueprint.Link to blueprint:https://blueprints.launchpad.net/horizon/+spec/angular-makemessagesThanks,Thai


__
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

2015-05-27 Thread Thai Q Tran
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.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: "Rob Cresswell (rcresswe)" rcres...@cisco.comDate: 05/26/2015 11:29PMSubject: 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.


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


Rob


From: Richard Jones r1chardj0...@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 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.org
Cc: "Johanson, Tyr H" 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 framework component, so I think should stay there. I'm not sure whether anyone would ever wish to override this. Also the bulk of it is probably going to be replaced by the toast implementation anyway... hmm...
- horizon/common/_sidebar.html
 This is an overridable component that I think should move.
-horizon/common/_page_header.html
 This is an overridable component that I think should move.
-horizon/_scripts.html

 Yep, should move.Thoughts, anyone who has read this far?
  Richard


On Sat, 23 May 2015 at 11:46 Richard Jones r1chardj0...@gmail.com wrote:


As part of the ongoing Horizon project code reorganisation, we today agreed to clean up the Horizon-the-Framework and OpenStack Dashboard separation issue by doing a couple of things:


1. nuke (the recently-created) horizon dashboard-app by moving the angular app over to dashboard and the other contents to appropriate places (mostly under the heading of "tech-debt" :)
2. move base.html, _conf.html and _scripts.html from horizon over to dashboard.


Thanks to Cindy, Sean and Thai for the pair (er triple?) programming keeping me honest today.


The first step is done and captured in several linked patches based off your leaf patch "ngReorg - Create dashboard-app" https://review.openstack.org/#/c/184597/ (yes, I am nuking
 the thing created by your patch).


I've not done the second step, but might find some time since I have 6 hours to waste in LAX tomorrow.


  Richard
__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


__
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

2015-05-26 Thread Thai Q Tran
Looks/sounds good, I started down this path a while ago and it never gained traction, so glad to see that it is finally moving along.-Richard Jones r1chardj0...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Richard Jones r1chardj0...@gmail.comDate: 05/25/2015 05:38PMCc: "Johanson, Tyr H" t...@hp.comSubject: Re: [openstack-dev] [Horizon] dashboard-app split in horizonAs 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, and2. 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 framework component, so I think should stay there. I'm not sure whether anyone would ever wish to override this. Also the bulk of it is probably going to be replaced by the toast implementation anyway... hmm...- horizon/common/_sidebar.html This is an overridable component that I think should move.-horizon/common/_page_header.html This is an overridable component that I think should move.-horizon/_scripts.html Yep, should move.Thoughts, anyone who has read this far?  RichardOn Sat, 23 May 2015 at 11:46 Richard Jones r1chardj0...@gmail.com wrote:As part of the ongoing Horizon project code reorganisation, we today agreed to clean up the Horizon-the-Framework and OpenStack Dashboard separation issue by doing a couple of things:1. nuke (the recently-created) horizon dashboard-app by moving the angular app over to dashboard and the other contents to appropriate places (mostly under the heading of "tech-debt" :)2. move base.html, _conf.html and _scripts.html from horizon over to dashboard.Thanks to Cindy, Sean and Thai for the pair (er triple?) programming keeping me honest today.The first step is done and captured in several linked patches based off your leaf patch "ngReorg - Create dashboard-app" https://review.openstack.org/#/c/184597/ (yes, I am nuking the thing created by your patch).I've not done the second step, but might find some time since I have 6 hours to waste in LAX tomorrow.  Richard
__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


__
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

2015-04-28 Thread Thai Q Tran
Welcome to the team Doug, Rob, and Travis!!!-David Lyle dkly...@gmail.com wrote: -To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgFrom: David Lyle dkly...@gmail.comDate: 04/28/2015 04:00PMSubject: [openstack-dev]  [Horizon] Core Reviewer UpdateI 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:unsubscribehttp://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] Outreachy call for mentor

2015-04-22 Thread Thai Q Tran

Hi Victoria,

Count me in also. I'll go ahead and subscribe myself to the mailing list as
well.



From:   Victoria Martínez de la Cruz victo...@vmartinezdelacruz.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   04/22/2015 06:10 PM
Subject:Re: [openstack-dev] [Horizon] Outreachy call for mentor



Hi David,

Thanks a lot for your quick response! I'll give you more details about the
applicant in a follow up email or in IRC.

Certainly having separate wikis is not practical sometimes, so Stefano has
been working on centralize all the information wrt internships and
mentoring opportunities in OpenStack. There is a new mailing list you can
subscribe to
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-internships.

Again, thanks.

Victoria

2015-04-22 21:51 GMT-03:00 David Lyle dkly...@gmail.com:
  I added my name to an openstack wiki page for this express purpose some
  time ago, apparently the wrong one, which I can find no reference to now.

  That said, I am willing to be a mentor for a Horizon focused intern, if
  inability to find the correct wiki pages isn't a limiting factor.

  David

  On Wed, Apr 22, 2015 at 6:31 PM, Victoria Martínez de la Cruz 
  victo...@vmartinezdelacruz.com wrote:
   Hi all,

   Horizon folks, we have a really good Outreachy candidate interested in
   working with you. The internship is from May 25th to August 25th, and
   interns are expected to work full time on their projects. Being a mentor
   should not be time consuming, we expect interns to be able to do their
   tasks independently and to solve the blockers they might find with the
   help of the community. I will be mentoring an applicant this round and,
   if time is a problem, I offer to help with this applicant as well.

   The announcement of accepted participants is soon, so this is a real
   last minute call.

   Outreachy is an internship targeted to anyone who identifies as a woman
   and OpenStack has been participating on it for about two years now. We
   had really good participants and many important features had been added
   as part of this program. For more details on OpenStack participation on
   Outreachy, check out the OpenStack Outreachy wiki page [0] and the
   Outreachy official site [1].

   If you decide you want to mentor, please reach me and I'll guide you
   through the process.

   Please, let me know if you have any doubt or concern.

   Thanks all,

   Victoria

   [0] https://wiki.openstack.org/wiki/Outreachy
   [1] https://wiki.gnome.org/Outreachy

   __

   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][keystone]

2015-02-05 Thread Thai Q Tran
Hi Ioram,Thanks for the feedback. I agree that the names are hard to follow, they can change to something more intuitive. Or we can even provide a tooltip for more information.As for the look and feel, I don't agree that its easier if all the options are listed. Image if you had 5 different ways for users to log in and they are all shown at once. That's a lot to take in.This approach keep things simply, it's really not that hard to pick from a list.Hi Anton,I'm just building on top of the visuals we already have without changing things too drastically. If you have a better idea, I would love to see it.-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Ioram Schechtman Sette i...@cin.ufpe.brDate: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Thai,I agree with Anton that the names are not intuitive for users.I would use something like:- Local authentication (for local credentials)- ?? (I also have no idea of what is a Default protocol)- Authenticate using name of IdPs or federation (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP)Here in the University of Kent we used another approach.Instead of selecting the method using a "list/combo" box, we present all the options in a single screen.I think it's not beautiful, but functional.I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted).Regards,Ioram2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:Hi,I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service".The proposed UI is rather embarrassing.AntonOn Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
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:unsubscribehttp://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][keystone]

2015-02-05 Thread Thai Q Tran
Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis marek.de...@cern.ch wrote: -To: openstack-dev@lists.openstack.orgFrom: Marek Denis marek.de...@cern.chDate: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone]
  

  
  
Thai,
  
  We could also add an option in the Horizon's settings that
  automatically chooses one authentication workflow. At CERN we are
  trying to use websso with use of the SAML2 protocols as much as we
  can. That's said we automatically make users to use websso when
  they want to access their accounts via the dashboard. 
  
  Hint: This is being done by automatic redirect to predefined
  Keystone endpoint once user hits our dashboard's URL).
  
  Marek
  
  
  On 05.02.2015 20:15, Thai Q Tran wrote:


  
  Hi Ioram,
Thanks for the feedback. I agree that the names are hard to
follow, they can change to something more intuitive. Or we can
even provide a tooltip for more information.
As for the look and feel, I don't agree that its easier if all
the options are listed. Image if you had 5 different ways for
users to log in and they are all shown at once. That's a lot to
take in.
This approach keep things simply, it's really not that hard to
pick from a list.

Hi Anton,
I'm just building on top of the visuals we already have without
changing things too drastically. If you have a better idea, I
would love to see it.

-Ioram Schechtman Sette
  i...@cin.ufpe.br wrote: -

  To: "OpenStack Development Mailing List (not for
usage questions)" openstack-dev@lists.openstack.org
From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]


  

  

  

  
Hi Thai,
  
  I agree with Anton that the names are not
  intuitive for users.
  

I would use something like:
  
  - Local authentication (for local credentials)

- ?? (I also have no idea of what is a Default
protocol)
  
  - Authenticate using name of IdPs or
  federation (something which is easy to the
  user understand that he could use or not - this is
  for the discovery service or remote IdP)
  

Here in the University of Kent we used another
approach.
  
  Instead of selecting the method using a "list/combo"
  box, we present all the options in a single screen.

I think it's not beautiful, but functional.
  
  I think it would be easier to the user if they could have
  all the options in a single interface, since it doesn't
  become too much loaded (visually polluted).
  
  
  

  
Regards,
  Ioram


  

  

  

  

  2015-02-05
9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:

  Hi,


I guess "Credentials"
  is login and password. I
  have no idea what is
  "Default Protocol" or
  "Discovery Service".
The proposed UI is
  rather embarrassing.


Re: [openstack-dev] [horizon] JavaScript docs?

2015-02-04 Thread Thai Q Tran
As we're moving toward Angular, might make sense for us to adopt ngdoc as well.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 02/04/2015 05:42AMSubject: [openstack-dev] [horizon] _javascript_ docs?In python we have a style to document methods, classes, and so forth. But, I don't see any guidance on how _javascript_ should be documented. I was looking for something like jsdoc or ngdoc (an extension of jsdoc). Is there any guidance on how _javascript_ should be documented?For anyone who doesn't know, Angular uses ngdoc (an extension to the commonly used jsdoc) which is written up at https://github.com/angular/angular.js/wiki/Writing-AngularJS-Documentation.
__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


__
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][keystone]

2015-02-04 Thread Thai Q Tran
Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
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] function expressions vs function declarations in JavaScript

2015-01-14 Thread Thai Q Tran
Wow, that IS interesting. No process required, just modify /horizon/doc/source/contributing.rst and submit a patch.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 12:20PMSubject: Re: [openstack-dev] [horizon] function expressions vs function declarations in _javascript_Thai, I'm still poking around at _javascript_ things and did a little testing on function declarations vs function expressions. Seems Firefox is faster with function expressions by quite a bit at parse time. For reference see http://jsperf.com/mfer-function-types.I'm not suggesting what we do. I'm just sharing a data point I found surprising.I'm curious about the process for proposing changes to https://wiki.openstack.org/wiki/Horizon/_javascript_. Is there any process?On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran tqt...@us.ibm.com wrote:It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it.For me, function declarations can get convoluted very fast if not use correctly.Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement.But they do have their uses when used correctly.I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions.As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 07:04AMSubject: [openstack-dev] [horizon] function expressions vs functiondeclarations in _javascript__javascript_ has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions).In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/_javascript_.Thanks,Matt
__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


__
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:unsubscribehttp://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] function expressions vs function declarations in JavaScript

2015-01-14 Thread Thai Q Tran
It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it.For me, function declarations can get convoluted very fast if not use correctly.Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement.But they do have their uses when used correctly.I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions.As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 07:04AMSubject: [openstack-dev] [horizon] function expressions vs function	declarations in _javascript__javascript_ has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions).In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/_javascript_.Thanks,Matt
__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


__
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] REST and Django

2014-12-12 Thread Thai Q Tran
In your previous example, you are posting to a certain URL (i.e./keystone/{ver:=x.0}/{method:=update}).client: POST /keystone/{ver:=x.0}/{method:=update} = middleware: just forward to clients[ver].getattr("method")(**kwargs) = keystone: updateCorrect me if I'm wrong, but it looks like you have a unique URL for each /service/version/method.I fail to see how that is different than what we have today? Is there a view for each service? each version?Let's say for argument sake that you have a single view that takes care of all URL routing. All requests pass through this view and contain a JSON that contains instruction on which API to invoke and what parameters to pass.And lets also say that you wrote some code that uses reflection to map the JSON to an action. What you end up with is a client-centric application, where all of the logic resides client-side. If there are things we want to accomplish server-side, it will be extremely hard to pull off. Things like caching, websocket, aggregation, batch actions, translation, etc What you end up with is a client with no help from the server.Obviously the other extreme is what we have today, where we do everything server-side and only using client-side for binding events. I personally prefer a more balance approach where we can leverage both the server and client. There are things that client can do well, and there are things that server can do well. Going the RPC way restrict us to just client technologies and may hamper any additional future functionalities we want to bring server-side. In other words, using REST over RPC gives us the opportunity to use server-side technologies to help solve problems should the need for it arises.I would also argue that the REST approach is NOT what we have today. What we have today is a static webpage that is generated server-side, where API is hidden from the client. What we end up with using the REST approach is a dynamic 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.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Tihomir Trifonov t.trifo...@gmail.comDate: 12/12/2014 04:53AMSubject: Re: [openstack-dev] [horizon] REST and DjangoHere'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 situationThat'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, helpedby specs now) and the service team takes on the burden of exposing aprogrammatic way to access the API. This is tested and easily consumablevia the python clients, which removes some guesswork from using theservice.True. But what if the service team modifies a method signature from let's say:def add_something(self, request, field1, field2):todef 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.com wrote:I just re-read and I apologize for the hastily written email I previously
sent. Ill 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.com wrote
(REVISED):

Tihomir,

Your comments in the patch were very helpful for me to 

Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboard

2014-12-12 Thread Thai Q Tran
As is the case with anything we change, but that should not stop us from making improvements/progress. I would argue that it would make life easier for them since all scripts are now in one place.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 12/12/2014 10:28AMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardConsolidating them would break it for users that have customization and extension on the two templates.-LinOn Fri, Dec 12, 2014 at 9:20 AM, David Lyle dkly...@gmail.com wrote:Not entirely sure why they both exist either.So by move, you meant override (nuance). That's different and I have no issue with that.I'm also fine with attempting to consolidate _conf and _scripts.DavidOn Thu, Dec 11, 2014 at 1:22 PM, Thai Q Tran tqt...@us.ibm.com wrote:It would not create a circular dependency, dashboard would depend on horizon - not the latter.Scripts that are library specific will live in horizon while scripts that are panel specific will live in dashboard.Let me draw a more concrete example.In HorizonWe know that _script and _conf are included in the base.htmlWe create a _script and _conf placeholder file for project overrides (similar to _stylesheets and _header)In DashboardWe create a _script and _conf file with today's contentIt overrides the _script and _conf file in horizonNow we can include panel specific scripts without causing circular dependency.In fact, I would like to go further and suggest that _script and _conf be combine into a single file.Not sure why we need two places to include scripts.-David Lyle dkly...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: David Lyle dkly...@gmail.comDate: 12/11/2014 09:23AMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardI'm probably not understanding the nuance of the question but moving the _scripts.html file to openstack_dashboard creates some circular dependencies, does it not? templates/base.html in the horizon side of the repo includes _scripts.html and insures that the _javascript_ needed by the existing horizon framework is present._conf.html seems like a better candidate for moving as it's more closely tied to the application code.DavidOn Wed, Dec 10, 2014 at 7:20 PM, Thai Q Tran tqt...@us.ibm.com wrote:Sorry for duplicate mail, forgot the subject.-Thai Q Tran/Silicon Valley/IBM wrote: -To: "OpenStack Development Mailing List \(not for usage questions\)" openstack-dev@lists.openstack.orgFrom: Thai Q Tran/Silicon Valley/IBMDate: 12/10/2014 03:37PMSubject: Moving _conf and _scripts to dashboardThe way we are structuring our_javascript_stoday is complicated. All of our static _javascript_s reside in /horizon/static and are imported through _conf.html and _scripts.html. Notice that there are already some panel specific _javascript_s like: horizon.images.js, horizon.instances.js, horizon.users.js. They do not belong in horizon. They belong in openstack_dashboard because they are specific to a panel.Why am I raising this issue now? In Angular, we need controllers written in _javascript_ for each panel. As we angularize more and more panels, we need to store them in a way that make sense. To me, it make sense for us to move _conf and _scripts to openstack_dashboard. Or if this is not possible, then provide a mechanism to override them in openstack_dashboard.Thoughts?Thai


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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] Moving _conf and _scripts to dashboard

2014-12-12 Thread Thai Q Tran
Haha, sure I'm willing to make concessions. I'll update the patch to retain the _conf file but it will be blank. This way, we can move forward and not break it for existing users.I'll also document it somewhere in the patch.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 12/12/2014 03:18PMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardBreaking something for existing user is progress, but not forward. :)I don't mind moving the code around to _scripts file, but simply dropping the _conf file is my concern since it might already be extended from. Perhaps document it first that it will be deprecated, and remove it on later release.On Fri, Dec 12, 2014 at 10:43 AM, Thai Q Tran tqt...@us.ibm.com wrote:As is the case with anything we change, but that should not stop us from making improvements/progress. I would argue that it would make life easier for them since all scripts are now in one place.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 12/12/2014 10:28AMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardConsolidating them would break it for users that have customization and extension on the two templates.-LinOn Fri, Dec 12, 2014 at 9:20 AM, David Lyle dkly...@gmail.com wrote:Not entirely sure why they both exist either.So by move, you meant override (nuance). That's different and I have no issue with that.I'm also fine with attempting to consolidate _conf and _scripts.DavidOn Thu, Dec 11, 2014 at 1:22 PM, Thai Q Tran tqt...@us.ibm.com wrote:It would not create a circular dependency, dashboard would depend on horizon - not the latter.Scripts that are library specific will live in horizon while scripts that are panel specific will live in dashboard.Let me draw a more concrete example.In HorizonWe know that _script and _conf are included in the base.htmlWe create a _script and _conf placeholder file for project overrides (similar to _stylesheets and _header)In DashboardWe create a _script and _conf file with today's contentIt overrides the _script and _conf file in horizonNow we can include panel specific scripts without causing circular dependency.In fact, I would like to go further and suggest that _script and _conf be combine into a single file.Not sure why we need two places to include scripts.-David Lyle dkly...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: David Lyle dkly...@gmail.comDate: 12/11/2014 09:23AMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardI'm probably not understanding the nuance of the question but moving the _scripts.html file to openstack_dashboard creates some circular dependencies, does it not? templates/base.html in the horizon side of the repo includes _scripts.html and insures that the _javascript_ needed by the existing horizon framework is present._conf.html seems like a better candidate for moving as it's more closely tied to the application code.DavidOn Wed, Dec 10, 2014 at 7:20 PM, Thai Q Tran tqt...@us.ibm.com wrote:Sorry for duplicate mail, forgot the subject.-Thai Q Tran/Silicon Valley/IBM wrote: -To: "OpenStack Development Mailing List \(not for usage questions\)" openstack-dev@lists.openstack.orgFrom: Thai Q Tran/Silicon Valley/IBMDate: 12/10/2014 03:37PMSubject: Moving _conf and _scripts to dashboardThe way we are structuring our_javascript_stoday is complicated. All of our static _javascript_s reside in /horizon/static and are imported through _conf.html and _scripts.html. Notice that there are already some panel specific _javascript_s like: horizon.images.js, horizon.instances.js, horizon.users.js. They do not belong in horizon. They belong in openstack_dashboard because they are specific to a panel.Why am I raising this issue now? In Angular, we need controllers written in _javascript_ for each panel. As we angularize more and more panels, we need to store them in a way that make sense. To me, it make sense for us to move _conf and _scripts to openstack_dashboard. Or if this is not possible, then provide a mechanism to override them in openstack_dashboard.Thoughts?Thai


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac

Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboard

2014-12-11 Thread Thai Q Tran
It would not create a circular dependency, dashboard would depend on horizon - not the latter.Scripts that are library specific will live in horizon while scripts that are panel specific will live in dashboard.Let me draw a more concrete example.In Horizon	We know that _script and _conf are included in the base.html	We create a _script and _conf placeholder file for project overrides (similar to _stylesheets and _header)In Dashboard	We create a _script and _conf file with today's content	It overrides the _script and _conf file in horizon	Now we can include panel specific scripts without causing circular dependency.In fact, I would like to go further and suggest that _script and _conf be combine into a single file.Not sure why we need two places to include scripts.-David Lyle dkly...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: David Lyle dkly...@gmail.comDate: 12/11/2014 09:23AMSubject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to dashboardI'm probably not understanding the nuance of the question but moving the _scripts.html file to openstack_dashboard creates some circular dependencies, does it not? templates/base.html in the horizon side of the repo includes _scripts.html and insures that the _javascript_ needed by the existing horizon framework is present._conf.html seems like a better candidate for moving as it's more closely tied to the application code.DavidOn Wed, Dec 10, 2014 at 7:20 PM, Thai Q Tran tqt...@us.ibm.com wrote:Sorry for duplicate mail, forgot the subject.-----Thai Q Tran/Silicon Valley/IBM wrote: -To: "OpenStack Development Mailing List \(not for usage questions\)" openstack-dev@lists.openstack.orgFrom: Thai Q Tran/Silicon Valley/IBMDate: 12/10/2014 03:37PMSubject: Moving _conf and _scripts to dashboardThe way we are structuring our_javascript_stoday is complicated. All of our static _javascript_s reside in /horizon/static and are imported through _conf.html and _scripts.html. Notice that there are already some panel specific _javascript_s like: horizon.images.js, horizon.instances.js, horizon.users.js. They do not belong in horizon. They belong in openstack_dashboard because they are specific to a panel.Why am I raising this issue now? In Angular, we need controllers written in _javascript_ for each panel. As we angularize more and more panels, we need to store them in a way that make sense. To me, it make sense for us to move _conf and _scripts to openstack_dashboard. Or if this is not possible, then provide a mechanism to override them in openstack_dashboard.Thoughts?Thai


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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] REST and Django

2014-12-10 Thread Thai Q Tran
quot;project" in the user API we've already implemented) and extend those interfaces (to allow batched operations).We want to be careful about what we expose in Horizon to the JS clients through this API. That necessitates some amount of code in Horizon. About half of the current API for keysone represents that control (the other half is docstrings :)  RichardOn Tue Dec 09 2014 at 9:37:47 PM Tihomir Trifonov t.trifo...@gmail.com wrote:Sorry for the late reply, just few thoughts on the matter.IMO the REST middleware should be as thin as possible. And I mean thin in terms of processing - it should not do pre/post processing of the requests, but just unpack/pack. So here is an example:instead of making AJAX calls that contain instructions:POST --json --data {"action": "delete", "data": [{"name": "item1"},{"name": "item2"}, {"name": "item3" ]}I think a better approach is just to pack/unpack batch commands, and leave execution to the frontend/backend and not middleware:POST --json --data {"batch": [{"action" : "delete", "payload": {"name": "item1"},{"action" : "delete", "payload":{"name": "item2"},{"action" : "delete", "payload":{"name": "item3"} ] }The idea is that the middleware should not know the actual data. It should ideally just unpack the data:responses = []for cmd in request.POST['batch']:  responses.append(getattr(controller, cmd['action'])(**cmd['payload']))return responsesand 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), soPOST --json --data {"batch":[{"action" : "tenant_update","payload": {"project": 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.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.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 mightbe 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.







 

[openstack-dev] Moving _conf and _scripts to dashboard

2014-12-10 Thread Thai Q Tran
The way we are structuring our_javascript_stoday is complicated. All of our static _javascript_s reside in /horizon/static and are imported through _conf.html and _scripts.html. Notice that there are already some panel specific _javascript_s like: horizon.images.js, horizon.instances.js, horizon.users.js. They do not belong in horizon. They belong in openstack_dashboard because they are specific to a panel.Why am I raising this issue now? In Angular, we need controllers written in _javascript_ for each panel. As we angularize more and more panels, we need to store them in a way that make sense. To me, it make sense for us to move _conf and _scripts to openstack_dashboard. Or if this is not possible, then provide a mechanism to override them in openstack_dashboard.Thoughts?Thai


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Horizon] Moving _conf and _scripts to dashboard

2014-12-10 Thread Thai Q Tran
Sorry for duplicate mail, forgot the subject.-Thai Q Tran/Silicon Valley/IBM wrote: -To: "OpenStack Development Mailing List \(not for usage questions\)" openstack-dev@lists.openstack.orgFrom: Thai Q Tran/Silicon Valley/IBMDate: 12/10/2014 03:37PMSubject: Moving _conf and _scripts to dashboardThe way we are structuring our_javascript_stoday is complicated. All of our static _javascript_s reside in /horizon/static and are imported through _conf.html and _scripts.html. Notice that there are already some panel specific _javascript_s like: horizon.images.js, horizon.instances.js, horizon.users.js. They do not belong in horizon. They belong in openstack_dashboard because they are specific to a panel.Why am I raising this issue now? In Angular, we need controllers written in _javascript_ for each panel. As we angularize more and more panels, we need to store them in a way that make sense. To me, it make sense for us to move _conf and _scripts to openstack_dashboard. Or if this is not possible, then provide a mechanism to override them in openstack_dashboard.Thoughts?Thai


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

2014-12-02 Thread Thai Q Tran

I like David's approach, but having two modals (one for the form, one for
the confirmation) on top of each other is a bit weird and would require
constant checks for input.
We already have three ways to close the dialog today: via the cancel
button, X button, and ESC key. It's more important to me that I don't lose
work by accidentally clicking outside. So from this perspective, I think
that having a static behavior is the way to go. Regardless of what approach
we pick, its an improvement over what we have today.




From:   Timur Sufiev tsuf...@mirantis.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   12/02/2014 04:22 AM
Subject:[openstack-dev] [horizon] [ux] Changing how the modals are
closed  in Horizon



Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap
defaults) regarding their closing is to simply close the modal once user
clicks somewhere outside of it (on the backdrop element below and around
the modal). This is not very convenient for the modal forms containing a
lot of input - when it is closed without a warning all the data the user
has already provided is lost. Keeping this in mind, I've made a patch [1]
changing default Bootstrap 'modal_backdrop' parameter to 'static', which
means that forms are not closed once the user clicks on a backdrop, while
it's still possible to close them by pressing 'Esc' or clicking on the 'X'
link at the top right border of the form. Also the patch [1] allows to
customize this behavior (between 'true'-current one/'false' - no backdrop
element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David
Lyle had been working on a similar solution [2] some time ago. It's a bit
more elaborate than mine: if the user has already filled some some inputs
in the form, then a confirmation dialog is shown, otherwise the form is
silently dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased
to the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better
late than never :).

--
Timur Sufiev___
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] REST and Django

2014-11-30 Thread Thai Q Tran
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...




From:   Richard Jones r1chardj0...@gmail.com
To: Tripp, Travis S travis.tr...@hp.com, OpenStack List
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.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 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.

Indeed, looking at the current launch wizard code it seems like you
wouldn't need to load all that data for the wizard to be displayed, since
only some subset of it would be necessary to display any given panel of the
wizard.


  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.

I'm glad to hear it. I'm a fan of optimising when necessary, and not
beforehand :)


  Of course if anybody is able to do some performance testing between the
  two approaches then that could affect the direction taken.

I would certainly like to see us take some measurements when performance
issues pop up. Optimising without solid metrics is bad idea :)


    Richard


  [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.com
  Date: Wednesday, November 26, 2014 at 11:55 PM
  To: Travis Tripp travis.tr...@hp.com, Thai Q Tran/Silicon Valley/IBM 
  tqt...@us.ibm.com, David Lyle dkly...@gmail.com, Maxime Vidori 
  maxime.vid...@enovance.com, Wroblewski, Szymon 
  szymon.wroblew...@intel.com, Wood, Matthew David (HP Cloud - Horizon)
  matt.w...@hp.com, Chen, Shaoquan sean.ch...@hp.com, Farina, Matt
  (HP Cloud) matthew.far...@hp.com, Cindy Lu/Silicon Valley/IBM 
  c...@us.ibm.com, Justin Pomeroy/Rochester/IBM jpom...@us.ibm.com, Neill
  Cox 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.com
  wrote:
   Thanks