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

[Douglas Fish]

+1 for both Richard and Timur. Great additions to the team!
Doug Fish
 
 
- Original message -From: "Chen, Shaoquan" To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-coreDate: Wed, Dec 2, 2015 2:03 PM 
+1 for both Timur and Richard!On 12/2/15, 10:57 AM, "David Lyle"  wrote:>Let's try that again.>>I propose adding Richard Jones[1] to horizon-core.>>Over the last several cycles Richard has consistently been providing>great reviews, actively participating in the Horizon community, and>making meaningful contributions around angularJS and overall project>stability and health.>>Please respond with comments, +1s, or objections within one week.>>Thanks,>David>>[1]>http://stackalytics.com/?module=horizon-group&user_id=r1chardj0n3s&release>=all>>On Wed, Dec 2, 2015 at 11:56 AM, David Lyle  wrote:>> I propose adding Richard Jones[1] to horizon-core. Over the last several cycles Timur has consistently been providing>> great reviews, actively participating in the Horizon community, and>> making meaningful contributions around angularJS and overall project>> stability and health. Please respond with comments, +1s, or objections within one week. Thanks,>> David [1]>>http://stackalytics.com/?module=horizon-group&user_id=r1chardj0n3s&releas>>e=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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

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

[Douglas Fish]

I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future:
1) When we are creating a panel that's a major refactor of an existing it should be a new separate panel, not a direct code replacement of the existing panel
2) New panels (include the refactors of existing panels) should be developed in an out of tree gerrit repository.
 
Why make refactors a separate panel?
 
