Re: [openstack-dev] [Heat][Horizon] Liberty horizon and get_file workaround?

2016-04-22 Thread Lin Hua Cheng
Based from stable policy, we don't backport new features [1]. The new
feature also reads from an external URL, which I think might be too risky
to add to stable branches.

-Lin

[1]
http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines

On Fri, Apr 22, 2016 at 3:14 AM, Ethan Lynn  wrote:

> There’s a patch to fix this problem in mitaka
> https://review.openstack.org/#/c/241700/ , Need to here more feedbacks
> about backport it to liberty release
> https://review.openstack.org/#/c/260436/ .
>
>
> Best Regards,
> Ethan Lynn
> xuanlangj...@gmail.com
>
>
>
>
> On Apr 22, 2016, at 13:06, Jason Pascucci  wrote:
>
> Hi,
>
> I wanted to add my yaml as new resources (via
> /etc/heat/environment.d/default.yaml, but we use some external files in the
> OS::Nova::Server personality section.
>
> It looks like the heat cli handles that when you pass yaml to it, but I
> couldn’t get it to work either through horizon, or even heat-cli when it
> was a get_file from inside of the new resources.
> I can see why file:// might not work, but I sort of
> expected that at least http://blah would still work within horizon (if
> so, I could just stick it in swift somewhere, but alas, no soup).
>
> What’s the fastest path to a workaround?
> I was thinking of making a new resource plugin that reads
> the path, and returns the contents so it could be used as a get_attr,
> essentially cribbing the code from the heat command line processing.
> Is there a better/sane way?
> Is there some conceptual thing I’m missing that makes this
> moot?
>
> Thanks in advance,
>
> JRPascucci
> Juniper Networks
>
> __
> 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] PTL noncandidacy

2016-03-11 Thread Lin Hua Cheng
Thanks for all the great work. Your leadership and commitment to horizon
has been instrumental to the projects success.

On Fri, Mar 11, 2016 at 9:19 AM, David Lyle  wrote:

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


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

2016-03-08 Thread Lin Hua Cheng
big +1 from me.

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

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  wrote:

> I propose adding Diana Whitten[1] to horizon-core.
>
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
>
> Please respond with comments, +1s, or objections by Friday.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [OpenStackClient] New core team members

2016-02-17 Thread Lin Hua Cheng
Congrats Richard and Tang! Thanks for all the contribution.

Welcome to the team!

-Lin


On Wed, Feb 17, 2016 at 9:50 AM, Steve Martinelli 
wrote:

> Congrats to both Richard Theis and Tang Chen -- very well deserved!!!
> Thank you for guarding the gate!
>
> stevemar
>
> [image: Inactive hide details for Dean Troyer ---2016/02/17 11:34:18
> AM---I would like to announce the addition of Richard Theis and Ta]Dean
> Troyer ---2016/02/17 11:34:18 AM---I would like to announce the addition of
> Richard Theis and Tang Chen to the OpenStackClient core tea
>
> From: Dean Troyer 
> To: OpenStack Development Mailing List 
> Date: 2016/02/17 11:34 AM
> Subject: [openstack-dev] [OpenStackClient] New core team members
> --
>
>
>
> I would like to announce the addition of Richard Theis and Tang Chen to
> the OpenStackClient core team.  They both have been contributing quality
> reviews and code for some time now, particularly in the areas of SDK
> integration and new Network commands.
>
> Thank you Richard and Tang for your work and welcome to the core team.
>
> dt
>
> --
>
> Dean Troyer
> *dtro...@gmail.com* 
> __
> 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] [keystone][nova][cinder][horizon] Projects acting as a domain at the top of the project hierarchy

2016-02-01 Thread Lin Hua Cheng
See inline response for horizon-related feedback.

Hope this helps.

-Lin

On Sat, Jan 30, 2016 at 7:02 PM, Henry Nash  wrote:

> Hi
>
> One of the things the keystone team was planning to merge ahead of
> milestone-3 of Mitaka, was “projects acting as a domain”. Up until now,
> domains in keystone have been stored totally separately from projects, even
> though all projects must be owned by a domain (even tenants created via the
> keystone v2 APIs will be owned by a domain, in this case the ‘default’
> domain). All projects in a project hierarchy are always owned by the same
> domain. Keystone supports a number of duplicate concepts (e.g. domain
> assignments, domain tokens) similar to their project equivalents.
>
> The idea of  “projects acting as a domain” is:
>
> - A domain is actually represented as a super-top-level project (with an
> attribute, “is_domain" set to True), and all previous top level projects in
> the domain specify this special project as their parent in their parent_id
> attribute. A project with is_domain=True is said to be a “project acing as
> a domain”. Such projects can not have parents - i.e. they are at the top of
> the tree.
> - The project_id of a project acting as a domain is the equivalent of the
> domain_id.
> - The existing domain APIs are still supported, but behind the scenes
> actually reference the “project acing as a domain”, although in the long
> run may be deprecated. On migration to Mitaka, the entries of the domain
> table are moved to be projects acting as domains in the project table

- The project api can now be used to create/update/delete a project acting
> as a domain (by setting is_domain=True) just like a regular project - and
> do the equivalent of the domain CRUD APIs
> - Although domain scoped tokens are still supported, you can get a project
> scoped token to the project acting as a domain (and the is_domain attribute
> will be part of the token), so you can write policy rules that can solely
> respond to project tokens. We can eventually deprecate domain tokens, if we
> chose.
>

Excellent. Some folks are working on making the domain scope token worked
on horizon to make the identity operations available in horizon when using
keystone V3 (since domain scoped token is required by the policy file to do
cloud admin stuff). With this change, horizon can re-use the same project
scoping mechanism.


> - Domain assignments (which will still be supported) really just become
> project assignments placed on the project acting as a domain.
> - In terms of the impact on the results of list projects:
> — There is no change to listing projects within a domain (since you don’t
> see “the domain” is such a listing today)
> — A filter is being added to the list projects API to allow filtering by
> the is_domain attribute - with a default of is_domain=False (i.e. so unless
> you ask for them when listing all projects, you won’t see the projects
> acting as a domain). Hence again, by default, no change to the collection
> returned today.


> The above proposed changes have been integrated into the latest version of
> the Identity API spec:
> https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html
>
> I’ve got a couple of questions about the impact of the above:
>
> 1) I already know that if we do exactly as described above, the cinder
> gets confused with how it does quotas today - since suddenly there is a new
> parent to what it thought was a top level project (and the permission rules
> it encodes requires the caller to be cloud admin, or admin of the root
> project of a hierarchy).
> 2) I’m not sure of the state of nova quotas - and whether it would suffer
> a similar problem?
> 3) Will Horizon get confused by this at all?
>

Horizon doesn't support project hierarchy yet, so there's not a lot of
impact with the proposed change.

As long as the Domain API behavior is retained and the List Project API
keeps the old behavior, horizon should work just fine.

So horizon will continue to use the Domain API, and can switch to the new
API when the "project acting as domain" stabilized next release.


>
> Depending on the answers to the above, we can go in a couple of
> directions. The cinder issues looks easy to fix (having had a quick look at
> the code) - and if that was the only issue, then that may be fine. If we
> think there may be problems in multiple services, we could, for Mitaka,
> still create the projects acting as domains, but not set the parent_id of
> the current top level projects to point at the new project acting as a
> domain - that way those projects acting as domains remain isolated from the
> hierarchy for now (and essentially invisible to any calling service). Then
> as part of Newton we can provide patches to those services that need
> changing, and then wire up the projects acting as a domain to their
> children.
>
> Interested in feedback to the questions above.
>
> Henry
> 

