[openstack-dev] [release][collectd-openstack-plugins] Schedule new release?

[Matthias Runge]

Hello,

it has been some time, since collectd-ceilometer-plugin[1]
has been renamed to collectd-openstack-plugins[2] and since there has 
been a release.


What is required to trigger a new release here?

Thank you,
Matthias


[1] https://github.com/openstack/collectd-ceilometer-plugin
[2] https://github.com/openstack/collectd-openstack-plugins
--
Matthias Runge 

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

__
OpenStack Development Mailing 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] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed

[Matthias Runge]

On 19/02/18 08:27, Matthias Runge wrote:
> On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote:
>> Hello kolla team,
>>
>> It looks like stable builds for kolla have been failing for some time now. 
>> Just forwarding this on to make sure the team is aware of it before the need 
>> for a stable release comes up.
>>
>>> Build failed.
>>>

Looking at this again, for example the centos-binary push job times out.
Especially, this here[1] is apparently started, but has not ended.
Unfortunately, I haven't been able to find any logs regarding docker push

2018-02-21 07:08:57.101374 | primary | 92bd2d995bd5: Pushed
2018-02-21 07:08:58.693761 | POST-RUN END RESULT_TIMED_OUT: [untrusted :
git.openstack.org/openstack/kolla/tests/playbooks/publish.yml@stable/ocata]
2018-02-21 07:08:58.693989 | POST-RUN START: [untrusted :
git.openstack.org/openstack/kolla/tests/playbooks/post.yml@stable/ocata]
2018-02-21 07:09:00.270882 |
2018-02-21 07:09:00.271153 | PLAY [all]
2018-02-21 07:09:00.416795 |
2018-02-21 07:09:00.417030 | TASK [shell]
2018-02-21 07:09:01.129686 | primary | /usr/bin/journalctl
2018-02-21 07:09:01.394259 | primary | Warning: Unable to open /dev/sr0
read-write (Read-only file system).  /dev/sr0
2018-02-21 07:09:01.394390 | primary | has been opened read-only.
2018-02-21 07:09:01.395668 | primary | Error: /dev/sr0: unrecognised
disk label
2018-02-21 07:09:02.797357 | primary | WARNING: bridge-nf-call-iptables
is disabled
2018-02-21 07:09:02.797457 | primary | WARNING: bridge-nf-call-ip6tables
is disabled
2018-02-21 07:09:06.029466 | primary | ok: Runtime: 0:00:04.787576
2018-02-21 07:09:06.079653 |
2018-02-21 07:09:06.079927 | TASK [synchronize]



[1]
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc859f1/ara/reports/a1a13a4a-3e90-4290-82e4-e031ce6029ad.html
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed

[Matthias Runge]

On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote:
> Hello kolla team,
> 
> It looks like stable builds for kolla have been failing for some time now. 
> Just forwarding this on to make sure the team is aware of it before the need 
> for a stable release comes up.
> 
> > Build failed.
> > 
> > - build-openstack-sphinx-docs 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/build-openstack-sphinx-docs/b0f5081/html/
> >  : SUCCESS in 2m 50s
> > - openstack-tox-py27 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/openstack-tox-py27/b6577a4/
> >  : SUCCESS in 2m 27s
> > - kolla-publish-centos-source 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-source/29e3a2b/
> >  : POST_FAILURE in 1h 16m 44s
> > - kolla-publish-centos-binary 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc12a93/
> >  : POST_FAILURE in 1h 08m 48s (non-voting)
> > - kolla-publish-ubuntu-source 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-source/dd419ce/
> >  : POST_FAILURE in 56m 40s
> > - kolla-publish-ubuntu-binary 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-binary/a7fca30/
> >  : POST_FAILURE in 52m 05s (non-voting)
> > - kolla-publish-oraclelinux-source 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-source/7e87ef0/
> >  : POST_FAILURE in 1h 35m 59s
> > - kolla-publish-oraclelinux-binary 
> > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-binary/56eb5bd/
> >  : POST_FAILURE in 1h 42m 57s (non-voting)

This one is differs significantly from the other build failures.

Previously, only both ubuntu-related builds failed.

Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] Resigning from horizon core

[Matthias Runge]

Hello,

this has been long due (and thank you Richard for reminding me),
my job responsibilities changed a while ago, and I don't have the
time anymore to review patches in Horizon or even to submit new ones.

Please remove my horizon core status (and the horizon-stable-maint as
well).

Thank you, and best,
Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [TripleO][UI] Port number for frontend app

[Matthias Runge]

On 22/08/16 08:08, Honza Pokorny wrote:
> Hello folks,
> 
> We've been using port 3000 for the GUI during development and testing.
> Now that we're working on packaging and shipping our code, we're
> wondering if port 3000 is still the best choice.
> 
> Would 3000 conflict with any other services?  Is there a better option?

grafana from opstools uses the same port[1]

That being said, I wonder if someone would install both services on the
same node.



[1]
https://github.com/centos-opstools/opstools-doc/blob/master/performance-monitoring.txt#L70


Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Matthias Runge]

On 25/07/16 09:57, Julien Danjou wrote:
> On Sun, Jul 24 2016, Mathias Ewald wrote:
> 
>> 5. InfluxDB to store metrics
>> 6. Grafana to dashboard metrics
> 
> Would be nice to leverage scalable and open source solution built your
> fellow OpenStack community, i.e. Gnocchi and its Grafana support.
> 
Yes, I'd like to repeat the question here: Is there any reason to
introduce another quite complex tool instead of something developed,
supported and used by the OpenStack community?

Matthias

-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Matthias Runge]

On 25/07/16 06:38, Mathias Ewald wrote:
> Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
> tenants rather than cloud ops? If that's the case I wont find info like
> "controller cpu usage" or "hypervisor memory usage".
> 
> Cheers
> Mathias
> 
Uhm, in this scenario, gnocchi just used as time-series database. It's
up to you, what you feed in. collectd collects whatever you want and put
it into your database.

Best,
Matthias

-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [kolla] Monitoring tooling

[Matthias Runge]

On 23/07/16 00:15, Steven Dake (stdake) wrote:
> Hi folks,
> 
> At the midcycle we decided to push off implementing Monitoring until
> post Newton.  The rationale for this decision was that the core review
> team has enough on their plates and nobody was super keen to implement
> any monitoring solution given our other priorities.
> 
> Like all good things, communities produce new folks that want to do new
> things, and Sensu was proposed as Kolla's monitoring solution (atleast
> the first one).  A developer that has done some good work has shown up
> to do the job as well :)  I have heard good things about Sensu, minus
> the fact that it is implemented in Ruby and I fear it may end up causing
> our gate a lot of hassle.

On a side note, we just founded a SIG in CentOS to bring in logging and
monitoring tools[1].

You were mentioning two different tasks: One is availability monitoring,
which we are doing with sensu/uchiwa
For performance monitoring there as a chain of collectd - graphite -
grafana.

Instead of graphite, one could use gnocchi[2] through a plugin.

These mentioned tools are implemented in Ruby(sensu/uchiwa),
Go/Nodejs(Grafana) and C (collectd). Graphite is a Django app.

[1] https://wiki.centos.org/SpecialInterestGroup/OpsTools
[2] http://docs.openstack.org/developer/gnocchi/grafana.html

-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] Midcycle Summary

[Matthias Runge]

On 22/07/16 09:38, Rob Cresswell wrote:
> We didn't discuss it explicitly, but I don't believe the decision has
> changed. We can remove it, but last I checked the patches in line to
> handle testing after deprecation still needed work. If they've been
> updated etc. I can look again.
> 
> Rob
> 
Patches I had up are now quite outdated. I'd highly appreciate someone
else taking over this.

That being said, I'm not sure if we should just remove it right now.

That would leave out all questions of testing disabled features etc,
which has been delaying this patch.

-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] Midcycle Summary

[Matthias Runge]

On 21/07/16 19:40, Rob Cresswell wrote:
> Hi everyone,
> 
> We had the Horizon mid cycle meetup last week, and I wanted to highlight
> some of the discussion and decisions made.
> 
> Agenda: https://etherpad.openstack.org/p/horizon-newton-midcycle 
> Notes: https://etherpad.openstack.org/p/horizon-newton-midcycle-notes
> 
Thanks for sharing this Rob!

Did you also talk about deprecating of ceilometer based metering dashboard?

IIRC, we all agreed at the last summit, this doesn't really work for
large deployments and should be removed or replaced?

Or does anyone still use it?

Matthias

-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [stable] Stable check of openstack/horizon failed

[Matthias Runge]

On 15/06/16 09:22, Matthias Runge wrote:
> On 15/06/16 09:20, Matthias Runge wrote:
>> On 15/06/16 08:14, A mailing list for the OpenStack Stable Branch test
>> reports. wrote:
>>> Build failed.
>>>
>>> - periodic-horizon-docs-liberty 
>>> http://logs.openstack.org/periodic-stable/periodic-horizon-docs-liberty/b029b21/
>>>  : SUCCESS in 7m 13s
>>> - periodic-horizon-python27-liberty 
>>> http://logs.openstack.org/periodic-stable/periodic-horizon-python27-liberty/45cf2ec/
>>>  : SUCCESS in 6m 55s
>>> - periodic-horizon-docs-mitaka 
>>> http://logs.openstack.org/periodic-stable/periodic-horizon-docs-mitaka/5083844/
>>>  : SUCCESS in 7m 00s
>>> - periodic-horizon-python27-mitaka 
>>> http://logs.openstack.org/periodic-stable/periodic-horizon-python27-mitaka/8dfd68c/
>>>  : FAILURE in 4m 27s
>>>
> This is due to a recent change in oslo_utils.
> 
> https://bugs.launchpad.net/horizon/+bug/1592553
> 
> we have a fix for current master branch
> https://review.openstack.org/329777
> 
> and it should be backported once the patch merges on master.