I was taken a bit off guard after we merged the Network Topology->Curvature improvement: this was a surprise to some people outside of the Horizon community (though it had been discussed within Horizon for as long as I've been on the project). In retrospect, I think it would have been better to keep both the old Network Topology and new curvature based topology in our Horizon codebase. Doing so would have allowed operators to perform A-B/ Red-Black testing if they weren't immediately convinced of the awesomeness of the panel. It also would have allowed anyone with a customization of the Network Topology panel to have some time to configure their Horizon instance to continue to use the Legacy panel while they updated their customization to work with the new panel.
 
Perhaps we should treat panels more like an API element and take them through a deprecation cycle before removing them completely. Giving time for customizers to update their code is going to be especially important as we build angular replacements for python panels. While we have much better plugin support for angular there is still a learning curve for those developers.
 
Why build refactors and new panels out of tree?
 
First off, it appears to me trying to build new panels in tree has been fairly painful. I've seen big long lived patches pushed along without being merged. It's quite acceptable and expected to quickly merge half-complete patches into a brand new repository - but you can't behave that way working in tree in Horizon. Horizon needs to be kept production/operator ready. External repositories do not. Merging code quickly can ease collaboration and avoid this kind of long lived patch set.
 
Secondly, keeping new panels/plugins in a separate repository decentralizes decisions about which panels are "ready" and which aren't. If one group feels a plugin is "ready" they can make it their default version of the panel, and perhaps put resources toward translating it. If we develop these panels in-tree we need to make a common decision about what "ready" means - and once it's in everyone who wants a translated Horizon will need to translate it.
 
Finally, I believe developing new panels out of tree will help improve our plugin support in Horizon. It's this whole "eating your own dog food" idea. As soon as we start using our own Horizon plugin mechanism for our own development we are going to become aware of it's shortcomings (like quotas) and will be sufficiently motivated to fix them.
 
Looking forward to further discussion and other ideas on this!
Doug Fish


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

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

[Douglas Fish]

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 AllOne of my students, Anton Brida, has developed an Attribute Mapping GUIfor Horizon as part of his MSc project. Attribute mappings are anessential, though complex, part of federated Keystone. Currently theycan only be created as JSON objects in the config file. The Horizon codeallows them to be dynamically created via an easy to use GUI.Since Anton has now left the university for full time employment, he isnot able to go through the process of submitting his code to the nextrelease of Horizon. His design however was submitted to InVision andcommented 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 codeand go through the process of submitting this to the next release ofHorizon. I have a copy of Anton's MSc dissertation as well whichexplains the work that he has done.All the attribute mapping features are supported in Anton's code(groups, users, direct mapping, multiple attribute values etc.)However the whitelist/blacklist feature is not, since this was not fullyincorporated into Keystone when Anton was doing his implementation. (Iam still not sure if it has been.)The code has a couple of known bugs:1. when a user tries to enter an email address into an attribute value(i.e. usern...@example.com) and saves the mapping rule into thedatabase, after reloading the new list of mappings rules the interfacedoes not work as intended. The particular reason why this is happeningis yet unknown. The only way to avoid such disruption is to delete thefaulty mapping rule from the table. After removing the faulty rule theinterface works as intended.2. Some of the descriptive text needs improvement due to incorrect grammar.There is also the following suggested enhancement which can be added later:1. After the mapping rules are created with the GUI, when they aredisplayed, they are still in JSON format. It would be nice to be able todisplay the rules in a table or similar.If you would like to take on the job of submitting this code to Horizonfor review and incorporation, please contact meregardsDavid__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 


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

[openstack-dev] [openstack-infra] format/pep8 checks for translations?

[Douglas Fish]

Right now translations can't be merged into Horizon because of a formatting error:
https://bugs.launchpad.net/openstack-i18n/+bug/1494914
 
Daisy and the i18n team have been responsive and are actively working to fix this. Thanks for your efforts!
 
I'm sharing here because this seems to me to be a very obscure and technical issue for the translators to have to manage. Although this problem is originating today in the Transifex translation, the same problem exists in our Zanata translations.
 
It is possible to enhance/configure/extend Zanata to have PEP8 style formatting checks to prevent translations like this from being submitted?
Doug


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

Re: [openstack-dev] [Horizon]Let's take care of our integrationtests

[Douglas Fish]

Also some info available at
 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/integration_tests/README.rst
 
to point out needed config
Doug
 
 
- Original message -From: David Lyle To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [Horizon]Let's take care of our integration testsDate: Fri, Sep 11, 2015 11:39 AM 
Of course, your question confused me. As you switched to selenium tests.To run integration tests,./run_tests.sh --integrationwhich is also documented in ./run_tests.sh --helpDavidOn Fri, Sep 11, 2015 at 10:25 AM, David Lyle  wrote:> Oops!>> ./run_tests.sh --only-selenium   only skips the non-selenium tests. It> works as intended.  ./run_tests.sh --with-selenium will run all tests.> Both of which are documented in the help of run_tests.sh>> David>> On Fri, Sep 11, 2015 at 10:23 AM, David Lyle  wrote:>> raj>>>> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig  wrote:>>> Is there any documentation to run the tests locally?>>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the>>> recommended way?>>>>>> -Rajat>>>>>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle  wrote:>>>>>>>> I completely agree about monitoring for integration test failures and>>>> blocking until the failure is corrected.>>>>>>>> The hope is to make sure we've stabilized the integration testing>>>> framework a bit before reenabling to vote.>>>>>>>> Thanks Timur, I know this has been a considerable undertaking.>>>>>>>> David>>>>>>>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:>>>> > It looks like we've reached the point where our Horizon integration>>>> > tests>>>> > are functional again.  Thanks for your work on this Timur! (Offer for>>>> > beer/hug at the next summit still stands)>>>> >>>>> > I'd like to have these tests voting again ASAP, but I understand that>>>> > might>>>> > be a bit risky at this point. We haven't yet proven that these tests>>>> > will be>>>> > stable over the long term.>>>> >>>>> > I encourage all of the reviewers to keep the integration tests in mind>>>> > as we>>>> > are reviewing code. Keep an eye on the status of the>>>> > gate-horizon-dsvm-integration test. It's failure would be great reason>>>> > to>>>> > hand out a -1!>>>> >>>>> > Doug>>>> >>>>> >>>>> >>>>> > __>>>> > OpenStack Development Mailing List (not for usage questions)>>>> > Unsubscribe:>>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>>> >>>>>>>>> __>>>> OpenStack Development Mailing List (not for usage questions)>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>>>>>>>>>>> __>>> OpenStack Development Mailing List (not for usage questions)>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>>__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 


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

[openstack-dev] [Horizon]Let's take care of our integration tests

[Douglas Fish]

It looks like we've reached the point where our Horizon integration tests
are functional again.  Thanks for your work on this Timur! (Offer for
beer/hug at the next summit still stands)

I'd like to have these tests voting again ASAP, but I understand that might
be a bit risky at this point. We haven't yet proven that these tests will
be stable over the long term.

I encourage all of the reviewers to keep the integration tests in mind as
we are reviewing code. Keep an eye on the status of the
gate-horizon-dsvm-integration test. It's failure would be great reason to
hand out a -1!

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

Re: [openstack-dev] [horizon][i18n] Horizon plugins translation

[Douglas Fish]

I took a quick look at the projects Daisy listed. None of them are ready to
be translated yet.

Manila UI and Tuskar UI
These projects don't have PO/POT files yet. In order to be ready they need
to start with step 1 from Daisy's note.

Horizon Cisco UI
Has a locale file
https://github.com/openstack/horizon-cisco-ui/tree/master/horizon_cisco_ui/cisco/locale
I don't see a Horizon-Cisco-UI project in either transifex or zanata (step
2 from Daisy's note).

I'm looking at this page
https://wiki.openstack.org/wiki/Translations/Infrastructure
and it doesn't seem to be up to date with any Zanata-based information.

How would these teams go about implementing steps 2 and 3 if they want to
be available to be translated?

Doug Fish


Ying Chun Guo  wrote on 08/25/2015 04:21:14 AM:

> From: Ying Chun Guo 
> To: OpenStack Development Mailing List

> Date: 08/25/2015 04:27 AM
> Subject: [openstack-dev] [horizon][i18n] Horizon plugins translation
>
> Hi,
>
> I see there are several UI plugins in Horizon, which are in
> OpenStack projects.yaml.
> They are: horizon-cisco-ui, manila-ui and tuskar-ui.
> They are using separated repo now.
>
> As the translation coordinator, I want to understand
> which of them want to be translated into multiple languages in
> Liberty release.
> Are they ready to be translated ?
>
> As a separated repo, if these plugins want to be translated,
> they need to:
> 1. Create locale folder and generate pot files in the repo
> 2. Create project in translation tool
> 3. Create auto jobs to upload pot files and download translations
> from translation tool.
>
> Please let me know your thoughts.
>
> Best regards
> Ying Chun Guo (Daisy)
>
__
> 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

[Douglas Fish]

Hi David,

This is a cool looking UI. I've made a minor comment on it in InVision.

I'm curious if this is an implementable idea - does keystone support large
numbers of 3rd party idps? is there an API to retreive the list of idps or
does this require carefully coordinated configuration between Horizon and
Keystone so they both recognize the same list of idps?

Doug Fish


David Chadwick  wrote on 08/01/2015 06:01:48 AM:

> From: David Chadwick 
> To: OpenStack Development Mailing List

> Date: 08/01/2015 06:05 AM
> Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
>
> 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] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Douglas Fish]