Re: [openstack-dev] [Horizon] Django

2016-02-01 Thread Lin Hua Cheng
Hi Sandeep,

Edit Subnet is a workflow that uses a _workflow.html to generate the HTML.

The form attribute is generated by looking up workflow.attr_string in
https://github.com/openstack/horizon/blob/5ef14e17961a699e5980b98aa7edb2a95a905c1b/horizon/templates/horizon/common/_workflow.html#L6

You can specify the attr_string in the workflow class provided by Matthias
and the additional form attribute should be rendered in the form.

HTH,
Lin



On Mon, Feb 1, 2016 at 4:40 AM, Sandeep Makhija <
sandeep.makh...@nectechnologies.in> wrote:

> Hi Matthias,
>
> Thanks for your reply.
>
> As mentioned, I need to change the  'action' attribute of the 'Edit
> Subnet' button.\
>
>
> Regards,
> Sandeep Makhija
>
> -Original Message-
> From: Matthias Runge [mailto:mru...@redhat.com]
> Sent: Monday, February 01, 2016 6:03 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] Django
>
> On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> > Hi,
> >
> > I have been trying to fix a bug in horizon but I am a beginner in Django
> and couldn't get my way through this code.
> >
> > Could somebody please help me with it? Below given are the details of
> what I am looking for.
>
> Since you did not describe, what you would like to change, it's a bit hard
> to set you on track.
>
> Looking at that image, I assume, you would like to change the subnet
> workflow, which is defined in subnets/workflows.py
>
>
> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457
>
>
> Matthias
> --
> Matthias Runge 
>
> __
> 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
>
>
>
> DISCLAIMER:
>
> ---
> The contents of this e-mail and any attachment(s) are confidential and
> intended
> for the named recipient(s) only.
> It shall not attach any liability on the originator or NEC or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the
> opinions of NEC or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is
> strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. .
>
> ---
>
> __
> 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] Email as User Name on the Horizon login page

2016-01-15 Thread Lin Hua Cheng
It might be simpler to just update the label on the python code. This is
where the form label are defined.

You can update the label here:
https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51

-Lin

On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia 
wrote:

>
> Looks like the form comes from django_openstack_auth:
>
> https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53
>
>
> But to be honest, no idea how that can be overridden trough the themes,
> not sure if its even possible to override anything on that page without
> modifying django_openstack_auth directly :(
>
> Maybe someone else has a better insight on this than me.
>
>
> * Horrible Hack Incoming, read at your own discretion *
>
> You can override the template here:
>
> https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51
>
> And change this line:
> {{
> field.label }}
>
> For this:
> {% if
> field.label == "User Name" and not request.user.is_authenticated %}Email{%
> else %}{{ field.label }}{% endif %}
>
>
> Which will check if the label is "User Name" and the user is logged out
> and directly write "Email" as the field label.
>
> I know, its horrible and if you update horizon it will be overriden, but
> probably works for the time being if you really need it ¯\_(ツ)_/¯
>
> * Horrible Hack Finished *
>
>
>
>
> Itxaka
>
>
>
>
>
> On 01/15/2016 05:13 AM, Adrian Turjak wrote:
>
>> I've run into a weird issue with the Liberty release of Horizon.
>>
>> For our deployment we enforce emails as usernames, and thus for Horizon
>> we used to have "User Name" on the login page replaced with "Email".
>> This used to be a straightforward change in the html template file, and
>> with the introduction of themes we assumed it would be the same. When
>> one of our designers was migrating our custom CSS and html changes to
>> the new theme system they missed that change and I at first it was a
>> silly mistake.
>>
>> Only on digging through the code myself I found that the "User Name" on
>> the login screen isn't in the html file at all, nor anywhere else
>> straightforward. The login page form is built on the fly with javascript
>> to facilitate different modes of authentication. While a bit annoying
>> that didn't seem too bad and I then assumed it might mean a javascript
>> change, only that the more I dug, the more I became confused.
>>
>> Where exactly is the login form defined? And where exactly is the "User
>> Name" text for the login form set?
>>
>> I've tried all manner of stuff to change it with no luck and I feel like
>> I must have missed something obvious.
>>
>> Cheers,
>> -Adrian Turjak
>>
>> __
>> 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] [Monasca] Enabling Graphana GUI from Horizon

2016-01-12 Thread Lin Hua Cheng
You would need to propose the new feature in the monasca-ui [1], which is
the horizon plugin for displaying monasca dashboard.

-Lin

[1] https://github.com/openstack/monasca-ui/

On Tue, Jan 12, 2016 at 3:32 AM, Pradip Mukhopadhyay <
pradip.inte...@gmail.com> wrote:

> Hello,
>
>
> We're using the following fullsetup to install Monasca (python):
>
> https://github.com/openstack/monasca-api/tree/master/devstack
>
>
>
> Most likely we need to do something more to see the "Monitoring" tab in
> left hand side that takes us to Monasca graphana GUI.
>
>
> Can anyone please point me?
>
>
> We do see it when do a vagrant setup with mini-mon and devstack VMs.
>
>
> Any help is highly solicited.
>
>
> --pradip
>
>
> __
> 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]

2015-12-04 Thread Lin Hua Cheng
The most efficient way to do this for Swift to do this is to implement Form
Post[1] (upload) and tempUrl[2] (download). With this setup, the user will
be directly uploading/downloading from Swift endpoint rather than passing
the files through horizon.

The caveat for this to work, you need to be able to associate access keys
to users.

-Lin

[1] http://docs.openstack.org/developer/swift/api/form_post_middleware.html
[2]
http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

On Thu, Dec 3, 2015 at 3:20 PM, Kyrylo Galanov 
wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-core

2015-12-02 Thread Lin Hua Cheng
+1 thanks for all the hard work! And Timur will fix pagination too :)

On Wed, Dec 2, 2015 at 7:52 PM, David Lyle  wrote:

> I propose adding Timur Sufiev[1] to horizon-core.
>
> Over the last several cycles Timur has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions particularly around testing and
> stability.
>
> 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:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2015-12-02 Thread Lin Hua Cheng
+1 thanks for all the hard work Richard!

On Wed, Dec 2, 2015 at 7:56 PM, David Lyle  wrote:

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


Re: [openstack-dev] [Horizon] Bug day! Yeah!

2015-11-19 Thread Lin Hua Cheng
Great, I'll be around next Tuesday.

-Lin

On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe) <
rcres...@cisco.com> wrote:

> As requested,
> https://etherpad.openstack.org/p/horizon-bug-day
>
> Rob
>
> From: Richard Jones 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, 19 November 2015 20:39
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon] Bug day! Yeah!
>
> Let's do it. I'd like to suggest we use an etherpad to keep track of what
> people have done. If it's not created when I start my day, I'll make one.
>
>
>  Richard
>
> On 19 November 2015 at 22:19, Rob Cresswell (rcresswe)  > wrote:
>
>> Hey folks,
>>
>> Our bug list is… rather large. We’ve discussed having a bug day, where as
>> a community we all dedicate some time to triaging bugs and discussing in
>> the IRC channel as we go.
>>
>> First off, see the docs about bug triage:
>> https://wiki.openstack.org/wiki/BugTriage
>>
>> Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if
>> that doesn’t work for a good number of us, then the following Tuesday (1st
>> December). Trying to account for Thanksgiving :)
>>
>> Rob
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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-11-14 Thread Lin Hua Cheng
Hi David,

Sounds good.

I am able to download both files, thanks!

Regards,
Lin

On Sat, Nov 14, 2015 at 4:04 AM, David Chadwick <d.w.chadw...@kent.ac.uk>
wrote:

