Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Richard Jones]

Unfortunately none of this discussion solves the substantive issue which is
that we cannot release an xstatic package without breaking the gate.

We currently have one solution that's a close to viable as we've been able
to get: move the version pinning for xstatic packages out of
upper-constraints and into Horizon's repository, and hope that the
app-catalog server and Horizon stay in step or that they're never installed
on the same debian/redhat system (or if they *are* then one of them is
installed in a virtualenv).


 Richard


On 17 March 2016 at 19:00, Thomas Goirand  wrote:

> On 03/17/2016 07:23 AM, Richard Jones wrote:
> > There's a basic difference here though. Your traditional "installed
> > components" are pieces of software and data used *by programs on that
> > system.*
> >
> > The components we're talking about here are, as far as the system is
> > concerned, opaque data to be transmitted over HTTP(S) to a web browser
> > client which then makes use of that data in some manner.
> >
> > There are no cross-program compatibility issues stemming from having
> > multiple different versioned copies of such client-side files on a
> > system
>
> The same way, we could have multiple version of fonts, tzdata, SSL root
> certificates and so on. There wouldn't be any compatibility issues.
> Though it's still not the right thing to do at a distribution level.
>
> Have you noticed also that in the Windows world, each program carries
> its .dll, which are supposed to be shared object, but in fact, they
> aren't shared? Yes, it is easier to do so.
>
> > - this is why the web development world has standardised on
> > tooling that *makes it easy to do so*. Different client-side web
> > applications *should* be able to use different versions of components.
>
> The same was as for shared .so libraries, that's not the correct way to
> do things. Even though the JavaScript objects aren't executed by the
> system (well, if we forget that nodejs exists), there's still potential
> bugs and security problems with them, and they may require maintenance.
>
> > xstatic shoe-horns that freedom of client-side application component
> > usage into a one-size-must-fit-all world that fundamentally only exists
> > because programs on a system can get confused when multiple versions are
> > installed on that system[1].
>
> I wouldn't say it this way. To me, they are just tools which makes it
> easy for us to stop the duplication madness of the same files.
>
> Have a look:
> # apt-file search jquery.js | grep -v doc | wc -l
> 128
>
> This is 127 bugs which should be fixed currently with the embedded
> jquery. I hardly see how one could argue this is a good thing. I hope we
> can be better citizens than this.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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] How do we move forward with xstatic releases?

[Richard Jones]

On 13 March 2016 at 07:06, Matthias Runge  wrote:

> On 10/03/16 08:46, Richard Jones wrote:
> > On 10 March 2016 at 18:23, Matthias Runge  > > wrote:
> >
> > 4.alt.2:
> > move to proper packages for static file management. I mean, they
> need to
> > be built anyways.
> >
> >
> > Please define what you mean by "proper packages" here. I *think* you
> > might mean system packages (aka Debian or Red Hat) which is not feasible
> > given other environments that Horizon runs under. Please correct me if
> > I'm wrong!
>
> Exactly. I mean system packages. If there are issues with system
> packages, then let's address the issue rather than re-inventing the wheel.
>

OK, the sticking point is that installation through system packages alone
forces us to make all software on a system work with a single version of
any given library. This has spawned the global-requirements and now
upper-constraints systems in OpenStack, and ultimately leads to the
problematic race condition that resulted in me starting this email thread.
That is, we can update *either* the version of a library being used *or*
the software that is compatible with that version *but not the two at the
same time, atomically*.



> Weren't we just talking about providing dependencies for the gate?


Well, partially, because the reason the problem surfaces is because of the
Continuous Deployment guarantee that OpenStack makes, which is enforced by
the gate, so sure, let's say it's the gate's fault 



> I mean, for production, it's quite the same situation we are at the
> moment. Nobody requires you to install Horizon and dependencies
> especially via rpm, deb or pip: Take what you want.
>

I'm not sure it's this simple, is it? Folks want to be able to install
OpenStack from a single source, and that seems reasonable. They want to be
able to do that "offline" too, so that rules out bower as a source of
packages.



> > It has been mentioned, xstatic packages can block the gate. We
> currently
> > control xstatic package releases, thus we can roll back, if something
> > goes wrong.
> >
> > If we're pulling directly with npm/bower, someone from the outside
> can
> > break us. We already have the situation with pypi packages.
> > With proper packages, we could even use the gate to release those
> > packages and thus verify, we're not breaking anyone.
> >
> >
> > We're going to have potential breakage (gate breakage, in the integrated
> > tests) any time we release a package (regardless of release mechanism)
> > and have to update two separate repositories resulting in out-of-sync
> > version specification and expectation (ie. upper-constraints
> > specification and Horizon's code expectation) as described in my OP. The
> > only solution that we're aware of is to synchronise updating those two
> > things, through one of the mechanisms proposed so far (or possibly
> > through a mechanism not yet proposed.)
> >
>
> Yes, and my proposal to address this is to gate updating/releasing
> dependencies the same way we're currently gating each change in horizon.
>

This is not going to solve the race condition I mention; it's actually
during our work implementing gating these releases that we found we had to
solve this problem.



> > 1. Horizon maintains its own constrained version list for the xstatic
> > packages,
> > 2. Plugins to Horizon must depend on Horizon to supply xstatic packages
> > except where they use additional packages that Horizon does not use, and
> > 3. We avoid installing app-catalog (the system, not the plugin) in the
> > integrated tests (I don't believe doing this is even on the ...
> > "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged)
> > system that also has Horizon installed. Or we try to convince
> > app-catalog to stay lock-step with Horizon's xstatic versions. I
> > understand the risk of a collision between app-catalog and Horizon in
> > the same system-packaged environment is very low.
>
> I don't really see a chance for app-catalog to require Horizon as a
> dependency and different versions of xstatic packages. This would be an
> immediate show-stopper for app-catalog either on Debian or on RPM based
> systems.
>

I think I used the wrong word above. Where I said "system" I probably
should have said "server". app-catalog the stand-alone server should not
depend on Horizon, just app-catalog the plugin to Horizon should (like all
Horizon plugins should).



> Let me repeat myself: you're free to install dependencies as you like,
> npm, bower, whatever. I was simply speaking about the gate and about
> gating dependencies to be sure, we're not broken by someone from outside.


Again, I don't believe we have the freedom to actually install dependencies
as we like, as I said above.


  Richard
__
OpenStack Development Mailing List (not for 

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/17/2016 07:12 AM, Richard Jones wrote:
> On 13 March 2016 at 07:11, Matthias Runge  > wrote:
> 
> On 10/03/16 11:48, Beth Elwell wrote:
> > If we will anyway have potential breakage I don’t understand why the
> > better solution here would not be to just use the bower and npm tools
> > which are standardised for JavaScript and would move Horizon more
> > towards using widely recognised tooling from within not just Openstack
> > but the wider development community. Back versions always need to be
> > supported for a time, however I would add that long term this could end
> > up saving time and create a stable longer term solution.
> >
> 
> I have a few issues with those "package managers":
> - downloads are not verified, there is a chance of getting a "bad"
> download.
> - they are pointing to the outside world, like to github etc. While they
> appear to work "most of the time", that might not good enough for
> the gate
> - how often have we been blocked by releases of software not managed by
> OpenStack? Seriously, that happens quite a few times over a release
> cycle, not to mention breakages by releases of our own tools turning out
> to block one or the other sub-project
> 
> 
> To be fair to those package managers,  the issues OpenStack has had with
> releases of libraries breaking things is a result of us either:
> 
> a) not pinning releases (upper-constraints now fixes that for *things
> that use it*, which isn't everything, sadly) or
> b) the system that tests upper-constraints changes not having broad
> enough testing across OpenStack for us to notice when a new library
> release breaks things. I would like to increase the inclusion of
> Horizon's test suite in the constraints testing for this reason. At
> least, it's on my TODO :-)
> 
> Horizon, for example, currently does *not* use the upper-constraints
> pinning in its test suite or installation, so we're vulnerable to, say,
> a python-*client release that's not compatible. I have a patch in the
> works to address this, but it kinda depends on us moving over from
> run_tests.sh to tox, which is definitely something to wait until N for.

Thanks for this work. I'm looking forward to it. Do you also have in the
pipe to stop using nose / python -m coverage, and switch to testr?

Cheers,

Thomas Goirand (zigo)


__
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] How do we move forward with xstatic releases?

[Richard Jones]

On 14 March 2016 at 11:08, Thomas Goirand  wrote:
>
> From a distribution package maintainer perspective, the most annoying
> part is that there's no easy way to get the web app use the JS libs from
> the OS, and there's no system wide registry of installed components.
>

There's a basic difference here though. Your traditional "installed
components" are pieces of software and data used *by programs on that
system.*

The components we're talking about here are, as far as the system is
concerned, opaque data to be transmitted over HTTP(S) to a web browser
client which then makes use of that data in some manner.

There are no cross-program compatibility issues stemming from having
multiple different versioned copies of such client-side files on a system -
this is why the web development world has standardised on tooling that
*makes it easy to do so*. Different client-side web applications *should*
be able to use different versions of components.

xstatic shoe-horns that freedom of client-side application component usage
into a one-size-must-fit-all world that fundamentally only exists because
programs on a system can get confused when multiple versions are installed
on that system[1].


Richard

[1] I note that OS X packaging solved that problem too, but let's not go
there 
__
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] How do we move forward with xstatic releases?

[Matthias Runge]

On 17/03/16 08:59, Thomas Goirand wrote:

>>
>> Horizon, for example, currently does *not* use the upper-constraints
>> pinning in its test suite or installation, so we're vulnerable to, say,
>> a python-*client release that's not compatible. I have a patch in the
>> works to address this, but it kinda depends on us moving over from
>> run_tests.sh to tox, which is definitely something to wait until N for.
> 
> Thanks for this work. I'm looking forward to it. Do you also have in the
> pipe to stop using nose / python -m coverage, and switch to testr?

There is basic testr support[1], and Itxaka has a patch up[2], to
replace run_tests.sh completely with tox.



[1]
https://github.com/openstack/horizon/commit/ab9e5d94af2b15eef39f8f971a7a0c9778883a4b
[2] https://review.openstack.org/#/c/259013/
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Richard Jones]

On 11 March 2016 at 04:37, Michael Krotscheck  wrote:

> On Wed, Mar 9, 2016 at 12:45 PM Tripp, Travis S 
> wrote:
>
>> The problem is that the warnings are so great that is really hard to read.
>>
>
> If all the warnings were fixed - I know Matt Borland's working on that -
> would we be having this conversation?
>

My position was that I didn't want Matt to waste his valuable time editing
a bunch of JSDoc when we might end up having to go through and re-edit it
to some other form. We've busy enough with Mitaka release issues during
these weeks without needing to be bothered by fixing ignorable some jsdoc
lint warnings (and they are ignorable - nothing currently cares about the
syntax of our Javascript comments *except* the linter).


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/17/2016 07:23 AM, Richard Jones wrote:
> There's a basic difference here though. Your traditional "installed
> components" are pieces of software and data used *by programs on that
> system.*
> 
> The components we're talking about here are, as far as the system is
> concerned, opaque data to be transmitted over HTTP(S) to a web browser
> client which then makes use of that data in some manner.
> 
> There are no cross-program compatibility issues stemming from having
> multiple different versioned copies of such client-side files on a
> system

The same way, we could have multiple version of fonts, tzdata, SSL root
certificates and so on. There wouldn't be any compatibility issues.
Though it's still not the right thing to do at a distribution level.

Have you noticed also that in the Windows world, each program carries
its .dll, which are supposed to be shared object, but in fact, they
aren't shared? Yes, it is easier to do so.

> - this is why the web development world has standardised on
> tooling that *makes it easy to do so*. Different client-side web
> applications *should* be able to use different versions of components.

The same was as for shared .so libraries, that's not the correct way to
do things. Even though the JavaScript objects aren't executed by the
system (well, if we forget that nodejs exists), there's still potential
bugs and security problems with them, and they may require maintenance.

> xstatic shoe-horns that freedom of client-side application component
> usage into a one-size-must-fit-all world that fundamentally only exists
> because programs on a system can get confused when multiple versions are
> installed on that system[1].

I wouldn't say it this way. To me, they are just tools which makes it
easy for us to stop the duplication madness of the same files.

Have a look:
# apt-file search jquery.js | grep -v doc | wc -l
128

This is 127 bugs which should be fixed currently with the embedded
jquery. I hardly see how one could argue this is a good thing. I hope we
can be better citizens than this.

Cheers,

Thomas Goirand (zigo)


__
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] How do we move forward with xstatic releases?

[Richard Jones]

On 13 March 2016 at 07:11, Matthias Runge  wrote:

> On 10/03/16 11:48, Beth Elwell wrote:
> > If we will anyway have potential breakage I don’t understand why the
> > better solution here would not be to just use the bower and npm tools
> > which are standardised for JavaScript and would move Horizon more
> > towards using widely recognised tooling from within not just Openstack
> > but the wider development community. Back versions always need to be
> > supported for a time, however I would add that long term this could end
> > up saving time and create a stable longer term solution.
> >
>
> I have a few issues with those "package managers":
> - downloads are not verified, there is a chance of getting a "bad"
> download.
> - they are pointing to the outside world, like to github etc. While they
> appear to work "most of the time", that might not good enough for the gate
> - how often have we been blocked by releases of software not managed by
> OpenStack? Seriously, that happens quite a few times over a release
> cycle, not to mention breakages by releases of our own tools turning out
> to block one or the other sub-project


To be fair to those package managers,  the issues OpenStack has had with
releases of libraries breaking things is a result of us either:

a) not pinning releases (upper-constraints now fixes that for *things that
use it*, which isn't everything, sadly) or
b) the system that tests upper-constraints changes not having broad enough
testing across OpenStack for us to notice when a new library release breaks
things. I would like to increase the inclusion of Horizon's test suite in
the constraints testing for this reason. At least, it's on my TODO :-)

Horizon, for example, currently does *not* use the upper-constraints
pinning in its test suite or installation, so we're vulnerable to, say, a
python-*client release that's not compatible. I have a patch in the works
to address this, but it kinda depends on us moving over from run_tests.sh
to tox, which is definitely something to wait until N for.


 Richard

ps. as for "unverified downloads" ... they're verified precisely as much as
pypi packages are, and we install a whole buncha those :-)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Cindy Lu]

Thank you so much David! You've done an *exceptional* job making Horizon
great! Look forward to continuing to work alongside you (your knowledge of
past/present/future is unmatched!).

Regards,
Cindy



From:   Zhenguo Niu <niu.zgli...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   03/14/2016 07:04 PM
Subject:        Re: [openstack-dev] [horizon] PTL noncandidacy



David,

Thanks for your commitment and leadership, really appreciated all the help
from you!

On Tue, Mar 15, 2016 at 5:41 AM, Diana Whitten <hurgleburg...@gmail.com>
wrote:
  David,

  I don't envy the person who has to fill these shoes.  You've been
  amazing!

  - Diana

  On Mon, Mar 14, 2016 at 1:04 PM, Timur Sufiev <tsuf...@mirantis.com>
  wrote:
   David,

   It's sad news for us, and a well-deserved vacation from bureaucratic
   hassles for you! Will try hard to not break Horizon in your absence.

   On Mon, 14 Mar 2016 at 22:46, Doug Fish <the.doug.f...@gmail.com> wrote:
 David, congratulations on a job well done!

 Doug

 On Mar 14, 2016, at 8:39 AM, Liz Blanchard <lsure...@redhat.com>
 wrote:



   On Fri, Mar 11, 2016 at 12:19 PM, David Lyle <dkly...@gmail.com>
   wrote:
After five cycles as PTL of Horizon, I've decided not to run
for the
Newton cycle.

   David,

   Thank you for everything you've done for Horizon, especially
   around helping push a focus on User Experience.

   Best,
   Liz


I am exceptionally proud of the things we've accomplished over
this
time. I'm amazed by how much our project's community has grown
and
evolved.

Looking at the community now, I believe we have a tremendous
group of
contributors for moving forward. There are several people
capable of
becoming great PTLs and overall the community will be healthier
with
some turnover in the PTL role. I feel honored to have had your
trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