I think another important question is how to represent this to the user on
the login screen. "Keystone Endpoint:" matches the setting, but seems like
a weird choice to me. Is there a better terminology to use for the label
for this on the login screen?

I see the related selector has no label at all in the header. Maybe using
the same label there would be a good idea.

Doug

Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM:

> From: Thai Q Tran/Silicon Valley/IBM@IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 07/09/2015 01:17 PM
> Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> of 'region' entity: finding better names for them
>
> Had the same issue when I worked on the context selection menu for
> switching domain and project. I think it make sense to rename it to
> AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its
> going to affect some folks (maybe even break) until they also update
> their setting, something that would have to be done manually.
>
> -Jay Pipes  wrote: -
> To: openstack-dev@lists.openstack.org
> From: Jay Pipes 
> Date: 07/08/2015 07:14AM
> Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> of 'region' entity: finding better names for them

> Got it, thanks for the excellent explanation, Timur! Yeah, I think
> renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.
>
> Best,
> -jay
>
> On 07/08/2015 09:53 AM, Timur Sufiev wrote:
> > Hi, Jay!
> >
> > As Doug said, Horizon regions are just different Keystone endpoints
that
> > Horizon could use to authorize against (and retrieve the whole catalog
> > from any of them afterwards).
> >
> > Another example of how complicated things could be: imagine that
Horizon
> > config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
> > http://keystone.europe and http://keystone.asia, each of them hosting a
> > different catalog with service endpoint pointing to Europe/Asia located
> > services. For European Keystone all Europe-based services are marked as
> > 'RegionOne', for Asian Keystone all its Asia-based services are marked
> > as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
> > region, for European Keystone the Asian services are marked so, for
> > Asian Keystone the opposite is true. One of customers did roughly the
> > same thing (with both Keystones using common LDAP backend), and
> > understanding what exactly in Horizon didn't work well was a puzzling
> > experience.
> >
> > On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes  > > wrote:
> >
> > On 07/08/2015 08:50 AM, Timur Sufiev wrote:
> >  > Hello, folks!
> >  >
> >  > Somehow it happened that we have 2 different kinds of regions:
the
> >  > service regions inside Keystone catalog and AVAILABLE_REGIONS
setting
> >  > inside Horizon, yet use the same name 'regions' for both of
them.
> > That
> >  > creates a lot of confusion when solving some
region-relatedissues at
> >  > the Horizon/Keystone junction, even explaining what is exactly
being
> >  > broken poses a serious challenge when our common language has
> > such a flaw!
> >  >
> >  > I propose to invent 2 distinct terms for these entities, so at
> > least we
> >  > won't be terminologically challenged when fixing the related
bugs.
> >
> > Hi!
> >
> > I understand what the Keystone region represents: a simple,
> > non-geographically-connotated division of the entire OpenStack
> > deployment.
> >
> > Unfortunately, I don't know what the Horizon regions represent.
Could
> > you explain?
> >
> > Best,
> > -jay
> >
> >
>
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >

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


_

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Douglas Fish]

Timur Sufiev  wrote on 07/08/2015 07:50:49 AM:

> From: Timur Sufiev 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 07/08/2015 07:53 AM
> Subject: [openstack-dev] [horizon] [keystone] [docs] Two kinds of
> 'region' entity: finding better names for them
>
> Hello, folks!
>
> Somehow it happened that we have 2 different kinds of regions: the
> service regions inside Keystone catalog and AVAILABLE_REGIONS
> setting inside Horizon, yet use the same name 'regions' for both of
> them. That creates a lot of confusion when solving some region-
> related issues at the Horizon/Keystone junction, even explaining
> what is exactly being broken poses a serious challenge when our
> common language has such a flaw!
>
> I propose to invent 2 distinct terms for these entities, so at least
> we won't be terminologically challenged when fixing the related bugs.
>
__
> 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

Hey Timur, thanks for starting this discussion!

I just had some confusion over this within the last few weeks as well. I
think that Horizon's use of regions to reference service regions in the
keystone catalog is the "correct" usage and the one we should maintain.

AVAILABLE_REGIONS is a Horizon setting that lets you configure multiple
independent keystone endpoints to be known to Horizon.
http://docs.openstack.org/developer/horizon/topics/settings.html
I don't think that's the usual meaning of "Region" in OpenStack, but
Horizon has labelled both the service catalog and multiple keystone related
widgets in the UI as "Regions". I guess we just hope people don't enable
both, or can guess the meaning from the values.