> Hi Lin
>
> I am submitting the code and dissertation links to the mailing list so
> that I only need to do it once for everyone.
>
> Since these are large files, I have sent them to Dropbox. They are
> public access, available as follows:
>
> Brida_Final Dissertation.pdf (3.5Mb)
> (
> https://www.dropbox.com/s/ugyrffgjkmq1a3s/Brinda_Final%20Dissertation.pdf?dl=0
> )
>
> and
>
> Corpus.zip  (12.7Mb)
> (https://www.dropbox.com/s/98fp2c9194n198j/corpus.zip?dl=0)
>
> regards
>
> David
>
> On 14/11/2015 02:59, Lin Hua Cheng wrote:
> > David,
> >
> > FYI, I've submitted a patch to enable registering Identity Providers in
> > horizon:
> >
> > https://review.openstack.org/#/c/244991/
> >
> > The next logical step for this is to look at the IdP mapping.
> >
> > I can follow-up on the work by Anton to add that support for horizon.
> >
> > Can you send me the code and documents you may have related to this?
> >
> > Thanks,
> > Lin
> >
> >
> >
> > On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick <d.w.chadw...@kent.ac.uk
> > <mailto:d.w.chadw...@kent.ac.uk>> wrote:
> >
> >
> >
> > On 07/10/2015 18:29, Adam Young wrote:
> > > On 10/07/2015 11:51 AM, Adam Young wrote:
> > >> Send me what you have, and I will post it as a Work in progress
> review
> > >> against Horizon.  That way at least it will be available for
> others to
> > >> look at and potentially adopt.
> > >
> > > Review has been posted here
> > > https://review.openstack.org/232114
> > >
> >
> > thanks Adam
> >
> > >
> > > I made a best guess as far as where it it should be placed in the
> source
> > > tree.  I have not tested the code.
> > >
> > > David and I have both signed the CLA. I am fairly certon Anton did
> not.
> > > It would be easiest for OpenStack to accept this code if he did, as
> > > there would be no question about copyright or licensing.
> >
> > Legally speaking it is not necessary, since any code produced by
> > students as part of their degree course does not belong to them.
> > However, it would be courteous of us to ask him, so I have done this.
> >
> > >
> > > David also provided me with a PDF version of Anton's dissertation.
> I do
> > > not know what the status of that document, but it would be a great
> > > resource to anyone that wants to take this code and get it
> integrated
> > > into Horizon.
> >
> > This can be made publicly available after the exam board next month.
> > Until then I will give out personal copies for private study.
> >
> > regards
> >
> > David
> >
> > >
> > > This does not look like a radical stretch.  It would be a decent
> > > opportunity for anyone looking to get involved with OpenStack to
> step
> > > into something immediately.
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >>
> > >> On 10/07/2015 11:37 AM, David Chadwick wrote:
> > >>> Hi Douglas
> > >>>
> > >>> we are happy for you (or someone else) to submit the code in 3
> > names:
> > >>> theirs, mine and Anton's. Then this third person can do all the
> work
> > >>> necessary to get it approved. In this way it is legitimate,
> > since the
> > >>> third person will have contributed to the overall effort.
> > >>>
> > >>> I dont have any spare time yet for another month or so. After
> that I
> > >>> could submit it, but having never done it before for Horizon,
> > there will
> > >>> be a big learning curve. And I might not have time to learn it
> > >>>
> > >>> regards
> > >>>
> > >>> David
> > >>>
> > >>> On 07/10/2015 16:05, Douglas Fish wrote:
> > >>>> Hi David,
> > >>>>   This sounds like a great set of code, I'm sure we are going to
> > >>>> realize
> > >>>> we want

Re: [openstack-dev] [horizon][keystone]

2015-11-13 Thread Lin Hua Cheng
David,

FYI, I've submitted a patch to enable registering Identity Providers in
horizon:

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

The next logical step for this is to look at the IdP mapping.

I can follow-up on the work by Anton to add that support for horizon.

Can you send me the code and documents you may have related to this?

Thanks,
Lin



On Wed, Oct 7, 2015 at 11:12 AM, David Chadwick 
wrote:

>
>
> On 07/10/2015 18:29, Adam Young wrote:
> > On 10/07/2015 11:51 AM, Adam Young wrote:
> >> Send me what you have, and I will post it as a Work in progress review
> >> against Horizon.  That way at least it will be available for others to
> >> look at and potentially adopt.
> >
> > Review has been posted here
> > https://review.openstack.org/232114
> >
>
> thanks Adam
>
> >
> > I made a best guess as far as where it it should be placed in the source
> > tree.  I have not tested the code.
> >
> > David and I have both signed the CLA. I am fairly certon Anton did not.
> > It would be easiest for OpenStack to accept this code if he did, as
> > there would be no question about copyright or licensing.
>
> Legally speaking it is not necessary, since any code produced by
> students as part of their degree course does not belong to them.
> However, it would be courteous of us to ask him, so I have done this.
>
> >
> > David also provided me with a PDF version of Anton's dissertation. I do
> > not know what the status of that document, but it would be a great
> > resource to anyone that wants to take this code and get it integrated
> > into Horizon.
>
> This can be made publicly available after the exam board next month.
> Until then I will give out personal copies for private study.
>
> regards
>
> David
>
> >
> > This does not look like a radical stretch.  It would be a decent
> > opportunity for anyone looking to get involved with OpenStack to step
> > into something immediately.
> >
> >
> >
> >
> >>
> >>
> >>
> >> On 10/07/2015 11:37 AM, David Chadwick wrote:
> >>> Hi Douglas
> >>>
> >>> we are happy for you (or someone else) to submit the code in 3 names:
> >>> theirs, mine and Anton's. Then this third person can do all the work
> >>> necessary to get it approved. In this way it is legitimate, since the
> >>> third person will have contributed to the overall effort.
> >>>
> >>> I dont have any spare time yet for another month or so. After that I
> >>> could submit it, but having never done it before for Horizon, there
> will
> >>> be a big learning curve. And I might not have time to learn it
> >>>
> >>> regards
> >>>
> >>> David
> >>>
> >>> On 07/10/2015 16:05, Douglas Fish wrote:
>  Hi David,
>    This sounds like a great set of code, I'm sure we are going to
>  realize
>  we want it sooner or later! Unfortunately I can't consume code in this
>  way (I can't propose code written by somebody else) and I can't spend
>  significant time on it right now.
>    Would you or Anton be willing to propose whatever code and
>  documentation
>  you have to Horizon? It doesn't have to be complete; it doesn't need
> to
>  have grammar cleaned up or anything like that. You could mark it as a
>  "Work in progress", and make it clear in the commit message that you
>  aren't planning further work on this, so the patch is available for
>  adoption. That way somebody else may be able to pick this up and
>  work on
>  it in the future, but Anton could get credit for the work he has done.
> 
>  Doug Fish
> 
>   - Original message -
>   From: David Chadwick 
>   To: OpenStack Development Mailing List
>   
>   Cc:
>   Subject: [openstack-dev] [horizon][keystone]
>   Date: Tue, Oct 6, 2015 2:13 PM
> Dear All
> 
>   One of my students, Anton Brida, has developed an Attribute
>  Mapping GUI
>   for Horizon as part of his MSc project. Attribute mappings are an
>   essential, though complex, part of federated Keystone.
>  Currently they
>   can only be created as JSON objects in the config file. The
>  Horizon code
>   allows them to be dynamically created via an easy to use GUI.
> 
>   Since Anton has now left the university for full time
>  employment, he is
>   not able to go through the process of submitting his code to
>  the next
>   release of Horizon. His design however was submitted to
>  InVision and
>   commented on by various people at the time of the development.
> 
>   I am now looking for someone who would like to take a copy of
>  this code
>   and go through the process of submitting this to the next
>  release of
>   Horizon. I have a copy of Anton's MSc dissertation as well which
>   explains the work that he has done.
> 
> 

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

2015-09-28 Thread Lin Hua Cheng
I agree with Travis that 2-3 minutes is not enough, that may not be even
enough to talk about one bug. :)

We could save some time if we have someone monitoring the bugs/feature and
publish the high priority item into a report - something similar to what
Keystone does [1].  Reviewers can look this up every time if they need to
prioritize their reviews.

We can rotate this responsibility among cores every month - even non-core
if someone wants to volunteer.

-Lin

[1]
https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Keystone_Weekly_Bug_Reports




On Mon, Sep 28, 2015 at 7:22 PM, Tripp, Travis S 
wrote:

> Things always move more quickly at the end of a cycle because people feel
> release pressure, but I do think this is a good idea. 2 - 3 minutes isn’t
> very realistic. It would need to be planned for longer.
>
>
>
>
>
> On 9/28/15, 3:57 AM, "Rob Cresswell (rcresswe)" 
> wrote:
>
> >Hi folks,
> >
> >I¹m wondering if we could try marking out a small 2-3 minute slot at the
> >start of each weekly meeting to highlight Critical/ High bugs that have
> >code up for review, as well as important blueprints that have code up for
> >review. These would be blueprints for features that were identified as
> >high priority at the summit.
> >
> >The thought here is that we were very efficient in L-RC1 at moving code
> >along, which is nice for productivity, but not really great for stability;
> >it would be good to do this kind of targeted work earlier in the cycle.
> >I¹ve noticed other projects doing this in their meetings, and it seems
> >quite effective.
> >
> >Rob
> >
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] PTL non-candidacy

