+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, 20
d 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: Th
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 pro
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
- Or
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 a
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
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 wit
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
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 fi
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 messa
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-c
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.
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 "re
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 s
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 A
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 cycl
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 pr
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
n Thu, Aug 20, 2015 at 4:36 PM, Doug Fish <the.doug.f...@gmail.com<mailto: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 (possi
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, "Tha
aintain, 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
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> wro
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-i
<<< 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/mailma
Love the idea, great explanation! I see value in this going forward.
Definitely interested.
From: "Chen, Shaoquan"
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 07/19/2015 05:34 PM
Subject:[openstack-dev] [Openstack][Horizon] Sharable Ang
Had the same issue when I worked on the context selection menu for switching domain and project. I think it make sense to rename it to AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its going to affect some folks (maybe even break) until they also update their setting, something that
Right, this was the suggestion I also recommended in IRC. The only issue here is if/when another plugin attempt to extend from the same panel, then we'd run into conflicts that would require manual resolution (but I'm not sure there is any other way around this).-Lin Hua Cheng wrote: -To:
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 rel
Hi Zhengou,I think it make sense to start with the angular version. It's true that we don't have an angular dashboard yet,but we have a pretty good idea of what needs to go into it. I'll link a few patches that will give you an ideaof where we are headed. I think this will also save you some work i
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
aeger Date: 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&
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 th
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 ex
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)" wrote: -To: "OpenStack Development Mailing List (not for usage questions
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
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)" wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: "Rob Cresswell (rcresswe)"
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 wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Richard Jones Date: 05/25/2015 05:38PMCc: "Johanson, Tyr H" S
Welcome to the team Doug, Rob, and Travis!!!-David Lyle wrote: -To: OpenStack Development Mailing List From: David Lyle Date: 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
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
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 04/22/2015 06:10 PM
Subject:Re: [openstack-dev] [Horizon] Out
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
f
uot;.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, defau
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 d
As we're moving toward Angular, might make sense for us to adopt ngdoc as well.-Matthew Farina wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Matthew Farina Date: 02/04/2015 05:42AMSubject: [openstack-dev] [horizon] _javascript_ docs?In python we have a st
erence 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,
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 qu
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
om> 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> wrot
In your previous example, you are posting to a certain URL (i.e. /keystone/{ver:=x.0}/{method:=update}). => => Correct 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 ser
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 <tq
Sorry for duplicate mail, forgot the subject.-Thai Q Tran/Silicon Valley/IBM wrote: -To: "OpenStack Development Mailing List \(not for usage questions\)" From: Thai Q Tran/Silicon Valley/IBMDate: 12/10/2014 03:37PMSubject: Moving _conf and _scripts to dashboardThe way we are s
The way we are structuring our _javascript_s today 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.
ion. 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 mi
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
8/openstack_dashboard/api/rest/urls.py
[2]
https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign
-Travis
From: Richard Jones
Date: Wednesday, November 26, 2014 at 11:55 PM
To: Travis Tripp , Thai Q Tran/Silicon Valley/IBM <
tqt...@us.ibm.com>, David Lyle
54 matches
Mail list logo