Doug



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

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

[Douglas Fish]

Anne Gentle  wrote on 05/14/2015 09:47:25
AM:

> From: Anne Gentle 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 05/14/2015 10:08 AM
> Subject: Re: [openstack-dev] [horizon][keystone][heat] Are
> "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?
>
> On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold 
wrote:
> +1
>
> There seems to be a significant disconnect between Heat, Horizon and
> Keystone on the subject of multi-region configurations, and the
> documentation isn’t helpful. At the very least, it would be useful
> if discussions at the summit could result in a decent Wiki page on
> the subject.
>
> We have a cross-project session and spec started about the service
catalog:
>
> https://review.openstack.org/#/c/181393/
>
> http://sched.co/3BL3
>
> I hope more than a wiki page comes of it. :)
> Anne
>
>
> Geoff
>
> On May 13, 2015, at 9:49 PM, Morgan Fainberg  > wrote:
>
>
> On May 13, 2015, at 21:34, David Lyle  wrote:

>
> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné  wrote:
> When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
> your "region" which is in fact "your keystone endpoint".
>
> Once logged in, you get a new dropdown at the top right to switch
> between the "keystone endpoints". This means you can configure an
> Horizon installation to login to multiple independent OpenStack
> installations.
>
> So I don't fully understand what "enhancing the multi-region support in
> Keystone" would mean. Would you be able to configure Horizon to login to
> multiple independent OpenStack installations?
>
> Mathieu
>
> On 2015-05-13 5:06 PM, Geoff Arnold wrote:
> > Further digging suggests that we might consider deprecating
> > AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
> > Keystone. It wouldn’t take a lot; the main points:
> >
> >   * Implement the Regions API discussed back in the Havana time period
> >     - https://etherpad.openstack.org/p/havana-availability-zone-
> and-region-management -
> >     but with full CRUD
> >   * Enhance the Endpoints API to allow filtering by region
> >
> > Supporting two different multi region models is problematic if we’re
> > serious about things like multi-region Heat.
> >
> > Thoughts?
> >
> > Geoff
> >
> >> On May 13, 2015, at 12:01 PM, Geoff Arnold  >> > wrote:
> >>
> >> I’m looking at implementing dynamically-configured multi-region
> >> support for service federation, and the prior art on multi-region
> >> support in Horizon is pretty sketchy. This thread:
> >>
http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
> >> is the only real discussion I’ve found, and it’s pretty inconclusive.
> >>
> >> More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
> >> pointing at two different Keystones with region names “X” and “Y", and
> >> each of those Keystones returns a service catalog with multiple
> >> regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
> >> Horizon going to do? Or rather, what’s it expected to do?
> >>
> >> Yes, I’m being lazy: I could actually configure this to see what
> >> happens, but hopefully it was considered during the design.
> >>
> >> Geoff
> >>
> >> PS I’ve added Heat to the subject, because from a quick read of
> >> https://wiki.openstack.org/wiki/Heat/Blueprints/
> Multi_Region_Support_for_Heat
> >> it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
> >> seems like an unfortunate disconnect.
> >>
> >>
> >>
>
> Horizon only supports authenticating to one keystone endpoint at a
> time, specifically to one of the entries in AVAILABLE_REGIONS as
> defined in settings.py. Once you have an authenticated session in
> Horizon, the region selection support is merely for filtering
> between regions registered with the keystone endpoint you
> authenticated to, where the list of regions is determined by parsing
> the service catalog returned to you with your token.
>
> What's really unclear to me is what you are intending to ask.
>
> AVAILABLE_REGIONS is merely a list of keystone endpoints. They can
> be backed by a different IdP per endpoint and thus not share a token
> store. Or, they can just be keystone endpoints that are
> geographically different but backed by the same IdP, which may or
> may not share a token store. The funny thing is, for Horizon, it
> doesn't matter. They are all supported.  But as one keystone
> endpoint may not know about another, unless nested, this has to be
> done with settings as it's not typically discoverable.
>
> If you are asking about token sharing between keystones which the
> thread you linked seems to indicate. Then yes, you can have a synced
> token store. But that is an exercise left to the operator.
>
> I'd like to quickly go on record and say that a token store sync
> like this is not recommended. It is possible to work around this in
> Kilo with some limited data sync (resource, assignment) and the use
> of

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

[Douglas Fish]

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

Hope to see you there!

Doug


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

Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)

[Douglas Fish]

Steve Martinelli  wrote on 03/17/2015 12:52:33 AM:

> From: Steve Martinelli 
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 03/17/2015 12:55 AM
> Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth
> for new mechanisms (websso, kerberos, k2k etc)
>
> I like proposal 1 better, but only because I am already familiar
> with how plugins interact with keystoneclient. The websso work is (i
> think) pretty close to getting merged, and could easily be tweaked
> to use a token plugin (when it's ready). I think the same can be
> said for our k2k issue, but I'm not sure.
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> Jamie Lennox  wrote on 03/15/2015 10:52:31 PM:
>
> > From: Jamie Lennox 
> > To: OpenStack Development Mailing List

> > Date: 03/15/2015 10:59 PM
> > Subject: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for
> > new mechanisms (websso, kerberos, k2k etc)
> >
> > Hi All,
> >
> > Please note when reading this that I have no real knowledge of django
so
> > it is very possible I'm overlooking something obvious.
> >
> > ### Issue
> >
> > Django OpenStack Auth (DOA) has always been tightly coupled to the
> > notion of a username and password.
> > As keystone progresses and new authentication mechanisms become
> > available to the project we need a way to extend DOA to keep up with
it.
> > However the basic processes of DOA are going to be much the same, it
> > still needs to fetch an unscoped token, list available projects and
> > handle rescoping and this is too much for every extension mechanism to
> > reimplement.
> > There is also a fairly tight coupling between how DOA populates the
> > request and sets up a User object that we don't really want to reuse.
> >
> > There are a couple of authentication mechanisms that are currently
being
> > proposed that are requiring this ability immediately.
> >
> > * websso: https://review.openstack.org/136178
> > * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2).
> >
> > and to a certain extent:
> >
> > * k2k: https://review.openstack.org/159910
> >
> > Enabling and using these different authentication mechanisms is going
to
> > need to be configured by an admin at deployment time.
> >
> > Given that we want to share the basic scoping/rescoping logic between
> > these projects I can essentially see two ways to enable this.
> >
> > ### Proposal 1 - Add plugins to DOA
> >
> > The easiest way I can see of doing this is to add a plugin model to the
> > existing DOA structure.
> > The initial differentiating component for all these mechanisms is the
> > retrieval of an unscoped token.
> >
> > We can take the existing DOA structure and simply make that part
> > pluggable and add interfaces to that plugin as required in the future.
> >
> > Review: https://review.openstack.org/#/c/153910/
> >
> > Pros:
> >
> > * Fairly simple and extensible as required.
> > * Small plugin interface.
> >
> > Cons:
> >
> > * Ignores that django already has an authentication plugin system.
> > * Doesn't work well for adding views that run these backends.
> >
> > ### Proposal 2 - Make the existing DOA subclassable.
> >
> > The next method is to essentially re-use the existing Django
> > authentication module architecture.
> > We can extract into a base class all the current logic around token
> > handling and develop new modules around that.
> >
> > Review: https://review.openstack.org/#/c/164071/
> > An example of using it:
> > https://github.com/jamielennox/django-openstack-auth-kerberos
> >
> > Pros:
> >
> > * Reusing Django concepts.
> > * Seems easier to handle adding of views.
> >
> > Cons:
> >
> > * DOA has to start worrying about public interfaces.
> >
> > ### Required reviews:
> >
> > Either way I think these two reviews are going to be required to make
> > this work:
> >
> > * Redirect to login page: https://review.openstack.org/#/c/153174/ - If
> > we want apache modules to start handling parts of auth we need to mount
> > those at dedicated paths, we can't put kerberos login at /
> > * Additional auth urls: https://review.openstack.org/#/c/164068/ - We
> > need to register additional views so that we can handle the output of
> > these apache modules and call the correct authenticate() parameters.
> >
> > ### Conclusion
> >
> > Essentially either of these could work and both will require some
> > tweaking and extending to be useful in all situations.
> >
> > However I am kind of passing through on DOA and Django and would like
> > someone with more experience in the field to comment on what feels more
> > correct or any issues they see arising with the different approaches.
> > Either way I think a clear approach on extensibility would be good
> > before committing to any of the kerberos, websso and k2k definitions.
> >
> >
> > Please let me know an opinion as there are multiple patches that will
> > depend upon it.
> >
> >
> > Thanks,
> >
> > Jamie
> >
> >
> >
> >
__

Re: [openstack-dev] #PERSONAL# : Facing problem in installing new python dependencies for Horizon- Pls help

[Douglas Fish]

Swati Shukla1  wrote on 12/14/2014 11:29:19 PM:

> From: Swati Shukla1 
> To: openstack-dev@lists.openstack.org
> Date: 12/14/2014 11:34 PM
> Subject: [openstack-dev] #PERSONAL# : Facing problem in installing
> new python dependencies for Horizon- Pls help
>
> Hi,
>
> I want to install 2 new modules in Horizon but have no clue how it
> installs in its virtualenv.
>
> I mentioned pisa >= 3.0.33 and reportlab >= 2.5 in requirements.txt
> file, ran ./unstack.sh and ./stack.sh, but still do not get these
> installed in its virtualenv.
>
> As a result, when I do ./run_tests.sh, I get " ImportError: No
> module named ho.pisa"
>
> Please suggest me if I am going wrong somewhere or how to proceed with
this.
>
> Thanks in advance.
>
> Regards,
> Swati Shukla
> Tata Consultancy Services
> Mailto: swati.shuk...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank
you___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

run_tests.sh --force
will reinstall the virtual environment and will be up the added modules


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

Re: [openstack-dev] django-pyscss failing with Django 1.7

[Douglas Fish]

Hi Thomas,

I have a few suggestions inline that I hope will be helpful!