2015-09-10 Thread Lin Hua Cheng
Thanks for doing a great job, Morgan!

Good luck on your next adventure.


On Thu, Sep 10, 2015 at 7:22 PM, Adam Young  wrote:

> Confirming that Morgan is eligible for non-candidacy.
>
> You've done a great job.  Thanks.
>
>
>
> On 09/10/2015 05:40 PM, Morgan Fainberg wrote:
>
> As I outlined (briefly) in my recent announcement of changes (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
> ) I will not be running for PTL of Keystone this next cycle (Mitaka). The
> role of PTL is a difficult but extremely rewarding job. It has been amazing
> to see both Keystone and OpenStack grow.
>
> I am very pleased with the accomplishments of the Keystone development
> team over the last year. We have seen improvements with Federation,
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
> releasing a dedicated authentication library, cross-project initiatives
> around improving the Service Catalog, and much, much more. I want to thank
> each and every contributor for the hard work that was put into Keystone and
> its associated projects.
>
> While I will be changing my focus to spend more time on the general needs
> of OpenStack and working on the Public Cloud story, I am confident in those
> who can, and will, step up to the challenges of leading development of
> Keystone and the associated projects. I may be working across more
> projects, but you can be assured I will be continuing to work hard to see
> the initiatives I helped start through. I wish the best of luck to the next
> PTL.
>
> I guess this is where I get to write a lot more code soon!
>
> See you all (in person) in Tokyo!
> --Morgan
>
>
> __
> 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS

2015-09-02 Thread Lin Hua Cheng
Opened a launchpad bug for tracking:
https://bugs.launchpad.net/horizon/+bug/1491637

-Lin

On Wed, Sep 2, 2015 at 2:28 PM, Eichberger, German  wrote:

> Hi Bharath,
>
> I am wondering if you can file this as a launchpad bug, please.
>
> Thanks,
> German
>
> From: bharath >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Date: Wednesday, September 2, 2015 at 9:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Subject: [openstack-dev] [Neutron][horizon][neutron][L3][dvr][fwaas] FWaaS
>
> Hi,
>
> Horizon seems to be broken.
>
> When i try to add new firewall rule , horizon broken with "'NoneType'
> object has no attribute 'id'" Error.
> This was fine about 10 hours back. Seems one of the  latest commit broken
> it.
>
>
> Traceback in horizon:
>
>
> 2015-09-02 16:15:35.337872 return nodelist.render(context)
> 2015-09-02 16:15:35.337877   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 903,
> in render
> 2015-09-02 16:15:35.337893 bit = self.render_node(node, context)
> 2015-09-02 16:15:35.337899   File
> "/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 79,
> in render_node
> 2015-09-02 16:15:35.337903 return node.render(context)
> 2015-09-02 16:15:35.337908   File
> "/usr/local/lib/python2.7/dist-packages/django/template/debug.py", line 89,
> in render
> 2015-09-02 16:15:35.337913 output =
> self.filter_expression.resolve(context)
> 2015-09-02 16:15:35.337917   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 647,
> in resolve
> 2015-09-02 16:15:35.337922 obj = self.var.resolve(context)
> 2015-09-02 16:15:35.337927   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 787,
> in resolve
> 2015-09-02 16:15:35.337931 value = self._resolve_lookup(context)
> 2015-09-02 16:15:35.337936   File
> "/usr/local/lib/python2.7/dist-packages/django/template/base.py", line 825,
> in _resolve_lookup
> 2015-09-02 16:15:35.337940 current = getattr(current, bit)
> 2015-09-02 16:15:35.337945   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 59, in attr_string
> 2015-09-02 16:15:35.337950 return flatatt(self.get_final_attrs())
> 2015-09-02 16:15:35.337954   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 42, in get_final_attrs
> 2015-09-02 16:15:35.337959 final_attrs['class'] = self.get_final_css()
> 2015-09-02 16:15:35.337964   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/utils/html.py",
> line 47, in get_final_css
> 2015-09-02 16:15:35.337981 default = "
> ".join(self.get_default_classes())
> 2015-09-02 16:15:35.337986   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 792, in get_default_classes
> 2015-09-02 16:15:35.337991 if not self.url:
> 2015-09-02 16:15:35.337995   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 756, in url
> 2015-09-02 16:15:35.338000 url = self.column.get_link_url(self.datum)
> 2015-09-02 16:15:35.338004   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/base.py",
> line 431, in get_link_url
> 2015-09-02 16:15:35.338009 return self.link(datum)
> 2015-09-02 16:15:35.338014   File
> "/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/firewalls/tables.py",
> line 261, in get_policy_link
> 2015-09-02 16:15:35.338019 kwargs={'policy_id': datum.policy.id})
> 2015-09-02 16:15:35.338023 AttributeError: 'NoneType' object has no
> attribute 'id'
>
>
>
> Thanks,
> bharath
>
> __
> 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] Update on Angular Identity work

2015-08-20 Thread Lin Hua Cheng
 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.org
 From: Lin Hua Cheng os.lch...@gmail.com
 Date: 08/19/2015 05:15PM
 Subject: Re: [openstack-dev] [Horizon] Update on Angular Identity work

 Hi 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,
 Lin

 On Wed, Aug 19, 2015 at 12:16 PM, Thai Q Tran tqt...@us.ibm.com wrote:

 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.html

 So 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.org
 From: Lin Hua Cheng os.lch...@gmail.com
 Date: 08/18/2015 02:36PM
 Cc: Vince Brunssen/Austin/IBM@IBMUS
 Subject: Re: [openstack-dev] [Horizon] Update on Angular Identity work


 I 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/table

 On 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 pluggable
 2. easy to understand
 3. reduce code duplication

 These 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

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

2015-08-19 Thread Lin Hua Cheng
Hi 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,
Lin