David


__

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

   
__

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

 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




--
Best Regards,
Zhenguo Niu
__
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-dev] [horizon] PTL candidacy

[Rob Cresswell (rcresswe)]

Hi folks,

I'm announcing my candidacy for PTL for Horizon for the Newton release cycle.

My main goals for the cycle are:

- Remove roadblocks from AngularJS development so that the code can
  mature. This means optimistically approving patches in the experimental
  disabled panels, so that it can be rapidly iterated. The Swift rewrite is a
  fantastic example of how focused reviews and dropping the demand for
  absolute perfection allow for a dramatically improved experience via
  AngularJS.

- Work on scale issues, and improve non-performant content. There are a number
  of panels in Horizon that are often unused (especially in the Admin
  dashboard). We need to apply the existing tools available to us such as
  pagination and filtering, as well as investigate other proposals.

- Improve bug management and project organisation. In the past few cycles, the
  bugs and blueprints on launchpad have been quickly growing while triage work
  dwindles. In Mitaka, we've run several bug days as well as holding a Horizon
  Drivers meeting every other week to analyse blueprints as a group. I'd like
  to continue the focus on bringing our tooling back to useable state, so that
  we correctly address current issues and customer needs.

Finally, I believe one of the most important parts of being a PTL is community
engagement, and will continue to build an active and positive developer
community.

Election repo patch: https://review.openstack.org/#/c/293083/

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

[openstack-dev] [horizon] remove 'external' option from router rules grid

[Aditya Vaja]

Hi,  
  
I wanted to bring attention to the router rules grid on the horizon GUI.  
Currently, we have 'external' and 'any' as two different options on the router
rules grid: github.com/openstack/horizon/blob/stable/liberty/openstack_dashboa
rd/dashboards/project/routers/extensions/routerrules/tabs.py#L110-L121  
  
But their CIDR representation is 0.0.0.0/0. Would it make sense to to have
just a single option 'any'?  
If we apply a permit or deny based on 'external', we essentially apply it for
the 'any', since the CIDR is the same. And if the user wants, they override it
with more specific rules (/16 or /24) for the subnets.  
If there are real use cases that do use the external option, I'd like to hear
about it.  
If not, I'd like to propose the change to remove 'external' option from the
grid and submit a patch for it.  
  
What would be the process to get  comments on this and merge the change?  
  
[Full Disclosure: I work at Big Switch Networks, which acts as one of the
backends for the router rules grid]  
  

\--

Aditya Vaja

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

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

[Zhenguo Niu]

David,

Thanks for your commitment and leadership, really appreciated all the help
from you!

On Tue, Mar 15, 2016 at 5:41 AM, Diana Whitten 
wrote:

> David,
>
> I don't envy the person who has to fill these shoes.  You've been amazing!
>
> - Diana
>
> On Mon, Mar 14, 2016 at 1:04 PM, Timur Sufiev 
> wrote:
>
>> David,
>>
>> It's sad news for us, and a well-deserved vacation from bureaucratic
>> hassles for you! Will try hard to not break Horizon in your absence.
>>
>> On Mon, 14 Mar 2016 at 22:46, Doug Fish  wrote:
>>
>>> David, congratulations on a job well done!
>>>
>>> Doug
>>>
>>> On Mar 14, 2016, at 8:39 AM, Liz Blanchard  wrote:
>>>
>>>
>>>
>>> On Fri, Mar 11, 2016 at 12:19 PM, David Lyle  wrote:
>>>
 After five cycles as PTL of Horizon, I've decided not to run for the
 Newton cycle.

>>>
>>> David,
>>>
>>> Thank you for everything you've done for Horizon, especially around
>>> helping push a focus on User Experience.
>>>
>>> Best,
>>> Liz
>>>
>>>

 I am exceptionally proud of the things we've accomplished over this
 time. I'm amazed by how much our project's community has grown and
 evolved.

 Looking at the community now, I believe we have a tremendous group of
 contributors for moving forward. There are several people capable of
 becoming great PTLs and overall the community will be healthier with
 some turnover in the PTL role. I feel honored to have had your trust
 over this time and lucky to have worked with such great people.

 I will still be around and will help the next PTL make a smooth
 transition where requested.

 David


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

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


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

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

[Diana Whitten]

David,

I don't envy the person who has to fill these shoes.  You've been amazing!

- Diana

On Mon, Mar 14, 2016 at 1:04 PM, Timur Sufiev  wrote:

> David,
>
> It's sad news for us, and a well-deserved vacation from bureaucratic
> hassles for you! Will try hard to not break Horizon in your absence.
>
> On Mon, 14 Mar 2016 at 22:46, Doug Fish  wrote:
>
>> David, congratulations on a job well done!
>>
>> Doug
>>
>> On Mar 14, 2016, at 8:39 AM, Liz Blanchard  wrote:
>>
>>
>>
>> On Fri, Mar 11, 2016 at 12:19 PM, David Lyle  wrote:
>>
>>> After five cycles as PTL of Horizon, I've decided not to run for the
>>> Newton cycle.
>>>
>>
>> David,
>>
>> Thank you for everything you've done for Horizon, especially around
>> helping push a focus on User Experience.
>>
>> Best,
>> Liz
>>
>>
>>>
>>> I am exceptionally proud of the things we've accomplished over this
>>> time. I'm amazed by how much our project's community has grown and
>>> evolved.
>>>
>>> Looking at the community now, I believe we have a tremendous group of
>>> contributors for moving forward. There are several people capable of
>>> becoming great PTLs and overall the community will be healthier with
>>> some turnover in the PTL role. I feel honored to have had your trust
>>> over this time and lucky to have worked with such great people.
>>>
>>> I will still be around and will help the next PTL make a smooth
>>> transition where requested.
>>>
>>> David
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Timur Sufiev]

David,

It's sad news for us, and a well-deserved vacation from bureaucratic
hassles for you! Will try hard to not break Horizon in your absence.
On Mon, 14 Mar 2016 at 22:46, Doug Fish  wrote:

> David, congratulations on a job well done!
>
> Doug
>
> On Mar 14, 2016, at 8:39 AM, Liz Blanchard  wrote:
>
>
>
> On Fri, Mar 11, 2016 at 12:19 PM, David Lyle  wrote:
>
>> After five cycles as PTL of Horizon, I've decided not to run for the
>> Newton cycle.
>>
>
> David,
>
> Thank you for everything you've done for Horizon, especially around
> helping push a focus on User Experience.
>
> Best,
> Liz
>
>
>>
>> I am exceptionally proud of the things we've accomplished over this
>> time. I'm amazed by how much our project's community has grown and
>> evolved.
>>
>> Looking at the community now, I believe we have a tremendous group of
>> contributors for moving forward. There are several people capable of
>> becoming great PTLs and overall the community will be healthier with
>> some turnover in the PTL role. I feel honored to have had your trust
>> over this time and lucky to have worked with such great people.
>>
>> I will still be around and will help the next PTL make a smooth
>> transition where requested.
>>
>> David
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Fish]

David, congratulations on a job well done!

Doug

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

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

[David Lyle]

Welcome Diana. Thanks for all of your hard work and dedication.

David

On Fri, Mar 11, 2016 at 11:51 AM, Akihiro Motoki <amot...@gmail.com> wrote:
> +1 from me too!
>
> 2016-03-11 17:38 GMT+09:00 Tatiana Ovtchinnikova 
> <t.v.ovtchinnik...@gmail.com>:
>> +1. Thanks for your contribution!
>>
>>
>>
>> 2016-03-11 6:40 GMT+03:00 Zhenguo Niu <niu.zgli...@gmail.com>:
>>>
>>> +1 from me, thanks for all the hard work!
>>>
>>> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
>>> wrote:
>>>>
>>>> +1. Another vote in favor of ditching django altogether is good by me :)
>>>>
>>>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>>>>>
>>>>> Big +1 from me, thanks for all the hard work Diana!
>>>>>
>>>>>
>>>>> - Original message -
>>>>> From: David Lyle <dkly...@gmail.com>
>>>>> To: OpenStack Development Mailing List
>>>>> <openstack-dev@lists.openstack.org>
>>>>> Cc:
>>>>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>>>>> horizon-core
>>>>> Date: Tue, Mar 8, 2016 2:07 PM
>>>>>
>>>>> I propose adding Diana Whitten[1] to horizon-core.
>>>>>
>>>>> Diana is an active reviewer, contributor and community member. Over
>>>>> the past couple of releases, Diana has driven extensive changes around
>>>>> theme-ability in Horizon and drastically increased the standardization
>>>>> of our use of bootstrap. During this time, Diana has also provided
>>>>> valuable reviews to keep us on the straight and narrow preventing our
>>>>> continued abuse of defenseless web technologies.
>>>>>
>>>>> Please respond with comments, +1s, or objections by Friday.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> [1]
>>>>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>> __
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Zhenguo Niu
>>>
>>> __
>>> 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] PTL noncandidacy

[Liz Blanchard]

On Fri, Mar 11, 2016 at 12:19 PM, David Lyle  wrote:

> After five cycles as PTL of Horizon, I've decided not to run for the
> Newton cycle.
>

David,

Thank you for everything you've done for Horizon, especially around helping
push a focus on User Experience.

Best,
Liz


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

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

[Matthias Runge]

On 11/03/16 18:19, David Lyle wrote:
> After five cycles as PTL of Horizon, I've decided not to run for the
> Newton cycle.

Thank you David for all you have done for Horizon and the community
around Horizon. It was (and is) still awesome to work with you.

If you can, please stay and continue to contribute to Horizon and
the ecosystem around it.

Best,
Matthias

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

__
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] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/12/2016 09:11 PM, Matthias Runge wrote:
> - how often have we been blocked by releases of software not managed by
> OpenStack? Seriously, that happens quite a few times over a release
> cycle, not to mention breakages by releases of our own tools turning out
> to block one or the other sub-project.

Let's remember the bad releases of setuptools :)

Cheers,

Thomas Goirand (zigo)


__
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] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/10/2016 12:14 PM, Richard Jones wrote:
> On 10 March 2016 at 21:48, Beth Elwell  > wrote:
> 
>> On 10 Mar 2016, at 07:46, Richard Jones > > wrote:
>>
>> It has been mentioned, xstatic packages can block the gate. We
>> currently
>> control xstatic package releases, thus we can roll back, if
>> something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the
>> outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>>
>> We're going to have potential breakage (gate breakage, in the
>> integrated tests) any time we release a package (regardless of
>> release mechanism) and have to update two separate repositories
>> resulting in out-of-sync version specification
>> and expectation (ie. upper-constraints specification and Horizon's
>> code expectation) as described in my OP. The only solution that
>> we're aware of is to synchronise updating those two things,
>> through one of the mechanisms proposed so far (or possibly through
>> a mechanism not yet proposed.)
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm
> tools which are standardised for JavaScript and would move Horizon
> more towards using widely recognised tooling from within not just
> Openstack but the wider development community. Back versions always
> need to be supported for a time, however I would add that long term
> this could end up saving time and create a stable longer term solution.
> 
> 
> I (and others) have argued several times for this, for a number of
> reasons, and it remains my preferred solution, but it has been shot down
> many times :-(

And I will attempt to do it once more unless someone brings the right
argumentation to the table.

> There are three major hurdles that I recall (sorry if I forgot any, it's
> getting late here):
> 
> 1. system packaging; installers using Debian or Red Hat (completely
> offline) installation will not be able to install Horizon. We don't have
> a solution for this though various caching mechanisms have been proposed.
> 2. security; the bower installation mechanism is seen as being very
> insecure - not that I would call the current xstatic mechanism secure.
> It's all down to degrees, I suppose.
> 3. installation in the gate; I believe that currently installation from
> bower would not be possible in the gate. This is pretty closely related
> to #1.
> 
> I think I recall licensing came up at one point too, but I might be
> mis-remembering.
> 
>   Richard

>From a distribution package maintainer perspective, the most annoying
part is that there's no easy way to get the web app use the JS libs from
the OS, and there's no system wide registry of installed components.
XStatic does that. Get $your-favoring-js-package-manager to do it, just
like php pear, perl CPAN, or Python pip does, then we will adopt it.
This, of course, requires work on upstream tooling.

Cheers,

Thomas Goirand (zigo)


__
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] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/10/2016 11:48 AM, Beth Elwell wrote:
> 
>> On 10 Mar 2016, at 07:46, Richard Jones > > wrote:
>>  
>>
>> It has been mentioned, xstatic packages can block the gate. We
>> currently
>> control xstatic package releases, thus we can roll back, if something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>>
>> We're going to have potential breakage (gate breakage, in the
>> integrated tests) any time we release a package (regardless of release
>> mechanism) and have to update two separate repositories resulting in
>> out-of-sync version specification and expectation (ie.
>> upper-constraints specification and Horizon's code expectation) as
>> described in my OP. The only solution that we're aware of is to
>> synchronise updating those two things, through one of the mechanisms
>> proposed so far (or possibly through a mechanism not yet proposed.)
> 
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm tools

We control the breakages, and we're trying to find a solution (if you
didn't notice, many where proposed in this thread).

> which are standardised for JavaScript

They are a *very bad* standard which doesn't work at all with downstream
distributions. Unless someone adds a system wide registry for javascript
(the say way that if you apt-get a Python package, pip wont download
it), then we can't use it.

> and would move Horizon more
> towards using widely recognised tooling

Recognized by who? Certainly not downstream distributions. This is a
nightmare.

> from within not just Openstack
> but the wider development community.

What community are you talking about? That JavaScript community which
breaks APIs every 2 weeks? Please re-read this:

https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst

and especially the part:
"Why we use XStatic"

We have every few months some Horizon contributors advocating for
pushing toward this direction, however, none have yet shown a way to
solve what Xstatic does. Until this is done, please refrain from writing:

"hey, everyone uses X, so let's do the same"

without valid technical argumentation.

Yes, using npm / bower / gulp / you-name-it, may make your Horizon
contributor life easier. But that's *not* the only thing to consider.

> Back versions always need to be
> supported for a time, however I would add that long term this could end
> up saving time and create a stable longer term solution.

Long term, I would like to see more contributions to the upstream
JavaScript tooling to make it behave reasonably. Until this is done, we
can't use it.

Cheers,

Thomas Goirand (zigo)


__
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] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/09/2016 04:53 PM, Monty Taylor wrote:
> On 03/07/2016 10:52 PM, Richard Jones wrote:
>> We've solved *most* of the issues around releasing new xstatic packages,
>> documented here[1] (and related documentation).
>>
>> We have one final issue that's blocking us, which is that during the
>> xstatic release there will be a point at which Horizon may be broken
>> from an integrated point of view - some of the interfaces may not work
>> and fail tests. The process goes something like this:
>>
>> ​Note: this assumes that depends-on can reliably bring in patches from
>> all over the place into a gate environment, which is technically
>> possible, but not necessarily correct today.
>>
>> The problem is that because we can't atomically update both
>> upper-constraints *and* Horizon at the same time (or upper-constraints
>> *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
>> situation where Horizon will be running against the wrong version of
>> xstatic-angular.
>>
>> So we break one of the basic assumptions of the OpenStack world: that
>> every single commit in every repository for the integrated environment
>> will pass tests.
>>
>> In the Python world, we code around this by making Horizon compatible
>> with both the X and X1 versions of xstatic-angular (if it was a Python
>> library). In Javascript land this is much more difficult - Javascript
>> libraries tend to break compatibility in far more interesting ways.
> 
> Yah. Honestly, this is one of the main places where I think we get into
> trouble in linux-distro land in trying to apply the tools/techniques
> developed for one set of problems with another.
> 
>> Maintaining compatibility across CSS and font releases is also a
>> difficult problem, though changes here are unlikely to break Horizon
>> enough that gate tests would fail. So, solution 1 to the problem is:
>>
>> SOLUTION 1: always maintain Horizon compatibility across xstatic library
>> releases.
>>
>> This is potentially very difficult to guarantee. So, a second solution
>> has been proposed:
>>
>> SOLUTION 2: move the upper-constraints information for *the xstatic
>> libraries only* from the global upper-constraints file into Horizon's
>> repository.
>>
>> This allows us to atomically update both Horizon and the xstatic library
>> version, removing the potential to break because of the version
>> mismatch. Unfortunately it means that we have version compatibility
>> issues with anything else that wants to install alongside Horizon that
>> also uses xstatic packages. For example, Horizon plugins. We could move
>> Horizon plugins into the Horizon repository to solve this. /ducks
> 
> I actually like this one a lot. I know that there is a plugin problem
> ... but ... plugin installers could also consume the horizon xstatic
> constraints when installing xstatic packages?
> 
> xstatic packages are specifically workarounds for doing javascript in a
> python-centric world. Putting then in upper-constraints and actually
> treating them like actual python packages rather than what they are
> which is a clever utilization of the python ecosystem to deliver
> javascript libraries is vexing at best.
> 
> 
>> A variation on this solution is:
>>
>> SOLUTION 3: allow Horizon to locally override upper-constraints for the
>> time needed to merge a patch in devstack.
>>
>> This solution allows Horizon to atomically update itself and the xstatic
>> library, but it also means installing Horizon in a CI/CD environment
>> becomes more difficult due to the need to always pull down the
>> upper-constraints file and edit it. We could code this in to tox, but
>> that doesn't help eg. devstack which needs to also do this thing.
> 
> Or people who are deploying horizon CD from master from source and
> applying upper-constraints to get the tested version. Those people would
> have to duplicate the tox logic.
> 
>> SOLUTION 4: vendor the javascript
>>
>> Heh.
> 
> Heh indeed.
> 
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.

Veto. See "Why we use XStatic" at:
https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst

Thomas


__
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] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/08/2016 05:52 AM, Richard Jones wrote:
> In the Python world, we code around this by making Horizon compatible
> with both the X and X1 versions of xstatic-angular (if it was a Python
> library). In Javascript land this is much more difficult - Javascript
> libraries tend to break compatibility in far more interesting ways.
> Maintaining compatibility across CSS and font releases is also a
> difficult problem, though changes here are unlikely to break Horizon
> enough that gate tests would fail. So, solution 1 to the problem is:
> 
> SOLUTION 1: always maintain Horizon compatibility across xstatic library
> releases.
> 
> This is potentially very difficult to guarantee. So, a second solution
> has been proposed:
> 
> SOLUTION 2: move the upper-constraints information for *the xstatic
> libraries only* from the global upper-constraints file into Horizon's
> repository.
> 
> This allows us to atomically update both Horizon and the xstatic library
> version, removing the potential to break because of the version
> mismatch. Unfortunately it means that we have version compatibility
> issues with anything else that wants to install alongside Horizon that
> also uses xstatic packages. For example, Horizon plugins. We could move
> Horizon plugins into the Horizon repository to solve this. /ducks
> 
> A variation on this solution is:
> 
> SOLUTION 3: allow Horizon to locally override upper-constraints for the
> time needed to merge a patch in devstack.
> 
> This solution allows Horizon to atomically update itself and the xstatic
> library, but it also means installing Horizon in a CI/CD environment
> becomes more difficult due to the need to always pull down the
> upper-constraints file and edit it. We could code this in to tox, but
> that doesn't help eg. devstack which needs to also do this thing.
> 
> SOLUTION 4: vendor the javascript
> 
> Heh.
> 
> SOLUTION 5: have dependencies on xstatic move from global requirements
> to Horizon
> 
> This is similar to 2 & 3 with some of the same drawbacks (multiple users
> of xstatic) but also we'd need a change to global-requirements handling
> to ignore some entries in Horizon's requirements.
> 
> Your thoughts on any and all of the above are requested.