another backport to mitaka is required to unlock the horizon mitaka gate:

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



-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [stable] Stable check of openstack/horizon failed

[Matthias Runge]

On 15/06/16 09:20, Matthias Runge wrote:
> On 15/06/16 08:14, A mailing list for the OpenStack Stable Branch test
> reports. wrote:
>> Build failed.
>>
>> - periodic-horizon-docs-liberty 
>> http://logs.openstack.org/periodic-stable/periodic-horizon-docs-liberty/b029b21/
>>  : SUCCESS in 7m 13s
>> - periodic-horizon-python27-liberty 
>> http://logs.openstack.org/periodic-stable/periodic-horizon-python27-liberty/45cf2ec/
>>  : SUCCESS in 6m 55s
>> - periodic-horizon-docs-mitaka 
>> http://logs.openstack.org/periodic-stable/periodic-horizon-docs-mitaka/5083844/
>>  : SUCCESS in 7m 00s
>> - periodic-horizon-python27-mitaka 
>> http://logs.openstack.org/periodic-stable/periodic-horizon-python27-mitaka/8dfd68c/
>>  : FAILURE in 4m 27s
>>
This is due to a recent change in oslo_utils.

https://bugs.launchpad.net/horizon/+bug/1592553

we have a fix for current master branch
https://review.openstack.org/329777

and it should be backported once the patch merges on master.

Best,
Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [stable][all] Tagging kilo-eol for "the world"

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/06/16 12:31, Tony Breeds wrote:
> Hi all, In early May we tagged/EOL'd several (13) projects.  We'd
> like to do a final round for a more complete set.  We looked for
> projects meet one or more of the following criteria: - The project
> is openstack-dev/devstack, openstack-dev/grenade or 
> openstack/requirements - The project has the 'check-requirements'
> job listed as a template in project-config:zuul/layout.yaml - The
> project is listed in governance:reference/projects.yaml and is
> tagged with 'release:managed' or 'stable:follows-policy' (or
> both).
> 
> The list of 171 projects that match above is at [1].  There are
> another 68
I just abandoned open reviews for django_openstack_auth in kilo version.

django_openstack_auth is tightly coupled with horizon and should
follow the same schedule.

- -- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXUTHeAAoJEBdpskgc9eOLNEIQAJtrEvtmCyEWo1aozIZOJSyp
+by9HO7s4UzP2wUmR5WpAG0w4wFDIlloY1i+jeRh9nDrSVJiyBqu7VKetgIhcEyP
Zcg+ACVzLUzM5cCDuGR9892yO7jo+M9ez8i9UORiCHi4Q5rqok6EyykEWCDgue1X
WMOJG+pTobdwA25bb9Eoq+3QNg/K988qzs0Y2JG+bU2chtcxLeJEfoeji1yEfnhE
rvpNfLlXOhaR8eN9ZguoEX2eAXGFy9uMLbk5r9kAGG7IPoq41Lkry47qJkOEtR7e
ztwqEfEy3BTTIi+bgV56HJRjZoirgj6+5pOmsXVN+CUJUVCrESK8yLIBORaj5LzN
pFssS5b4h/j7/MShkV1AbltbrQNbiKJw/0CHjvxKll0bHpgfSedqGJCPfWZQvHqF
qXODns0dmIS2xvFU8dBhLpAuRG5kirUzTXJb/Rfaknta7Smz5IWQ7lW37eeDvrrz
/LDo3P4gQa8jaSj/1ye4QYnTulRgOw5TGitctHofzKPxfm+oPu3p2/QR08kAWA/g
HUAenWrRkralksf5vX/vecW8lvZyyJBcKWeBVZbZQH5LHE062SwWHc0kXekgAmtT
ewYUzWDBt0Afuwf70dl59GMlbk0wk4VT9awybBgMyRKmZI6UyAaVhLY0htcc2GZv
wN+EdXCr4KNyPriWcT4T
=U9ij
-END PGP SIGNATURE-

__
OpenStack Development Mailing 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] new stable-maint cores for Horizon

[Matthias Runge]

Horizoners,

please join me to welcome

* Richard Jones
* Rob Cresswell
* Thai Tran

as new Horizon stable core reviewers.

Thank you guys for stepping up and thank you tonyb for pulling stats and
pushing this.

Best,
Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] [tc] supporting Go

[Matthias Runge]

On 05/05/16 02:25, Tom Fifield wrote:

> Not a TC member, and this might not even be the right place for this,
> but ... I think it would be nice if someone has a think about how moving
> from a primarily single language community to a
> multiple-languages-allowed-in-a-bigger-way community impacts the
> "people" side of the community. Then, possibly write that down, maybe
> even with things that we could do to address any badness foreseen.
> 
We already had that, for example in Horizon, moving from a mostly Python
oriented community to a mostly JavaScript community.

At the same time, when the shift happened, the community changed quite a
lot. That might be coincidence.
-- 
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] [tc] supporting Go

[Matthias Runge]

On 10/05/16 08:57, Angus Lees wrote:
> No, it doesn't.  Several applications written in go are already packaged
> for Debian (for example).
> 
> Indeed the equivalent of "installing from master/pip" (ie: not using
> distro packages) is _much_ easier in go, since there is no need for the
> equivalent of venvs.  Like all compiled languages, there is a separate
> compile step required.
> 
>  - Gus
> 

For fedora, there is gofed, which produces nice spec files for golang
packages. Fedora already contains a few golang packages.

As a packager looking at go packages, I noticed

1. most golang "packages" don't even have a release, they only consist
of a series of commits
2. golang programs often fetch various sources from all over the net at
build time; they are compiled into static linked binaries, with all
known consequences
3. both 1. and 2. make issue tracking or tracking for vulnerabilities
quite hard, or even impossible.
4. I also noticed, upstreams change quite quickly, some changed
location, some just a name, not to speak about api changes. That might
be due to the age of observed projects. But the nature of go makes is
quite easy to import directly from the net.



-- 
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] [stable][horizon] feature freeze exception Logout user if he has no valid tokens for stable/Kilo

[Matthias Runge]

On 04/05/16 12:44, Itxaka Serrano Garcia wrote:
> This is me asking for a feature freeze exception, sorry if it wasnt clear.
> 
> Itxaka
> 
> On 05/04/2016 12:11 PM, Itxaka Serrano Garcia wrote:
>> Link to the patch: https://review.openstack.org/#/c/304504/
>>
>> Pros:
>> Only 13 lines of code (the rest is modifying the tests).
>> Resolves a very nasty end user experience issue which is not documented
>> anywhere.
>> Already merged on master since Liberty.
>>
>> Cons:
>> 
>>
>>
>>
>> Seems to me that its a low-risk/high-gain patchset.
>>
>> Proposing it into the list as no consensus has been taken on the patch
>> itself and Kilo is going EOL.
>>
>>
>> Would also be good to get some explanations in case of refusal :)
>>

Makes sense to me, thank you for the heads-up here.

-- 
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] [ceilometer][horizon] metric-list not complete and show metrics in horizon dashboard

[Matthias Runge]

On 12/04/16 13:47, Safka, JaroslavX wrote:
> Hi all,
> 

> Second question how I can propagate the metrics to horizon dashboard 
> "Resource usage"?
> (I'm able only see cpu metric from started worker image)

Jaroslav,

I would suggest you to look at gnocchi instead of ceilometer for Horizon
integration. We (in Horizon) did not manage to deprecate ceilometer yet
[1], but that being said, Ceilometer is not the right tool for
displaying (lots of) metering data in horizon.


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

-- 
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][stable] proposing Rob Cresswell for Horizon stable core

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/04/16 05:12, Tony Breeds wrote:
> On Thu, Apr 07, 2016 at 12:01:31PM +0200, Matthias Runge wrote:
>> Hello,
>> 
>> I'm proposing Rob Cresswell to become stable core for Horizon. I 
>> thought, in the past all PTL were in stable team, but this
>> doesn't seem to be true any more.
> 
> This *may* have been true when the project specific team were
> created, which was before my time, but it isn't true now.
> 
>> Please chime in with +1/-1
> 
> -1
> 
> As with core status in other parts of OpenStack its merit /
> evidence based. That is to say if you're doing good work, showing
> an understanding of the stable policy then great lets do this
> thing.
> 
> A quite check of reviewstats:
> 
> stable-liberty-horizon-120.txt :
> http://paste.openstack.org/show/493706 stable-kilo-horizon-120.txt
> : http://paste.openstack.org/show/493707
> 
> Shows that Rob has done 2 stable reviews in the last 120 days.
> 
> This is absolutely no reflection on Rob's contribution to Horizon
> as a whole.
> 
We never took review stats for stable branches as basis for proposing
or voting for someone being stable-maint.

In the past, people were proposed (and approved) to become stable
maintainer, because people were convinced the new person will care
about stable status in Horizon.

And after approval, someone would act as mentor to educate the new
core on stable review guidelines. That's a quite lightweight process,
it currently didn't fail for us, and we're in the situation, where
we're desperately looking for stable reviewers and cores.