On Wed, Aug 19, 2015 at 12:16 PM, Thai Q Tran tqt...@us.ibm.com wrote:

 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.html

 So 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.org
 From: Lin Hua Cheng os.lch...@gmail.com
 Date: 08/18/2015 02:36PM
 Cc: Vince Brunssen/Austin/IBM@IBMUS
 Subject: Re: [openstack-dev] [Horizon] Update on Angular Identity work


 I 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/table

 On 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 pluggable
 2. easy to understand
 3. reduce code duplication

 These 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

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

2015-08-18 Thread Lin Hua Cheng
I 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/table

On 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 pluggable
 2. easy to understand
 3. reduce code duplication

 These 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


__
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-04 Thread Lin Hua Cheng
Hi David,

There was a similar effort in Kilo to design the flow in the login page for
federated login[1].   WebSSO feature[2] was implemented in Kilo, it allows
the user to perform federated login by selecting an IdP protocol.  This
have tested with kerberos and saml2.

There is a proposal to extend that feature to show listing per Idp/Protocol
instead [3], because just listing only by protocol is fairly limited .

I think the Type Ahead can fit it nicely when we implement the support for
WebSSO by IdP/Protocol.

thanks,
Lin

[1] https://openstack.invisionapp.com/d/main#/projects/2784587
[2] http://docs.openstack.org/developer/keystone/extensions/websso.html
[3] https://review.openstack.org/#/c/199339/


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

On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:

 Hi Everyone

 I have a student building a GUI for federated login with Horizon. The
 interface supports both a drop down list of configured IDPs, and also
 Type Ahead for massive federations with hundreds of IdPs. Screenshots
 are visible in InVision here

 https://invis.io/HQ3QN2123

 All comments on the design are appreciated. You can make them directly
 to the screens via InVision

 Regards

 David



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

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


Re: [openstack-dev] [Keystone] [Horizon] UI for Keystone dynamic policies editing

2015-08-03 Thread Lin Hua Cheng
Hi Timur,

Thanks for bringing this up.

I think we can borrow some concept from the Mistral Workbook Builder. I
like the ability to add items and seeing the preview on the right side. We
can re-use that part.

The challenging part would be building a Rule expression builder that
supports the policy semantic [1] [2]. We should start with creating some
mockups.  The builder will also be useful even if we don't land the dynamic
policy in L by adding support of loading local policy files for editing and
providing export functionality.

I imagine there would be a pop-up that will allow user to build the
expression with support for:
1. Building nested expression using AND OR and ()
2. Auto-complete that lists:
-  existing rule definition
-  available context variable (like domain_id, user_id, target.token)

Just throwing some ideas around.

This is a good opportunity to engage the new UX project they might have a
better idea how the Expression Builder should look like. :)

Thanks,
Lin

[1]
https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L18-L210
[2]
http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html


On Mon, Aug 3, 2015 at 5:10 AM, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello, folks!

 A word has come to me that on the recent Keystone mid-cycle summit dynamic
 policies have been discussed - as well as the lack of means to edit them in
 UX-friendly manner. I had my own share of editing *_policy.json files
 inside openstack_dashboard/conf and can hardly state it's easy. At least,
 when dynamic policies are fully supported by all OpenStack services we will
 have no longer to edit the same files on every controller node in case of
 HA installations. Still, the problem of editing a single policy file
 remains. AFAIK, the obscurity of policy rules' format had lead may
 deployers to the copy-pasting existing rules with minimal changes - when
 they were meant to a flexible tool for RBAC definitions.

 But I wouldn't write this letter, if I didn't have some kind of solution
 to the task of editing the policies. During my work on Merlin
 framework/Mistral Workbook Builder I've achieved some results that might be
 useful for a Keystone community. More specifically, visual structure and
 type of relations between Workbook entities appeared to me to be similar to
 the entities of Keystone policies. Understanding that some things are
 better seen in dynamic than in static screenshots, I'm sharing the address
 of the VM where the Workbook builder is deployed inside Horizon:
 http://horizon-merlin.mirantis.com/horizon/project/ Credentials are
 demo/demo. Some features like saving the workbooks to db or the rest
 OpenStack control plane are disabled for security reasons, leaving only the
 Workbook Builder UI there.

 I'd like to start the discussion about the extent of reusing Merlin UI
 elements for making a dynamic policies editor.

 __
 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] [neutron][lbaas] Horizon support for neutron-lbaas v2

2015-07-29 Thread Lin Hua Cheng
You have to request access from Piet (copied here) or reach out to folks in
the #openstack-ux room.

-Lin

On Wed, Jul 29, 2015 at 12:22 AM, Samuel Bercovici samu...@radware.com
wrote:

  Hi,

 How do I sign  in to this?

 I am asked for credentials.

 -Sam.





 *From:* Jain, Vivek [mailto:vivekj...@ebay.com]
 *Sent:* Wednesday, July 29, 2015 5:54 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* Tonse, Milan

 *Subject:* Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Initial code for horizon lbaas v2 dashboard submitted:



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



 Thanks,

 vivek



 *From: *Jain, Vivek vivekj...@ebay.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, July 28, 2015 at 6:19 PM
 *To: *OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Tonse, Milan mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Hi Folks,



 Screenshots are uploaded. Please review and leave your feedback:



 https://openstack.invisionapp.com/d/main#/projects/4237816



 Thanks,

 vivek



 *From: *Jain, Vivek vivekj...@ebay.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, July 28, 2015 at 4:14 PM
 *To: *OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Tonse, Milan mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Thanks Doug. We are planning to submit initial review version by end of
 day today.



 Also, we will be uploading LBaaS wireframes for review here:

 https://openstack.invisionapp.com/d/main#/projects/4237816



 Thanks,

 Vivek





 *From: *Doug Wiegley doug...@parksidesoftware.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, July 28, 2015 at 4:04 PM
 *To: *OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Tonse, Milan mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 The repo is now live.  Initial review is here:
 https://review.openstack.org/#/c/206757 , please make any near-term
 reviews dependent on that, unless you’re replacing the skeleton. Vivek,
 when do you think we can get some initial code in there to start iterating
 on?



 Thanks,

 doug





  On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.com wrote:



 A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT)
 in #openstack-lbaas to discuss Horizon LBaaS v2 UI.



 Thanks,

 Vivek



 *From: *Balle, Susanne susanne.ba...@hp.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Wednesday, July 15, 2015 at 10:35 AM
 *To: *Eichberger, German german.eichber...@hp.com, OpenStack
 Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Tonse, Milan mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 I agree with German. Let’s keep things together for now. Susanne



 *From:* Eichberger, German
 *Sent:* Wednesday, July 15, 2015 1:31 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Cc:* Balle, Susanne; Tonse, Milan
 *Subject:* Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Hi,



 Let’s move it into the LBaaS repo that seems like the right place for me —



 Thanks,

 German



 *From: *Jain, Vivek vivekj...@ebay.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, July 14, 2015 at 10:22 AM
 *To: *OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Balle Balle, Susanne susanne.ba...@hp.com, Tonse, Milan 
 mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there
 is a easy way to de-couple lbaas dashboard from horizon? I think that will
 simplify development efforts. What does it take to separate lbaas dashboard
 from horizon?



 Thanks,

 Vivek



 *From: *Akihiro Motoki amot...@gmail.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Tuesday, July 14, 2015 at 10:09 AM
 *To: *OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Cc: *Balle, Susanne susanne.ba...@hp.com, Tonse, Milan 
 mto...@ebay.com
 *Subject: *Re: [openstack-dev] [neutron][lbaas] Horizon support for
 neutron-lbaas v2



 Another option is to create a 

Re: [openstack-dev] [horizon] [stable] Freeze exception