SOLUTION 6: educate upstream and make them stop breaking the world.

SOLUTION 7: Stop having dependencies on libraries that constantly break
the world.

SOLUTION 8: Stop using JavaScript.

SOLUTION 9: Rewrite Horizon as QT client! :)

Cheers,

Thomas Goirand (zigo)

P.S: While all of this is just for fun, I seriously believe that
upstream JavaScript people should be educated to not break things every
2 weeks... though I don't think it will happen anytime soon.


__
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] How do we move forward with xstatic releases?

[Matthias Runge]

On 10/03/16 11:48, Beth Elwell wrote:

> 
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm tools
> which are standardised for JavaScript and would move Horizon more
> towards using widely recognised tooling from within not just Openstack
> but the wider development community. Back versions always need to be
> supported for a time, however I would add that long term this could end
> up saving time and create a stable longer term solution.
> 

I have a few issues with those "package managers":
- downloads are not verified, there is a chance of getting a "bad" download.
- they are pointing to the outside world, like to github etc. While they
appear to work "most of the time", that might not good enough for the gate
- how often have we been blocked by releases of software not managed by
OpenStack? Seriously, that happens quite a few times over a release
cycle, not to mention breakages by releases of our own tools turning out
to block one or the other sub-project.

Matthias
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

__
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] How do we move forward with xstatic releases?

[Matthias Runge]

On 10/03/16 08:46, Richard Jones wrote:
> On 10 March 2016 at 18:23, Matthias Runge  > wrote:
> 
> 4.alt.2:
> move to proper packages for static file management. I mean, they need to
> be built anyways.
> 
> 
> Please define what you mean by "proper packages" here. I *think* you
> might mean system packages (aka Debian or Red Hat) which is not feasible
> given other environments that Horizon runs under. Please correct me if
> I'm wrong!

Exactly. I mean system packages. If there are issues with system
packages, then let's address the issue rather than re-inventing the wheel.

Weren't we just talking about providing dependencies for the gate? I
mean, for production, it's quite the same situation we are at the
moment. Nobody requires you to install Horizon and dependencies
especially via rpm, deb or pip: Take what you want.

> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
> 
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
> 
> 
> We're going to have potential breakage (gate breakage, in the integrated
> tests) any time we release a package (regardless of release mechanism)
> and have to update two separate repositories resulting in out-of-sync
> version specification and expectation (ie. upper-constraints
> specification and Horizon's code expectation) as described in my OP. The
> only solution that we're aware of is to synchronise updating those two
> things, through one of the mechanisms proposed so far (or possibly
> through a mechanism not yet proposed.)
> 

Yes, and my proposal to address this is to gate updating/releasing
dependencies the same way we're currently gating each change in horizon.

> 
> 1. Horizon maintains its own constrained version list for the xstatic
> packages,
> 2. Plugins to Horizon must depend on Horizon to supply xstatic packages
> except where they use additional packages that Horizon does not use, and
> 3. We avoid installing app-catalog (the system, not the plugin) in the
> integrated tests (I don't believe doing this is even on the ...
> "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged)
> system that also has Horizon installed. Or we try to convince
> app-catalog to stay lock-step with Horizon's xstatic versions. I
> understand the risk of a collision between app-catalog and Horizon in
> the same system-packaged environment is very low.

I don't really see a chance for app-catalog to require Horizon as a
dependency and different versions of xstatic packages. This would be an
immediate show-stopper for app-catalog either on Debian or on RPM based
systems.

Let me repeat myself: you're free to install dependencies as you like,
npm, bower, whatever. I was simply speaking about the gate and about
gating dependencies to be sure, we're not broken by someone from outside.

Matthias
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

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

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

[Adam Young]

On 03/11/2016 12:19 PM, David Lyle wrote:

After five cycles as PTL of Horizon, I've decided not to run for the
Newton cycle.

I am exceptionally proud of the things we've accomplished over this
time. I'm amazed by how much our project's community has grown and
evolved.

Looking at the community now, I believe we have a tremendous group of
contributors for moving forward. There are several people capable of
becoming great PTLs and overall the community will be healthier with
some turnover in the PTL role. I feel honored to have had your trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

David

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



This drew a groan from me. You've been fantastic.  Thanks for all you 
have done.


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

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

[Richard Jones]

Thanks for everything David. My involvement and engagement with the project
would not be what it is without your leadership. I look forward to
continuing to work with and learn from you!


   Richard

On 12 March 2016 at 04:19, David Lyle  wrote:

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

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

[Tripp, Travis S]

David,

Thank you so much for the patience and wisdom you’ve demonstrated over the 
years.
I always appreciate sense of humor you bring to IRC.

For the love of all that is OpenStack, please stay active on Horizon!

-Travis




On 3/11/16, 10:19 AM, "David Lyle"  wrote:

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

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

[Thai Q Tran]

Thanks David for your commitment and leadership. I learned a lot from you and your perspective on things. Looking forward to learn more from you and to work along side you into the foreseeable future. You are sticking around right? I still have TONS of questions to ask, JK :P
 
- Original message -From: Anita Kuno <ante...@anteaya.info>To: openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [horizon] PTL noncandidacyDate: Fri, Mar 11, 2016 1:18 PM 
On 03/11/2016 12:19 PM, David Lyle wrote:> After five cycles as PTL of Horizon, I've decided not to run for the> Newton cycle.>> I am exceptionally proud of the things we've accomplished over this> time. I'm amazed by how much our project's community has grown and> evolved.>> Looking at the community now, I believe we have a tremendous group of> contributors for moving forward. There are several people capable of> becoming great PTLs and overall the community will be healthier with> some turnover in the PTL role. I feel honored to have had your trust> over this time and lucky to have worked with such great people.>> I will still be around and will help the next PTL make a smooth> transition where requested.>> David>> __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>It has been a delight and honour to work with you in your role asHorizon PTL. I look forward to continuing to work with you as HorizonnonPTL.Thanks for your many cycles of hard work and dedication to the project.I really appreciate it.Thank you,Anita.__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

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

[Anita Kuno]

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

Thanks for your many cycles of hard work and dedication to the project.
I really appreciate it.

Thank you,
Anita.

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

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

[Lin Hua Cheng]

Thanks for all the great work. Your leadership and commitment to horizon
has been instrumental to the projects success.

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

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

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

[Akihiro Motoki]

+1 from me too!

2016-03-11 17:38 GMT+09:00 Tatiana Ovtchinnikova <t.v.ovtchinnik...@gmail.com>:
> +1. Thanks for your contribution!
>
>
>
> 2016-03-11 6:40 GMT+03:00 Zhenguo Niu <niu.zgli...@gmail.com>:
>>
>> +1 from me, thanks for all the hard work!
>>
>> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
>> wrote:
>>>
>>> +1. Another vote in favor of ditching django altogether is good by me :)
>>>
>>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>>>>
>>>> Big +1 from me, thanks for all the hard work Diana!
>>>>
>>>>
>>>> - Original message -----
>>>> From: David Lyle <dkly...@gmail.com>
>>>> To: OpenStack Development Mailing List
>>>> <openstack-dev@lists.openstack.org>
>>>> Cc:
>>>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>>>> horizon-core
>>>> Date: Tue, Mar 8, 2016 2:07 PM
>>>>
>>>> I propose adding Diana Whitten[1] to horizon-core.
>>>>
>>>> Diana is an active reviewer, contributor and community member. Over
>>>> the past couple of releases, Diana has driven extensive changes around
>>>> theme-ability in Horizon and drastically increased the standardization
>>>> of our use of bootstrap. During this time, Diana has also provided
>>>> valuable reviews to keep us on the straight and narrow preventing our
>>>> continued abuse of defenseless web technologies.
>>>>
>>>> Please respond with comments, +1s, or objections by Friday.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> [1]
>>>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>> __
>> 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-dev] [horizon] PTL noncandidacy

[David Lyle]

After five cycles as PTL of Horizon, I've decided not to run for the
Newton cycle.

I am exceptionally proud of the things we've accomplished over this
time. I'm amazed by how much our project's community has grown and
evolved.

Looking at the community now, I believe we have a tremendous group of
contributors for moving forward. There are several people capable of
becoming great PTLs and overall the community will be healthier with
some turnover in the PTL role. I feel honored to have had your trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

David

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

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

[Tatiana Ovtchinnikova]

+1. Thanks for your contribution!


2016-03-11 6:40 GMT+03:00 Zhenguo Niu <niu.zgli...@gmail.com>:

> +1 from me, thanks for all the hard work!
>
> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
> wrote:
>
>> +1. Another vote in favor of ditching django altogether is good by me :)
>>
>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>>
>>> Big +1 from me, thanks for all the hard work Diana!
>>>
>>>
>>> - Original message -
>>> From: David Lyle <dkly...@gmail.com>
>>> To: OpenStack Development Mailing List <
>>> openstack-dev@lists.openstack.org>
>>> Cc:
>>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>>> horizon-core
>>> Date: Tue, Mar 8, 2016 2:07 PM
>>>
>>> I propose adding Diana Whitten[1] to horizon-core.
>>>
>>> Diana is an active reviewer, contributor and community member. Over
>>> the past couple of releases, Diana has driven extensive changes around
>>> theme-ability in Horizon and drastically increased the standardization
>>> of our use of bootstrap. During this time, Diana has also provided
>>> valuable reviews to keep us on the straight and narrow preventing our
>>> continued abuse of defenseless web technologies.
>>>
>>> Please respond with comments, +1s, or objections by Friday.
>>>
>>> Thanks,
>>> David
>>>
>>> [1]
>>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Zhenguo Niu]

+1 from me, thanks for all the hard work!

On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
wrote:

> +1. Another vote in favor of ditching django altogether is good by me :)
>
> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>
>> Big +1 from me, thanks for all the hard work Diana!
>>
>>
>> - Original message -
>> From: David Lyle <dkly...@gmail.com>
>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org
>> >
>> Cc:
>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>> Date: Tue, Mar 8, 2016 2:07 PM
>>
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> 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
>
>


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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

On Wed, Mar 9, 2016 at 4:15 PM Richard Jones  wrote:

>
> We already have a "lintq" npm task that does this, which most of us use.
> The problem is that we then ignore all the legitimate code linting warnings.
>

I think we both agree that some form of jsdoc linting is useful, yes? You'd
prefer for it to be in the doc builder, while I'm ambivalent about where
those checks happen. How about this: Let's keep the checks in there, and
once a replacement is in place, we can turn it off.

In the meantime, they do provide a benefit - for one, I know that Matt
Borland is working on digging into those warnings.


> My perspective on this is if the documentation builder can produce
> documentation that is useful then it's enforcing exactly enough checks on
> the input.
>

It sounds like we don't actually know what this documentation builder is
going to enforce. In fact, it may be more strict and/or less configurable
than eslint. I'm not comfortable turning off a rule if we don't know what
kind of a future we'll get; could you investigate and report back with your
findings?


> For example, the jsdoc linter currently forces us to write @returns
> statements in our docs for angular methods that have no return value, and
> never will (i.e. module.config()) or is otherwise not exposed to developers
> and not interesting (i.e. the return from service or controller
> construction).
>

Given javascript's flexible return types, many IDE's look to the jsdoc to
guess at what the returned type for a method is. This drives things like
code hinting, sanity checks, and tab completion. Explicitly declaring the
return type, even if it's {void}, has a concrete benefit.

And yes, I find it annoying too, but I put up with it for the beauty of
Command-Space-Oh-That's-What-I-Can-Do-Here.


> I mentioned this in passing in the meeting, but most of our JS
> documentation has been written to ngdoc syntax, and that's potentially a
> good thing since it provides much greater hinting to the doc generators
> about how to present and organise the output, but also influences things
> like @returns usefulness.
>

I remember you saying that ngdoc doesn't actually work, so I'm a bit
confused as to why we're writing documentation to that standard. Could you
clarify?


> We just have to find the right tool (or, more likely, create, since I've
> been looking for a while and haven't found a suitable tool) that uses the
> information we're coding into our comments.
>

Awesome. So once this tool is completed, let's come back to this
conversation! I don't think we can continue without really knowing what the
tradeoffs will be.

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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

On Wed, Mar 9, 2016 at 12:45 PM Tripp, Travis S 
wrote:

> The problem is that the warnings are so great that is really hard to read.
>

If all the warnings were fixed - I know Matt Borland's working on that -
would we be having this conversation?

Michael
__
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] How do we move forward with xstatic releases?

