Re: [openstack-dev] [ironic] Translations removal
Hi,
Thanks for pointing out that 2 and 3 won’t actually work, I apologize for the
confusion it could’ve created.
I don’t like the option 6, because making user-messages friendlier was the
whole purpose of translation. Mixing languages in exception would be even worse
than doing it in logs, IMHO. What is more – if there’s a custom message passed
to exception (e.g. MyException(“My message” % {k: v}), it overwrites the
default one, so it would end up with English-only message.
Option 5 looks nice (and easy), but I don’t think that it will be very good if
all other components will allow showing translated messages and Ironic won’t.
Seems like *if* we want to translate entire exception messages, we’re left with
option 1 only, right?
Regards,
Joanna
From: Pavlo Shchelokovskyy
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Wednesday, March 22, 2017 at 7:54 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [ironic] Translations removal
HI all,
my 5 cents:
- option 1) is ugly due to code/string duplication;
- options 2) and 3) are not going to work for translators as others already
pointed;
- option 4) has a caveat that we should do it consistently - either translate
all or translate none, so there won't be a mess of log messages written in
different languages at seemingly random;
- option 5) from Lucas looks nice and easy, but I'm afraid we still have to
i18n the errors returned to end user in API responses.
So how about half-solution 6) - reorg our exception messages (at least those
returned from API) to always include some string that is i18n'ed in the
exception class declaration itself, but may have part of strings passed in at
instantiation, so nowhere the whole exception message is completely passed in
when instantiating the exception. Downside is that final exception message may
be returned in two languages (half i18n'ed, half English).
Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
On Wed, Mar 22, 2017 at 4:13 PM, Lucas Alvares Gomes
mailto:lucasago...@gmail.com>> wrote:
Hi,
>> Possible options to handle that:
>>
>> 1) Duplicate messages:
>>
>> LOG.error(“”, {: })
>>
>> raise Exception(_(“”) % {: })
>>
>> 2) Ignore this error
>>
>> 3) Talk to hacking people about possible upgrade of this check
>>
>> 4) Pass translated text to LOG in such cases
>>
>>
>>
>> I’d personally vote for 2. What are your thoughts?
>
> When the translators go to translate, they generally only get to see
> what's inside _(), so #2 is a no-go for translations, and #3 also is a
> no-go.
+1
Just throwing and idea here: Is not translating anything an option ?
Personally I don't see much benefits in translating a software like
Ironic, there are many "user facing" parts that will remain in
english, e.g: The resource attributes name, node's states (powered
off, powered on, deploying, deploy wait...), etc... So why bother ? I
think it's fair to assume that people using Ironic directly (not via
horizon for example) understands english. It's a lot of overhead to
get it translated and there are very few people working on it for
Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the
costs of having duplicated strings all over in the code overweight the
benefits.
I did some translation of Ironic to Brazilian Portuguese in the past
myself and it's really tough to keep up the pace, strings are added or
changed very rapidly.
So again, is: "5) Not translate anything" an option here ?
[0] https://translate.openstack.org/iteration/view/ironic/master?dswid=9016
Cheers,
Lucas
__
OpenStack Development Mailing 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] [ironic] Translations removal
Hi team,
As discussed on Monday, logged messages shouldn’t be translated anymore.
Exception messages still should be still translated.
While removing usages of _LE, _LW, _LI should be fairly easy, some usages of _
may cause issues.
Some messages in the code are declared with ‘_’ method and used both for logger
and exception. This has to be changed, so we don’t have some log entries
translated because of that.
The best option in terms of code redundancy would be something like:
msg = “”
LOG.error(msg, {: })
raise Exception(_(msg) % {: })
However, pep8 does not accept passing variable to translation functions, so
this results in ‘H701 Empty localization string’ error.
Possible options to handle that:
1) Duplicate messages:
LOG.error(“”, {: })
raise Exception(_(“”) % {: })
2) Ignore this error
3) Talk to hacking people about possible upgrade of this check
4) Pass translated text to LOG in such cases
I’d personally vote for 2. What are your thoughts?
Kind regards,
Joanna
[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2017-03-21.log.html#t2017-03-21T14:00:49
__
OpenStack Development Mailing 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][ironic] Kubernetes-based long running processes
Thank you for this explanation, Clint. Kuberentes gets more and more popular and it would be great if we could also take advantage of it. There are already projects in Openstack that have a mission that aligns with task scheduling, like Mistral, that could possibly support Kubernetes as a backend and this solution could be adopted by other projects. I’d rather think about enriching an existing common project with k8s support, than starting from scratch. I think it’s a good idea to gather cross-project use cases and expectation to come up with a solution that will be adoptable by all the projects that desire to use while still being generic. WRT Swift use case – I don’t see what was listed there as excluded from Kubernetes usage, as K8S supports also 1 time jobs [0]. Joanna [0] https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/ On 3/16/17, 11:15 AM, "Clint Byrum" wrote: Excerpts from Dean Troyer's message of 2017-03-16 12:19:36 -0500: > On Wed, Mar 15, 2017 at 5:28 PM, Taryma, Joanna wrote: > > I’m reaching out to you to ask if you’re aware of any other use cases that > > could leverage such solution. If there’s a need for it in other project, it > > may be a good idea to implement this in some sort of a common place. > > Before implementing something new it would be a good exercise to have > a look at the other existing ways to run VMs and containers already in > the OpenStack ecosystem. Service VMs are a thing, and projects like > Octavia are built around running inside the existing infrastructure. > There are a bunch of deployment projects that are also designed > specifically to run services with minimal base requirements. The console access bit Joanna mentioned is special in that it needs to be able to reach things like IPMI controllers. So that's not going to really be able to run on a service VM easily. It's totally doable (I think we could have achieved it with VTEP switches and OVN when I was playing with that), but I can understand why a container solution running on the same host as the conductor might be more desirable than service VMs. __ OpenStack Development Mailing 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] [all][ironic] Kubernetes-based long running processes
Hi all, There was an idea of using Kubernetes to handle long running processes for Ironic [0]. It could be useful for example for graphical and serial consoles or improving scalability (and possibly for other long-running processes in the future). Kubernetes would be used as a backend for running processes (as containers). However, the complexity of adding this to ironic would be a too laborious, considering the use case. At the PTG it was decided not to implement it within ironic, but in the future ironic may adopt such solution if it’s common. I’m reaching out to you to ask if you’re aware of any other use cases that could leverage such solution. If there’s a need for it in other project, it may be a good idea to implement this in some sort of a common place. Kind regards, Joanna [0] https://review.openstack.org/#/c/431605/ __ OpenStack Development Mailing 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
Just thinking – horns seem pretty metal, what do you think about goat-like horned bear? :) Joanna On 2/6/17, 5:26 AM, "Sam Betts (sambetts)" wrote: +100 On 06/02/2017, 12:32, "Dmitry Tantsur" wrote: On 02/06/2017 12:49 PM, Miles Gould wrote: > On 01/02/17 21:38, Lucas Alvares Gomes wrote: >> But, let me ask something, what the foundation really wants to achieve >> with this ? Cause I think we are conflating two things here: A logo (or >> brand) and a mascot. > > I think this is an excellent point. The constraints on logos make a lot of sense > *for logos*, but it'll be very hard to achieve something like Pixie Boots within > them. Could we perhaps use *two* images for different contexts? > > 1) a stylized logo, matching the guidelines, for use in "official" settings and > anywhere that it will be seen alongside other projects' logos; > 2) our existing Pixie Boots mascot, for use in "unofficial" settings (laptop > stickers, T-shirts, chatbots, The Bear Metal Adventures of Pixie Boots webcomic > series*, etc, etc). > > It'll be much easier to agree on image 1 if we don't reject every proposal for > not capturing every nuance of image 2. > > If that makes sense, I have a suggestion for the next iteration of the logo, if > one is needed: take the head from logo version 3.0. AFAICT, that meets all the > objections raised so far: > > - it's simple and logo-like, > - it's not holding any man-made objects, > - it's friendly, > - it has heavy-metal facial markings, > - it's not making any potentially-obscene gestures. > > It doesn't look exactly like Pixie Boots, but if we can carry on using Pixie in > unofficial contexts, that shouldn't be a problem. +100 to everything written here. > > Miles > > * In which Pixie Boots, sysadmin by day and rock musician by night, solves a > series of increasingly baffling deployment problems using AWESOME DRUM SOLOS. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
