Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

To be honest, I don't see much point in automatically creating bugs that nobody is going to look at. When you implement a new feature, it's up to you to make it available in Horizon and CLI and wherever else, since the people working there simply don't have the time to work on it. Creating a

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

A fix for it is in review: https://review.openstack.org/577820 On Mon, Jun 25, 2018 at 3:07 PM, Andreas Jaeger wrote: > On 2018-06-25 14:57, Radomir Dopieralski wrote: > > Any idea where it took the 1.1.5.0 version from? > > git grep 1.1.5 shows at least: > > setup.cfg:

Re: [openstack-dev] [Release-job-failures][release][horizon] Release of openstack/xstatic-angular-material failed

Any idea where it took the 1.1.5.0 version from? On Mon, Jun 25, 2018 at 2:38 PM, Doug Hellmann wrote: > Excerpts from zuul's message of 2018-06-25 12:14:34 +: > > Build failed. > > > > - xstatic-check-version http://logs.openstack.org/59/ >

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

t; >> >>>> Horizon core is not consistent. >>>>> >> >>>> Also having exception might make unexpected confusion in near >>>>> future. >>>>> >> >>>> >>>>> >> >>>> Eventually we will follow

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

I did a quick search for all the glyphs we are using: ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq fa- fa-angle-left fa-angle-right fa-arrow-down fa-arrow-up fa-asterisk fa-b fa-bars fa-bolt fa-bug fa-calculator fa-calendar fa-caret-down fa-caret-up fa-check

Re: [openstack-dev] [horizon][xstatic]How to handle xstatic if upstream files are modified

The whole idea about xstatic files is that they are generic, not specific to Horizon or OpenStack, usable by other projects that need those static files. In fact, at the time we started using xstatic, it was being used by the MoinMoin wiki project (which is now dead, sadly). The modifications you

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

Yes, please do that. We can then discuss in the review about technical details. On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge wrote: > Hi, Akihiro > > Thanks for the quick reply. > > I agree with your opinion that BASE_XSTATIC_MODULES should not be > modified. > It is much

Re: [openstack-dev] [horizon] Approach for bugs in xstatic packages

I can see several possible ways forward with this: * provide a complete fix for the issue that would be more likely to get merged upstream, * instead of adding hacks in the code, actually rename the wrongly named files, * instead of adding hacks, actually fix all the references to use proper

Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

I think that you have to remember that OpenStack doesn't only work with officially approved OpenStack services, but with any services that have a conforming API. OpenStack itself provides implementations of those services, and you are right that it's unlikely that there will be two competing

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

he version to see > >> > if it's >= 2.40 and take action appropriately? I don't see how it > >> > changes anything to force requesting 2.40 with every request? Then > >> > again, I've not been able to look into how the current clients' > >> > micr

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

gt; the 2.40 version in https://review.openstack.org/#/c/422642 results in > > all requests being forced to use that version? > > > > > > Richard > > > > On 23 January 2017 at 23:10, Radomir Dopieralski <openst...@sheep.art.pl> > wrote: > >&g

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

We need to support that nova API >> change. >> >> On 20 January 2017 at 01:28, Radomir Dopieralski <openst...@sheep.art.pl> >> wrote: >> > I would like to request a feature freeze exception for the following >> patch: >> > >> > https://revie

[openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

I would like to request a feature freeze exception for the following patch: https://review.openstack.org/#/c/410337 This patch adds support for retrieving the simple tenant usages from Nova in chunks, and it is necessary for correct data given that related patches have been already merged in

Re: [openstack-dev] [all] Using \ for multiline statements

There is a problem with the use of backslash at the end of the line, where if you also put a space after it, it no longer does what it seemingly should. Together with the fact, that you can achieve the same thing using () in pretty much all instances (it used to not be true for imports, but that

Re: [openstack-dev] [Horizon] Weekly wrap-up

I wonder if it really makes sense to put WIP patches on the priority list. I think it's a bit counter-productive, considering that the prioritizing of patches was supposed to make them merge faster -- but we don't want to merge WIP patches, do we? On Fri, Dec 16, 2016 at 5:31 AM, Richard Jones

Re: [openstack-dev] [Horizon] Draft team mascot

Here, fixed. On Wed, Dec 7, 2016 at 10:54 AM, Radomir Dopieralski <openst...@sheep.art.pl > wrote: > That looks kinda like a white baboon. It definitely doesn't look like Doge > -- wrong color, wrong head. I think the legs are too long too. > > On Wed, Dec 7, 2016 at 10:31 AM,

Re: [openstack-dev] [Horizon] Draft team mascot

That looks kinda like a white baboon. It definitely doesn't look like Doge -- wrong color, wrong head. I think the legs are too long too. On Wed, Dec 7, 2016 at 10:31 AM, Timur Sufiev wrote: > I still think this one https://wtf.jpg.wtf/0c/10/1479414543- >

Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

+1 On Mon, Nov 14, 2016 at 1:24 AM, Richard Jones wrote: > Hi Horizon core team, > > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a > solid Horizon contributor for some time, with thoughtful and helpful > reviews showing good judgment and good

Re: [openstack-dev] [horizon] Browser Support

On Tue, Sep 20, 2016 at 3:53 AM, Jason Rist wrote: > This page hasn't been updated for a while - does anyone know the latest? > > https://wiki.openstack.org/wiki/Horizon/BrowserSupport > > As far as I know, there were no changes to the officially supported browser versions.

Re: [openstack-dev] [OPENSTACK] [HORIZON] Changing theme

Did you forget to run collectstatic? On Fri, Jul 15, 2016 at 10:00 AM, BIKRAMADITYA SAHOO < ansh.ansh20...@gmail.com> wrote: > Hi, > > I am unable to change the theme for my openstack horizon. I tried with the > this and >

Re: [openstack-dev] [kolla][horizon] Out of branch horizon plugins?

Hi, sorry for late reply. The whole "openstack_dashboard/local/enabled/" mechanism was inspired by the mechanisms used commonly in Debian and other distributions to enable/disable plugins. In short, you shouldn't *copy* the configuration files to the "enabled" directory -- instead you should keep

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

t even used by Horizon. Issue raised by Richard exists for plugins too, not only for Horizon itself. How would such an xstatic library conflict with what is in Horizon then, though? -- Radomir Dopieralski __ OpenStack Devel

[openstack-dev] [nova] patches that improve code quality

is the correct way to have such a patch merged in Nova, and -- if there isn't one -- should we think about making it easier? -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe

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

packages anyways, so why specify the dependencies twice? If the changes between versions are so big as to be breaking, then the plugins have to be updated to work with the new Horizon anyways. -- Radomir Dopieralski

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

On 01/08/2016 09:51 PM, Mike Bayer wrote: On 01/08/2016 04:44 AM, Radomir Dopieralski wrote: On 01/07/2016 05:55 PM, Mike Bayer wrote: but also even if you're under something like mod_wsgi, you can spawn a child process or worker thread regardless. You always have a Python interpreter

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

shouldn't. Most web servers out there expect to do their own process/thread management and get really embarrassed if you do something like this, resulting in weird stuff happening. -- Radomir Dopieralski __ OpenStack

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

, a critical angularJS reviewer, and played a significant role in driving the angular based launch instance work in Kilo. Thank you all for your contributions and welcome to the team! Welcome! -- Radomir Dopieralski

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

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

Re: [openstack-dev] [horizon] - Add custom JS functions to dashboard

/topics/settings.html#add-js-files -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org

Re: [openstack-dev] [horizon] JavaScript docs?

On 02/05/2015 07:26 PM, Michael Krotscheck wrote: On Thu Feb 05 2015 at 12:07:01 AM Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: Plus, the documentation generator that we are using already, Sphinx, supports JavaScript perfectly fine, so I see

Re: [openstack-dev] [horizon] JavaScript docs?

on Sphinx? I don't think anyone would argue for that. We actually rely on Sphinx for documenting methods, classes or functions. Not sure what your point is here. -- Radomir Dopieralski __ OpenStack Development Mailing List

Re: [openstack-dev] [horizon] JavaScript docs?

another tool. I agree it would be nice to actually start using it for JavaScript code too, though. -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [horizon] JavaScript docs?

are often not updated (who want to do much more work)? And JSDoc generated documentation loses the connection to reality. That is not a problem. We will just reject patches that do such changes without updating the comments. -- Radomir Dopieralski

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

, that is *exactly* the change that we want to make now and that we are discussing! Drop the whole XStatic thing, and have a file in Horizon that configures all the paths. Then use Bower for downloading the files in development environments, and system packages in production. -- Radomir Dopieralski

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

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. -- Radomir Dopieralski __ OpenStack

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

solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. -- Radomir Dopieralski

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

are provided by the system-wide packages. -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi

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

having to create all those dummy XStatic shims. -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

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

of dependencies in a format compatible with Bower -- but it's a simple JSON file that can be read by any other tool or script, written in any language. I hope that clears it. -- Radomir Dopieralski __ OpenStack Development Mailing List

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

at managing the JavaScript libraries. I have some bad news for you. Horizon already uses node.js for running jshint on its JavaScript files on the gate. Simply because there is no other alternative. You are welcome to work on and propose a better solution. -- Radomir Dopieralski

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

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

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

already. Sorry for my mistake. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

On 05/01/15 00:35, Richard Jones wrote: On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: On 20/12/14 21:25, Richard Jones wrote: This is a good proposal, though I'm unclear on how the static_settings.py file

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

is configured to put the files. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

and helping with its testing. What do you think? Do you see any disastrous problems with this system? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon]

On 25/11/14 00:09, David Lyle wrote: I am pleased to nominate Thai Tran and Cindy Lu to horizon-core. [...] Thai Tran +1 Cindy Lu +1 -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

', xstatic.main.XStatic(xstatic.pkg.jquery_ui).base_dir)) But in your Debian package, you can completely drop xstatic and just use absolute paths to the filesystem explicitly. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 18/11/14 00:59, Richard Jones wrote: On 17 November 2014 21:54, Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: - Bower in the development environment, - Bower configuration file in two copies, one for global-requirements, and one for the Horizon's local

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

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

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

, that would get included in Horizon's settings.py What do you think? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 15/11/14 03:21, Richard Jones wrote: On 15 November 2014 00:58, Radomir Dopieralski openst...@sheep.art.pl wrote: [...] 4. additions and upgrades of libraries moderated by the packagers, Is there already some mechanism for handling the creation and management of xstatic packages

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 14/11/14 13:02, Richard Jones wrote: On 14 November 2014 18:51, Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: On 13/11/14 23:30, Martin Geisler wrote: [...] Maybe a difference is that you don't (yet) install a web application like you

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

with the packagers to make sure that the resulting process makes sense and is acceptable for them. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

without having to modify the code of those tools. Of course things might have changed since, or we may have someone with better JavaScript hacking skills who would manage to make it work. But last year we failed. -- Radomir Dopieralski ___ OpenStack-dev

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

node.js on their production servers. Violence may result. [...] -- Radomir Dopieralski ___ 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

-horizon) to devstack I suppose we have to reach out to the devstack people for that. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