[Richard Jones]

On 10 March 2016 at 21:48, Beth Elwell  wrote:
>
> On 10 Mar 2016, at 07:46, Richard Jones  wrote:
>
>> It has been mentioned, xstatic packages can block the gate. We currently
>> control xstatic package releases, thus we can roll back, if something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>
> We're going to have potential breakage (gate breakage, in the integrated
> tests) any time we release a package (regardless of release mechanism) and
> have to update two separate repositories resulting in out-of-sync version
> specification and expectation (ie. upper-constraints specification and
> Horizon's code expectation) as described in my OP. The only solution that
> we're aware of is to synchronise updating those two things, through one of
> the mechanisms proposed so far (or possibly through a mechanism not yet
> proposed.)
>
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm tools which
> are standardised for JavaScript and would move Horizon more towards using
> widely recognised tooling from within not just Openstack but the wider
> development community. Back versions always need to be supported for a
> time, however I would add that long term this could end up saving time and
> create a stable longer term solution.
>

I (and others) have argued several times for this, for a number of reasons,
and it remains my preferred solution, but it has been shot down many times
:-(

There are three major hurdles that I recall (sorry if I forgot any, it's
getting late here):

1. system packaging; installers using Debian or Red Hat (completely
offline) installation will not be able to install Horizon. We don't have a
solution for this though various caching mechanisms have been proposed.
2. security; the bower installation mechanism is seen as being very
insecure - not that I would call the current xstatic mechanism secure. It's
all down to degrees, I suppose.
3. installation in the gate; I believe that currently installation from
bower would not be possible in the gate. This is pretty closely related to
#1.

I think I recall licensing came up at one point too, but I might be
mis-remembering.


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Itxaka Serrano Garcia]

On 03/10/2016 11:48 AM, Beth Elwell wrote:



On 10 Mar 2016, at 07:46, Richard Jones > wrote:

It has been mentioned, xstatic packages can block the gate. We
currently
control xstatic package releases, thus we can roll back, if something
goes wrong.

If we're pulling directly with npm/bower, someone from the outside can
break us. We already have the situation with pypi packages.
With proper packages, we could even use the gate to release those
packages and thus verify, we're not breaking anyone.


We're going to have potential breakage (gate breakage, in the
integrated tests) any time we release a package (regardless of release
mechanism) and have to update two separate repositories resulting in
out-of-sync version specification and expectation (ie.
upper-constraints specification and Horizon's code expectation) as
described in my OP. The only solution that we're aware of is to
synchronise updating those two things, through one of the mechanisms
proposed so far (or possibly through a mechanism not yet proposed.)


If we will anyway have potential breakage I don’t understand why the
better solution here would not be to just use the bower and npm tools
which are standardised for JavaScript and would move Horizon more
towards using widely recognised tooling from within not just Openstack
but the wider development community. Back versions always need to be
supported for a time, however I would add that long term this could end
up saving time and create a stable longer term solution.


__
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




npm/bower seems like the right tool for this instead of trying to 
convert everything to the python ecosystem.



And I dont understand the issues with plugins. They depend on a horizon 
version so they need to work with the js libraries that are provided by 
that version, same as with any python packages that horizon brings, they 
have to work with that, should not be a difference in there no?


Itxaka



__
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] How do we move forward with xstatic releases?

[Beth Elwell]

> On 10 Mar 2016, at 07:46, Richard Jones  wrote:
>  
> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
> 
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
> 
> We're going to have potential breakage (gate breakage, in the integrated 
> tests) any time we release a package (regardless of release mechanism) and 
> have to update two separate repositories resulting in out-of-sync version 
> specification and expectation (ie. upper-constraints specification and 
> Horizon's code expectation) as described in my OP. The only solution that 
> we're aware of is to synchronise updating those two things, through one of 
> the mechanisms proposed so far (or possibly through a mechanism not yet 
> proposed.)

If we will anyway have potential breakage I don’t understand why the better 
solution here would not be to just use the bower and npm tools which are 
standardised for JavaScript and would move Horizon more towards using widely 
recognised tooling from within not just Openstack but the wider development 
community. Back versions always need to be supported for a time, however I 
would add that long term this could end up saving time and create a stable 
longer term solution.

> __
> 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] How do we move forward with xstatic releases?

[Richard Jones]

On 10 March 2016 at 18:23, Matthias Runge  wrote:
>
> 4.alt.2:
> move to proper packages for static file management. I mean, they need to
> be built anyways.
>

Please define what you mean by "proper packages" here. I *think* you might
mean system packages (aka Debian or Red Hat) which is not feasible given
other environments that Horizon runs under. Please correct me if I'm wrong!



> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
>
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
>

We're going to have potential breakage (gate breakage, in the integrated
tests) any time we release a package (regardless of release mechanism) and
have to update two separate repositories resulting in out-of-sync version
specification and expectation (ie. upper-constraints specification and
Horizon's code expectation) as described in my OP. The only solution that
we're aware of is to synchronise updating those two things, through one of
the mechanisms proposed so far (or possibly through a mechanism not yet
proposed.)


I think that David's proposal is the only really feasible approach at this
time:

1. Horizon maintains its own constrained version list for the xstatic
packages,
2. Plugins to Horizon must depend on Horizon to supply xstatic packages
except where they use additional packages that Horizon does not use, and
3. We avoid installing app-catalog (the system, not the plugin) in the
integrated tests (I don't believe doing this is even on the ... "horizon"
so to speak) *or* in a Debian / Red Hat (i.e. system-packaged) system that
also has Horizon installed. Or we try to convince app-catalog to stay
lock-step with Horizon's xstatic versions. I understand the risk of a
collision between app-catalog and Horizon in the same system-packaged
environment is very low.


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Matthias Runge]

On 09/03/16 19:52, Michael Krotscheck wrote:
> On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor  > wrote:
> 
> 
> > SOLUTION 4: vendor the javascript
> >
> > Heh.
> 
> Heh indeed.
> 
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.
> 
> 
> +1. Let's move the codebase forward, instead of continuing to build
> hacky workarounds for poor past architectural decisions.
> 
Coming from a distro perspective:

4.alt.2:
move to proper packages for static file management. I mean, they need to
be built anyways.

It has been mentioned, xstatic packages can block the gate. We currently
control xstatic package releases, thus we can roll back, if something
goes wrong.

If we're pulling directly with npm/bower, someone from the outside can
break us. We already have the situation with pypi packages.
With proper packages, we could even use the gate to release those
packages and thus verify, we're not breaking anyone.

Matthias

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Richard Jones]

On 10 March 2016 at 06:49, Michael Krotscheck  wrote:

> I guess I don't see what problems is being solved by turning the rule off,
> and I also don't see the harm in having more check. It does generate a lot
> of warnings, but invoking `npm run lint -- --quiet` gets rid of those.
>

We already have a "lintq" npm task that does this, which most of us use.
The problem is that we then ignore all the legitimate code linting warnings.


Also, from my experience, sphinx-based doc builds are notoriously
> permissive about bad formatting. Eslint's stricter jsdoc checks would add
> an additional safety net.
>

My perspective on this is if the documentation builder can produce
documentation that is useful then it's enforcing exactly enough checks on
the input. For example, the jsdoc linter currently forces us to write
@returns statements in our docs for angular methods that have no return
value, and never will (i.e. module.config()) or is otherwise not exposed to
developers and not interesting (i.e. the return from service or controller
construction). I mentioned this in passing in the meeting, but most of our
JS documentation has been written to ngdoc syntax, and that's potentially a
good thing since it provides much greater hinting to the doc generators
about how to present and organise the output, but also influences things
like @returns usefulness. We just have to find the right tool (or, more
likely, create, since I've been looking for a while and haven't found a
suitable tool) that uses the information we're coding into our comments.



> However, if you're working on this with the docs team, then the result
> should be applicable to the entirety of openstack - meaning that once your
> work is complete, it may make sense to turn the rule off globally.
>

Yep!


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

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

[Cindy Lu]

+2 for Diana :)

 - Original message -
 From: David Lyle <dkly...@gmail.com>
 To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
 Cc:
 Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
 horizon-core
 Date: Tue, Mar 8, 2016 2:07 PM

 I propose adding Diana Whitten[1] to horizon-core.

 Diana is an active reviewer, contributor and community member. Over
 the past couple of releases, Diana has driven extensive changes around
 theme-ability in Horizon and drastically increased the standardization
 of our use of bootstrap. During this time, Diana has also provided
 valuable reviews to keep us on the straight and narrow preventing our
 continued abuse of defenseless web technologies.

 Please respond with comments, +1s, or objections by Friday.

 Thanks,
 David

 [1]
 http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Tripp, Travis S]

> On 03/09/2016 04:43 PM, Serg Melikyan wrote:

>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

> Say there are two xstatic libraries, a and b. B depends on a. Horizon depends 
> only on a. Plugin-foo depends on b. Horizon updates to a version of a that 
> the version of b consumed by plugin-foo is not compatible with.

> Rob

Just FYI, this topic came up in the horizon IRC today at the 20:30:45 minute 
mark.:  
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-03-09-20.00.log.html
__
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] How do we move forward with xstatic releases?

[Richard Jones]

Hi Serg,

There's a crucial difference: getting the solution to this wrong for
Horizon will break the gate for all OpenStack projects. Updating an xstatic
package that a plugin uses has no side-effect outside of the plugin.


  Richard

On 10 March 2016 at 02:43, Serg Melikyan  wrote:

> >This is exactly my first thought. The plugins *must* depend on Horizon,
> and they have to use the same versions of XStatic packages anyways, so why
> specify the dependencies twice?
>
> Plugins may require different xstatic library, which is not even used
> by Horizon. Issue raised by Richard exists for plugins too, not only
> for Horizon itself.
>
>
> On Wed, Mar 9, 2016 at 12:24 AM, Radomir Dopieralski
>  wrote:
> > On 03/08/2016 11:43 PM, David Lyle wrote:
> >
> >> I'm wondering if since horizon is really the only project consuming
> >> these xstatic libraries and none are likely to venture down this path of
> >> madness with us that it would be safe to manage the xstatic requirements
> >> and upper-constraints locally.
> >>
> >> Technically the plugins for horizon depend on this, but they depend via
> >> horizon. If they require specific versions that are not supported by
> >> Horizon, I think all bets are off anyway.
> >
> >
> > This is exactly my first thought. The plugins *must* depend on Horizon,
> > and they have to use the same versions of XStatic packages anyways, so
> > why specify the dependencies twice? If the changes between versions are
> > so big as to be breaking, then the plugins have to be updated to work
> > with the new Horizon anyways.
> >
> > --
> > Radomir Dopieralski
> >
> >
> >
> >
> __
> > 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
>
>
>
> --
> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com
>
> +1 (650) 440-8979
>
> __
> 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] Javascript linting and documentation

[Tripp, Travis S]

Hi Michael,

The problem is that the warnings are so great that is really hard to read.

What if we amended the recently added lintq to do some inline filtering of the 
doc warnings?  This is just a bandaid of course.

I also am opposed to any major linting changes until Mitaka closes. They cause 
too many merge conflicts when the fix goes in, making the real bugs harder to 
get through.

-Travis

From: Michael Krotscheck <krotsch...@gmail.com<mailto:krotsch...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 9, 2016 at 12:49 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Horizon] Javascript linting and documentation

+1 to what Rob said.

I guess I don't see what problems is being solved by turning the rule off, and 
I also don't see the harm in having more check. It does generate a lot of 
warnings, but invoking `npm run lint -- --quiet` gets rid of those. Also, from 
my experience, sphinx-based doc builds are notoriously permissive about bad 
formatting. Eslint's stricter jsdoc checks would add an additional safety net.

However, if you're working on this with the docs team, then the result should 
be applicable to the entirety of openstack - meaning that once your work is 
complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:
If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and 
quickly noticed that about 85% of the "linting" warnings were about jsdoc. We 
have significant issues around jsdoc anyway and we're supposed to be using 
Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating 
publishable documentation for our Javascript code for some time. Most of the 
tools either don't work (dgeni) or produce pretty unusable output for a project 
our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx in 
collaboration with the docs team.

Regardless, I believe that the documentation generation should generate errors 
about that documentation, not the code linter. Once we actually get a 
documentation generator going. Until then, we don't even know what syntax the 
documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the moment, 
it is less than useful (the noise drowns out any other, legitimate linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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://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] Javascript linting and documentation

[Michael Krotscheck]

+1 to what Rob said.

I guess I don't see what problems is being solved by turning the rule off,
and I also don't see the harm in having more check. It does generate a lot
of warnings, but invoking `npm run lint -- --quiet` gets rid of those.
Also, from my experience, sphinx-based doc builds are notoriously
permissive about bad formatting. Eslint's stricter jsdoc checks would add
an additional safety net.

However, if you're working on this with the docs team, then the result
should be applicable to the entirety of openstack - meaning that once your
work is complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
wrote:

> If possible, I’d really prefer we left linting work to Newton. It’ll be
> good to get it to a more usable state again, but we ought to be focusing on
> thoroughly checking the new Launch Instance for bugs and edge usage cases,
> as well as the outstanding bugs and blueprints targeted at RC1 (
> https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great
> opportunity to prove that the Angular rewrites are fully capable of
> providing an improved experience, and we should be capitalising on that.
>
> Rob
>
>
> On 9 Mar 2016, at 02:25, Richard Jones  wrote:
>
> Hey all,
>
> I started looking into fixing the wall of "npm run lint" warnings today
> and quickly noticed that about 85% of the "linting" warnings were about
> jsdoc. We have significant issues around jsdoc anyway and we're supposed to
> be using Sphinx anyway[1].
>
> Some Horizon folks will know that I've been investigating generating
> publishable documentation for our Javascript code for some time. Most of
> the tools either don't work (dgeni) or produce pretty unusable output for a
> project our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx
> in collaboration with the docs team.
>
> Regardless, I believe that the documentation generation should generate
> errors about that documentation, not the code linter. Once we actually get
> a documentation generator going. Until then, we don't even know what syntax
> the documentation should follow.
>
> I've proposed a change which just turns jsdoc "linting" off[2]. At the
> moment, it is less than useful (the noise drowns out any other, legitimate
> linting).
>
>
>  Richard
>
>
> [1] http://governance.openstack.org/reference/cti/javascript-cti.html
> [2] https://review.openstack.org/#/c/290235/
>
> __
> 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] Proposal to add Diana Whitten tohorizon-core

[Michael Krotscheck]

+1. Another vote in favor of ditching django altogether is good by me :)

On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:

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

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

[Thai Q Tran]

Big +1 from me, thanks for all the hard work Diana!
 
- Original message -From: David Lyle <dkly...@gmail.com>To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Cc:Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-coreDate: Tue, Mar 8, 2016 2:07 PM 
I propose adding Diana Whitten[1] to horizon-core.Diana is an active reviewer, contributor and community member. Overthe past couple of releases, Diana has driven extensive changes aroundtheme-ability in Horizon and drastically increased the standardizationof our use of bootstrap. During this time, Diana has also providedvaluable reviews to keep us on the straight and narrow preventing ourcontinued abuse of defenseless web technologies.Please respond with comments, +1s, or objections by Friday.Thanks,David[1] http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Rob Cresswell (rcresswe)]

If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
> wrote:

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and 
quickly noticed that about 85% of the "linting" warnings were about jsdoc. We 
have significant issues around jsdoc anyway and we're supposed to be using 
Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating 
publishable documentation for our Javascript code for some time. Most of the 
tools either don't work (dgeni) or produce pretty unusable output for a project 
our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx in 
collaboration with the docs team.

Regardless, I believe that the documentation generation should generate errors 
about that documentation, not the code linter. Once we actually get a 
documentation generator going. Until then, we don't even know what syntax the 
documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the moment, 
it is less than useful (the noise drowns out any other, legitimate linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

__
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] How do we move forward with xstatic releases?

[Michael Krotscheck]

On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor  wrote:

>
> > SOLUTION 4: vendor the javascript
> >
> > Heh.
>
> Heh indeed.
>
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.
>