- -- 
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDMiMAAoJEBdpskgc9eOLiF4P/jqGY2CaTavyvKgpRloXCpvP
bLT5VDKG5HFVG9KA2KBgVxC8ZbSRiFZeFBwVKzGa9ROscj21QUt3bo1DDqHBObys
AS0ZMW3ZuJQ+Meb4TX3WqemeT68qSrR4u5/BiUldtG8Fd8Ib2c8aKDeqdqKh/X2f
VyodWWt/IW2yFEpuWIQU+RRRz5UMr6I6lf2LGWGmHA5LuLotjs0L+6Gnob67K6Iz
PuU05TlV9pekfPcOr0neiKv4Bkz7mhS6gtQPo0be5coAGdFITxr6Vqnjvmixrowi
SsnhNZvDDF8Q/BRddsEeNtv+X6iqkKCAaSJKRvVLlVCQX+kubDxTWyxUKDUwt++r
wliMQKuAmqbJJvvLkvMvMM51obQaqL9WMkmp5SNBA/7YGf6+aujZuR5IBNHoE9uf
nEh5MQ7RwJmhJWYBIn14oZ6t5o/8EFQbXcFYnUyvSIvIefw/EFxt+ZG0Xg6NMIk2
aUlGO273Tj+EXoHopa/r/FmTORkffOENUmq8+WJoP8c2T2lKSVnYOebZvMa4wDHD
F2dbFWIqmHBDd4vPY49QhOlqDZpozJe4k8R1tqNa6h+lZrZQZ1Jx6yNC3/jly+Tp
m8t1S8b5sKVtXBMJBp2v/Bm9gyaE2d5gujeMzpxlk4jk0NJKKwhROp1Rd/ek+WIF
46tflQkI60Wy7EbKXiP+
=7abv
-END PGP SIGNATURE-

__
OpenStack Development Mailing 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][stable] proposing Rob Cresswell for Horizon stable core

[Matthias Runge]

Hello,

I'm proposing Rob Cresswell to become stable core for Horizon. I
thought, in the past all PTL were in stable team, but this doesn't seem
to be true any more.

Please chime in with +1/-1

-- 
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] Launch of an instance from a bootable volume fails on Xen env

[Matthias Runge]

On 24/03/16 12:03, Eugen Block wrote:
> Hi,
> 
>> Has this been resolved?  Is anyone working on this issue?
> 
> I had traced down the effect and found a possible solution, see
> https://bugs.launchpad.net/nova/+bug/1560965
> 
> If you're just trying to start via Horizon, changing
> /srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py
> ought to fix this for you:
> 
> ---cut here---
> control1:/srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows
> # diff -u5 create_instance.py.dist create_instance.py
> --- create_instance.py.dist 2016-03-18 10:40:51.123942306 +0100
> +++ create_instance.py  2016-03-24 11:49:00.404537704 +0100
> @@ -119,11 +119,11 @@


Eugen, did you file a bug for Horizon about this? I would think, that
should be examined carefully.

-- 
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 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] 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?

[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  <mailto:mru...@redhat.com>> 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] 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  <mailto:mord...@inaugust.com>> 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Matthias Runge]

On 09/03/16 18:26, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've

> openstack/django_openstack_auth 2.2.0

Yes please

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] 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

[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

Re: [openstack-dev] [Horizon] Django

[Matthias Runge]

On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> Hi,
> 
> I have been trying to fix a bug in horizon but I am a beginner in Django and 
> couldn't get my way through this code.
> 
> Could somebody please help me with it? Below given are the details of what I 
> am looking for.

Since you did not describe, what you would like to change, it's a bit
hard to set you on track.

Looking at that image, I assume, you would like to change
the subnet workflow, which is defined in subnets/workflows.py

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457


Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [horizon]Back porting code from master to liberty

[Matthias Runge]

On 18/01/16 07:22, Sirisha Guduru wrote:
> Hi,
> 
> ³VolumeTypeList² for admin is enabled in the master release of openstack
> horizon, where an admin can see all the volume types listed in horizon.
> The same is not implemented in liberty. Can we back port the code from
> master to liberty to meet the requirement or should it be implemented
> locally?

Sirisha,

in your local repositories, you can do anything you want.

For official branches there is an official policy:
https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes

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] Routing in Horizon

[Matthias Runge]

On 12/01/16 11:22, Matthias Runge wrote:

> 
> https://launchpad.net/bugs/1532759
> 
> Unfortunately, that even hasn't been detected by tests.
> 
https://github.com/openstack/horizon/commit/871505c130cf1fd02aae41aeb8f6062af4a5fe88

fixes this issue (another revert).

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] Routing in Horizon

[Matthias Runge]

On 12/01/16 03:33, Richard Jones wrote:
> The  tag addition has had to be reverted as it broke other parts
> of the application (notably lazy loaded tabs like Instance Details), sadly.
> 
> Regarding which router to use - I've used the built-in router in the
> past quite successfully. I think I'd want to see a solid reason for
> using a 3rd party one. It could be that nested routes are part of that,
> but I kinda see that as a convenience thing, unless I'm missing
> something core to how routing is planned to be done. Then again we
> really haven't had any discussion about how we see routing work. The one
> patch that's up that uses routing seems perfectly able to do so without
> needing extended capabilities of 3rd party routers.

I believe, there has been something else messing up with routing,
causing pagination to be broken now.

https://launchpad.net/bugs/1532759

Unfortunately, that even hasn't been detected by tests.

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] [stable] [horizon] Horizon stable and fast increasing Django releases

[Matthias Runge]

On Mon, Jan 11, 2016 at 10:44:11AM +0100, Thierry Carrez wrote:
> Thomas Goirand wrote:
> >[...]
> >Best would be if this kind of cap was only a temporary solution until we
> >really fix the issues. If possible (I perfectly know that in some case
> >this may be difficult), I'd like to have Horizon stable to contain
> >backports for Django last release (currently 1.9), instead of just
> >capping the requirements. Otherwise, Horizon becomes the single piece in
> >all of OpenStack where I spend all of my maintainer's time, which really
> >isn't good (there's lots of work to be done in other fields).
> >
> >Your thoughts? Am I the only one interested by this? Let's say I'm the
> >only one interested by it (I hope it's not the case), if I do the work,
> >will the patches be accepted in the Stable branch?
> 
> If the backports are done in a way that fixes issues for Django 1.9 users
> without changing code paths for <1.9 users, I guess that those backports
> could be accepted. Sounds like a good topic to add to the stable team
> meeting agenda if you want a more definitive answer to that question.

That's what we did in the past. IIRC Horizon in Juno supported Django-1.4, 
Django-1.5, and Django-1.6.

Backporting fixes to support Django-1.9 in Liberty seems fine for me.

-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On Tue, Jan 05, 2016 at 12:26:24PM +1300, Robert Collins wrote:
> On 5 January 2016 at 12:04, Robert Collins  wrote:
> ...
> > Indeed - 
> > https://bitbucket.org/pypa/setuptools/commits/fb35fcade302fa828d34e6aff952ec2398f2c877?at=get_command_list
> > - the failing bit AFAICT is indeed new code :/.
> 
> 
> Ok, so I've paged this all in. Here's whats up, and some thoughts on fixing 
> it.
> 
> Old pbr does indeed have a bug where 'setup.py test' will error with
> that unguarded import of what isn't meant to be a dependency.
> 
> The reason this started failing is that a bugfix to setuptools - so
> that the existing pbr code that wraps commands can wrap commands only
> added by setuptools plugins like 'wheel' was merged and included in a
> setuptools release.
> 
> This causes the pbr testr command to be loaded, which fails in old pbr.
> 
> The right answer is a back port of the import guard to pbr < 1.0.0 and
> a point release - 0.11.1.
> 
> IMO that is :)
> 
> I see that a workaround has been committed - installing testrepository
> - but I'd hate for folk to cargo cult the idea that pbr could have a
> runtime dependency on test-only tools like that.

Rob,

thank you for looking deeper into this. Your conclusions sound logical
to me and much saner than just pulling in testrepository.

Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On 04/01/16 15:41, Ihar Hrachyshka wrote:
> UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s
> interesting that it did not break the thing for e.g. Neutron master.
> 
> Matthias Runge  wrote:
> 
>> Hello,
>>

Horizon in Kilo *only* fails since Dec 26th. Horizon liberty seems to be
fine.

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][stable][tempest] Horizon|tempest kilo gate fails due to testrepository dependency

[Matthias Runge]

On Mon, Jan 04, 2016 at 01:32:53PM +0100, Ihar Hrachyshka wrote:
> Note that it’s keystone installation that fails, not horizon, and it seems
> that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would
> expect keystone gate to be broken too, so you could add the dep there and
> validate whether it fixes the thing for you.
> 
> The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr
> release that would pull in the dependency for you.
> 

keystone fails after adding testrepository to horizons test
requirements.

Horizon failed before, if we don't add it. Horizon does not use testr at
all.
http://logs.openstack.org/periodic-stable/periodic-horizon-python27-kilo/3fc703b/tox/py27-2.log

It looks like keystone does not fail,
but tempest fails in the same way as horizon does:
http://logs.openstack.org/periodic-stable/periodic-tempest-dsvm-full-kilo/a33736f/logs/devstacklog.txt.gz
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On Mon, Jan 04, 2016 at 12:29:27PM +0100, Ihar Hrachyshka wrote:
> Matthias Runge  wrote:
> >testrepository
> >
> >Any suggestions here?
> 
> Seems like pbr importing testrepository, hence the dependency belongs to
> pbr, not horizon (and as a runtime dependency, not just test only).
> 
> But note that since pbr 1.1.0, they no longer depend on the package and fail
> gracefully:
> 
> https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81
> 
> So the proper way would be indeed to make your package to install testr for
> tests. Not sure why it worked before, but I would bet that some other
> components installed it for you (devstack? devstack-gate? job definition?
> some other component previously installed before keystone? Not that it’s too
> important.)
> 
> Ihar