2015-07-28 Thread Lin Hua Cheng
The patch fixes a bug that prevent user from using N1KV network, and the
change is low risk and minimal.

I think it would be good to backport.

Thanks,
Lin

On Tue, Jul 28, 2015 at 3:20 PM, Saksham Varma (sakvarma) 
sakva...@cisco.com wrote:

  Hi all,

  I would like to request for a freeze exception for the this bug:
 https://bugs.launchpad.net/horizon/+bug/1474618

  This is the patch:
 https://review.openstack.org/#/c/206184/

  It’s a critical bug, which has already been merged to master, and needs
 to be back ported to kilo.

  Thanks,
 Saksham

 __
 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] Kilo v3 identity problems

2015-06-03 Thread Lin Hua Cheng
The command requires a domain scoped token.

Did you set the environment variable so that OSC uses a domain scoped
token? This can be done by providing OS_DOMAIN_NAME instead of
OS_PROJECT_NAME.

-Lin

On Wed, Jun 3, 2015 at 9:29 AM, Amy Zhang amy.u.zh...@gmail.com wrote:

 Hi guys,

 I have installed Kilo and try to use identity v3. I am using v3 policy
 file. I changed the domain_id for cloud admin as default. As cloud admin,
 I tried openstack domain list and got the error message saying that I was
 not authorized.

 The part I changed in policy.json:

 cloud_admin: rule:admin_required and domain_id:default,


 The error I got from openstack domain list:

 ERROR: openstack You are not authorized to perform the requested action:
 identity:create_domain (Disable debug mode to suppress these details.)
 (HTTP 403) (Request-ID: req-2f42b1da-9933-4494-9b39-c1664d154377)

 Has anyone tried identity v3 in Kilo? Did you have this problem? Any
 suggestions?

 Thanks
 Amy
 --
 Best regards,
 Amy (Yun Zhang)

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


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


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

2015-04-28 Thread Lin Hua Cheng
Congrats Doug, Rob and Travis! thanks for all the hard work

On Tue, Apr 28, 2015 at 3:57 PM, David Lyle dkly...@gmail.com wrote:

 I am pleased to announce the addition of Doug Fish, Rob Cresswell and
 Travis Tripp to the Horizon Core Reviewer team.

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

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

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

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

 David

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


__
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 token expiration causes user to be logged out

2015-04-14 Thread Lin Hua Cheng
That is the expected behavior. Horizon does not support extendable session
token.

From my understanding on that spec, it would require Horizon to store only
the unscoped token and request for extension of that from keystone.

Horizon is currently dependent on the project scoped token and store that
in the session.

We have to make changes in how project scoped token is managed in Horizon
and just store the unscoped token to support that feature.

-Lin

On Tue, Apr 14, 2015 at 4:26 PM, Brad Pokorny brad_poko...@symantec.com
wrote:

 Hi all,

 When a user is logged into Horizon and the Keystone token expires, I'm
 seeing that the user gets logged out, even though the web session hasn't
 expired.  After some searching around and finding [1], it looks like this
 is expected, as the implementation of Session Extendable Tokens would allow
 applications such as Horizon to fetch another token when the existing token
 expires.

 Is there anything I've missed in the Horizon implementation that would
 currently allow extension of the token?

 [1]
 https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens

 Thanks,
 Brad

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


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


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

2015-04-08 Thread Lin Hua Cheng
Thank you very much for having me in the Keystone Core Reviewer team. I am
very excited to be part of the team.

It has been pleasure a working with the team, everyone has just been so
helpful and supportive. Thank you!!!

I am looking forward for more great results in Liberty.

Cheers,
Lin

On Tue, Apr 7, 2015 at 3:30 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 I am pleased to announce that Lin Hua Cheng has joined the Keystone Core
 Reviewer team. He has been extremely helpful and active in reviewing
 Keystone code changes throughout a number of previous development cycle.
 Lin is also a member of Horizon Core which should help provide a strong
 view on the user experience of the Keystone APIs (and visualizations
 thereof).

 Cheers,
 --Morgan

 __
 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] Failed to set up keystone v3 api for horizon

2015-03-12 Thread Lin Hua Cheng
Hi,

The 'cloud_admin' policy file requires domain-scoped to work to work.

Horizon does not currently support domain scope token yet. So yes, it is a
gap in horizon at the moment.

There are on-going patches to address this in horizon:
- https://review.openstack.org/#/c/141153/
- https://review.openstack.org/#/c/148082/

Dan (esp) prepared a nicely written document on this should eventually work.

-Lin

On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang zhang.lei@gmail.com wrote:

 is there anyone tryed this and successfully?

 On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com wrote:

 Hi guys,

 I am setting up the keytone v3 api. Now I meet a issue about the
 `cloud_admin` policy.

 Base on the
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html
 article, I modify the cloud_admin policy to

 ```
 cloud_admin: rule:admin_required and
 domain_id:ef0d30167f744401a0cbfcc938ea7d63,
 ```

 But the cloud_admin don't work as expected. I failed to open all the
 identity panel ( like http://host/horizon/identity/domains/)
 Horizon tell me Error: Unable to retrieve project list.
 And keystone log warning:

 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
 enforce identity:list_user_projects: {'is_delegated_auth': False,
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
 'consumer_id': None, 'token': KeystoneToken
 (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
 0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
 'trust_id': None}, enforce
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not
 authorized to perform the requested action: identity:list_projects (Disable
 debug mode to suppress these details.)
 ```

 ​I make some debug and found that, the root cause is that the `context`
 variable in keystone has no `domain_id` field( like the above keystone
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
 following. It works as expected.

 ```
 cloud_admin: rule:admin_required and user_id:
 6433222efd78459bb70ad9adbcfac418,
 ```

 I found that in the keystone code[0], the domain_id only exist when it is
 a domain scope. But i believe that the horizon login token is a project
 one( I am not very sure this)

 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')

 ```

 Is it a bug? or some wrong configuration?


 Following is my configuration.


 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```

 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = /etc/openstack-dashboard/
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = 127.0.0.1
 OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
 OPENSTACK_API_VERSIONS = {
  data_processing: 1.1,
  identity: 3,
  volume: 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ```

 ​[0]
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
 ​

 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l




 --
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l

 __
 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] [openstackclient] doodle for meeting time selection

2015-03-04 Thread Lin Hua Cheng
+1

Thanks Doug for setting up the Doodle.

On Wed, Mar 4, 2015 at 8:55 AM, Ian Cordasco ian.corda...@rackspace.com
wrote:

 +1

 On 3/4/15, 08:01, Doug Hellmann d...@doughellmann.com wrote:

 
 
 On Tue, Mar 3, 2015, at 06:17 PM, Dean Troyer wrote:
  On Thu, Feb 26, 2015 at 3:32 PM, Doug Hellmann d...@doughellmann.com
  wrote:
 
   As we discussed in the meeting today, I’ve created a Doodle to
 coordinate
   a good day and time for future meetings. I picked a bunch of options
 based
   on when it looked like there were IRC rooms obviously available. If
 none of
   these options suit us, I can dig harder to find other open times.
  
   http://doodle.com/4uy5w2ehn8y2eayh
 
 
  Thanks Doug.
 
  At this point two times are at the top of the list.  Since one of them
 is
  one hour later than the time we originally proposed and the other is the
  same time on Monday, I propose we declare our first choice to move the
  meeting one hour later to 19:00 UTC on Thursdays in #openstack-meeting.
 
 +1
 
 
  dt
 
  --
 
  Dean Troyer
  dtro...@gmail.com
 
 _
 _
  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] [keystone] Output on stderr

2015-03-04 Thread Lin Hua Cheng
Here's the link to the code review: https://review.openstack.org/#/c/147399/