> From: Matt Riedemann 
> To: Douglas Fish/Rochester/IBM@IBMUS, Justin Pomeroy/Rochester/IBM@IBMUS
> Date: 09/30/2014 10:26 PM
> Subject: Fwd: Re: [openstack-dev] django-pyscss failing with Django 1.7
>
> FYI in case one of you can provide some guidance. Thomas is a Debian
> packager.
>
>
>  Original Message 
> Subject: Re: [openstack-dev] django-pyscss failing with Django 1.7
> Date: Tue, 30 Sep 2014 14:03:50 +0800
> From: Thomas Goirand 
> Reply-To: OpenStack Development Mailing List (not for usage questions)
> 
> Organization: Debian
> To: OpenStack Development Mailing List (not for usage questions)
> 
>
> On 09/30/2014 10:10 AM, Thomas Goirand wrote:
> > Since the latest commit before the release of version 1.0.3,
> > django-pyscss fails in Sid:
> >
> > https://github.com/fusionbox/django-pyscss/commit/
> 187a7a72bf72370c739f3675bef84532e524eaf1
> >
> > The issue is that storage.prefix doesn't seem to exist anymore in
Django
> > 1.7.

I'm not sure that's really your root cause.  It seems like it _should_
exist.
I think it comes from
https://github.com/django/django/blob/master/django/contrib/staticfiles/finders.py#L71

What error message do you see?

> >
> > Does anyone have an idea how to fix this? Would it be ok to just revert
> > that commit in my Debian package?

Have you engaged with the django_pyscss guys at
https://github.com/fusionbox/django-pyscss ?
They were helpful and responsive to me when I interacted with them.

> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
>
> I produced this patch:
> http://anonscm.debian.org/cgit/openstack/python-django-pyscss.git/
> tree/debian/patches/fix-storage.prefix-not-found.patch

It looks like an accurate revert to me.  At first glance I don't see why
its functionally different.  Do you know why the revert works?

>
> Does this look correct? I really would appreciate peer review, as I'm
> really not sure of what I'm doing. The only thing I know, it that it's
> looking like it's passing all unit tests, including the prefix one.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>

Doug Fish


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

Re: [openstack-dev] [Horizon] SCSS conversion and SCSS upgrade patches

[Douglas Fish]

It's possible that the only purpose of this discussion will be to fix my
thinking, but I still can't understand why we are so anxious to integrate a
patch that makes Horizon look funny.  I expect the patch Radomir has our
for review will be quite stable.  People should be able to contribute work
based on it now using dependent patches.
https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency   Once we
have a set of patches with good Horizon behavior we can merge the set.

Doug Fish

Jason Rist  wrote on 06/30/2014 09:22:20 AM:

> From: Jason Rist 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc: Douglas Fish/Rochester/IBM@IBMUS
> Date: 06/30/2014 09:22 AM
> Subject: Re: [openstack-dev] [Horizon] SCSS conversion and SCSS
> upgrade patches
>
> On Mon 30 Jun 2014 08:09:40 AM MDT, Douglas Fish wrote:
> >
> > I had an IRC discussion with jtomasek and rdopieralski recently
regarding
> > Radomir's patch for converting to SCSS bootstrap.
> > https://review.openstack.org/#/c/90371/   We were trying to sort out
how
> > soon this patch should merge.  We'd like to discuss this at the team
> > meeting tomorrow, but I'm sharing here to get an initial discussion
> > started.
> >
> > It seems that in this version of bootstrap SCSS had some bugs.  They
are
> > low impact, but pretty obvious bugs - I saw mouseover styling and
disable
> > button styling problems.
> >
> > The most straightforward fix to this is to upgrade bootstrap.  I
understand
> > that Jiri is working on that this week, and would like to have the SCSS
> > patch merged ASAP to help with that effort.
> >
> > My feeling is that we shouldn't merge the SCSS patch until we have a
> > bootstrap patch ready to merge.  I'd like to see dependent patches used
to
> > manage this so we can get both changes reviewed and merged at the same
> > time.
> >
> > Radomir has shared that he thinks dependent patches are too painful to
use
> > for this situation.  Also he'd like to see the SCSS bootstrap patch
merged
> > ASAP because the horizon split depends on that work as well.
> >
> > Doug Fish
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I agree with Radomir and will voice that same opinion during the
> meeting.  Lets get the SCSS patch up, and then everyone can contribute
> to improvements, not just Jiri.
>
> -J
>
> --
> 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] [Horizon] SCSS conversion and SCSS upgrade patches

[Douglas Fish]

I had an IRC discussion with jtomasek and rdopieralski recently regarding
Radomir's patch for converting to SCSS bootstrap.
https://review.openstack.org/#/c/90371/   We were trying to sort out how
soon this patch should merge.  We'd like to discuss this at the team
meeting tomorrow, but I'm sharing here to get an initial discussion
started.

It seems that in this version of bootstrap SCSS had some bugs.  They are
low impact, but pretty obvious bugs - I saw mouseover styling and disable
button styling problems.

The most straightforward fix to this is to upgrade bootstrap.  I understand
that Jiri is working on that this week, and would like to have the SCSS
patch merged ASAP to help with that effort.

My feeling is that we shouldn't merge the SCSS patch until we have a
bootstrap patch ready to merge.  I'd like to see dependent patches used to
manage this so we can get both changes reviewed and merged at the same
time.

