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_id=r1chardj0n3s>=all>>On Wed, Dec 2, 2015 at 11:56 AM, David Lyle  wrote:>> I propose adding Richard Jones[1] to horizon-core. Over the last several cycles Timur has consistently been providing>> great reviews, actively participating in the Horizon community, and>> making meaningful contributions around angularJS and overall project>> stability and health. Please respond with comments, +1s, or objections within one week. Thanks,>> David [1]>>http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s>>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 <dkly...@gmail.com>To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>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 <dkly...@gmail.com> 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 <dkly...@gmail.com> wrote:>> raj>>>> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig <raj...@thoughtworks.com> 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 <dkly...@gmail.com> 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 <drf...@us.ibm.com> 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 guoyi...@cn.ibm.com wrote on 08/25/2015 04:21:14 AM:

 From: Ying Chun Guo guoyi...@cn.ibm.com
 To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
 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 d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM:

 From: David Chadwick d.w.chadw...@kent.ac.uk
 To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
 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\)
 openstack-dev@lists.openstack.org
 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 jaypi...@gmail.com wrote: -
 To: openstack-dev@lists.openstack.org
 From: Jay Pipes jaypi...@gmail.com
 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 jaypi...@gmail.com
  mailto:jaypi...@gmail.com 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
__
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

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


__
OpenStack Development 

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

[Douglas Fish]

Anne Gentle annegen...@justwriteclick.com wrote on 05/14/2015 09:47:25
AM:

 From: Anne Gentle annegen...@justwriteclick.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 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 ge...@geoffarnold.com
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 morgan.fainb...@gmail.com
  wrote:


 On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com wrote:


 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com 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 ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com 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 Fernet tokens. 

[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 steve...@ca.ibm.com wrote on 03/17/2015 12:52:33 AM:

 From: Steve Martinelli steve...@ca.ibm.com
 To: OpenStack Development Mailing List \(not for usage questions\)
 openstack-dev@lists.openstack.org
 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 jamielen...@redhat.com wrote on 03/15/2015 10:52:31 PM:

  From: Jamie Lennox jamielen...@redhat.com
  To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
  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
 
 
 
 
__
  OpenStack Development Mailing List (not for usage 

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

[Douglas Fish]

Swati Shukla1 swati.shuk...@tcs.com wrote on 12/14/2014 11:29:19 PM:

 From: Swati Shukla1 swati.shuk...@tcs.com
 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 mrie...@linux.vnet.ibm.com
 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 z...@debian.org
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Organization: Debian
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 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

[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] 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 jr...@redhat.com wrote on 06/30/2014 09:22:20 AM:

 From: Jason Rist jr...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 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]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 lsure...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/05/2014 09:21 AM
Subject:Re: [openstack-dev] [Horizon] Accessibility




On Apr 24, 2014, at 11:06 AM, Douglas Fish drf...@us.ibm.com 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