On Wed, Mar 4, 2015 at 7:17 AM, Dolph Mathews dolph.math...@gmail.com
wrote:



 On Wednesday, March 4, 2015, David Stanek dsta...@dstanek.com wrote:


 On Wed, Mar 4, 2015 at 6:50 AM, Abhishek Talwar/HYD/TCS 
 abhishek.tal...@tcs.com wrote:

 While working on a bug for keystoneclient I have replaced sys.exit with
 return. However, the code reviewers want that the output should be on
 stderr(as sys.exit does). So how can we get the output on stderr.


 The print function allows you to specify a file:

  from __future__ import print_function
  import sys
  print('something to', file=sys.stderr)

 The __future__ import is needed for Python 2.6/2.7 because print was
 changed to a function in Python 3.


 I hope that answers your question. Can we have a link to the bug and/or
 code review?




 --
 David
 blog: http://www.traceback.org
 twitter: http://twitter.com/dstanek
 www: http://dstanek.com


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


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


Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

2015-02-13 Thread Lin Hua Cheng
++ One of the feature that I am looking forward to see in Kilo, this
feature will solve one of the pain points from operators in maintaining the
token db backend.

-Lin

On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli steve...@ca.ibm.com
wrote:

 It would be great to see this land in Kilo, I'll definitely be willing to
 review the code.

 Steve

 Morgan Fainberg morgan.fainb...@gmail.com wrote on 02/13/2015 04:19:15
 PM:

  From: Morgan Fainberg morgan.fainb...@gmail.com
  To: Lance Bragstad lbrags...@gmail.com, OpenStack Development
  Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Date: 02/13/2015 04:24 PM
  Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated
  Encryption (AE) Tokens
 
  On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@gmail.com
  ) wrote:

  Hello all,
 
  I'm proposing the Authenticated Encryption (AE) Token specification
  [1] as an SPFE. AE tokens increases scalability of Keystone by
  removing token persistence. This provider has been discussed prior
  to, and at the Paris summit [2]. There is an implementation that is
  currently up for review [3], that was built off a POC. Based on the
  POC, there has been some performance analysis done with respect to
  the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].
 
  The Keystone team spent some time discussing limitations of the
  current POC implementation at the mid-cycle. One case that still
  needs to be addressed (and is currently being worked), is federated
  tokens. When requesting unscoped federated tokens, the token
  contains unbound groups which would need to be carried in the token.
  This case can be handled by AE tokens but it would be possible for
  an unscoped federated AE token to exceed an acceptable AE token
  length (i.e.  255 characters). Long story short, a federation
  migration could be used to ensure federated AE tokens never exceed a
  certain length.
 
  Feel free to leave your comments on the AE Token spec.
 
  Thanks!
 
  Lance
 
  [1] https://review.openstack.org/#/c/130050/
  [2] https://etherpad.openstack.org/p/kilo-keystone-authorization
  [3] https://review.openstack.org/#/c/145317/
  [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
 
 __
  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
 
  I am for granting this exception as long as it’s clear that the
  following is clear/true:
  * All current use-cases for tokens (including federation) will be
  supported by the new token provider.
  * The federation tokens being possibly over 255 characters can be
  addressed in the future if they are not addressed here (a
  “federation migration” does not clearly state what is meant.
  I am also ok with the AE token work being re-ordered ahead of the
  provider cleanup to ensure it lands. Fixing the AE Token provider
  along with PKI and UUID providers should be minimal extra work in the
 cleanup.
  This addresses a very, very big issue within Keystone as scaling
  scaling up happens. There has been demand for solving token
  persistence for ~3 cycles. The POC code makes this exception
  possible to land within Kilo, whereas without the POC this would
  almost assuredly need to be held until the L-Cycle.
 
  TL;DR, I am for the exception if the AE Tokens support 100% of the
  current use-cases of tokens (UUID or PKI) today.
 
  —Morgan
 
 __
  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] [nova] Feature Freeze Exception Request

2015-02-11 Thread Lin Hua Cheng
+1

The specs has been merged through FFE request, doesn't that mean the BP is
already approved?  Maybe the status of the BP just need to be updated to
reflect the current state.

-Lin

On Wed, Feb 11, 2015 at 9:26 AM, Sajeesh Cimson Sasi sajeesh...@cern.ch
wrote:

  Hello,
I'd like to request a feature freeze exception for the change,
 https://review.openstack.org/#/c/149828/
This change implements NestedQuotaDriver that does the quota
 management in nested projects.

The specs has been merged :*
 https://review.openstack.org/#/c/129420/
 https://review.openstack.org/#/c/129420/*

The blueprint was approved.

 https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api

 But due to Feature Freeze,its status was changed to Pending
 Approval .

 Keystone already supports nested projects. This change implements the
 quota  management  of those nested projects. Without this
 change(NestedQuotaDriver), Nova will not be able to support nested
 projects,even if they exist in keystone.NestedQuotaDriver is made by adding
 nested quota functionality to the existing DbQuotaDriver. It is a superset
 of DbQuotaDriver and its supports one to N levels of projects.That is,it
 can support nested as well as non-nested projects.

 The implementation of NestedQuotaDriver is over and the code is under
 review. All the use cases mentioned in the blue print have been
 implemented. It is supposed to become the default quota driver of nova.To
 avoid any potential risks,it can be deployed as an optional driver in the
 current release(Kilo) and can be made default in the next release(L).

 Kindly grant freeze exception for the change.Nested projects are very
 important for large organizations like CERN who are waiting for this code
 to get merged in Kilo.Yahoo also has  expressed keen interest in this
 feature.

   best regards
sajeesh

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


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


Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team

2015-02-10 Thread Lin Hua Cheng
+1 Well deserved!

Lin

On Tue, Feb 10, 2015 at 11:47 AM, Priti Desai priti_de...@symantec.com
wrote:

 +1

 Cheers
 Priti

 From: Brad Topol bto...@us.ibm.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Tuesday, February 10, 2015 at 11:04 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Keystone] Proposing Marek Denis for the
 Keystone Core Team

 +1!  Marek has been an outstanding Keystone contributor and reviewer!

 --Brad


 Brad Topol, Ph.D.
 IBM Distinguished Engineer
 OpenStack
 (919) 543-0646
 Internet:  bto...@us.ibm.com
 Assistant: Kendra Witherspoon (919) 254-0680



 From:David Stanek dsta...@dstanek.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:02/10/2015 12:58 PM
 Subject:Re: [openstack-dev] [Keystone] Proposing Marek Denis for
 the Keystone Core Team
 --



 +1

 On Tue, Feb 10, 2015 at 12:51 PM, Morgan Fainberg 
 *morgan.fainb...@gmail.com* morgan.fainb...@gmail.com wrote:
 Hi everyone!

 I wanted to propose Marek Denis (marekd on IRC) as a new member of the
 Keystone Core team. Marek has been instrumental in the implementation of
 Federated Identity. His work on Keystone and first hand knowledge of the
 issues with extremely large OpenStack deployments has been a significant
 asset to the development team. Not only is Marek a strong developer working
 on key features being introduced to Keystone but has continued to set a
 high bar for any code being introduced / proposed against Keystone. I know
 that the entire team really values Marek’s opinion on what is going in to
 Keystone.

 Please respond with a +1 or -1 for adding Marek to the Keystone core team.
 This poll will remain open until Feb 13.

 --
 Morgan Fainberg

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




 --
 David
 blog: *http://www.traceback.org* http://www.traceback.org/
 twitter: *http://twitter.com/dstanek* http://twitter.com/dstanek
 www: *http://dstanek.com* http://dstanek.com/
 __
 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] static files handling, bower/