Thank you.

I'm a bit confused, why it worked before e.g Dec 20th last year, but
fails after.
And it's only failing in kilo, not on liberty.

And even when adding testrepository to test-requirements, it fails,
because it's missing?

If pbr uses testrepository at run-time, it should be pulled in as
run-time requirement.
-- 
Matthias Runge 

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

[openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz
-- 
Matthias Runge 

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

Re: [openstack-dev] [neutron] How to make deb and rpm packages for a networking-* project?

[Matthias Runge]

On 22/12/15 16:05, P. Ramanjaneya Reddy wrote:
> Changes are not merged to upstream still, we need to generate the rpm or
> deb with local changes.
> Please describe the steps/method how to generate..
> 
> On Tue, Dec 22, 2015 at 3:37 PM, Jaume Devesa  > wrote:

One can apply patches during package build process.

In the wider scope of RDO it is described  how to do use git for patch
handling and how to automatically generate and add patches to packages.

It all falls down to a git clone, cherry-pick patches and re-generate
packages. If you never heard before about building packages, I suggest
to look at that before.

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] Proposal to add Richard Jones to horizon-core

[Matthias Runge]

On 02/12/15 19:57, David Lyle wrote:
> Let's try that again.
> 
> I propose adding Richard Jones[1] to horizon-core.

> Please respond with comments, +1s, or objections within one week.
Yes, +1 from me.

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] Proposal to add Timur Sufiev to horizon-core

[Matthias Runge]

On 02/12/15 19:52, David Lyle wrote:
> I propose adding Timur Sufiev[1] to horizon-core.
> 
> Over the last several cycles Timur has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions particularly around testing and
> stability.
> 
> Please respond with comments, +1s, or objections within one week.
> 
Oh, yes please! Timur has been doing a great job, not only over the past
cycle.

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] Supporting Django 1.9

[Matthias Runge]

On 27/11/15 10:23, Thomas Goirand wrote:
> Hi,
> 
> Django 1.9 is due to be released in early December, and will reach
> Debian Sid soon after that. It'd be nice to have fixes for it ASAP. I
> already have bugs against some of the packages I maintain:

I would expect upstream to go the same route as before: supporting the
last LTS version (which is currently Django-1.8), and the latest release
too.

We in horizon are currently working on fixing deprecation notes[1]

Matthias


[1] https://blueprints.launchpad.net/horizon/+spec/drop-dj17





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

Re: [openstack-dev] [horizon][bug] Mitigation to BREACH vulnerability

[Matthias Runge]

On Fri, Nov 20, 2015 at 10:00:30PM +, BARTRA, RICK wrote:
> Until django releases an official patch for the BREACH vulnerability, I think 
> we should take a look at django-debreach. The django-debreach package 
> provides some, possibly enough, protection against a BREACH attack. Its 
> integration to Horizon is clear by following the configuration found here: 
> https://pypi.python.org/pypi/django-debreach
> 
> 
> The proposed change to Horizon: https://review.openstack.org/#/c/247838/
> 
> The proposed change to Requirements: https://review.openstack.org/#/c/248233/

Thank you for proposing this

still I believe, this is
a) security hardening to be done by deployers
b) something not specific to Horizon, and a solution should be integrated in
Django, not just in a single application using Django.

Matthias

-- 
Matthias Runge 

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

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

[Matthias Runge]

On 19/11/15 12:19, Rob Cresswell (rcresswe) wrote:
> Hey folks,
> 
> Our bug list is… rather large. We’ve discussed having a bug day, where
> as a community we all dedicate some time to triaging bugs and discussing
> in the IRC channel as we go.
> 
> First off, see the docs about bug
> triage: https://wiki.openstack.org/wiki/BugTriage
> 
> Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if
> that doesn’t work for a good number of us, then the following Tuesday
> (1st December). Trying to account for Thanksgiving :)
> 
Thank you Rob for pushing this forward!

I'd say, let's get started, the sooner the better. Next Tuesday seems fine.

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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Matthias Runge]

On 13/11/15 02:49, Tony Breeds wrote:
> On Thu, Nov 12, 2015 at 02:40:19PM +0100, Alan Pevec wrote:
> 
>> AFAICT there are at least two blockers for 2014.2.4: - horizon -
>> django_openstack_auth issue Tony mentions in 
>> https://review.openstack.org/172826
> 
> Horizon itself is fine BUT gets caught up in a mess of g-r updates.
> The issue at hand is that DOA has an uncapped requirement on
> oslo.config which then gets a 2.x release which doesn't contain the
> oslo namespace.  The *right* way to fix it is to cut a new relases
> of DOA including the a g-r sync.
> 
> There was some discussion on this in #openstack-stable: 
> http://eavesdrop.openstack.org/irclogs/%23openstack-stable/%23openstack-stable.2015-11-12.log.html
>
>  An alternate hack would be:
> https://review.openstack.org/#/c/244950/ but that seems fragile to
> me.
> 

Looking at
http://logs.openstack.org/periodic-stable/periodic-horizon-python27-juno/1f5b282/console.html

it's obvious, horizon falls down the same way like doa.

Speaking of your "hacky" patch: yes and no. It makes the gate passing,
it doesn't change the code itself. For most people, this will work fine.

The right way to do it, would be to create a juno branch for doa and
cap requirements there.

How to do this? Is there a procedure to request a branch?

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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Matthias Runge]

On 12/11/15 14:40, Alan Pevec wrote:
>> This is a call to stable-maint teams for Nova, Keystone, Glance,
>> Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
>> open stable/juno changes[2] and approve/abandon them as appropriate.
> 
> CCing CPLs listed in
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch
> 
> I got only ACK from Erno for Glance, anyone other project ready?
> 
> 
>> [2] 
>> https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z
> 
> AFAICT there are at least two blockers for 2014.2.4:
> - horizon - django_openstack_auth issue Tony mentions in
> https://review.openstack.org/172826
> - nova - gate-grenade-dsvm-ironic-sideways failures e.g. in
> https://review.openstack.org/227800
> 
> 

Horizon itself *should* be fine. For me, issues Tony mentioned are
actually inherited from keystoneclient.

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][infra] Horizon gate currently broken

[Matthias Runge]

Hello,

it looks like Horizon gate jobs (esp. the npm-run-lint jobs) are
currently timing out, and it looks like a networking issue.
I opened
https://bugs.launchpad.net/horizon/+bug/1514734
to track this.

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] Handling of 202 response code

[Matthias Runge]

On 04/11/15 09:25, Saravanan KR wrote:

> There may be multiple solutions:
> 1) Waiting for the synchronous and then respond
> 2) Do not trigger page refresh and respond with Operation in progress
> 3) If there is a mechanism to know delete in progress, do not list the
> interface
> 
> To decide on the solution, it is important to know how 202 responses
> should be handled. Can anyone can help with understanding?

Asynchronous operations are handled in horizon as synchronous
operations. To illustrate that: launch an instance, you'll get
immediately a feedback ("launch instance issued").
But, you don't get a status feedback directly. Horizon pulls nova api
for status updates via ajax calls.

So: there is no solution yet for this. You could duplicate the same
update strategy as in launch instance (on instances page), create a
volume (on volumes table), etc.

In ideal case, one would use something like a message bus to get
notified on changes.

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] [Zaqar][Horizon] UI for pools and flavors

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 09:25, Flavio Percoco wrote:
> On 10/10/15 21:07 +0530, Shifali Agrawal wrote:
>> Greetings!
>> 
>> I have prepared mock-ups[1],[2] to build Zaqar UI, at present
>> focusing only to bring pools and flavors on dashboard. Sharing
>> two mock-ups for same purpose - allowing all operations related
>> to them(CRUD).
>> 
>> It will be great to know the views of zaqar developers/users if
>> the design is satisfactory to them or they want some amendments.
>> Also let me know if any information of pools/flavors is missing
>> and need to be added.
>> 
>> In first mockup[1] showing pools information by default and will
>> show flavors if user click on flavors button present on top
>> second menu bar.
>> 
>> [1]: http://tinyurl.com/o2b9q6r [2]: http://tinyurl.com/pqwgwhl

> I'm adding `[horizon]` to the subject to get more folks'
> attention.
> 
Thank you for bringing this up!

maybe it's necessary to give a brief context for those mockups?
What does a pool here? why is a pool weighted (or how) and isn't a
pools and a pool group somehow the same?
If you have pools, what is the intention of flavors then?