Radomir has shared that he thinks dependent patches are too painful to use
for this situation.  Also he'd like to see the SCSS bootstrap patch merged
ASAP because the horizon split depends on that work as well.

Doug Fish


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

Re: [openstack-dev] [Horizon][Tuskar-UI] Location for common dashboard code?

[Douglas Fish]

Hey Tzu-Mainn,

I've actually discouraged people from doing this sort of thing when
customizing Horizon.  IMO it's risky to extend those panels because they
really aren't intended as extension points.  We intend Horizon to be
extensible by adding additional panels or dashboards.  I know you are
closely involved in Horizon development, so you are better able to manage
that better than most customizers.

Still, I wonder if we can better address this for Tuskar-UI as well as
other situations by defining extensibility points in the dashboard panels
and workflows themselves.  Like well defined ways to add/show a column of
data, add/hide row actions, add/skip a workflow step, override text
elements, etc.  Is it viable to create a few well defined extension points
and meet your need to modify existing dashboard panels?

In any case, it seems to me that if you are overriding the dashboard
panels, it's reasonable that tuskar-ui should be dependent on the
dashboard.

Doug Fish





From:   Tzu-Mainn Chen 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date:   05/28/2014 11:40 AM
Subject:[openstack-dev] [Horizon][Tuskar-UI] Location for common
dashboard   code?



Heya,

Tuskar-UI is currently extending classes directly from openstack-dashboard.
For example, right now
our UI for Flavors extends classes in both
openstack_dashboard.dashboards.admin.flavors.tables and
openstack_dashboard.dashboards.admin.flavors.workflows.  In the future,
this sort of pattern will
increase; we anticipate doing similar things with Heat code in
openstack-dashboard.

However, since tuskar-ui is intended to be a separate dashboard that has
the potential to live
away from openstack-dashboard, it does feel odd to directly extend
openstack-dashboard dashboard
components.  Is there a separate place where such code might live?
Something similar in concept
to
https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage
?


Thanks,
Tzu-Mainn Chen

___
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] [Horizon]Atlanta Summit Sunday Evening Unofficial Meetup Plan

[Douglas Fish]

The Horizon team is planning an informal meet up before the Atlanta summit.
We're still working out the time and place.  Discussion is happening here:
https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening


Doug Fish


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

Re: [openstack-dev] [Horizon] Accessibility

[Douglas Fish]

Great article Liz!   Verifying contrast ratios is another aspect of
ensuring accessibility.  I've added the link you shared to the
accessibility wiki.

Doug Fish




From:   Liz Blanchard 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date:   05/05/2014 09:21 AM
Subject:Re: [openstack-dev] [Horizon] Accessibility




On Apr 24, 2014, at 11:06 AM, Douglas Fish  wrote:


  I've proposed a design session for accessibility for the Juno summit,
  and
  I'd like to get a discussion started on the work that needs to be
  done.
  (Thanks Julie P for pushing that!)

  I've started to add information to the wiki that Joonwon Lee created:
  https://wiki.openstack.org/wiki/Horizon/WebAccessibility
  I think that's going to be a good place to gather material.  I'd like
  to
  see additional information added about what tools we can use to
  verify
  accessibility.  I'd like to try to summarize the WCAG guidelines into
  some
  broad areas where Horzion needs work.  I expect to add a checklist of
  accessibility-related items to consider while reviewing code.

  Joonwon (or anyone else with an interest in accessibility):  It would
  be
  great if you could re-inspect the icehouse level code and create bugs
  for
  any issues that remain.  I'll do the same for issues that I am aware
  of.
  In each bug we should include a link to the WCAG guideline that has
  been
  violated.  Also, we should describe the testing technique:  How was
  this
  bug discovered?  How could a developer (or reviewer) determine the
  issue
  has actually been fixed?  We should probably put that in each bug at
  first,
  but as we go they should be gathered up into the wiki page.

  There are some broad areas of need that might justify blueprints (I'm
  thinking of WAI-ARIA tagging, and making sure external UI widgets
  that we
  pull in are accessible).

  Any suggestions on how to best share info, or organize bugs and
  blueprints
  are welcome!

Doug,

Thanks very much for bringing this up as a topic and pushing it forward at
Summit. I think this will be a great step forward for Horizon in maturity
as we continue to have better accessibility support. I wanted to throw out
any article that I found helpful when it comes to testing sites for
accessibility for colorblindness:
http://css-tricks.com/accessibility-basics-testing-your-page-for-color-blindness/

I think we can make some very small/easy changes with the color scheme to
be sure there is enough contrast to target all types of colorblindness.

Looking forward to this session,
Liz


  Doug Fish
  IBM STG Cloud Solution Development
  T/L 553-6879, External Phone 507-253-6879


  ___
  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] [Horizon] Accessibility: testing with the keyboard

[Douglas Fish]

An easy way to get started identifying accessibility problems is to test
using the keyboard.  I've made a small update to the wiki describing what
to do:  https://wiki.openstack.org/wiki/Horizon/WebAccessibility

I've open our first accessibility bug, and it's related to keyboard
testing:  https://bugs.launchpad.net/horizon/+bug/1315488

There are a couple of other easy to discover bugs related to keyboard
access.  I've left them undocumented for people who might want to start
trying out some accessibility testing.  Happy Hunting!