+1. Let's move the codebase forward, instead of continuing to build hacky
workarounds for poor past architectural decisions.

Michael
__
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] How do we move forward with xstatic releases?

[Robert Collins]

On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" 
wrote:
>
> On 03/09/2016 04:43 PM, Serg Melikyan wrote:
>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

Say there are two xstatic libraries, a and b. B depends on a. Horizon
depends only on a. Plugin-foo depends on b. Horizon updates to a version of
a that the version of b consumed by plugin-foo is not compatible with.

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

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

[Beth Elwell]

I’m not a core but I wanted to add my complete agreement with making Diana a 
core in horizon. She has done some incredible work in horizon through her work 
on the code, reviews and also community attitude and assistance getting people 
(myself included) familiar with horizon.

Beth

> On 8 Mar 2016, at 22:48, Lin Hua Cheng  wrote:
> 
> big +1 from me.
> 
> She made a lot of contribution in making theming better for horizon and also 
> prevented potential issues through reviews.
> Thanks for all the hard work, Diana.
> 
> -Lin
> 
> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  > wrote:
> I propose adding Diana Whitten[1] to horizon-core.
> 
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
> 
> Please respond with comments, +1s, or objections by Friday.
> 
> Thanks,
> David
> 
> [1] 
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>  
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Rob Cresswell (rcresswe)]

+1 from me. Diana’s almost single handedly fixed our Bootstrap usage and gives 
lots of great reviews all across Horizon too. The boost to branding, theming 
and potential for accessibility, as well as huge reduction in CSS/HTML 
maintenance overhead, has been brilliant.

Rob


On 9 Mar 2016, at 16:15, Timur Sufiev 
<tsuf...@mirantis.com<mailto:tsuf...@mirantis.com>> wrote:

+1, Diana's contribution to the front-end aspect of Horizon during several 
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
+1 we need Diana's perspective, knowledge and enthusiasm

On 9 March 2016 at 10:03, Tripp, Travis S 
<travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>> wrote:
+1, no questions asked. It is rare to find somebody with the passion that Diana 
has shown.

From: Lin Hua Cheng 
<os.lch...@gmail.com<mailto:os.lch...@gmail.com><mailto:os.lch...@gmail.com<mailto:os.lch...@gmail.com>>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>>
Date: Tuesday, March 8, 2016 at 3:48 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>>
Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to 
horizon-core

big +1 from me.

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

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle 
<dkly...@gmail.com<mailto:dkly...@gmail.com><mailto:dkly...@gmail.com<mailto:dkly...@gmail.com>>>
 wrote:
I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

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

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

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

[Timur Sufiev]

+1, Diana's contribution to the front-end aspect of Horizon during several
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones <r1chardj0...@gmail.com> wrote:

> +1 we need Diana's perspective, knowledge and enthusiasm
>
> On 9 March 2016 at 10:03, Tripp, Travis S <travis.tr...@hpe.com> wrote:
>
>> +1, no questions asked. It is rare to find somebody with the passion that
>> Diana has shown.
>>
>> From: Lin Hua Cheng <os.lch...@gmail.com<mailto:os.lch...@gmail.com>>
>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Date: Tuesday, March 8, 2016 at 3:48 PM
>> To: OpenStack List <openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>>
>> big +1 from me.
>>
>> She made a lot of contribution in making theming better for horizon and
>> also prevented potential issues through reviews.
>> Thanks for all the hard work, Diana.
>>
>> -Lin
>>
>> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle <dkly...@gmail.com> dkly...@gmail.com>> wrote:
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
>> http://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] How do we move forward with xstatic releases?

[Radomir Dopieralski]

On 03/09/2016 04:43 PM, Serg Melikyan wrote:

This is exactly my first thought. The plugins *must* depend on Horizon,
and they have to use the same versions of XStatic packages anyways,

>> so why specify the dependencies twice?


Plugins may require different xstatic library, which is not even used
by Horizon. Issue raised by Richard exists for plugins too, not only
for Horizon itself.


How would such an xstatic library conflict with what is in Horizon then,
though?

--
Radomir Dopieralski


__
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] How do we move forward with xstatic releases?

[Monty Taylor]

On 03/07/2016 10:52 PM, Richard Jones wrote:

We've solved *most* of the issues around releasing new xstatic packages,
documented here[1] (and related documentation).

We have one final issue that's blocking us, which is that during the
xstatic release there will be a point at which Horizon may be broken
from an integrated point of view - some of the interfaces may not work
and fail tests. The process goes something like this:

​Note: this assumes that depends-on can reliably bring in patches from
all over the place into a gate environment, which is technically
possible, but not necessarily correct today.

The problem is that because we can't atomically update both
upper-constraints *and* Horizon at the same time (or upper-constraints
*and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
situation where Horizon will be running against the wrong version of
xstatic-angular.

So we break one of the basic assumptions of the OpenStack world: that
every single commit in every repository for the integrated environment
will pass tests.

In the Python world, we code around this by making Horizon compatible
with both the X and X1 versions of xstatic-angular (if it was a Python
library). In Javascript land this is much more difficult - Javascript
libraries tend to break compatibility in far more interesting ways.


Yah. Honestly, this is one of the main places where I think we get into 
trouble in linux-distro land in trying to apply the tools/techniques 
developed for one set of problems with another.



Maintaining compatibility across CSS and font releases is also a
difficult problem, though changes here are unlikely to break Horizon
enough that gate tests would fail. So, solution 1 to the problem is:

SOLUTION 1: always maintain Horizon compatibility across xstatic library
releases.

This is potentially very difficult to guarantee. So, a second solution
has been proposed:

SOLUTION 2: move the upper-constraints information for *the xstatic
libraries only* from the global upper-constraints file into Horizon's
repository.

This allows us to atomically update both Horizon and the xstatic library
version, removing the potential to break because of the version
mismatch. Unfortunately it means that we have version compatibility
issues with anything else that wants to install alongside Horizon that
also uses xstatic packages. For example, Horizon plugins. We could move
Horizon plugins into the Horizon repository to solve this. /ducks


I actually like this one a lot. I know that there is a plugin problem 
... but ... plugin installers could also consume the horizon xstatic 
constraints when installing xstatic packages?


xstatic packages are specifically workarounds for doing javascript in a 
python-centric world. Putting then in upper-constraints and actually 
treating them like actual python packages rather than what they are 
which is a clever utilization of the python ecosystem to deliver 
javascript libraries is vexing at best.




A variation on this solution is:

SOLUTION 3: allow Horizon to locally override upper-constraints for the
time needed to merge a patch in devstack.

This solution allows Horizon to atomically update itself and the xstatic
library, but it also means installing Horizon in a CI/CD environment
becomes more difficult due to the need to always pull down the
upper-constraints file and edit it. We could code this in to tox, but
that doesn't help eg. devstack which needs to also do this thing.


Or people who are deploying horizon CD from master from source and 
applying upper-constraints to get the tested version. Those people would 
have to duplicate the tox logic.



SOLUTION 4: vendor the javascript

Heh.


Heh indeed.

SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.



SOLUTION 5: have dependencies on xstatic move from global requirements
to Horizon

This is similar to 2 & 3 with some of the same drawbacks (multiple users
of xstatic) but also we'd need a change to global-requirements handling
to ignore some entries in Horizon's requirements.

Your thoughts on any and all of the above are requested.


Thanks for your work on this - it's a hard problem - especially with 
sets of potentially conflicting desires from your consumers.



__
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] How do we move forward with xstatic releases?

[Serg Melikyan]

>This is exactly my first thought. The plugins *must* depend on Horizon, and 
>they have to use the same versions of XStatic packages anyways, so why specify 
>the dependencies twice?

Plugins may require different xstatic library, which is not even used
by Horizon. Issue raised by Richard exists for plugins too, not only
for Horizon itself.


On Wed, Mar 9, 2016 at 12:24 AM, Radomir Dopieralski
 wrote:
> On 03/08/2016 11:43 PM, David Lyle wrote:
>
>> I'm wondering if since horizon is really the only project consuming
>> these xstatic libraries and none are likely to venture down this path of
>> madness with us that it would be safe to manage the xstatic requirements
>> and upper-constraints locally.
>>
>> Technically the plugins for horizon depend on this, but they depend via
>> horizon. If they require specific versions that are not supported by
>> Horizon, I think all bets are off anyway.
>
>
> This is exactly my first thought. The plugins *must* depend on Horizon,
> and they have to use the same versions of XStatic packages anyways, so
> why specify the dependencies twice? If the changes between versions are
> so big as to be breaking, then the plugins have to be updated to work
> with the new Horizon anyways.
>
> --
> Radomir Dopieralski
>
>
>
> __
> 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



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+1 (650) 440-8979

__
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] How do we move forward with xstatic releases?

[Radomir Dopieralski]

On 03/08/2016 11:43 PM, David Lyle wrote:


I'm wondering if since horizon is really the only project consuming
these xstatic libraries and none are likely to venture down this path of
madness with us that it would be safe to manage the xstatic requirements
and upper-constraints locally.

Technically the plugins for horizon depend on this, but they depend via
horizon. If they require specific versions that are not supported by
Horizon, I think all bets are off anyway.


This is exactly my first thought. The plugins *must* depend on Horizon,
and they have to use the same versions of XStatic packages anyways, so
why specify the dependencies twice? If the changes between versions are
so big as to be breaking, then the plugins have to be updated to work
with the new Horizon anyways.

--
Radomir Dopieralski


__
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] Javascript linting and documentation

[Richard Jones]

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and
quickly noticed that about 85% of the "linting" warnings were about jsdoc.
We have significant issues around jsdoc anyway and we're supposed to be
using Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating
publishable documentation for our Javascript code for some time. Most of
the tools either don't work (dgeni) or produce pretty unusable output for a
project our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx
in collaboration with the docs team.

Regardless, I believe that the documentation generation should generate
errors about that documentation, not the code linter. Once we actually get
a documentation generator going. Until then, we don't even know what syntax
the documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the
moment, it is less than useful (the noise drowns out any other, legitimate
linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/
__
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] How do we move forward with xstatic releases?

[Robert Collins]

On 9 March 2016 at 14:23, Jeremy Stanley  wrote:
> On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
>> On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
>> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
>> > [...]
>> >> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> >> commits.
>> >
>> > This seems unlikely to happen, as it's very much counter to Zuul's
>> > designed-in reliance on serializing changes to test before merging
>> > them.
>>
>> I'd like to explore this more, but a mailing list thread probably
>> isn't terribly efficient - I don't even know where to start to figure
>> out any differing assumptions, whether whats being propose is
>> conceptually desirable and-or how to represent that in zuul. But we've
>> spent nearly three days of bug smash here in sydney trying to get some
>> sort of design for going forward, and so far this is the only one that
>> hasn't bad pretty big negative external side effects such as 'break
>> every other user of xstatic when horizon updates'. :(.
>>
>> So -> IRC and/or/perhaps voice?
>
> ML thread will probably work for some initial exploration, but with
> James leading the Zuul v3 design and implementation he's in the best
> position to say whether it's going to be sane to support having
> changes in multiple repos which must test and merge together rather
> than being able to merge one before the other. Previously we've seen
> the idea of atomic merges coordinated across multiple repositories
> to be a sign of poor software design, and as such have actively
> discouraged the notion (it did come up briefly during the original
> cross-repo dependencies design, and was pretty quickly rejected as
> unsanitary).
>
> Anyway, I'll give him a heads up on this since he likely doesn't
> follow Horizon-specific discussions very closely.

Thanks. The driving factor here is that supporting both versions of
many of these static things - both JS, and the html that interacts
with it - is very tricky. E.g. having two copies of all templates
tricky.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] How do we move forward with xstatic releases?

[Jeremy Stanley]

On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
> On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> > [...]
> >> SOLUTION 6 - make zuul capable of performing atomic cross-repository
> >> commits.
> >
> > This seems unlikely to happen, as it's very much counter to Zuul's
> > designed-in reliance on serializing changes to test before merging
> > them.
> 
> I'd like to explore this more, but a mailing list thread probably
> isn't terribly efficient - I don't even know where to start to figure
> out any differing assumptions, whether whats being propose is
> conceptually desirable and-or how to represent that in zuul. But we've
> spent nearly three days of bug smash here in sydney trying to get some
> sort of design for going forward, and so far this is the only one that
> hasn't bad pretty big negative external side effects such as 'break
> every other user of xstatic when horizon updates'. :(.
> 
> So -> IRC and/or/perhaps voice?

ML thread will probably work for some initial exploration, but with
James leading the Zuul v3 design and implementation he's in the best
position to say whether it's going to be sane to support having
changes in multiple repos which must test and merge together rather
than being able to merge one before the other. Previously we've seen
the idea of atomic merges coordinated across multiple repositories
to be a sign of poor software design, and as such have actively
discouraged the notion (it did come up briefly during the original
cross-repo dependencies design, and was pretty quickly rejected as
unsanitary).

Anyway, I'll give him a heads up on this since he likely doesn't
follow Horizon-specific discussions very closely.
-- 
Jeremy Stanley

__
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] How do we move forward with xstatic releases?

[Robert Collins]

On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
>> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.

I'd like to explore this more, but a mailing list thread probably
isn't terribly efficient - I don't even know where to start to figure
out any differing assumptions, whether whats being propose is
conceptually desirable and-or how to represent that in zuul. But we've
spent nearly three days of bug smash here in sydney trying to get some
sort of design for going forward, and so far this is the only one that
hasn't bad pretty big negative external side effects such as 'break
every other user of xstatic when horizon updates'. :(.

So -> IRC and/or/perhaps voice?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] How do we move forward with xstatic releases?

[Richard Jones]

But Jeremy: Atomic Zuul. How cool is that name.


So I know I'm going to potentially get yelled at for voicing this, but what
are the chances that app-catalog and Horizon are ever installed on the same
system? That is, could it have its own xstatic constraints, with the
promise that the two constraints will never meet in a dark alley behind
some VM somewhere? app-catalog isn't in the integrated tests, so it's never
going to break the gate like Horizon will...


On 9 March 2016 at 11:07, Jeremy Stanley  wrote:

> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
> > SOLUTION 6 - make zuul capable of performing atomic cross-repository
> > commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.
> --
> Jeremy Stanley
>
> __
> 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] How do we move forward with xstatic releases?

[Jeremy Stanley]

On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
[...]
> SOLUTION 6 - make zuul capable of performing atomic cross-repository
> commits.

This seems unlikely to happen, as it's very much counter to Zuul's
designed-in reliance on serializing changes to test before merging
them.
-- 
Jeremy Stanley

__
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][app-catalog] How do we move forward with xstatic releases?

[Fox, Kevin M]

fyi, we are planning on using the xstatic packages for the app catalog website 
so we can share as much code as possible with horizon and the app catalog 
horizon plugin. So it will affect the app catalog too, not just horizon.

Thanks,
Kevin

From: David Lyle [dkly...@gmail.com]
Sent: Tuesday, March 08, 2016 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] How do we move forward with xstatic 
releases?



On Mon, Mar 7, 2016 at 9:52 PM, Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
We've solved *most* of the issues around releasing new xstatic packages, 
documented here[1] (and related documentation).

We have one final issue that's blocking us, which is that during the xstatic 
release there will be a point at which Horizon may be broken from an integrated 
point of view - some of the interfaces may not work and fail tests. The process 
goes something like this:
[cid:ii_ilix1nfi0_153547b4957000a0]
​Note: this assumes that depends-on can reliably bring in patches from all over 
the place into a gate environment, which is technically possible, but not 
necessarily correct today.

The problem is that because we can't atomically update both upper-constraints 
*and* Horizon at the same time (or upper-constraints *and* xstatic-angular, or 
Horizon *and* xstatic-angular) we run into a situation where Horizon will be 
running against the wrong version of xstatic-angular.

So we break one of the basic assumptions of the OpenStack world: that every 
single commit in every repository for the integrated environment will pass 
tests.