or support problem -- you just have to care about that single application, because the packagers from the distribution that you are using are taking care about all the rest of software on your server. -- Radomir Dopieralski ___ OpenStack-dev mailing list

Re: [openstack-dev] [horizon]Blueprint- showing a small message to the user for browser incompatibility

remember that discussion differently, and I'm not so sure there was a definite conclusion. We definitely should not use a white list for this. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [Horizon] Problem with compressing scss files

? They are quite responsive. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Deprecating exceptions

, and it uses a global variable. I'm sure it would be possible to do it in a little bit cleaner way. But at least it gives us the warning (sure, only if an exception is actually being thrown, but that's test coverage problem). I propose to do exception deprecating in this way in the future. -- Radomir

Re: [openstack-dev] [all] PYTHONDONTWRITEBYTECODE=true in tox.ini

filenames. find . -name '*.pyc' -delete -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Some thoughts about Horizon's test suite

, instead of testing its behavior. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

/tip/xstatic/__init__.py -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 28/08/14 12:41, Radomir Dopieralski wrote: On 27/08/14 16:31, Sean Dague wrote: [snip] In python 2.7 (using pip) namespaces are a bolt on because of the way importing modules works. And depending on how you install things in a namespace will overwrite the base __init__.py for the top

Re: [openstack-dev] Criteria for giving a -1 in a review

On 21/08/14 18:05, Matthew Booth wrote: [snip] This seems to mean different things to different people. There's a list here which contains some criteria for new commits: [snip] Any more of these? There is also https://wiki.openstack.org/wiki/CodeReviewGuidelines -- Radomir Dopieralski

[openstack-dev] [horizon] Customization use cases

. If you are customizing or extending Horizon, please take a moment and write what you are doing exactly and what you would like to do, if it's not possible at the moment. Please do it under a new heading, so that we have some order in there. Thank you, -- Radomir Dopieralski

Re: [openstack-dev] [Horizon] request to review bug 1301359

faster and get to your patch sooner. Thank you, -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

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

[openstack-dev] [horizon] Configuration files RFC

Hello, I did some planning and thinking around the subject of Horizon's configuration files. I summarized it all at: https://review.openstack.org/#/c/100521/8/horizon-config-rfc.rst Please feel free to comment. Any feedback appreciated. -- Radomir Dopieralski