2015-01-06 Thread Lin Hua Cheng
Radomir,

The current version of Angular were using in Horizon still does not have
cookie and mock packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data

We still need to do it the long way:
1. Update the Angular version in global-requirements
2. Wait till it gets merge and propagate to horizon requirements
3. Remove references loading of mock and cookie packages in horizon and
horizon requirement
4. Remove mock and cookie from global-requirements.

-Lin

On Tue, Jan 6, 2015 at 1:00 AM, Radomir Dopieralski openst...@sheep.art.pl
wrote:

 On 06/01/15 01:39, Tripp, Travis S wrote:
  What Radomir proposes looks like it would greatly ease the process I am
 still going through to get the latest angular available to Horizon for
 current development.  At the time of writing this, I’m still trying to get
 the updated library through.  I hit a rather difficult workflow:
 
 
1.  Packaged the latest into Xstatic-Angular-1.3.7
2.  Submitted patch which deprecated the separate older
 xstatic-angular-cookies and xstatic-angular-mock packages
3.  Reviewed and approved (after correcting an initial mis-repackaging)
4.  Radomir released to Pypi
 
  This was pretty easy and not too hard. Not too much to complain about.
 
  However, now, to get Horizon to use it, I have to get that into global
 requirements.  Since I’m deprecating old packages I got stuck in a sort of
 ugly dependency path.  I couldn’t remove the cookies and mock libraries
 from the global requirements patch that added the new 1.3.7 package because
 of horizon still referencing the deprecated packages.  And, when I did it
 anyway, the integration tests failed due to horizon being dependent on
 something not in global requirements.  So, now, as far as I can tell we
 have to jump through the following hoops:
 
 
1.  Global requirements patch to add angular 1.3.7
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
2.  Horizon patch to update to angular 1.3.7 and remove deprecated
 mock and cookies packages
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
3.  Global requirements patch to remove deprecated mock and cookies
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
 
  Don’t get me wrong, I really do think the gate is brilliant and am all
 for a review / approval process, but this does seem excessive for a UI
 library that should only be used by Horizon. Is there some other reason
 that this should have to go through global requirements?

 You can do it much easier, since the current version of Angular already
 packages what is in the deprecated modules. So just:

 1. Patch Horizon to remove the xstatic dependencies to the mock and
 cookies packages.
 2. Patch global-requirements to remove them, and add newer Angular.
 3. Patch Horizon to use the newer Angular.

 --
 Radomir Dopieralski

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

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


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

2014-12-12 Thread Lin Hua Cheng
Consolidating them would break it for users that have customization and
extension on the two templates.

-Lin

On 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.

 David

 On 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 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.org
 From: David Lyle dkly...@gmail.com
 Date: 12/11/2014 09:23AM
 Subject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to
 dashboard


 I'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.

 David


 On 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.org
 From: Thai Q Tran/Silicon Valley/IBM
 Date: 12/10/2014 03:37PM
 Subject: Moving _conf and _scripts to dashboard

 The way we are structuring our javascripts today is complicated. All of
 our static javascripts reside in /horizon/static and are imported through
 _conf.html and _scripts.html. Notice that there are already some panel
 specific javascripts 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 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 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] Moving _conf and _scripts to dashboard

2014-12-12 Thread Lin Hua Cheng
Breaking 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.org
 From: Lin Hua Cheng os.lch...@gmail.com
 Date: 12/12/2014 10:28AM

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

 Consolidating them would break it for users that have customization and
 extension on the two templates.

 -Lin

 On 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.

 David

 On 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 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.org
 From: David Lyle dkly...@gmail.com
 Date: 12/11/2014 09:23AM
 Subject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to
 dashboard


 I'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.

 David


 On 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.org
 From: Thai Q Tran/Silicon Valley/IBM
 Date: 12/10/2014 03:37PM
 Subject: Moving _conf and _scripts to dashboard

 The way we are structuring our javascripts today is complicated. All of
 our static javascripts reside in /horizon/static and are imported through
 _conf.html and _scripts.html. Notice that there are already some panel
 specific javascripts 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 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 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]

2014-11-25 Thread Lin Hua Cheng
+1 for both!

Yep, thanks for all the hard work!

On Tue, Nov 25, 2014 at 1:35 PM, Ana Krivokapic akriv...@redhat.com wrote:


 On 25/11/14 00:09, David Lyle wrote:
  I am pleased to nominate Thai Tran and Cindy Lu to horizon-core.
 
  Both Thai and Cindy have been contributing significant numbers of high
  quality reviews during Juno and Kilo cycles. They are consistently
  among the top non-core reviewers. They are also responsible for a
  significant number of patches to Horizon. Both have a strong
  understanding of the Horizon code base and the direction of the project.
 
  Horizon core team members please vote +1 or -1 to the
  nominations either in reply or by private communication. Voting will
  close on Friday unless I hear from everyone before that.
 
  Thanks,
  David
 
 

 +1 for both.

 Cindy and Thai, thanks for your hard work!

 --
 Regards,

 Ana Krivokapic
 Software Engineer
 OpenStack team
 Red Hat Inc.


 ___
 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] Separate horizon and openstack_dashboard

2014-11-17 Thread Lin Hua Cheng
On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote:
 Le 17/11/2014 14:19, Matthias Runge a écrit :

 There is already horizon on pypi[1]

 IMHO this will lead only to more confusion.

 Matthias


 [1] https://pypi.python.org/pypi/horizon/2012.2

 Well the current horizon on Pypi is The OpenStack Dashboard +
 horizon(_lib) included

 If the future horizon on pypi is openstack_dashboard alone, it would
 still pull horizon_lib as a dependency, so it would not brake the
 existing.

 So indeed the horizon package itself in Pypi would not have
 horizon(_lib) in it anymore, but he pip install horizon would pull
 everything due to the dependency horizon will have with horizon_lib.

 I find this the least confusing issue and the horizon package on Pypi
 would still be seen as The OpenStack Dashboard like it is now. We
 would only add an horizon_lib package on Pypi.
 Therefore existing third-party requirements.txt would not brake
 because they would pull horizon_lib with horizon. and they would still
 import the proper module. Every backwards compatibility (requirements
 and module) is therefore preserved.


+1 on this proposal as well

On Mon, Nov 17, 2014 at 6:00 PM, Jason Rist jr...@redhat.com wrote:

 On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote:
  Le 17/11/2014 14:19, Matthias Runge a écrit :
 
  There is already horizon on pypi[1]
 
  IMHO this will lead only to more confusion.
 
  Matthias
 
 
  [1] https://pypi.python.org/pypi/horizon/2012.2
 
  Well the current horizon on Pypi is The OpenStack Dashboard +
  horizon(_lib) included
 
  If the future horizon on pypi is openstack_dashboard alone, it would
  still pull horizon_lib as a dependency, so it would not brake the
  existing.
 
  So indeed the horizon package itself in Pypi would not have
  horizon(_lib) in it anymore, but he pip install horizon would pull
  everything due to the dependency horizon will have with horizon_lib.
 
  I find this the least confusing issue and the horizon package on Pypi
  would still be seen as The OpenStack Dashboard like it is now. We
  would only add an horizon_lib package on Pypi.
  Therefore existing third-party requirements.txt would not brake
  because they would pull horizon_lib with horizon. and they would still
  import the proper module. Every backwards compatibility (requirements
  and module) is therefore preserved.
 
 

 +1 to this solution

 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Management UI
 Red Hat, Inc.
 openuc: +1.972.707.6408
 mobile: +1.720.256.3933
 Freenode: jrist
 github/identi.ca: knowncitizen

 ___
 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