In the Python world, we code around this by making Horizon compatible with both 
the X and X1 versions of xstatic-angular (if it was a Python library). In 
Javascript land this is much more difficult - Javascript libraries tend to 
break compatibility in far more interesting ways. Maintaining compatibility 
across CSS and font releases is also a difficult problem, though changes here 
are unlikely to break Horizon enough that gate tests would fail. So, solution 1 
to the problem is:

SOLUTION 1: always maintain Horizon compatibility across xstatic library 
releases.

This is potentially very difficult to guarantee. So, a second solution has been 
proposed:

This seems unlikely to go well.


SOLUTION 2: move the upper-constraints information for *the xstatic libraries 
only* from the global upper-constraints file into Horizon's repository.

This allows us to atomically update both Horizon and the xstatic library 
version, removing the potential to break because of the version mismatch. 
Unfortunately it means that we have version compatibility issues with anything 
else that wants to install alongside Horizon that also uses xstatic packages. 
For example, Horizon plugins. We could move Horizon plugins into the Horizon 
repository to solve this. /ducks

I don't know that you can duck low enough for that.

I'm wondering if since horizon is really the only project consuming these 
xstatic libraries and none are likely to venture down this path of madness with 
us that it would be safe to manage the xstatic requirements and 
upper-constraints locally.

Technically the plugins for horizon depend on this, but they depend via 
horizon. If they require specific versions that are not supported by Horizon, I 
think all bets are off anyway.


A variation on this solution is:

SOLUTION 3: allow Horizon to locally override upper-constraints for the time 
needed to merge a patch in devstack.

This solution allows Horizon to atomically update itself and the xstatic 
library, but it also means installing Horizon in a CI/CD environment becomes 
more difficult due to the need to always pull down the upper-constraints file 
and edit it. We could code this in to tox, but that doesn't help eg. devstack 
which needs to also do this thing.


I combined this with #2.

SOLUTION 4: vendor the javascript

Heh.

This makes me sad.


SOLUTION 5: have dependencies on xstatic move from global requirements to 
Horizon

This is similar to 2 & 3 with some of the same drawbacks (multiple users of 
xstatic) but also we'd need a change to global-requirements handling to ignore 
some entries in Horizon's requirements.


I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the 
openstack global mechanism.

Your thoughts on any and all of the above are requested.


Richard

[1] https://review.openstack.org/#/c/289142/


__
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


David
__
OpenStack De

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

[Richard Jones]

+1 we need Diana's perspective, knowledge and enthusiasm

On 9 March 2016 at 10:03, Tripp, Travis S <travis.tr...@hpe.com> wrote:

> +1, no questions asked. It is rare to find somebody with the passion that
> Diana has shown.
>
> From: Lin Hua Cheng <os.lch...@gmail.com<mailto:os.lch...@gmail.com>>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>>
> Date: Tuesday, March 8, 2016 at 3:48 PM
> To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to
> horizon-core
>
> big +1 from me.
>
> She made a lot of contribution in making theming better for horizon and
> also prevented potential issues through reviews.
> Thanks for all the hard work, Diana.
>
> -Lin
>
> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle <dkly...@gmail.com dkly...@gmail.com>> wrote:
> I propose adding Diana Whitten[1] to horizon-core.
>
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
>
> Please respond with comments, +1s, or objections by Friday.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://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] Proposal to add Diana Whitten to horizon-core

[Tripp, Travis S]

+1, no questions asked. It is rare to find somebody with the passion that Diana 
has shown.

From: Lin Hua Cheng <os.lch...@gmail.com<mailto:os.lch...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, March 8, 2016 at 3:48 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to 
horizon-core

big +1 from me.

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

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle 
<dkly...@gmail.com<mailto:dkly...@gmail.com>> wrote:
I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

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

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

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

[Lin Hua Cheng]

big +1 from me.

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

-Lin

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

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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[David Lyle]

On Mon, Mar 7, 2016 at 9:52 PM, Richard Jones 
wrote:

> We've solved *most* of the issues around releasing new xstatic packages,
> documented here[1] (and related documentation).
>
> We have one final issue that's blocking us, which is that during the
> xstatic release there will be a point at which Horizon may be broken from
> an integrated point of view - some of the interfaces may not work and fail
> tests. The process goes something like this:
>
> ​Note: this assumes that depends-on can reliably bring in patches from all
> over the place into a gate environment, which is technically possible, but
> not necessarily correct today.
>
> The problem is that because we can't atomically update both
> upper-constraints *and* Horizon at the same time (or upper-constraints
> *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
> situation where Horizon will be running against the wrong version of
> xstatic-angular.
>
> So we break one of the basic assumptions of the OpenStack world: that
> every single commit in every repository for the integrated environment will
> pass tests.
>
> In the Python world, we code around this by making Horizon compatible with
> both the X and X1 versions of xstatic-angular (if it was a Python library).
> In Javascript land this is much more difficult - Javascript libraries tend
> to break compatibility in far more interesting ways. Maintaining
> compatibility across CSS and font releases is also a difficult problem,
> though changes here are unlikely to break Horizon enough that gate tests
> would fail. So, solution 1 to the problem is:
>
> SOLUTION 1: always maintain Horizon compatibility across xstatic library
> releases.
>
> This is potentially very difficult to guarantee. So, a second solution has
> been proposed:
>

This seems unlikely to go well.


>
> SOLUTION 2: move the upper-constraints information for *the xstatic
> libraries only* from the global upper-constraints file into Horizon's
> repository.
>
> This allows us to atomically update both Horizon and the xstatic library
> version, removing the potential to break because of the version mismatch.
> Unfortunately it means that we have version compatibility issues with
> anything else that wants to install alongside Horizon that also uses
> xstatic packages. For example, Horizon plugins. We could move Horizon
> plugins into the Horizon repository to solve this. /ducks
>

I don't know that you can duck low enough for that.

I'm wondering if since horizon is really the only project consuming these
xstatic libraries and none are likely to venture down this path of madness
with us that it would be safe to manage the xstatic requirements and
upper-constraints locally.

Technically the plugins for horizon depend on this, but they depend via
horizon. If they require specific versions that are not supported by
Horizon, I think all bets are off anyway.


>
> A variation on this solution is:
>
> SOLUTION 3: allow Horizon to locally override upper-constraints for the
> time needed to merge a patch in devstack.
>
> This solution allows Horizon to atomically update itself and the xstatic
> library, but it also means installing Horizon in a CI/CD environment
> becomes more difficult due to the need to always pull down the
> upper-constraints file and edit it. We could code this in to tox, but that
> doesn't help eg. devstack which needs to also do this thing.
>
>
I combined this with #2.


> SOLUTION 4: vendor the javascript
>
> Heh.
>

This makes me sad.


>
> SOLUTION 5: have dependencies on xstatic move from global requirements to
> Horizon
>
> This is similar to 2 & 3 with some of the same drawbacks (multiple users
> of xstatic) but also we'd need a change to global-requirements handling to
> ignore some entries in Horizon's requirements.
>
>
I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the
openstack global mechanism.


> Your thoughts on any and all of the above are requested.
>
>
> Richard
>
> [1] https://review.openstack.org/#/c/289142/
>
>
> __
> 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
>
>
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-dev] [horizon] Proposal to add Diana Whitten to horizon-core

[David Lyle]

I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

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

[openstack-dev] [horizon] [searchlight] Horizon, Search, and Composability

[Tripp, Travis S]

Hello everybody,

At the Horizon mid-cycle we had a lot of discussion on UI composability and 
searchability. Matt and Tyr provided a short presentation and demo at the 
mid-cycle. This morning I gave a more detailed presentation and demo via 
hangouts on air regarding Searchlight and Horizon. The audience this morning 
was broader, so I started with content based on Matt and Tyr’s presentation and 
included an extended demo, additional information about Searchlight, and some 
status information about what was discussed at the Horizon mid-cycle. Since 
both of these have recordings, I wanted to share them both with you.

[Full Presentation (Travis)]

https://www.youtube.com/watch?v=ExzULavwvNQ

[Horizon Mid-Cycle Presentation (Matt and Tyr)]

https://www.youtube.com/watch?v=jr5iIs4zvbY

Thanks,
Travis

__
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] How do we move forward with xstatic releases?

[Richard Jones]

Two things I forgot to mention:

Currently there is another break point in the diagram of releases when X1
is released. Currently Horizon does not use upper-constraints and thus will
immediately pick up the new xstatic release file, potentially breaking
things. This is easy to fix - I will be proposing a patch soon.

SOLUTION 6 - make zuul capable of performing atomic cross-repository
commits.

Richard

Sent from my portable device, please excuse the brevity.
On 8 Mar 2016 15:52, "Richard Jones"  wrote:

> We've solved *most* of the issues around releasing new xstatic packages,
> documented here[1] (and related documentation).
>
> We have one final issue that's blocking us, which is that during the
> xstatic release there will be a point at which Horizon may be broken from
> an integrated point of view - some of the interfaces may not work and fail
> tests. The process goes something like this:
>
> ​Note: this assumes that depends-on can reliably bring in patches from all
> over the place into a gate environment, which is technically possible, but
> not necessarily correct today.
>
> The problem is that because we can't atomically update both
> upper-constraints *and* Horizon at the same time (or upper-constraints
> *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
> situation where Horizon will be running against the wrong version of
> xstatic-angular.
>
> So we break one of the basic assumptions of the OpenStack world: that
> every single commit in every repository for the integrated environment will
> pass tests.
>
> In the Python world, we code around this by making Horizon compatible with
> both the X and X1 versions of xstatic-angular (if it was a Python library).
> In Javascript land this is much more difficult - Javascript libraries tend
> to break compatibility in far more interesting ways. Maintaining
> compatibility across CSS and font releases is also a difficult problem,
> though changes here are unlikely to break Horizon enough that gate tests
> would fail. So, solution 1 to the problem is:
>
> SOLUTION 1: always maintain Horizon compatibility across xstatic library
> releases.
>
> This is potentially very difficult to guarantee. So, a second solution has
> been proposed:
>
> SOLUTION 2: move the upper-constraints information for *the xstatic
> libraries only* from the global upper-constraints file into Horizon's
> repository.
>
> This allows us to atomically update both Horizon and the xstatic library
> version, removing the potential to break because of the version mismatch.
> Unfortunately it means that we have version compatibility issues with
> anything else that wants to install alongside Horizon that also uses
> xstatic packages. For example, Horizon plugins. We could move Horizon
> plugins into the Horizon repository to solve this. /ducks
>
> A variation on this solution is:
>
> SOLUTION 3: allow Horizon to locally override upper-constraints for the
> time needed to merge a patch in devstack.
>
> This solution allows Horizon to atomically update itself and the xstatic
> library, but it also means installing Horizon in a CI/CD environment
> becomes more difficult due to the need to always pull down the
> upper-constraints file and edit it. We could code this in to tox, but that
> doesn't help eg. devstack which needs to also do this thing.
>
> SOLUTION 4: vendor the javascript
>
> Heh.
>
> SOLUTION 5: have dependencies on xstatic move from global requirements to
> Horizon
>
> This is similar to 2 & 3 with some of the same drawbacks (multiple users
> of xstatic) but also we'd need a change to global-requirements handling to
> ignore some entries in Horizon's requirements.
>
> Your thoughts on any and all of the above are requested.
>
>
> Richard
>
> [1] https://review.openstack.org/#/c/289142/
>
>
__
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] How do we move forward with xstatic releases?

[Richard Jones]

We've solved *most* of the issues around releasing new xstatic packages,
documented here[1] (and related documentation).

We have one final issue that's blocking us, which is that during the
xstatic release there will be a point at which Horizon may be broken from
an integrated point of view - some of the interfaces may not work and fail
tests. The process goes something like this:

​Note: this assumes that depends-on can reliably bring in patches from all
over the place into a gate environment, which is technically possible, but
not necessarily correct today.

The problem is that because we can't atomically update both
upper-constraints *and* Horizon at the same time (or upper-constraints
*and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
situation where Horizon will be running against the wrong version of
xstatic-angular.

So we break one of the basic assumptions of the OpenStack world: that every
single commit in every repository for the integrated environment will pass
tests.

In the Python world, we code around this by making Horizon compatible with
both the X and X1 versions of xstatic-angular (if it was a Python library).
In Javascript land this is much more difficult - Javascript libraries tend
to break compatibility in far more interesting ways. Maintaining
compatibility across CSS and font releases is also a difficult problem,
though changes here are unlikely to break Horizon enough that gate tests
would fail. So, solution 1 to the problem is:

SOLUTION 1: always maintain Horizon compatibility across xstatic library
releases.

This is potentially very difficult to guarantee. So, a second solution has
been proposed:

SOLUTION 2: move the upper-constraints information for *the xstatic
libraries only* from the global upper-constraints file into Horizon's
repository.

This allows us to atomically update both Horizon and the xstatic library
version, removing the potential to break because of the version mismatch.
Unfortunately it means that we have version compatibility issues with
anything else that wants to install alongside Horizon that also uses
xstatic packages. For example, Horizon plugins. We could move Horizon
plugins into the Horizon repository to solve this. /ducks

A variation on this solution is:

SOLUTION 3: allow Horizon to locally override upper-constraints for the
time needed to merge a patch in devstack.

This solution allows Horizon to atomically update itself and the xstatic
library, but it also means installing Horizon in a CI/CD environment
becomes more difficult due to the need to always pull down the
upper-constraints file and edit it. We could code this in to tox, but that
doesn't help eg. devstack which needs to also do this thing.

SOLUTION 4: vendor the javascript

Heh.

SOLUTION 5: have dependencies on xstatic move from global requirements to
Horizon

This is similar to 2 & 3 with some of the same drawbacks (multiple users of
xstatic) but also we'd need a change to global-requirements handling to
ignore some entries in Horizon's requirements.

Your thoughts on any and all of the above are requested.


Richard

[1] https://review.openstack.org/#/c/289142/
__
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] Blueprints for Outreachy internship

[Sayali Lunkad]

Hi Richard,

Thanks for you reply. I had a short conversation with Matthias and we
decided to put the blueprint for context-sensitive help
 as
an internship idea for now. Maybe I add another project to the list, then I
can look into the ideas you listed as well. Although if you wish to propose
one you can do it here  https://wiki.openstack.org/wiki/Internship_ideas


Thanks again!

Regards,
Sayali.


On Wed, Mar 2, 2016 at 9:44 AM, Richard Jones 
wrote:

> Hi Sayali,
>
> Sorry I missed your original message, and thanks Matthias for responding.
> Indeed the new Swift UI is currently being merged. Some of those blueprints
> you list are things I'd like to see once the basic reimplementation is
> landed. Select-all is already in the new version though (though we'd like
> to see hotkey support in there). There's also a bunch of good work done by
> the OpenStack UX team on the interface - changes that we'll look at rolling
> in during the N cycle. My wishlist (also my TODO list), which doesn't have
> blueprints yet, includes:
>
> - https://github.com/chieffancypants/angular-hotkeys for cmd/ctrl-a
> select-all
> - https://github.com/danialfarid/ng-file-upload
> - Recursive delete of folders
> - replacing SimpleModals with bootstrap modals
> - Support for >10k objects, most likely requiring Searchlight
> - Support for >1k containers (filtering)
> - Switch to action registry
> - Implement UX’s design ideas
> - Copy / rename of objects
>
>
>   Richard
>
> On 2 March 2016 at 00:07, Matthias Runge  wrote:
>
>> On 29/02/16 12:41, Sayali Lunkad wrote:
>> > Hi Matthias,
>> >
>> > Thanks for the links to the blueprints. I in fact did checkout the list
>> > of bps earlier but I found many of them have not been approved yet. I
>> > can give you a list of bps I would like to mentor for, from which we
>> > could perhaps select one or two for the internship program depending on
>> > which of these can be approved.
>>
>>
>> Hey Sayali,
>>
>> >
>> > Here is the list:
>> >
>> https://blueprints.launchpad.net/horizon/+spec/enable-download-multiple-objects
>> > 
>>
>>
>> Swift interface is currently changing quite quickly, see
>> https://review.openstack.org/#/c/258769/ and related.
>>
>>
>>
>> >
>> https://blueprints.launchpad.net/horizon/+spec/horizon-multiple-objects-uploading
>> > 
>>
>> Same here, it's Horizon's swift interface, which changes right now.
>> >
>> https://blueprints.launchpad.net/horizon/+spec/horizon-reports-in-different-formats
>> > 
>>
>> This is something, which still requires discussion; I strongly believe,
>> Horizon is not a reporting tool at all.
>>
>> > https://blueprints.launchpad.net/horizon/+spec/swift-direct-upload
>> > 
>> Swift, same as above
>>
>>
>> > https://blueprints.launchpad.net/horizon/+spec/instance-backup
>> > 
>>
>> I'd support the idea, the blueprint is a bit thin, I would expect this
>> to be implemented quickly.
>>
>>
>> >
>> https://blueprints.launchpad.net/horizon/+spec/select-all-checkbox-object-containers
>>
>> Swift, see above
>>
>>
>> > https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
>>
>> This is something, one could implement, yes. Still the blueprint is a
>> bit thin though.
>>
>> Best,
>> Matthias
>>
>> __
>> 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] Blueprints for Outreachy internship