Re: [openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup

reason to organize it. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Name proposals

On 06/10/2014 09:18 PM, Radomir Dopieralski wrote: The name poll is now officially over, and the winner is: horizon_lib You can view the results here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ea99af9511f3f255 I think we won't need to check for trademark issues with this name, so we

Re: [openstack-dev] [horizon] Name proposals

already voted from given key. Can anybody help? Thanks -- Jarda On 2014/10/06 21:18, Radomir Dopieralski wrote: Hello everyone. We have collected a fine number of name proposals for the library part of Horizon, and now it is time to vote for them. I have set up a poll on CIVS

Re: [openstack-dev] [horizon] Name proposals

for the dashboard part were removed from the list. Once we get the results, we will consult with the OpenStack Foundation and select the first valid name with the highest ranking. The poll will end at the next Horizon team meeting, Tuesday, June 17, at 16:00 UTC. Thank you, -- Radomir Dopieralski

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

they are packaging are not related to OpenStack. Have them be managed by someone else? Who? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Name proposals

On 06/03/2014 06:44 PM, Radomir Dopieralski wrote: We decided that we need to pick the name for the splitting of Horizon properly. From now up to the next meeting on June 10 we will be collecting name proposals at: https://etherpad.openstack.org/p/horizon-name-proposals After that, until

[openstack-dev] [horizon] mocking policy

. In Horizon we only use Mox, and Mock is not even in requirements.txt. I would like to propose to add Mock to requirements.txt and start using it in new tests where it makes more sense than Mox -- in particular, when we are writing unit tests only testing small part of the code. Thoughts? -- Radomir

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

themselves, do the equivalent repositories in Gerrit get decommissioned at that point? Yes, we will hand over the keys to the pypi entries, and get rid of the repositories on our side. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev

[openstack-dev] [horizon] Name proposals

for the proposed names. In case the most popular name is impossible to use (due to trademark issues), we will use the next most popular. In case of a tie, we will pick randomly. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Horizon] Use of AngularJS

, Horizon has to be packaged at the end of the cycle, with all of its dependencies. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

it was made, but I'm hopeless at it. It would be a great help if you could handle that. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

time until the patches for static files and other stuff clear, we could have a poll for the name. Gabriel, would you like to run that? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi

[openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

will work that out soonish. Oh, and great thanks to all the people who have helped me so far with it, I wouldn't even dream about trying such a thing without you. Also thanks in advance to anybody who plans to help! -- Radomir Dopieralski ___ OpenStack

[openstack-dev] [horizon] Static file handling -- followup

, because django-pyscss actually solves that problem for us. Horizon's plugins can refer to Horizon's own files easily now. The linter and other tools: We will be able to include the linter in the gate check without having to explicitly depend on it in Horizon itself. -- Radomir Dopieralski

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski

Re: [openstack-dev] [horizon] xstatic for removing bundled js libs

versions? How the actual xstatic-* packages are created and maintained is up to the packager. They are not part of Horizon, so you can use any tools you wish to create and update them. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

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

Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

Hello, I also think that this thread is going in the wrong direction, but I don't think the direction Boris wants is the correct one either. Frankly I'm a little surprised that nobody mentioned another advantage that soft delete gives us, the one that I think it was actually used for originally.

Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

On 14/03/14 11:08, Alexei Kornienko wrote: On 03/14/2014 09:37 AM, Radomir Dopieralski wrote: [snip] OpenStack is a big, distributed system of multiple databases that sometimes rely on each other and cross-reference their records. It's not uncommon to have some long-running operation started

Re: [openstack-dev] [Horizon] Edit subnet in workflows - ip_version hidden?

of the disabled or readonly attribute. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Edit subnet in workflows - ip_version hidden?

, that when re-displaying this form (after an error in any other field, for example), that field's value will be missing, and the browser will happily display the first option, which is ipv4. Another solution could be perhaps using readonly instead of disabled. -- Radomir Dopieralski

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 21/02/14 10:38, Dougal Matthews wrote: On 21/02/14 09:24, Tomas Sedovic wrote: On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

that we get from it as NoEcho: true, so we do have an idea about which parts are sensitive. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

to ask ourselves the question about system boundaries and about what we are protecting from what. Otherwise we will end up with ridiculous things like encrypting the passwords and storing the decryption key right in the same place. In other words, this has to be designed. -- Radomir Dopieralski

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 12:02, Radomir Dopieralski wrote: On 20/02/14 11:46, Dougal Matthews wrote: On 20/02/14 10:36, Radomir Dopieralski wrote: On 20/02/14 11:21, Dougal Matthews wrote: If we do store passwords however, I wonder if we are best to encrypt everything to be safe. The overhead shouldn't

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 14:10, Jiří Stránský wrote: On 20.2.2014 12:18, Radomir Dopieralski wrote: Thinking about it some more, all the uses of the passwords come as a result of an action initiated by the user either by tuskar-ui, or by the tuskar command-line client. So maybe we could put the key

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? -- Radomir Dopieralski ___ OpenStack-dev

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 15:57, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them

Re: [openstack-dev] why do we put a license in every file?

and copy/paste behavior. It's actually not just a habit, it's a requirement, and hacking has a check for files with missing licenses. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin

Re: [openstack-dev] [Horizon] RFC - Suggestion for switching from Less to Sass (Bootstrap 3 Sass support)

make that impossible. It's a workaround, but it also makes it impossible for apps other than the dashboard (like tuskar-ui) to inherit from those less files. I think that if we had a solution for that for SASS, that would be another strong advantage of switching. -- Radomir Dopieralski

  1   2   >