Just to ask the obvious questions here

Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWG2LZAAoJEBdpskgc9eOLSnYQAIFJb2/u5FWUkuk+mAVcRHXJ
nHD0oAN5fxmAR0fqZH57n0T7et8Ocp+Xgp9aUD9roLPGlj9uFnLntMSHo9WIAzU9
gq2fl0pgnmpMzwJ0yooAiMq4HXyJcG5UaY9xImTReTH4382x8j1OTVFvS+9ws+VU
enK4S/2JW4Rvf6jpYGUcoNqtdmkFRLQohvu/K3V1Cg1Y+zMeYIQZxb4oZzcEOEyo
6E+DicR/4VVGi8gl0UGPkXSmm/jFaG8H3m5KTvTQr0PDd6l5ypwDXvZcRKQvPYmc
c155EvjeXPByhm1jXpE6Cgv6NNROQFr+uRM1jKLF0Ss030XI7TSyMNYv9br6OVxi
/SMlF+BG+FK26uwTc9Mf5D5mqTF6qgbPTLLu4vlqKa3JX0/y7Z8a7NoujzTKUBEl
WAftY2ADAJE6Vb/1TEubujDIlKGBtoT/lGQUIJtj1t5VftfaNrZ1N2vMQ4P7c9hA
W2EoRCTe6m8YbPPT3b3QFuuH2oecPECTiWcjEgRxp23ksnoFDkgjEGeM1+xNeQVV
kfwfG4mcGP4lEUwPk2sdL/3xu16iUTMJURZdvkqI1FX3YfMwITjiY/jdqIwVwlNF
03XhFn1uloXyHSNRNNFXf85r3v4FDw9FWQCeCU5mqOzkdZZafhvdi2tUjkHniGsG
mDyxERTHHiDOAqHUhLNn
=nLNP
-END PGP SIGNATURE-

__
OpenStack Development Mailing 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] [stable][horizon] adding stable reviewer

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/15 13:44, Thierry Carrez wrote:
> Ihar Hrachyshka wrote:
>> Welcome Doug!
> 
> Please (re)read and apply the policy at: 
> https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

Thank you Ihar!

Best,
Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWF7afAAoJEBdpskgc9eOLn04QAMVQhUCArh3rvpTBqHIS0mCB
SHdj1Go5LMU6+t8p42codEn0q+dihtO5sZaOKx+7LR6YZn5AhEmnf8ihn7dB4iHA
I+xgEdBNDXoalQhvS9fuoMtOqVesf+aUaH1bEnsktQpycYwXCXz5bSDhHqYEMkvn
Yq1rJfzA3JpHSeLR0yTaT3eFNfOJYyIx2vo9+bl77U7kZ8NnWpKsH3HRRXfW90fy
8Z6udKo3+bqtf03xHJAyHGxlD7TtkL5mGeNY9P+WKlHHKXSW3kkKpUj2RotzVoD3
d3Zz9A8g350vbXrfFhVwsbjdWBW6UMgtOpAheqZ+Nz/w/ZqClPGT6NAxjJfyLLWL
EsKcy4oHJ1VZPk7ql+MEjK6WNLe5c6PPTQT1QSOv49YfFfDPRYCBYx32Gs3hAMRH
zSRm24DJBoGq6aVBQQFUhun4YuisglWYTaSvwQbqe5arS/lNOyWzEC2sbI5ffJLR
fjtFXmJQDgJRIxkAC0VKlXEMizAfMstZJoG/ID05VZPe6KWGwlkrkAkT5p0XR2Oz
5EqJ9myy+Y9ZKwNC32R5fEt8JCG3z/FLMmA64OYtZ3ylY3VTrBzGVg4TtsP28gkV
AcKMMuSyIaKMpAavR7SWxJq1HvSr9bDQqCX+4AHApxvr0Z8YN355AudlTbylLUGz
wumYrnthpMwF6UpCA09K
=4S4k
-END PGP SIGNATURE-

__
OpenStack Development Mailing 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] [stable][horizon] adding stable reviewer

[Matthias Runge]

Hello,

who would be the person to talk to, to add a new reviewer to
horizon-stable-maint

I would like Doug Fish aka drfish (on launchpad) added.

Unfortunately, the fields on
https://review.openstack.org/#/admin/groups/537,members
are greyed out for me.

Thanks, 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] [stable][horizon] adding Doug Fish to horizon stable-maint

[Matthias Runge]

On 01/10/15 11:21, Matthias Runge wrote:
> Hello,
> 
> I would like to propose to add
> 
> Doug Fish (doug-fish)
> 
> to horizon-stable-maint team.
> 
> I'd volunteer and introduce him to stable branch policy.
A week has passed, no negative votes.

Doug, I'll request to add you to horizon-stable-maint, apparently I
can't do that myself.

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] [tc] naming N and O releases nowish

[Matthias Runge]

On Wed, Oct 07, 2015 at 03:02:47PM +0200, Christian Berendt wrote:
> Is this list correct?
> 
> M = Tokyo
> N = Atlanta
> O = Barcelona
> P = ?

IIRC N should be Austin instead of Atlanta.
-- 
Matthias Runge 

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

[openstack-dev] [stable][horizon] adding Doug Fish to horizon stable-maint

[Matthias Runge]

Hello,

I would like to propose to add

Doug Fish (doug-fish)

to horizon-stable-maint team.

I'd volunteer and introduce him to stable branch policy.

Matthias
--
Matthias Runge 

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

Re: [openstack-dev] [all][stable][release][horizon] 2015.1.2

[Matthias Runge]

On 25/09/15 15:39, Ihar Hrachyshka wrote:

> I see you have three people in the horizon-stable-maint team only. 
> Have you considered expanding the team with more folks? In
> neutron, we have five people in the stable-maint group.

Good suggestion!

In horizon, we just have a very few cores being in charge to support a
installation or a distribution.

So: if any of you considering themself to be a good candidate for
being a stable reviewer, please speak up!

For Horizon, I will ping Horizon cores asking them to join
horizon-stable-maint team.

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] [all][stable][release] 2015.1.2

[Matthias Runge]

On 25/09/15 00:17, Alan Pevec wrote:
>> For Horizon, it would make sense to move this a week back. We discovered
>> a few issues in Liberty, which are present in current kilo, too. I'd
>> love to cherry-pick a few of them to kilo.
> 
> What are LP bug#s ? Are you saying that fixes are still work in
> progress on master and not ready for backporting yet?
> 
Current backports:
https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:stable/kilo,n,z

They are tagged with lp bugs currently under review. As you see, they
are in (slow) progress.

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] [all][stable][release] 2015.1.2

[Matthias Runge]

On Wed, Sep 23, 2015 at 08:47:31PM -0400, Chuck Short wrote:
> Hi,
> 
> We would like to do a stable/kilo branch release, next Thursday. In order
> to do that I would like to freeze the branches on Friday. Cut some test
> tarballs on Tuesday and release on Thursday. Does anyone have an opinnon on
> this?

For Horizon, it would make sense to move this a week back. We discovered
a few issues in Liberty, which are present in current kilo, too. I'd
love to cherry-pick a few of them to kilo.

Unfortunately, it takes a bit, until Kilo (or in general: stable)
reviews are being done.
-- 
Matthias Runge 

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

Re: [openstack-dev] openstack-dahboard directory is not created

[Matthias Runge]

On 18/09/15 20:03, OpenStack Mailing List Archive wrote:
> Link: https://openstack.nimeyo.com/59453/?show=59453#q59453
> From: vidya 
> 
> I am trying to create openstack -dashboard on my VM and
> /usr/share/openstack-dashboard in not create. Please help me what i am
> missing here.
> 
> here is what i tried
> 1 yum install openstack-selinux
> 2 yum install yum-plugin-priorities
> 3 yum install
> http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
> 4 yum install openstack-dashboard httpd mod_wsgi memcached python-memcached
> 5 yum install python-pip
> 6 yum groupinstall 'Development Tools'
> 7 yum install python-devel
> 8 yum install libffi-devel
> 9 yum install openssl-devel
> 10 pip install dep/horizon-2014.1.1.tar.gz
> 11 yum install openstack-dashboard
> 12 yum upgrade
> 13 reboot
> 14 history
> 15 yum install openstack-dashboard
> 16 pip install horizon-2014.1.1.tar.gz
> 

Ugh,

you're mixing pip install and yum install.

For a distro, I recommend to use distro packages. We're not providing
horizon packages on pypi (and if we do, they are outdated).

horizon-2014.1.1.tar.gz is a good year old. If you're *really* looking
for installing that version, I'd suggest you to go with horizon-2014.1.4
(or later instead).


You can get a more recent version of horizon (and OpenStack) from
https://www.rdoproject.org

After following repo install instructions at
https://www.rdoproject.org/Quickstart
you can do yum install openstack-dashboard

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] Concern about XStatic-bootswatch imports from fonts.googleapis.com

[Matthias Runge]

On 03/09/15 21:02, Matthias Runge wrote:
> On 03/09/15 13:24, Thomas Goirand wrote:
>> Hi,
>>
>> When doing:
>> grep -r fonts.googleapis.com *
>>
>> there's 56 lines of this kind of result:
>> xstatic/pkg/bootswatch/data/cyborg/bootstrap.css:@import
>> url("https://fonts.googleapis.com/css?family=Roboto:400,700";);
>>
>> This is wrong because:
I'd like to raise an issue with roboto fontface.


xstatic package points to
https://github.com/choffmeister/roboto-fontface-bower/tree/develop/fonts

it's unclear, where those files are coming from. roboto font is
apparently coming from Google
https://www.google.com/fonts/specimen/Roboto

Unfortunately it's not clear, where .eot, .woff, .svg are coming from.
or how to recreate them form googles published .ttf files.

On the other side Googles repository doesn't have tags or releases at
all. That makes it hard to detect a newer release (there is no release).




Why do we care (about this)?

Packaging a software package can be compared to building a car in the
middle of nowhere, where you simply have a plan and maybe steel, and
some basic tools. But no access to postal service, no flying in special
tools, etc.
According to the plan, you're building the car. If you need a tool,
build that tool, too.

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] Concern about XStatic-bootswatch imports from fonts.googleapis.com

[Matthias Runge]