[Richard Jones]

Hi Sayali,

Sorry I missed your original message, and thanks Matthias for responding.
Indeed the new Swift UI is currently being merged. Some of those blueprints
you list are things I'd like to see once the basic reimplementation is
landed. Select-all is already in the new version though (though we'd like
to see hotkey support in there). There's also a bunch of good work done by
the OpenStack UX team on the interface - changes that we'll look at rolling
in during the N cycle. My wishlist (also my TODO list), which doesn't have
blueprints yet, includes:

- https://github.com/chieffancypants/angular-hotkeys for cmd/ctrl-a
select-all
- https://github.com/danialfarid/ng-file-upload
- Recursive delete of folders
- replacing SimpleModals with bootstrap modals
- Support for >10k objects, most likely requiring Searchlight
- Support for >1k containers (filtering)
- Switch to action registry
- Implement UX’s design ideas
- Copy / rename of objects


  Richard

On 2 March 2016 at 00:07, Matthias Runge  wrote:

> On 29/02/16 12:41, Sayali Lunkad wrote:
> > Hi Matthias,
> >
> > Thanks for the links to the blueprints. I in fact did checkout the list
> > of bps earlier but I found many of them have not been approved yet. I
> > can give you a list of bps I would like to mentor for, from which we
> > could perhaps select one or two for the internship program depending on
> > which of these can be approved.
>
>
> Hey Sayali,
>
> >
> > Here is the list:
> >
> https://blueprints.launchpad.net/horizon/+spec/enable-download-multiple-objects
> > 
>
>
> Swift interface is currently changing quite quickly, see
> https://review.openstack.org/#/c/258769/ and related.
>
>
>
> >
> https://blueprints.launchpad.net/horizon/+spec/horizon-multiple-objects-uploading
> > 
>
> Same here, it's Horizon's swift interface, which changes right now.
> >
> https://blueprints.launchpad.net/horizon/+spec/horizon-reports-in-different-formats
> > 
>
> This is something, which still requires discussion; I strongly believe,
> Horizon is not a reporting tool at all.
>
> > https://blueprints.launchpad.net/horizon/+spec/swift-direct-upload
> > 
> Swift, same as above
>
>
> > https://blueprints.launchpad.net/horizon/+spec/instance-backup
> > 
>
> I'd support the idea, the blueprint is a bit thin, I would expect this
> to be implemented quickly.
>
>
> >
> https://blueprints.launchpad.net/horizon/+spec/select-all-checkbox-object-containers
>
> Swift, see above
>
>
> > https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
>
> This is something, one could implement, yes. Still the blueprint is a
> bit thin though.
>
> Best,
> Matthias
>
> __
> 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] Blueprints for Outreachy internship

[Matthias Runge]

On 29/02/16 12:41, Sayali Lunkad wrote:
> Hi Matthias,
> 
> Thanks for the links to the blueprints. I in fact did checkout the list
> of bps earlier but I found many of them have not been approved yet. I
> can give you a list of bps I would like to mentor for, from which we
> could perhaps select one or two for the internship program depending on
> which of these can be approved.


Hey Sayali,

> 
> Here is the list:
> https://blueprints.launchpad.net/horizon/+spec/enable-download-multiple-objects
> 


Swift interface is currently changing quite quickly, see
https://review.openstack.org/#/c/258769/ and related.



> https://blueprints.launchpad.net/horizon/+spec/horizon-multiple-objects-uploading
> 

Same here, it's Horizon's swift interface, which changes right now.
> https://blueprints.launchpad.net/horizon/+spec/horizon-reports-in-different-formats
> 

This is something, which still requires discussion; I strongly believe,
Horizon is not a reporting tool at all.

> https://blueprints.launchpad.net/horizon/+spec/swift-direct-upload
> 
Swift, same as above


> https://blueprints.launchpad.net/horizon/+spec/instance-backup
> 

I'd support the idea, the blueprint is a bit thin, I would expect this
to be implemented quickly.


> https://blueprints.launchpad.net/horizon/+spec/select-all-checkbox-object-containers

Swift, see above


> https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary

This is something, one could implement, yes. Still the blueprint is a
bit thin though.

Best,
Matthias

__
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] Blueprints for Outreachy internship

[Sayali Lunkad]

Hi Matthias,

Thanks for the links to the blueprints. I in fact did checkout the list of
bps earlier but I found many of them have not been approved yet. I can give
you a list of bps I would like to mentor for, from which we could perhaps
select one or two for the internship program depending on which of these
can be approved.

Here is the list:
https://blueprints.launchpad.net/horizon/+spec/enable-download-multiple-objects

https://blueprints.launchpad.net/horizon/+spec/horizon-multiple-objects-uploading

https://blueprints.launchpad.net/horizon/+spec/horizon-reports-in-different-formats

https://blueprints.launchpad.net/horizon/+spec/swift-direct-upload

https://blueprints.launchpad.net/horizon/+spec/instance-backup

https://blueprints.launchpad.net/horizon/+spec/select-all-checkbox-object-containers
https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary

Regards,
Sayali.

On Mon, Feb 29, 2016 at 8:39 AM, Matthias Runge  wrote:

> On 26/02/16 10:36, Sayali Lunkad wrote:
> > Hello,
> >
> > I am looking for some blueprints in horizon that can be set aside for
> > the Outreachy Internship
> > program. If anyone has any
> > blueprints in mind which are not needed anytime soon as well as not so
> > difficult to implement please let me know so we can include these as
> > tasks for the interns.
> > These blueprints will be worked on around May - August, 2016.
> >
> > Regards,
> > Sayali.
> >
>
> Hello Sayali,
>
> there are a few blueprints in Horizon, which would fit into that area,
> just to name a few (not limited to)
>
> * https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
> * https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help
> *
>
> https://blueprints.launchpad.net/horizon/+spec/download-images-and-snapshots
>
> In general, https://blueprints.launchpad.net/horizon
> gives a HUGE list of ideas. For specific questions, a interested person
> should try to understand a blueprint and should either send a mail here,
> should stop by  at #openstack-horizon or send me a mail.
>
> Matthias
>
> __
> 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] Blueprints for Outreachy internship

[Matthias Runge]

On 26/02/16 10:36, Sayali Lunkad wrote:
> Hello,
> 
> I am looking for some blueprints in horizon that can be set aside for
> the Outreachy Internship
> program. If anyone has any
> blueprints in mind which are not needed anytime soon as well as not so
> difficult to implement please let me know so we can include these as
> tasks for the interns.
> These blueprints will be worked on around May - August, 2016.
> 
> Regards,
> Sayali.
> 

Hello Sayali,

there are a few blueprints in Horizon, which would fit into that area,
just to name a few (not limited to)

* https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
* https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help
*
https://blueprints.launchpad.net/horizon/+spec/download-images-and-snapshots

In general, https://blueprints.launchpad.net/horizon
gives a HUGE list of ideas. For specific questions, a interested person
should try to understand a blueprint and should either send a mail here,
should stop by  at #openstack-horizon or send me a mail.

Matthias

__
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] Testing of angular promise based code paths

[Richard Jones]

Hi all,

I've just added a comment to a review and I think I'd like to ask for a
broader discussion of whether I'm correct.

The review is here: https://review.openstack.org/#/c/284857/2

It boils down to: when testing code that uses a promise, should we *use* a
promise to have the follow-on callback invoked, or should we mock/spy and
then manually perform the same action the promise would if resolved?

The two forms are, broadly, pretending that a promise fired:

  it('successful submit calls the successCallback', function() {
*var successFunc = {success: angular.noop};*
*spyOn(successFunc, 'success');*
spyOn(nova, 'createKeypair')*.and.returnValue(successFunc);*
spyOn(toastService, 'add').and.returnValue({ add: angular.noop });
ctrl.submit();
*var successCallback = successFunc.success.calls.argsFor(0)[0];*
*var data = {name: 'newKeypair'};*
*successCallback(data);*
expect(toastService.add).toHaveBeenCalledWith(
'success',
'Successfully imported key pair newKeypair.'
);
  });

or actually using a promise and making it fire:

it('should load container contents', function test() {
  *var deferred = $q.defer();*
  spyOn(swiftAPI, 'getObjects')*.and.returnValue(deferred.promise);*
  service.selectContainer('spam');
  expect(service.containerName).toEqual('spam');
  expect(swiftAPI.getObjects).toHaveBeenCalledWith('spam', {delimiter:
'/'});
  *deferred.resolve({data: {items: ['two', 'items']}});*
  *$rootScope.$apply();*
  expect(service.objects).toEqual(['two', 'items']);
  expect(service.pseudo_folder_hierarchy).toEqual([]);
});


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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Kirill Zaitsev]

A small followup on murano-dashboard. We have just added i18n support during 
mitaka cycle, and I believe, that murano-dashboard is ready for being 
translated.
There is a https://review.openstack.org/#/c/277874/ cleanup commit, however, 
that I really hope would land before the string freeze. (it removes lot’s of 
unnecessary noise in marked strings and squashes near-identical strings to one)

We’re going to follow string freeze guidelines for murano (since we now have 
our projects translated). And since murano-dashboard follows 
release:cycle-with-milestones the RC1 date is going to be more or less the same 
as horizon’s 

Would be happy to help if you have any more questions.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 February 2016 at 08:19:30, Akihiro Motoki (amot...@gmail.com) wrote:

Daisy,

I can followup trove- and sahara- dashboard.
I don't think I can track the status of all of others. This is the
reason I used 'seem' in the past emails.
I suggest to check a release model which each project adopts at
http://governance.openstack.org/reference/projects/index.html.

2016-02-26 9:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
> Thank you, Akihiro.
>
> Can you help me to understand these plugin projects are release together
> with Horizon or they have their own release schedule ?
> I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
> for Horizon project ?
>
> Best regards
> Ying Chun Guo (Daisy)
>
>
> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/26 01:00:15:
>
>> From: Akihiro Motoki <amot...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: 2016/02/26 01:04
>
>
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger <a...@suse.com>:
>> > On 2016-02-25 11:40, Ying Chun Guo wrote:
>> >> Thank you, Akihiro.
>> >> The projects listed below are all in translation website except
>> >> desginate-dasbhard.
>> >
>> > Typo, it' designate, see
>> > https://translate.openstack.org/project/view/designate-dashboard
>>
>> Thanks for the follow-up.
>> Yeah. I typed designate-dashboard and made a mistake :-(
>>
>> >
>> >> Whether these projects can get translated in Mitaka depends.
>> >> Let's discuss with team.
>> >
>> > Andreas
>> >
>> >> Best regards
>> >> Ying Chun Guo (Daisy)
>> >>
>> >>
>> >> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
>> >>
>> >>> From: Akihiro Motoki <amot...@gmail.com>
>> >>> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> <openstack-dev@lists.openstack.org>
>> >>> Date: 2016/02/23 16:00
>> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> >>> ready for translation in Mitaka?
>> >>>
>> >>> Hi Daisy,
>> >>>
>> >>> AFAIK the following horizon plugins are ready for translation.
>> >>> I tested and confirmed translations of these two work well with
>> >>> Japanese.
>> >>> A minor improvement on devstack or other stuff are in progress but it
>> >>> does not affect translation.
>> >>>
>> >>> * trove-dashboard
>> >>> * sahara-dashboard
>> >>>
>> >>> The following horizon plugins SEEM to support translations.
>> >>> I have never tried them.
>> >>>
>> >>> * desginate-dasbhard
>> >>> * magnum-ui
>> >>> * monasca-ui
>> >>> * murano-dashboard
>> >>> * senlin-dashboard
>> >>>
>> >>> Thanks,
>> >>> Akihiro
>> >>>
>> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
>> >>> > Hi,
>> >>> >
>> >>> > Mitaka translation will be started from March 4 and ended in the
>> >>> > week of
>> >>> > March 28.
>> >>> > I'd like to know which Horizon plugins[1] are ready for translation
>> >>> > in
>> >>> > Mitaka release.
>> >>> > If there are, I'm happy to include them in the Mitaka translation
>> >>> > plan.
>> >>> >
>> >>> > Thank you.
&g

[openstack-dev] [Horizon] Blueprints for Outreachy internship

[Sayali Lunkad]

Hello,

I am looking for some blueprints in horizon that can be set aside for
the Outreachy
Internship program. If anyone
has any blueprints in mind which are not needed anytime soon as well as not
so difficult to implement please let me know so we can include these as
tasks for the interns.
These blueprints will be worked on around May - August, 2016.

Regards,
Sayali.
__
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] Any Horizon plugins ready for translation in Mitaka?

[Akihiro Motoki]

Daisy,

I can followup trove- and sahara- dashboard.
I don't think I can track the status of all of others. This is the
reason I used 'seem' in the past emails.
I suggest to check a release model which each project adopts at
http://governance.openstack.org/reference/projects/index.html.

2016-02-26 9:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
> Thank you, Akihiro.
>
> Can you help me to understand these plugin projects are release together
> with Horizon or they have their own release schedule ?
> I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
> for Horizon project ?
>
> Best regards
> Ying Chun Guo (Daisy)
>
>
> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/26 01:00:15:
>
>> From: Akihiro Motoki <amot...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: 2016/02/26 01:04
>
>
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger <a...@suse.com>:
>> > On 2016-02-25 11:40, Ying Chun Guo wrote:
>> >> Thank you, Akihiro.
>> >> The projects listed below are all in translation website except
>> >> desginate-dasbhard.
>> >
>> > Typo, it' designate, see
>> > https://translate.openstack.org/project/view/designate-dashboard
>>
>> Thanks for the follow-up.
>> Yeah. I typed designate-dashboard and made a mistake :-(
>>
>> >
>> >> Whether these projects can get translated in Mitaka depends.
>> >> Let's discuss with team.
>> >
>> > Andreas
>> >
>> >> Best regards
>> >> Ying Chun Guo (Daisy)
>> >>
>> >>
>> >> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
>> >>
>> >>> From: Akihiro Motoki <amot...@gmail.com>
>> >>> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> <openstack-dev@lists.openstack.org>
>> >>> Date: 2016/02/23 16:00
>> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> >>> ready for translation in Mitaka?
>> >>>
>> >>> Hi Daisy,
>> >>>
>> >>> AFAIK the following horizon plugins are ready for translation.
>> >>> I tested and confirmed translations of these two work well with
>> >>> Japanese.
>> >>> A minor improvement on devstack or other stuff are in progress but it
>> >>> does not affect translation.
>> >>>
>> >>> * trove-dashboard
>> >>> * sahara-dashboard
>> >>>
>> >>> The following horizon plugins SEEM to support translations.
>> >>> I have never tried them.
>> >>>
>> >>> * desginate-dasbhard
>> >>> * magnum-ui
>> >>> * monasca-ui
>> >>> * murano-dashboard
>> >>> * senlin-dashboard
>> >>>
>> >>> Thanks,
>> >>> Akihiro
>> >>>
>> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
>> >>> > Hi,
>> >>> >
>> >>> > Mitaka translation will be started from March 4 and ended in the
>> >>> > week of
>> >>> > March 28.
>> >>> > I'd like to know which Horizon plugins[1] are ready for translation
>> >>> > in
>> >>> > Mitaka release.
>> >>> > If there are, I'm happy to include them in the Mitaka translation
>> >>> > plan.
>> >>> >
>> >>> > Thank you.
>> >>> >
>> >>> > Best regards
>> >>> > Ying Chun Guo (Daisy)
>> >>> >
>> >>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>> >>> >
>> >>> >
>> >>> >
>> >>
>> >> __
>> >>> > 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] Any Horizon plugins ready for translation in Mitaka?

