Re: [openstack-dev] [horizon] collectstatic with custom theme is broken at least since Ocata

[Mateusz Kowalski]

Hi,

We are running Horizon in Pike and cannot confirm having the same problem as 
you describe. We are using a custom theme however the folder structure is a bit 
different than the one you presented in the bug report.
In our case we have

- /usr/share/openstack-dashboard/openstack_dashboard/themes
|-- cern
|-- default
|-- material

what means we do not modify at all files inside "default". Let me know if you 
want to compare more deeply our changes to see where the problem comes from, as 
for us "theme_file.split('/templates/')" does not cause the trouble.

Cheers,
Mateusz

> On 5 Feb 2018, at 14:44, Saverio Proto  wrote:
> 
> Hello,
> 
> I have tried to find a fix to this:
> 
> https://ask.openstack.org/en/question/107544/ocata-theme-customization-with-templates/
> https://bugs.launchpad.net/horizon/+bug/1744239
> https://review.openstack.org/#/c/536039/
> 
> I am upgrading from Newton to Pike.
> 
> Here the real question is: how is it possible that this bug was found so
> late ???
> 
> There is at least another operator that documented hitting this bug in
> Ocata.
> 
> Probably this bug went unnoticed because you hit it only if you have
> customizations for Horizon. All the automatic testing does not notice
> this bug.
> 
> What I cannot undestand is.
> - are we two operators hitting a corner case ?
> - No one else uses Horizon with custom themes in production with
> version newer than Newton ?
> 
> This is all food for your brainstorming about LTS,bugfix branches,
> release cycle changes
> 
> Cheers,
> 
> Saverio
> 
> 
> -- 
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

[Mateusz Kowalski]

Hi everyone,

I would like to raise a question about our approach to xstatic packages, more 
specifically xstatic-roboto-fontface, and its updates/bugfixes. What we have 
encountered was https://bugs.launchpad.net/horizon/+bug/1671004 
 what according to our 
knowledge affects everyone using stable/ocata with Material design (though I 
get there may not be many operators using this setup).

What I did at the very first was to submit a patch 
https://review.openstack.org/#/c/443025/ 
 but unfortunately a policy is to 
take xstatic packages from the upstream in their unchanged form. As I totally 
understand this, I raised this issue to the upstream package provider in March 
— https://github.com/choffmeister/roboto-fontface-bower/issues/41 
. Again, 
unfortunately, as since then there was no any response I submitted a merge 
request for this issue — 
https://github.com/choffmeister/roboto-fontface-bower/pull/47 
. However, it’s 
complete openstack-wise, but it does not solve the issue in general (long story 
short, more than just one file requires patching, but Horizon uses only the one 
I have patched).

Anyway, seeing no much response for my initial upstream report since March, I 
don’t have much hope with the merge request I have just submitted. From the 
other side, any advice on how I can proceed in this particular case would be 
helpful as I have no any experience in this kind of workflow (bugs in xstatic 
packages).

Thanks for any suggestions,
Mateusz

smime.p7s
Description: S/MIME cryptographic 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] [ironic] New mascot design

[Mateusz Kowalski]

Hi all,

Any updates on it ?
We would like to start using the logo, but the only version is the one from the 
email bellow with a grey background. Can we expect having rest of "the branding 
set" ?

Cheers,
Mateusz

> On 20 Mar 2017, at 15:47, Mario Villaplana  wrote:
> 
> +1, this looks like a nicely stylized version of PXE Boots. Thanks!
> 
> Mario
> 
> On Mon, Mar 13, 2017 at 3:25 PM, Jim Rollenhagen  
> wrote:
>> 
>> On Fri, Mar 10, 2017 at 11:28 AM, Heidi Joy Tretheway
>>  wrote:
>>> 
>>> Hi Ironic team,
>>> Here’s an update on your project logo. Our illustrator tried to be as true
>>> as possible to your original, while ensuring it matched the line weight,
>>> color palette and style of the rest. Thanks for your patience as we worked
>>> on this! Feel free to direct feedback to me; we really want to get this
>>> right for you.
>> 
>> 
>> This is fantastic! Thank you for putting up with us, I think it turned out
>> well in the end.
>> 
>> // jim
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



smime.p7s
Description: S/MIME cryptographic 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] Empty metadata value support

[Mateusz Kowalski]

Hello everyone,

This mail is to ask for opinion and/or recommendation regarding inconsistent 
behaviour between CLI and UI re: support of metadata keys with empty values.

The current behaviour is as follows: most, if not all, of the backend 
components fully support custom metadata properties with value = null. At the 
same time Horizon UI by default in all "Update ... Metadata" requires that for 
each key value is non-empty (that means null is not a valid input).

We have a following scenario happening just now for one of our customers -- 
there is an image X uploaded via CLI with property "custom_x:null". User 
creates a VM from this image and later creates a snapshot of the VM (these two 
steps are indifferent for CLI and UI). Next, using UI, he tries to rename the 
snapshot he has just created using "Edit Image" panel. Apparently the operation 
is not possible because the metadata tab is marked as "mandatory" with property 
"custom_x" appearing without any value and tagged as "required". This means our 
user is forced to either put non-null value to the property or completely 
remove it in order to be able to rename the snapshot. At the same time renaming 
it using CLI works without any impact on the metadata. The same applies to 
changing any other detail like "image description", "visibility", "protection".

Therefore the question - does anyone have a strong "no" against pushing a patch 
which will allow null as a valid value for a custom metadata across all Horizon 
?

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