On 03/09/15 13:24, Thomas Goirand wrote:
> Hi,
> 
> When doing:
> grep -r fonts.googleapis.com *
> 
> there's 56 lines of this kind of result:
> xstatic/pkg/bootswatch/data/cyborg/bootstrap.css:@import
> url("https://fonts.googleapis.com/css?family=Roboto:400,700";);
> 
> This is wrong because:
> 
> 1/ This is a privacy breach, and one may not agree on hitting any web
> server which he doesn't control. It's a problem in itself for packaging
> in Debian, which is currently stopping me from uploading.
> 
> 2/ More importantly (and even if you don't care about this kind of
> privacy breach), this requires Internet access, which isn't at all
> granted in some installations.
> 
> So I wonder if using bootswatch, which includes such a problem, is
> really a good idea. Are these fonts import completely mandatory? Or can
> I patch them out? Will the result be ugly if I patch it out?
> 
Thomas,

You're right! I'd assume, this happened by accident. Nevertheless it
should be solved.

My simple POV is: solve it upstream or do not use bootswatch rather than
patch something out, which will lead to unexpected results for users and
will lead to complaints about stupid packagers (or else).

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] [heat][horizon] Backward-incompatible changes to the Neutron API

[Matthias Runge]

On 26/08/15 23:55, James Dempsey wrote:
> Greetings Heat/Horizon Devs,
> 
> There is some talk about possibly backward-incompatible changes to the
> Neutron VPNaaS API and I'd like to better understand what that means for
> Heat and Horizon.
> 
> It has been proposed to change Neutron VPNService objects such that they
> reference a new resource type called an "Endpoint Group" instead of
> simply a Subnet.
> 
> Does this mean that any version of Heat/Horizon would only be able to
> support either the old or new Neutron API, or is there some way to allow
> a version of Heat/Horizon to support both?
> 
In the past, Horizon worked cross releases.

The way horizon works is, it looks out for a networking endpoint in
keystone catalog. We don't really care, if it's nova or neutron
answering. The rest should be discoverable via API.
Horizon uses neutronclient rather than directly talking to neutron by
using its API interface.

If you make it discoverable, and you'd add that to neutronclient,
horizon could support both.

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] OpenStack Meiji (明治) - Our next release name has been selected

[Matthias Runge]

On 07/07/15 13:55, Masayuki Igawa wrote:



https://www.youtube.com/watch?v=D9vwge557hY
I think this is a casual version and Japanese people are familiar with this.

Thank you! I have an idea now.

About the youtube snippet: Is that a commercial?

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] OpenStack Meiji (明治) - Our next release name has been selected

[Matthias Runge]

On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote:
> significant identified problems... but the third in the list, Meiji (明
> 治) is clear.
> 
> So please join me in welcoming the latest name to our family ... and if
> you, like me, are not a native Japanese speaker, in learning two new
> characters.

Could someone provide a hint please, how to pronounce this properly?
-- 
Matthias Runge 

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

Re: [openstack-dev] [horizon] Modifying existing dashboards with plugins

[Matthias Runge]

On Mon, Jul 06, 2015 at 04:23:29PM -0700, Skyler Berg wrote:
> I am wondering if there is a way to have plugins modify existing
> dashboards currently that I am overlooking. If not, should there be?

Very briefly: There is currently no way to extend something else other
than a dashboard or a panel.

It's a known issue, there should be a pluggable way to extend tables
etc.
-- 
Matthias Runge 

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

Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?

[Matthias Runge]

On 18/06/15 17:58, Dolph Mathews wrote:

This was entirely intentional, in order to replace the implicit role
assignment behavior in v2 with an explicit behavior in v3.



I must admit, this is quite irritating, as the command line client still 
offers the --project ability; dropping this silently leads to somewhat 
unexpected results.


From a user perspective, I would appreciate a warning in such cases; 
this is a common pattern everywhere else in OpenStack.


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] [tests] [dsvm] Tests failed because of timeout during the images upload

[Matthias Runge]

On 16/06/15 11:20, Timur Nurlygayanov wrote:


In this method integration tests try to upload image by the following
link [4]:
http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-uec.tar.gz



Imho it would be better to host this somewhere internal in infra rather 
than getting it from the net.


Wouldn't that be an option for improvement? It would even make tests 
more reliable.


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] [packaging] Adding packaging as an OpenStack project

[Matthias Runge]

On 10/06/15 12:07, Robert Collins wrote:

On 10 June 2015 at 20:12, Matthias Runge  wrote:


Since our software is to be consumed by packages, shouldn't the packages
project consider itself to be responsible for global requirements? I.e.
checking, if requirements are packageable, if versions fit, etc.


I think we welcome input from distribution maintainers on
global-requirements; especially for new packages.

But, the responsibility is ultimately a team effort: all the
components of openstack have to meet the operator/distributor
co-installability requirement. If one project has a minimum version of
X, its not possible for other projects to have a max version of < X
otherwise we're not coinstallable. This works both ways of course.


My wording was not that good here.

I know, some distro packagers are already looking at changes, but maybe 
this could be improved, i.e. intensified? It was more about: giving this 
more basic openstack effort a home in a project.





In some distros, there are multiple versions of the same package allowed, in
others, it's forbidden.


Thats true, but its also a per-distro thing. Within a distro you need
to be consistent. There's no need for RHEL to match RDO for instance,
and trying to make that happen across a dozen redistributors in the
OpenStack context makes no sense at all. We're moving to making our
ranges as wide as we can to make life easier for anyone that wants to
pick slightly different versions: we can't assert that it will work,
but unless we know it doesnt', we won't preclude you trying :)


Yes, that's right. But distros have an interest in being able to install 
the full stack somewhere. If we have conflicting requirements preventing 
that, it should be a target of the packaging project, to fix this. 
Currently, we (as OpenStack devs) are offloading those checks (and 
fixes) completely to distributions.


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] [packaging] Adding packaging as an OpenStack project

[Matthias Runge]

On 27/05/15 10:14, Thomas Goirand wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

tl;dr:
- - We'd like to push distribution packaging of OpenStack on upstream
gerrit with reviews.
- - The intention is to better share the workload, and improve the overall
QA for packaging *and* upstream.
- - The goal is *not* to publish packages upstream
- - There's an ongoing discussion about using stackforge or openstack.
This isn't, IMO, that important, what's important is to get started.
- - There's an ongoing discussion about using a distribution specific
namespace, my own opinion here is that using /openstack-pkg-{deb,rpm} or
/stackforge-pkg-{deb,rpm} would be the most convenient because of a
number of technical reasons like the amount of Git repository.
- - Finally, let's not discuss for too long and let's do it!!! :)



Since our software is to be consumed by packages, shouldn't the packages 
project consider itself to be responsible for global requirements? I.e. 
checking, if requirements are packageable, if versions fit, etc.


In some distros, there are multiple versions of the same package 
allowed, in others, it's forbidden.


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] [javascript] Linters

[Matthias Runge]

On Fri, Jun 05, 2015 at 07:26:24PM +, Michael Krotscheck wrote:
> Right now, there are several JS linters in use in OpenStack: JSHint, JSCS,
> and Eslint. I really would like to only use one of them, so that I can
> figure out how to sanely share the configuration between projects.
> 
> Can all those who have a strong opinion please stand up and state their
> opinions?
> 
> Michael

jshint: still non-free license [1]

eslint seems to require to sign a CLA, if we come across an issue and
were going to fix that.

jscs seems to be the utility, cool kids are using. As expected, it
requires node. It has seen 3 releases within 3 months, or 5 in 4 months. 
My question here would be: how are we going to handle changes here over
a release (and how to keep this running on the gate for released
versions)?

Matthias






[1] https://github.com/jshint/jshint/blob/master/src/jshint.js#L19

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


-- 
Matthias Runge 

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

[Matthias Runge]

On 01/06/15 12:10, Flavio Percoco wrote:


Is this a real problem? What are *tarball timestamps* used for in the
packaging world?

I'm sure there's a way we can workaround this issue.


timestamps just give you a hint, how old the source actually is, not 
when a packager downloaded the tarball somewhere. It just gives you a 
more realistic idea, how ancient the ancient code release is.




And: you probably want some hashes to verify, your downloaded tarball
is actually, what you wanted.


These can be generated as well. You can generate a tarball hash for
each commit and keep it around. The hash shouldn't change if the
tarball is generated on-the-fly. You could actually generate it
on-the-fly as well.
Sure, you can. You still need to provide that info. Ideally you'd 
prepare a signed file containing your hash.


I mean, something comparable to:

http://centos.bio.lmu.de/7/isos/x86_64/sha256sum.txt.asc

(for CentOS 7 iso files).


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] [all] [stable] No longer doing stable point releases

[Matthias Runge]

On 01/06/15 10:29, Flavio Percoco wrote:


AFAIK, these tarballs are generated on the flight in GH. Couldn't we
do the same ?
The issue with on-the-fly generation is: timestamps are actually new, 
and not the same as when the release was tagged.


And: you probably want some hashes to verify, your downloaded tarball is 
actually, what you wanted.


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] xstatic-angular-fileupload with no license

[Matthias Runge]

On 13/05/15 11:02, Thierry Carrez wrote:


You'll need an xstatic-release team member to pick it up. As of today
that would be:

Radomir Dopieralski, David Lyle, Gabriel Hurley* or Mathias Runge.

*: Looks like this group needs clean up.


Ugh,

sorry about that.

Unfortunately, I won't have some spare cycles before the summit.

Maybe David can tag a release here?

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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R