[Ying Chun Guo]

Thank you, Akihiro.

Can you help me to understand these plugin projects are release together
with Horizon or they have their own release schedule ?
I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
for Horizon project ?

Best regards
Ying Chun Guo (Daisy)


Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/26 01:00:15:

> From: Akihiro Motoki <amot...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 2016/02/26 01:04
> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> ready for translation in Mitaka?
>
> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger <a...@suse.com>:
> > On 2016-02-25 11:40, Ying Chun Guo wrote:
> >> Thank you, Akihiro.
> >> The projects listed below are all in translation website except
> >> desginate-dasbhard.
> >
> > Typo, it' designate, see
> > https://translate.openstack.org/project/view/designate-dashboard
>
> Thanks for the follow-up.
> Yeah. I typed designate-dashboard and made a mistake :-(
>
> >
> >> Whether these projects can get translated in Mitaka depends.
> >> Let's discuss with team.
> >
> > Andreas
> >
> >> Best regards
> >> Ying Chun Guo (Daisy)
> >>
> >>
> >> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
> >>
> >>> From: Akihiro Motoki <amot...@gmail.com>
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> <openstack-dev@lists.openstack.org>
> >>> Date: 2016/02/23 16:00
> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> >>> ready for translation in Mitaka?
> >>>
> >>> Hi Daisy,
> >>>
> >>> AFAIK the following horizon plugins are ready for translation.
> >>> I tested and confirmed translations of these two work well with
Japanese.
> >>> A minor improvement on devstack or other stuff are in progress but it
> >>> does not affect translation.
> >>>
> >>> * trove-dashboard
> >>> * sahara-dashboard
> >>>
> >>> The following horizon plugins SEEM to support translations.
> >>> I have never tried them.
> >>>
> >>> * desginate-dasbhard
> >>> * magnum-ui
> >>> * monasca-ui
> >>> * murano-dashboard
> >>> * senlin-dashboard
> >>>
> >>> Thanks,
> >>> Akihiro
> >>>
> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
> >>> > Hi,
> >>> >
> >>> > Mitaka translation will be started from March 4 and ended in the
week of
> >>> > March 28.
> >>> > I'd like to know which Horizon plugins[1] are ready for translation
in
> >>> > Mitaka release.
> >>> > If there are, I'm happy to include them in the Mitaka translation
plan.
> >>> >
> >>> > Thank you.
> >>> >
> >>> > Best regards
> >>> > Ying Chun Guo (Daisy)
> >>> >
> >>> > [1]
http://docs.openstack.org/developer/horizon/plugin_registry.html
> >>> >
> >>> >
> >>> >
> >>
__
> >>> > 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
> >>
> >
> >
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject: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-dev] [Horizon][Searchlight] Plans for Horizon cross-region view

[Brad Pokorny]

The last info I've found on the ML about a cross-region view in Horizon is [1], 
which mentions making asynchronous calls to the APIs. Has anyone done further 
work on such a view?

If not, I think it would make sense to only show the view if Searchlight is 
enabled. One of the Searchlight use cases is cross-region searching, and only 
using the searchlight APIs would cut down on the slowness of going directly to 
the service APIs for what would potentially be a lot of records. Thoughts?

[1] http://openstack.markmail.org/message/huk5l73un7t255ox
__
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] Any Horizon plugins ready for translation in Mitaka?

[Akihiro Motoki]

2016-02-25 19:47 GMT+09:00 Andreas Jaeger <a...@suse.com>:
> On 2016-02-25 11:40, Ying Chun Guo wrote:
>> Thank you, Akihiro.
>> The projects listed below are all in translation website except
>> desginate-dasbhard.
>
> Typo, it' designate, see
> https://translate.openstack.org/project/view/designate-dashboard

Thanks for the follow-up.
Yeah. I typed designate-dashboard and made a mistake :-(

>
>> Whether these projects can get translated in Mitaka depends.
>> Let's discuss with team.
>
> Andreas
>
>> Best regards
>> Ying Chun Guo (Daisy)
>>
>>
>> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
>>
>>> From: Akihiro Motoki <amot...@gmail.com>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev@lists.openstack.org>
>>> Date: 2016/02/23 16:00
>>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>>> ready for translation in Mitaka?
>>>
>>> Hi Daisy,
>>>
>>> AFAIK the following horizon plugins are ready for translation.
>>> I tested and confirmed translations of these two work well with Japanese.
>>> A minor improvement on devstack or other stuff are in progress but it
>>> does not affect translation.
>>>
>>> * trove-dashboard
>>> * sahara-dashboard
>>>
>>> The following horizon plugins SEEM to support translations.
>>> I have never tried them.
>>>
>>> * desginate-dasbhard
>>> * magnum-ui
>>> * monasca-ui
>>> * murano-dashboard
>>> * senlin-dashboard
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
>>> > Hi,
>>> >
>>> > Mitaka translation will be started from March 4 and ended in the week of
>>> > March 28.
>>> > I'd like to know which Horizon plugins[1] are ready for translation in
>>> > Mitaka release.
>>> > If there are, I'm happy to include them in the Mitaka translation plan.
>>> >
>>> > Thank you.
>>> >
>>> > Best regards
>>> > Ying Chun Guo (Daisy)
>>> >
>>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>>> >
>>> >
>>> >
>> __
>>> > 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
>>
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: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][i18n] Any Horizon plugins ready for translation in Mitaka?

[Andreas Jaeger]

On 2016-02-25 11:40, Ying Chun Guo wrote:
> Thank you, Akihiro.
> The projects listed below are all in translation website except
> desginate-dasbhard.

Typo, it' designate, see
https://translate.openstack.org/project/view/designate-dashboard

> Whether these projects can get translated in Mitaka depends.
> Let's discuss with team.

Andreas

> Best regards
> Ying Chun Guo (Daisy)
> 
> 
> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
> 
>> From: Akihiro Motoki <amot...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: 2016/02/23 16:00
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> Hi Daisy,
>>
>> AFAIK the following horizon plugins are ready for translation.
>> I tested and confirmed translations of these two work well with Japanese.
>> A minor improvement on devstack or other stuff are in progress but it
>> does not affect translation.
>>
>> * trove-dashboard
>> * sahara-dashboard
>>
>> The following horizon plugins SEEM to support translations.
>> I have never tried them.
>>
>> * desginate-dasbhard
>> * magnum-ui
>> * monasca-ui
>> * murano-dashboard
>> * senlin-dashboard
>>
>> Thanks,
>> Akihiro
>>
>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
>> > Hi,
>> >
>> > Mitaka translation will be started from March 4 and ended in the week of
>> > March 28.
>> > I'd like to know which Horizon plugins[1] are ready for translation in
>> > Mitaka release.
>> > If there are, I'm happy to include them in the Mitaka translation plan.
>> >
>> > Thank you.
>> >
>> > Best regards
>> > Ying Chun Guo (Daisy)
>> >
>> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>> >
>> >
>> >
> __
>> > 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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Ying Chun Guo]

Thank you, Akihiro.
The projects listed below are all in translation website except
desginate-dasbhard.
Whether these projects can get translated in Mitaka depends.
Let's discuss with team.

Best regards
Ying Chun Guo (Daisy)


Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:

> From: Akihiro Motoki <amot...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 2016/02/23 16:00
> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
> ready for translation in Mitaka?
>
> Hi Daisy,
>
> AFAIK the following horizon plugins are ready for translation.
> I tested and confirmed translations of these two work well with Japanese.
> A minor improvement on devstack or other stuff are in progress but it
> does not affect translation.
>
> * trove-dashboard
> * sahara-dashboard
>
> The following horizon plugins SEEM to support translations.
> I have never tried them.
>
> * desginate-dasbhard
> * magnum-ui
> * monasca-ui
> * murano-dashboard
> * senlin-dashboard
>
> Thanks,
> Akihiro
>
> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
> > Hi,
> >
> > Mitaka translation will be started from March 4 and ended in the week
of
> > March 28.
> > I'd like to know which Horizon plugins[1] are ready for translation in
> > Mitaka release.
> > If there are, I'm happy to include them in the Mitaka translation plan.
> >
> > Thank you.
> >
> > Best regards
> > Ying Chun Guo (Daisy)
> >
> > [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
> >
> >
> >
__
> > 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][Neutron][QoS]horizon angular network QoS panel

[Miguel Angel Ajo Pelayo]

Hi Masco!,

   Thanks a lot for working on this, I’m not following the [Horizon] tag and I 
missed
this. I’ve added the Neutron and QoS tags.

   I will give it a try as soon as I can. 

   Keep up the good work!,

Cheers,
Miguel Ángel.
> On 10 Feb 2016, at 13:04, masco  wrote:
> 
> 
> Hello All,
> 
> As most of you people knows the 'QoS' feature is added in neutron during 
> liberty release.
> It will be nice to have this feature in horizon, so I have added a 'network 
> qos' panel for the same in angularJS.
> It will be very helpful if you people reviewing this patches and helping to 
> land this feature in horizon.
> 
> gerrit links:
> 
> https://review.openstack.org/#/c/247997/ 
> 
> https://review.openstack.org/#/c/259022/11 
> 
> https://review.openstack.org/#/c/272928/4 
> 
> https://review.openstack.org/#/c/277743/3 
> 
> 
> 
> To set test env:
> here is some steps how to enable a QoS in neutron.
> If you want to test it will help you.
> 
> 
>   To enable the QoS in devstack please add below two
>   lines in the local.conf enable_plugin neutron
>   git://git.openstack.org/openstack/neutron
>   enable_service q-qos and rebuild your stack
>   (./stack.sh)
> 
> Thanks,
> Masco.
> 
> 
> __
> 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][i18n] Any Horizon plugins ready for translation in Mitaka?

[Akihiro Motoki]

Hi Daisy,

AFAIK the following horizon plugins are ready for translation.
I tested and confirmed translations of these two work well with Japanese.
A minor improvement on devstack or other stuff are in progress but it
does not affect translation.

* trove-dashboard
* sahara-dashboard

The following horizon plugins SEEM to support translations.
I have never tried them.

* desginate-dasbhard
* magnum-ui
* monasca-ui
* murano-dashboard
* senlin-dashboard

Thanks,
Akihiro

2016-02-23 15:52 GMT+09:00 Ying Chun Guo :
> Hi,
>
> Mitaka translation will be started from March 4 and ended in the week of
> March 28.
> I'd like to know which Horizon plugins[1] are ready for translation in
> Mitaka release.
> If there are, I'm happy to include them in the Mitaka translation plan.
>
> Thank you.
>
> Best regards
> Ying Chun Guo (Daisy)
>
> [1] http://docs.openstack.org/developer/horizon/plugin_registry.html
>
>
> __
> 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][i18n] Any Horizon plugins ready for translation in Mitaka?

[Andreas Jaeger]

On 2016-02-23 07:52, Ying Chun Guo wrote:
> Hi,
> 
> Mitaka translation will be started from March 4 and ended in the week of
> March 28.
> I'd like to know which Horizon plugins[1] are ready for translation in
> Mitaka release.
> If there are, I'm happy to include them in the Mitaka translation plan.
> 
> Thank you.
> 
> Best regards
> Ying Chun Guo (Daisy)
> 
> [1] http://docs.openstack.org/developer/horizon/plugin_registry.html

Keep in mind that only some have translations setup - I think you can
take those that are setup in Zanata.

Exception is zaqar-ui which is not setup correctly for translations and
not ready from latest conversations I've had,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

[openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

[Ying Chun Guo]

Hi,

Mitaka translation will be started from March 4 and ended in the week of
March 28.
I'd like to know which Horizon plugins[1] are ready for translation in
Mitaka release.
If there are, I'm happy to include them in the Mitaka translation plan.

Thank you.

Best regards
Ying Chun Guo (Daisy)

[1] http://docs.openstack.org/developer/horizon/plugin_registry.html
__
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] [octavia] [heat] [docs] Meeting times and the -cp meeting room

[Anne Gentle]

On Mon, Feb 22, 2016 at 8:49 AM, Anne Gentle 
wrote:

> Hi all,
>
> The docs team has been seeking a new meeting time for North America/Europe
> for a couple of months now. With that search comes the search for a meeting
> room. Here's what we know:
>
> We want Wed 20:00.
>
> Heat, Horizon, and Octavia are currently in the three meeting rooms in the
> time slot we want.
>
> We've requested the use of #openstack-meeting-cp but there's some who
> express a need for ad-hoc meeting times in that room.
>
> The meetbot is enabled in #openstack-doc.
>
> So, could we either use #openstack-meeting-cp or #openstack-doc? Or have
> Heat, Horizon, or Octavia been looking for another time slot by chance?
>
> Thanks for ideas.
>

New idea: 1900 Wed. has free meeting rooms. I've updated the review, please
vote on this time:

https://review.openstack.org/271361

Thanks Andreas for looking!

Anne


>
> Anne
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [octavia] [heat] [docs] Meeting times and the -cp meeting room

[Anne Gentle]

Hi all,

The docs team has been seeking a new meeting time for North America/Europe
for a couple of months now. With that search comes the search for a meeting
room. Here's what we know:

We want Wed 20:00.

Heat, Horizon, and Octavia are currently in the three meeting rooms in the
time slot we want.

We've requested the use of #openstack-meeting-cp but there's some who
express a need for ad-hoc meeting times in that room.

The meetbot is enabled in #openstack-doc.

So, could we either use #openstack-meeting-cp or #openstack-doc? Or have
Heat, Horizon, or Octavia been looking for another time slot by chance?

Thanks for ideas.

Anne

-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Trove][Sahara] Horizon-Trove/Sahara External Repository

[Akihiro Motoki]

Hi,

> Horizon still have some things we need to tidy up on our end to make sure we
> have full support for testing and localization for external plugins.

I am pleased to announce that translations of trove-dashboard and
sahara-dashboard
now work for the master branch. We have the parity to Liberty release :-)
Thanks Andreas and folks involved in this effort.

Akihiro

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

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

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

[Thai Q Tran]

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


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

Re: [openstack-dev] [Horizon] eslint without color?

[Jeremy Stanley]

On 2016-02-15 16:45:09 +1100 (+1100), Richard Jones wrote:
> I'm just curious why our eslint configuration (in packages.json)
> specifies --no-color. It's much harder to spot the errors without
> color, and I always end up running it manually to get the color.
> Also, karma output has color, so why one and not the other?
> 
> In short, would anyone object to turning color on for eslint?

If it's being run in gate jobs, we need some mechanism to disable
ANSI color there since the embedded escapes tend to make logged
output from it nearly unreadable. If it acts like most _sane_
command-line tools however, it should disable all terminal escapes
if it detects that there's no controlling terminal (for example, if
stdin is null). No idea whether command-line sanity is common to
Javascript programmers, but perhaps someone here is willing to make
it a reality if not.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

[Andreas Jaeger]

On 2016-02-15 11:32, Omer (Nokia - IL) Etrog wrote:
> Hi,
> Is there proper documentation how to add localization for external plugins 
> that use AngularJS?


http://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructure

Note that the translation team only translates official projects - and
prioritizes there on what they do,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

[Etrog, Omer (Nokia - IL)]

Hi,
Is there proper documentation how to add localization for external plugins that 
use AngularJS?
Thanks,
Omer Etrog
Vitrage Team    

From: Thai Q Tran [mailto:tqt...@us.ibm.com] 
Sent: Thursday, December 03, 2015 11:44 PM
To: openstack-dev@lists.openstack.org
Cc: Vince Brunssen
Subject: [openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

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

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