Doug Fish


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

[openstack-dev] [Horizon] Accessibility

[Douglas Fish]

I've proposed a design session for accessibility for the Juno summit, and
I'd like to get a discussion started on the work that needs to be done.
(Thanks Julie P for pushing that!)

I've started to add information to the wiki that Joonwon Lee created:
https://wiki.openstack.org/wiki/Horizon/WebAccessibility
I think that's going to be a good place to gather material.  I'd like to
see additional information added about what tools we can use to verify
accessibility.  I'd like to try to summarize the WCAG guidelines into some
broad areas where Horzion needs work.  I expect to add a checklist of
accessibility-related items to consider while reviewing code.

Joonwon (or anyone else with an interest in accessibility):  It would be
great if you could re-inspect the icehouse level code and create bugs for
any issues that remain.  I'll do the same for issues that I am aware of.
In each bug we should include a link to the WCAG guideline that has been
violated.  Also, we should describe the testing technique:  How was this
bug discovered?  How could a developer (or reviewer) determine the issue
has actually been fixed?  We should probably put that in each bug at first,
but as we go they should be gathered up into the wiki page.

There are some broad areas of need that might justify blueprints (I'm
thinking of WAI-ARIA tagging, and making sure external UI widgets that we
pull in are accessible).

Any suggestions on how to best share info, or organize bugs and blueprints
are welcome!

Doug Fish
IBM STG Cloud Solution Development
T/L 553-6879, External Phone 507-253-6879


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

Re: [openstack-dev] [Horizon] web accessibility issues

[Douglas Fish]

Hi Joowon, Stackers,

Joowon, thanks for initiating this discussion.  Web accessibility is a
priority for my company as well.  I've taken a quick look at Icehouse
horizon and share similar concerns.  later, I'm going to go to your wiki
page and share my concerns and thoughts.

I have experience with web accessibility, but I'm still quite new to the
Horizon project.  Part of my long term interest in the project is to see
Horizon become accessible.  I look forward to being involved in
accessibility work.

Below are my initial, unprocessed notes on accessibility issues I've
informally observed.  I expect to turn these into bug reports or blueprints
and I get a better understanding of the project.
Several Tables:
- more button doesn't show focus
- more menu doesn't close when focus is elsewhere
- column headers don't have tabstops
- filter button traps keyboard

Overview:
- calendar widget isn't reachable (in date range selection)
- calendar widget never closes once its opened via tabbing

Modal Dialog:
- can tab outside of the "modal" dialog (observed on Domains, but I suspect
its a global issue)
- cancel button is not tabbable

I don't see wai-aria tagging anywhere.  It's really needed on divs that are
used as widgets, like the more button pop-up - I assume but haven't
verified this will cause problems with screen readers.

I _think_ horizon uses jqueryUI widgets which aren't accessible.  This guy
has forked a set of accessible jQueryUI widgets, but I'm not sure that
helps us any:
http://hanshillen.github.io/jqtest/#goto_dialog

It does look like bootstrap is committed to accessibility.  Maybe this will
be a path to getting accessible widgets?

Doug Fish
IBM STG Cloud Solution Development
T/L 553-6879, External Phone 507-253-6879




From:   Joonwon Lee 
To: openstack-dev@lists.openstack.org,
Date:   01/23/2014 01:39 AM
Subject:[openstack-dev]  [Horizon] web accessibility issues



Dear stackers,
We inspected the Horizon (Havana release) for web accessibility and
found the following problems, as it's required by our domestic standards.

1.1.1 Non-text Contents
- A few non-text contents such as Network Topology (for Neutron) and
  Resource Usage (for Ceilometer) have no text alternatives.

1.3.1 Info and Relationships
- There is no caption element, summary attribute in tables such as
  instances, volumes, images, so on.
- There is no scope attribute in th elements.

1.4.3 Contrast (Minimum)
- text color and background color in the left menu
- text color and background color in the top menu
- link color and background color in the main content area
- text color and background color of the some buttons

2.1.1 Keyboard
- It's not easy to handle the layered message window by keyboard only.
- It may be difficult for a blind person to notice this layered error
  message.

2.4.1 Bypass Blocks
- There is no mechanism to skip repeated contents such as menu.
  For example, we can add a link at the top of each page that goes
  directly to the main content area.

2.4.3 Focus Order
- The order of navigation doesn't match the visual order in some cases.
- The focus movement is not restricted to the layered pop-up window.

3.1.1 Language of Page
- There is no lang attribute on the html element.

3.3.2 Labels or Instructions
- Is it better to use label element to associate text labels with
  input elements?

The above items are in the WCAG 2.0 W3C Recommendation:
http://www.w3.org/TR/WCAG20/ (Web Content Accessibility Guidelines 2.0)

I'd like to discuss in public how to solve these issues in the Horizon
with the people who have the similar interests. However, I'm not an expert
on this issues at all. Please correct me if I'm wrong at any points.

I also created the wiki page. Feel free to edit it.
https://wiki.openstack.org/wiki/Horizon/WebAccessibility

Looking forward to seeing the reply from who wants to use the Horizon
in the public cloud service. Thanks for your consideration.

Regards,
Joonwon Lee, Samsung SDS
___
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