[Matthias Runge]

On 05/05/15 04:31, Ian Cordasco wrote:


Even so, Horizon is deployed in many places, and given the reliability of
system packages, it’s increasingly deployed from source.


Ok, I'll bite.

You surely have a source for your statement, or even better, a proof?

This is wrong in so many ways. It's the same truth as someone could 
claim: neutron doesn't work, so don't use it. (just took neutron as example)


If there is something wrong with system packages, please file bugs. 
Every distribution has a bug tracker.


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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R

[Matthias Runge]

On 05/05/15 05:29, Robert Collins wrote:


Probably, but it's legally wrong (ie: worst case, you can be sued) to leave
a package which is in direct violation of the license of things it contains.


So,we shouldn't use angular at all then, because as a js framework its
distributed to users when they use the website, but the license file
isn't included in that distribution.

Would be good to get a legal position on this.

If we're not allowed to use angular (and anybody else), I wonder how 
anyone could use it (following above logic)


Angular.js is licensed under MIT License [1],[2]:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.


question is, if our use of angular is a substantial portion if this 
software.



Matthias

[1] https://angularjs.org/
[2] https://github.com/angular/angular.js/blob/master/LICENSE

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

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

[Matthias Runge]

On 29/04/15 00:57, David Lyle wrote:


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

David



Yes! Thanks a lot. You'll all make a great addition to the team.

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] [all] Kilo stable branches for "other" libraries

[Matthias Runge]

On 08/04/15 15:55, Thierry Carrez wrote:


I'm especially worried with python-cinderclient, python-designateclient
and django_openstack_auth which are more than 2 months old and may well
contemplate another kilo release that could be disrupting at this point.

In general: a great idea, and I've been expecting this for a longer time 
now. That would save some work.


django_openstack_auth: it's quite stable now, although it would make 
sense to cut a newer release for kilo. We will merge that into horizon 
eventually, since it's a helper and we never saw anyone to use it 
outside of horizon.


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] [depfreeze][horizon] Update to Django-1.7.x

[Matthias Runge]

On Thu, Mar 26, 2015 at 06:02:41AM -0400, Sean Dague wrote:
> 
> Yes, just approved.

Thank you, much appreciated!
-- 
Matthias Runge 

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

Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x

[Matthias Runge]

On Wed, Mar 25, 2015 at 12:00:11PM +0100, Matthias Runge wrote:
> On 25/03/15 11:34, Sean Dague wrote:
> 
> >>Could you make this one "Depends on"
> >>https://review.openstack.org/#/c/167515/ so that we check that all
> >>Django 1.7 related issues are fixed ?
> >
> >I don't think it was ever sufficiently explained why horizon now needs
> >django nose to compile it's message catalog (which is where it is
> >failing) when moving to 1.7.
> >
> >http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098
> >
> We're getting nearer here, thank you!
> 
> --compilemessages is called with test settings, which is wrong imo.
> 
Now that this has been been fixed, can we proceed now?

Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x

[Matthias Runge]

On 25/03/15 11:34, Sean Dague wrote:


Could you make this one "Depends on"
https://review.openstack.org/#/c/167515/ so that we check that all
Django 1.7 related issues are fixed ?


I don't think it was ever sufficiently explained why horizon now needs
django nose to compile it's message catalog (which is where it is
failing) when moving to 1.7.

http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098


We're getting nearer here, thank you!

--compilemessages is called with test settings, which is wrong imo.

The question is, why it has not hit us earlier.

In any case, django_nose is not a runtime dep. I can see, why this is 
run at the gate as part of tests, though.


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] [depfreeze][horizon] Update to Django-1.7.x

[Matthias Runge]

Hello,

I'm requesting an exception to bump Django to Django-1.7.x (or better).

Rationale:

Django-1.8 is expected to be released during the next days. Once it's
released, Django-1.6.x will become unsupported by its upstream.
Unfortunately that's the latest version we're gating against and that's
the version frozen for kilo, or in other words:

When Kilo is released, it relies on a version, not supported any more.

Review is at https://review.openstack.org/#/c/155353/
-- 
Matthias Runge 

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

Re: [openstack-dev] [infra][horizon] Need help at debugging requirements issue

[Matthias Runge]

On 19/03/15 15:52, Ihar Hrachyshka wrote:

>> [1] https://review.openstack.org/#/c/155353/
> 
> 
> Hi,
> 
> it all comes to the fact that DEVSTACK_GATE_INSTALL_TESTONLY=1 is not
> specified in the requirements integration job. I think you need to set
> it at [1]. In that case, your test requirements will also be installed
> during the job.
> 
Thanks Ihar,

the issue is, the only change was, to remove the upper boundary from

Django>=1.4.2,<1.7

And removing "<1.7" from that line resulted in not installing
django-nose any more.

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] [infra][horizon] Need help at debugging requirements issue

[Matthias Runge]

Hello,

I was trying to raise the cap for Django in[1].
It looks quite simple, current requirements is
Django>=1.4.2,<1.7
and I simply removed the upper boundary:
Django>=1.4.2

with the result, django-nose is not installed any more.
(That's a rest dependency for horizon), it's listed in the same
global-requirements file:

django-nose

(no version requirement).

Sadly, I can not figure out, why that happens and how to fix that.
In local tests, this just works. Any hints please?

Thanks,
Matthias


[1] https://review.openstack.org/#/c/155353/
-- 
Matthias Runge 

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

Re: [openstack-dev] [horizon] Do No Evil

[Matthias Runge]

On 09/03/15 15:54, Doug Hellmann wrote:
> 

> 
> Not everyone realizes that many of the distros run our tests against the
> packages they build, too. So our tool choices trickle downstream beyond
> our machines and our CI environment. In this case, because the tool is a
> linter, it seems like the distros wouldn't care about running it. But if
> it was some sort of test runner or other tool that might be used for
> functional tests, then they may well consider running it a requirement
> to validate the packages they create.

For Fedora, we're also running horizons unit tests during package build.

I would assume the same is true for other distros as well.

Because our build system is not allowed to pull anything from the
internet, we rely exclusively on already available software packages.
Due to the license (good not evil), we can not have jslint as package.
For the given reason, pulling it from the net during build doesn't work
either.

Another warning: users expect development as essential and to be
available, because they might require them to CUSTOMIZE horizon.

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] HTTPD Config

[Matthias Runge]

On Fri, Mar 06, 2015 at 11:08:44AM -0500, Adam Young wrote:
> >No matter what we do in devstack, this is something, horizon and
> >keystone devs need to fix first. E.g. in Horizon, we still discover hard
> >coded URLs here and there. To catch that kind of things, I had a patch
> >up for review, to easily configure moving Horizon from using http server
> >root to something different.
> Link?
https://review.openstack.org/#/c/86880/

Obviously, that needs a bit work now.

-- 
Matthias Runge 

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

Re: [openstack-dev] HTTPD Config

[Matthias Runge]

On 05/03/15 19:49, Adam Young wrote:

> 
> I'd like to drop port 5000 all-together, as we are using a port assigned
> to a different service.  35357 is also problematic as it is in the
> middle of the Ephemeral range.  Since we are  talking about running
> everything in one web server anywya, using port 80/443 for all web stuff
> is the right approach.

I have thought about this as well. The issue here is, URLs for keystone
and horizon will probably clash.
(is https://server/api/... a keystone or a call for horizon).

No matter what we do in devstack, this is something, horizon and
keystone devs need to fix first. E.g. in Horizon, we still discover hard
coded URLs here and there. To catch that kind of things, I had a patch
up for review, to easily configure moving Horizon from using http server
root to something different.

I would expect the same thing for keystone, too.

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] Weekly status report (Thu, Jan 22)

[Matthias Runge]

On 29/01/15 13:20, Matthias Runge wrote:
> Hello,
> 
> a bit early, but here's my status report for the past week
Yupp, please ignore the noise here.

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] Weekly status report (Thu, Jan 22)

[Matthias Runge]

Hello,

a bit early, but here's my status report for the past week

RED:
- none

AMBER:
- still preparing my workshop for devconf in Brno
- prepared a patch to add OVA format to horizon
https://review.openstack.org/150751
- continued JavaScript fun
- cleaned up blueprints upstream
- bugzilla housekeeping

GREEN:
- lots of reviews upstream
- Feature for Fedora 22 was approved:
https://fedoraproject.org/wiki/Changes/Django18
- debugged Ciscos "Dashboard unavailable" issue
- changed Django package due to several guideline changes
  (bash completion change, python-sphinx-latex was added and broke
python-django builds)
- packaged and got python-oslo-concurrency approved

Will be traveling tomorrow to FOSDEM.

See you there and/or have a great weekend,
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] static files handling, bower/

[Matthias Runge]

On 23/01/15 10:31, Jeremy Stanley wrote:
> On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote:
> [...]
>> It would be totally awesome to switch from pip install to using
>> distribution packages for testing purposes. At least for
>> dependencies.
> [...]
> 
> While it seems nice on the surface, the unfortunate truth is that
> neither the infra team nor the various package maintainers has the
> excess of manpower needed to be able to near-instantly package new
> requirements and new versions of requirements for the platforms on
> which we run our CI jobs. I fear that the turn-around on getting new
> requirements into projects would go from being on the order of hours
> or days to weeks or even months.
> 
> We could work around that by generating our own system packages for
> multiple platforms rather than relying on actual distro packages,

Oh, I still would try to get that enabled from a distro perspective. But
that's something, a distro CI could provide feedback here.

I think providing/updating distro packages is quite comparable to
updating pypi packages. Maintaining an additional set of packages is
just wrong IMO. Nevertheless, that might be required for a transitional
phase.

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] static files handling, bower/

[Matthias Runge]

On Thu, Jan 22, 2015 at 09:18:46PM +, Jeremy Stanley wrote:
> On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
> [...]
> > When there is an update to our requirements, such as the recent
> > version increment in the version of angular used, a new package
> > version doesn't automatically show up as evident from that list.
> > How would that process be kicked off so we don't end up with a
> > missing dependency? Does that have to wait for a release cycle?
> 
> I don't want to speak for the distro package maintainers, but from
> what I've seen they generally wait until close enough to an
> integrated release that they can be pretty sure the requirements are
> close to frozen, so as not to waste effort packaging things which
> will end up not being used.
> 

Yes, exactly.

I for myself am using horizonfrom a github checkout, providing all
dependencies as RPM packages. That being said, I'm updating/packaging
requirements, whenever they'll show up for me.
There is no automatic process.
> I assume (perhaps incorrectly?) that we do use those in CI jobs, so
> that we can download the things a given project needs in an
> automated fashion--for us handling pip requirements lists is a
> solved problem (well, for some definitions of solved at least).

It would be totally awesome to switch from pip install to using
distribution packages for testing purposes. At least for dependencies.
> 
> > This appears to affect the testing setup as well. When we start to
> > use a new version of a JavaScript dependency no package will exist
> > for it. I believe this would mean the testing environment needs to
> > use the development setup, in the proposal, of bower. IIRC, bower
> > goes out to the Internet and there isn't a mirror of packages
> > (just a mirror of the registry). That means we'll loose the
> > ability to run testing installs from local mirrors for these
> > dependencies. I imagine a solution has been thought of for this.
> > Can you share any details?
Uh, we have seen so many timeouts and failing tests, because some
mirror was not answering fast enough etc. I don't think, adding another
external service will improve the situation here.

-- 
Matthias Runge 

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

Re: [openstack-dev] [horizon] static files handling, bower/

[Matthias Runge]

On 22/01/15 09:48, Radomir Dopieralski wrote:

> All of the XStatic packages had to be packaged for the respective
> distributions in order to package Horizon. That was a lot of work, but
> it has been done my the packagers of the distributions. As far as I
> understand, most of those XStatic packages are just dummies, pointing to
> the actual system-wide JavaScript packages -- XStatic has such a
> capability. So while we are indeed maintaining some of the XStatic
> packages for our own convenience, the packages that contain actual code
> in the distributions are maintained by those distributions' packagers.
> 
Yupp,

poniting to system packages is something, which makes the XStatic
approach way more acceptable.
But, if you don't have them (yet), xstatic packages will bundle js libs
for you.

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] static files handling, bower/

[Matthias Runge]

On 21/01/15 09:59, Martin Geisler wrote:

> 
> This seems to imply that users will download at least one .js file per
> dependency.
> 

Not necessarily. We still use django-compressor, which copies all
javascript into fewer files. E.g. here in my untweaked juno environment,
I just get 3 instead of 10-15 following your logic above. (at least one
js file per xstatic package).

> That's probably acceptable for an application like Horizon which users
> will be using again and again, but for most web applications, you don't
> want your users to download 10-20 small .js files, instead you want them
> to download one minified and compressed file with all the JavaScript
> code needed.
see above :D

> 
> I'm just mentioning this since it's one way that web apps differ from
> how normal Linux apps are typically deployed. Basically, web apps prefer
> static compilation and discourages "dynamic linking".

I'm not sure, I can really follow you here.

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] static files handling, bower/

[Matthias Runge]

On 13/01/15 16:31, Jeremy Stanley wrote:
> On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote:
> [...]
>> Why were the libraries ripped from the Horizon codebase in the
>> first place? It seems to me they belong with the code using it.
> 
> I disagree. If those libraries aren't developed as part of Horizon
> then they should not be copied into and distributed as part of its
> source tree. That's code duplication, plain and simple.
> 
> I'm in favor of cleaning out all the "vendoring" of third-party
> libraries in OpenStack projects, but agree that it would be nice to
> find a cross-platform/portable mechanism for handling them.
> 
Yes!

Keeping libraries separate, makes maintaining stuff so much easier.

You don't need to persuade me here. I completely agree.

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] static files handling, bower/

[Matthias Runge]

On 12/01/15 21:53, Drew Fisher wrote:

> I know I'm very very late to this thread but can I ask why Bower?  Bower
> has a hard requirement on Node.js which was removed as a dependency in
> Havana.  Why are we reintroducing this requirement?
> 
> For Solaris, a requirement on Node.js is especially problematic as there
> is no official SPARC port and I'm not aware of anybody else working on one.
> 
> I agree that XStatic isn't really the best solution here but are there
> any other solutions that don't involve Node.js?
> 
The same is true for ARM based machines, as node.js is AFAIK x86 only.

But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
deployment.

Bower is just another package manager, comparable to npm, pip etc. if
you use that aside your systems package manager.

The idea is, to use something like dpkg or rpm to provide dependencies
for installation. During development and testing, it's proposed to rely
on bower to install dependencies.

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] packaging problem production build question

[Matthias Runge]

On 08/01/15 23:46, Matthew Farina wrote:
> Thanks for humoring me as I ask these questions. I'm just trying to
> connect the dots.
> 
> How would system packages work in practice? For example, when it comes
> to ubuntu lucid (10.04 LTS) there is no system package meeting the
> jQuery requirement and for precise (12.04 LTS) you need
> precise-backports. This is for the most popular JavaScript library.
> There is only an angular package for trusty (14.04 LTS) and the version
> is older than the horizon minimum.
> 
> private-bower would be a nice way to have a private registry. But, bower
> packages aren't packages in the same sense as system or pypi packages.
> If I understand it correctly, when bower downloads something it doesn't
> get it from the registry (bower.io  or private-bower).
> Instead it goes to the source (e.g., Github) to download the code.
> private-bower isn't a package mirror but instead a private registry (of
> location). How could private-bower be used to negate network effects if
> you still need to go out to the Internet to get the packages?
> 
> 
For a deployment, you want updates, often installed automatically.

Your repository providing your horizon package needs to provide required
dependencies as well.

I wouldn't recommend to use bower. In some environments, it's not
allowed to use third party repositories at all. A test environment
should match a possible production environment, where it can. This one
is quite easy.

Matthias

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

[openstack-dev] [stable] Proposing to add Lin-Hua Cheng to horizon-stable-maint

[Matthias Runge]

Hello,

I'd like to propose to add Lin-Hua Cheng to horizon-stable-maint.

Lin has been a Horizon Core for a long time and has expressed interest
in helping out with horizon stable reviews.

I think, he'll make a great addition!

Matthias

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

Re: [openstack-dev] Horizon switching to the normal .ini format

[Matthias Runge]

On 05/01/15 19:27, Matthew Farina wrote:
> Switching to an ini format would likely be painful to impossible.
> 
> Horizon is built on django which is where the settings.py format comes
> from. It's part of a django app.
> 
> For more info see the django docs. The settings information is at
> https://docs.djangoproject.com/en/1.6/topics/settings/
> 

Sorry, I fail to see, how this should be impossible, esp. if you look at
the linked patch; the rest of the stack uses such an .ini format, too.


Matthias
> On Thu, Dec 25, 2014 at 1:25 PM, Timur Sufiev  > wrote:
> 
> Thomas,
> 
> I could only point you to the Radomir's
> patch https://review.openstack.org/#/c/100521/
> 
> It's still a work in progress, so you may ask him for more details.
> 


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

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

[Matthias Runge]

On 17/11/14 10:12, Matthias Runge wrote:
> On 30/10/14 13:13, Matthias Runge wrote:
>> Hi,
>>
>> tl;dr: how to progreed in separating horizon and openstack_dashboard
> Options so far:

In yesterday's horizon meeting, we canceled the repo split[1]


In the light of moving to a more angular based implementation, splitting
the repo will just slow down development, and will unnecessarily bind
resources.


Matthias



[1]
https://blueprints.launchpad.net/horizon/+spec/separate-horizon-from-dashboard


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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Matthias Runge]

On 03/12/14 20:22, Alan Pevec wrote:
>> Horizon
>> standing-after-freeze translation update, coming on Dec 3
> 
> This is now posted https://review.openstack.org/138798
> David, Matthias, I'd appreciate one of you to have a quick look before
> approving.
> 
> Cheers,
> Alan
> 
Alan, thanks for the heads-up here. Approved.

Matthias


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

Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard

[Matthias Runge]

On 17/11/14 14:43, Yves-Gwenaël Bourhis wrote:
> Le 17/11/2014 14:19, Matthias Runge a écrit :
> 
>> There is already horizon on pypi[1]
>>
>> IMHO this will lead only to more confusion.
>>
>> Matthias
>>
>>
>> [1] https://pypi.python.org/pypi/horizon/2012.2
> 
> Well the current "horizon" on Pypi is "The OpenStack Dashboard" +
> horizon(_lib) included
> 
> If the future "horizon" on pypi is "openstack_dashboard" alone, it would
> still pull "horizon_lib" as a dependency, so it would not brake the
> existing.

That would break expectations.

When installing a software package named python-foo, I would expect a
python package named foo in there, not a package named bar.

Dependencies between packages are best defined in distribution packages.
They solve dependencies since ages.

For Fedora, there is a policy for package naming. I'd assume the same to
be true for Debian.


Matthias

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