Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Julie Pichon]

On 8 August 2018 at 00:47, Victoria Martínez de la Cruz
 wrote:
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this effort
> for several rounds now and I believe is a good moment for somebody else to
> take the lead. You all know how important is Outreachy to me and I'm
> grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.

Thanks for doing such a wonderful job and keeping Outreachy going the
last few years! :)

Julie

> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria

__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Julie Pichon]

On 19 April 2018 at 18:01, Emilien Macchi  wrote:
> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing on
> TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.

+1

__
OpenStack Development Mailing 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] Dependency management

[Julie Pichon]

On 2 March 2018 at 22:52, Alan Pevec <ape...@redhat.com> wrote:
> On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichon <jpic...@redhat.com> wrote:
>> On 19 January 2018 at 18:43, Honza Pokorny <ho...@redhat.com> wrote:
>>> We've recently discovered an issue with the way we handle dependencies for
>>> tripleo-ui.  This is an explanation of the problem, and a proposed solution.
>>> I'm looking for feedback.
>>>
>>> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
>>> tripleo-ui:
>>>
>>> * Native npm jobs
>>> * Undercloud integration jobs
>>>
>>> After the upgrade, the integration jobs went away.  Our goal is to add them
>>> back.
>>>
>>> There is a difference in how these two types of jobs handle dependencies.
>>> Native npm jobs use the "npm install" command to acquire packages, and
>>> undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
>>> dependencies called openstack-tripleo-ui-deps.
>>>
>>> Because of the requirement to use a separate RPM for dependencies, there is 
>>> some
>>> extra work needed when a new dependency is introduced, or an existing one is
>>> upgraded.  Once the patch that introduces the dependency is merged, we have 
>>> to
>>> increment the version of the -deps package, and rebuild it.  It then shows 
>>> up in
>>> the yum repos used by the undercloud.
>>>
>>> To make matters worse, we recently upgraded our infrastructure to nodejs 
>>> 8.9.4
>>> and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" 
>>> patches
>>> that simply introduce a new dependency to package.json, and nothing more.  
>>> The
>>> code that uses the new dependency must be included.  I tend to think that 
>>> each
>>> commit should work on its own so this can be seen as a plus.
>>>
>>> This presents a problem: you can't get a patch that introduces a new 
>>> dependency
>>> merged because it's not included in the RPM needed by the undercloud ci job.
>>>
>>> So, here is a proposal on how that might work:
>>>
>>> 1. Submit a patch for review that introduces the dependency, along with code
>>>changes to support it and validate its inclusion
>>> 2. Native npm jobs will pass
>>> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM
>>> 4. We ask RDO to review for licensing
>>> 5. Once reviewed, new -deps package is built
>>> 6. Recheck
>>> 7. All jobs pass
>>
>> Perhaps there should be a step after 3 or 4 to have the patch normally
>> reviewed, and wait for it to have two +2s before building the new
>> package? Otherwise we may end up with wasted work to get a new package
>> ready for dependencies that were eventually dismissed.
>
> Thanks Julie for reminding me of  this thread!
>
> I agree we can only build ui-deps package when the review is about to merge.
> I've proposed https://github.com/rdo-common/openstack-tripleo-ui-deps/pull/19
> which allows us to build the package with the review and patchset
> numbers, before it's merged.
> Please review and we can try it on the next deps update!

Thanks Alan! Let's do that :)

Glad to see the pull request merged. If we're happy with the new
suggested process here, I proposed a patch to update the docs with it
at [1]. Hopefully we can move ahead with this and also merge the patch
to reenable the undercloud job [2] to get back minimal sanity checking
on the UI rpms.

Thanks!

Julie

[1] https://review.openstack.org/#/c/560846/
[2] https://review.openstack.org/#/c/526430/

__
OpenStack Development Mailing 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] Dependency management

[Julie Pichon]

On 19 January 2018 at 18:43, Honza Pokorny  wrote:
> We've recently discovered an issue with the way we handle dependencies for
> tripleo-ui.  This is an explanation of the problem, and a proposed solution.
> I'm looking for feedback.
>
> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
> tripleo-ui:
>
> * Native npm jobs
> * Undercloud integration jobs
>
> After the upgrade, the integration jobs went away.  Our goal is to add them
> back.
>
> There is a difference in how these two types of jobs handle dependencies.
> Native npm jobs use the "npm install" command to acquire packages, and
> undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
> dependencies called openstack-tripleo-ui-deps.
>
> Because of the requirement to use a separate RPM for dependencies, there is 
> some
> extra work needed when a new dependency is introduced, or an existing one is
> upgraded.  Once the patch that introduces the dependency is merged, we have to
> increment the version of the -deps package, and rebuild it.  It then shows up 
> in
> the yum repos used by the undercloud.
>
> To make matters worse, we recently upgraded our infrastructure to nodejs 8.9.4
> and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" 
> patches
> that simply introduce a new dependency to package.json, and nothing more.  The
> code that uses the new dependency must be included.  I tend to think that each
> commit should work on its own so this can be seen as a plus.
>
> This presents a problem: you can't get a patch that introduces a new 
> dependency
> merged because it's not included in the RPM needed by the undercloud ci job.
>
> So, here is a proposal on how that might work:
>
> 1. Submit a patch for review that introduces the dependency, along with code
>changes to support it and validate its inclusion
> 2. Native npm jobs will pass
> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM
> 4. We ask RDO to review for licensing
> 5. Once reviewed, new -deps package is built
> 6. Recheck
> 7. All jobs pass

Perhaps there should be a step after 3 or 4 to have the patch normally
reviewed, and wait for it to have two +2s before building the new
package? Otherwise we may end up with wasted work to get a new package
ready for dependencies that were eventually dismissed.

Julie

> There is the obvious issue with building an RPM based on an unmerged patch.
>
> What do you think?  Is that possible?  Any other solutions?
>
> Honza Pokorny

__
OpenStack Development Mailing 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] CI promotion blockers

[Julie Pichon]

On 2 January 2018 at 16:30, Alex Schultz <aschu...@redhat.com> wrote:
> On Tue, Jan 2, 2018 at 9:08 AM, Julie Pichon <jpic...@redhat.com> wrote:
>> Hi!
>>
>> On 27 December 2017 at 16:48, Emilien Macchi <emil...@redhat.com> wrote:
>>> - Keystone removed _member_ role management, so we stopped using it
>>> (only Member is enough): https://review.openstack.org/#/c/529849/
>>
>> There's been so many issues with the default member role and Horizon
>> over the years, that one got my attention. I can see that
>> puppet-horizon still expects '_member_' for role management [1].
>> However trying to understand the Keystone patch linked to in the
>> commit, it looks like there's total freedom in which role name to use
>> so we can't just change the default in puppet-horizon to use 'Member'
>> as other consumers may expect and settle on '_member_' in their
>> environment. (Right?)
>>
>> In this case, the proper way to fix this for TripleO deployments may
>> be to make the change in instack-undercloud (I presume in [2]) so that
>> the default role is explicitly set to 'Member' for us? Does that sound
>> like the correct approach to get to a working Horizon?
>>
>
> We probably should at least change _member_ to Member in
> puppet-horizon. That fixes both projects for the default case.

Oh, I thought there was no longer a default and that TripleO was
creating the 'Member' role by itself? Fixing it directly in
puppet-horizon sounds ideal in general, if changing the default value
isn't expected to cause other issues.

Thanks,

Julie

>
> Thanks,
> -Alex
>
>> Julie
>>
>> [1] 
>> https://github.com/openstack/puppet-horizon/blob/master/manifests/init.pp#L458
>> [2] 
>> https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.yaml.template#L622

__
OpenStack Development Mailing 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] CI promotion blockers

[Julie Pichon]

Hi!

On 27 December 2017 at 16:48, Emilien Macchi  wrote:
> - Keystone removed _member_ role management, so we stopped using it
> (only Member is enough): https://review.openstack.org/#/c/529849/

There's been so many issues with the default member role and Horizon
over the years, that one got my attention. I can see that
puppet-horizon still expects '_member_' for role management [1].
However trying to understand the Keystone patch linked to in the
commit, it looks like there's total freedom in which role name to use
so we can't just change the default in puppet-horizon to use 'Member'
as other consumers may expect and settle on '_member_' in their
environment. (Right?)

In this case, the proper way to fix this for TripleO deployments may
be to make the change in instack-undercloud (I presume in [2]) so that
the default role is explicitly set to 'Member' for us? Does that sound
like the correct approach to get to a working Horizon?

Julie

[1] 
https://github.com/openstack/puppet-horizon/blob/master/manifests/init.pp#L458
[2] 
https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.yaml.template#L622

__
OpenStack Development Mailing 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] Proposing Wesley Hayutin core on TripleO CI

[Julie Pichon]

On 6 December 2017 at 15:45, Emilien Macchi  wrote:
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)

+1!

__
OpenStack Development Mailing 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] Nominate akrivoka for tripleo-validations core

[Julie Pichon]

On 6 November 2017 at 14:32, Honza Pokorny  wrote:
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.
>
> With Ana's help as a core, we can get more done, and innovate faster.
>
> If there are no objections within a week, we'll proceed with adding Ana
> to the team.

It's been over a week, with no objections. Ana has now been added to
the tripleo-core group - welcome!

Julie

__
OpenStack Development Mailing 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] Proposing John Fulton core on TripleO

[Julie Pichon]

On 8 November 2017 at 22:24, Giulio Fidente  wrote:
> I would like to propose John Fulton core on TripleO.
>
> I think John did an awesome work during the Pike cycle around the
> integration of ceph-ansible as a replacement for puppet-ceph, for the
> deployment of Ceph in containers.
>
> I think John has good understanding of many different parts of TripleO
> given that the ceph-ansible integration has been a complicated effort
> involving changes in heat/tht/mistral workflows/ci and last but not
> least, docs and he is more recently getting busier with reviews outside
> his main comfort zone.

+1!

__
OpenStack Development Mailing 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] Nominate chem and matbu for tripleo-core !

[Julie Pichon]

On 9 November 2017 at 08:48, Marios Andreou  wrote:
> I would like to nominate (and imo these are both long overdue already):
>
> Sofer Athlan Guyot (chem)  and
>
> Mathieu Bultel (matbu)
>
> to tripleo-core. They have both made many many core contributions to the
> upgrades & updates over the last 3 cycles touching many of the tripleo repos
> (tripleo-heat-templates, tripleo-common, python-tripleoclient, tripleo-ci,
> tripleo-docs and others tripleo-quickstart/extras too unless am mistaken).
>
> IMO their efforts and contributions are invaluable for the upgrades squad
> (and beyond - see openstack overcloud config download for example) and we
> will be very lucky to have them as fully voting cores.
>
> Please vote with +1 or -1 for either or both chem and matbu - I'll keep it
> open for a week as customary,

+1 for both!

Julie

__
OpenStack Development Mailing 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] Nominate akrivoka for tripleo-validations core

[Julie Pichon]

On 6 November 2017 at 14:32, Honza Pokorny  wrote:
> I would like to nominate Ana Krivokapić (akrivoka) for the core team for
> tripleo-validations.  She has really stepped up her game on that project
> in terms of helpful reviews, and great patches.

+1

__
OpenStack Development Mailing 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] proposing Alex Schultz tripleo-core in all projects

[Julie Pichon]

On 7 July 2017 at 18:39, Emilien Macchi  wrote:
> Alex has demonstrated high technical and community skills in TripleO -
> where he's already core on THT, instack-undercloud, and puppet-tripleo
> - but also very involved in other repos.
> I propose that we extend his core status to all TripleO projects and
> of course trust him (like we trust all core members) to review patches
> were we feel confortable with.
>
> He has shown an high interest in reviewed other TripleO projects and I
> think he would be ready for this change.
> As usual, this is an open proposal, any feedback is welcome.

+1

__
OpenStack Development Mailing 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] I18n-themed Deep Dive - July 6th

[Julie Pichon]

Many thanks to those who could attend! The recording is available on
BlueJeans [1] and YouTube [2] (thanks Carlos!). I also wrote up a
transcript [3] if skimming is more your thing.

Regards,

Julie

[1] https://bluejeans.com/s/XmuHa
[2] https://www.youtube.com/watch?v=dmAw7b2yUEo
[3] 
http://www.jpichon.net/blog/2017/07/tripleo-deep-dive-internationalisation-ui/

On 29 June 2017 at 16:22, Julie Pichon <jpic...@redhat.com> wrote:
> Hi folks,
>
> As I mentioned during the weekly meeting on Tuesday, I'd like to do a
> short i18n-themed deep dive during next week's slot (Thu July 6th, 14:00
> UTC). I'll use my BlueJeans at [1] and updated the deep dives etherpad
> [2] with that information.
>
> There should be two broad topics:
> - Life and journey of a string
>   - From when it gets introduced in tripleo-ui, goes through infra, up
> to Zanata, and then back
>   - I'd also like to share some debugging tips, and how the infra jobs
> work
> - Working with the I18n team
>   - The role of the I18n cross-project liaison
>   - How we interact with the team in general, how to make their work
> easier
>   - Governance, release schedule & string freezes, particularly as a
> cycle-trailing project
>
> I mentioned this presentation at the I18n meeting this morning and
> several people expressed an interest in attending, it could be a nice
> opportunity for both devs & translators to see another side of the
> work. If there's something in particular you'd like me to touch on,
> feel free to bring it up.
>
> The talk will be recorded and I'll post a transcript as well.
>
> Regards,
>
> Julie
>
> [1] https://bluejeans.com/4050564424/
> [2] https://etherpad.openstack.org/p/tripleo-deep-dive-topics

__
OpenStack Development Mailing 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] [tripleo] I18n-themed Deep Dive - July 6th

[Julie Pichon]

Hi folks,

As I mentioned during the weekly meeting on Tuesday, I'd like to do a
short i18n-themed deep dive during next week's slot (Thu July 6th, 14:00
UTC). I'll use my BlueJeans at [1] and updated the deep dives etherpad
[2] with that information.

There should be two broad topics:
- Life and journey of a string
  - From when it gets introduced in tripleo-ui, goes through infra, up
to Zanata, and then back
  - I'd also like to share some debugging tips, and how the infra jobs
work
- Working with the I18n team
  - The role of the I18n cross-project liaison
  - How we interact with the team in general, how to make their work
easier
  - Governance, release schedule & string freezes, particularly as a
cycle-trailing project

I mentioned this presentation at the I18n meeting this morning and
several people expressed an interest in attending, it could be a nice
opportunity for both devs & translators to see another side of the
work. If there's something in particular you'd like me to touch on,
feel free to bring it up.

The talk will be recorded and I'll post a transcript as well.

Regards,

Julie

[1] https://bluejeans.com/4050564424/
[2] https://etherpad.openstack.org/p/tripleo-deep-dive-topics

__
OpenStack Development Mailing 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] another i18n proposal for heat templates 'description' help strings

[Julie Pichon]

Hi Peng,

I added some thoughts in-line, let me know what you think.

On 10 April 2017 at 08:10, Peng Wu  wrote:
> Hi,
>
>   In TripleO UI project users requested translation of the web UI. But
> some web UI strings are displayed from heat template files in tripleo-
> heat-templates project.
>
>   In order to get translated templates displayed in tripleo-ui, we
> propose another solution as follows, which needs to change code in
> tripleo-heat-templates and tripleo-ui projects.
>
>   I18n proposal for Heat templates 'description' help strings
>
>   1. Update tripleo-heat-templates to generate the javascript files to
> include all translation strings, like "tripleo-heat-templates.js"
>
>  a. Need to write python script to extract "title" and
> "description" field from yaml files and generate "tripleo-heat-
> templates.js" for react-intl usage in tripleo-ui

I think extracting the strings directly into js/json format may be not
be a viable option, because it isn't a format supported by
Zanata [1].

For tripleo-ui itself we use react-intl which expects json, and work
with scripts to convert to/from pot and po (see [2]) which are fully
supported by Zanata.

Or is the idea that we'd also generate pot/po as intermediary steps and
only store json in the repo?

>  b. Use default message as message id or consider nodejs-i18n for
> tripleo-ui

I'm wary of considering a library change considering the amount of
churn it would cause in the code base for all the existing strings,
plus that would then make backports more difficult. It really needs to
be considered carefully.

>
>   2. Update tripleo-ui to use "tripleo-heat-templates.js"
>
>  a. Write some script to sync "tripleo-heat-templates.js" from
> tripleo-heat-templates
>
>  b. Call formatMessage function for "title" and "description" field
> with message id (use default message) and default message or consider
> nodejs-i18n for tripleo-ui
>
>   Refer URL for message id: https://github.com/yahoo/react-intl/issues/
> 912

Could you explain a bit more the issue with the ids? I see us defining
an id in every message [3] and this is how they are referenced in the
locale json [4] (the mapping is not done by message, but by ID).

When it comes to the THT message, I think they all have a hierarchy
that perhaps could be used as a key to map between the original string
and the translation? Something along the lines of
OS::TripleO::Services::Apache::ApacheMaxRequestWorkers::description,
whichever form the API gives us at the moment.

>   Please evaluate it, thanks!

Thank you!

Julie

[1] 
http://docs.zanata.org/en/release/user-guide/projects/project-types/#supported-types
[2] 
https://github.com/openstack/tripleo-ui/blob/master/docs/translation.rst#extracting-messages-from-components
[3] 
https://github.com/openstack/tripleo-ui/blob/master/src/js/components/nodes/Nodes.js#L17
[4] https://github.com/openstack/tripleo-ui/blob/master/i18n/locales/es.json#L3

__
OpenStack Development Mailing 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] Proposing Florian Fuchs for tripleo-validations core

[Julie Pichon]

On 6 April 2017 at 10:53, Martin André  wrote:
> Hellooo,
>
> I'd like to propose we extend Florian Fuchs +2 powers to the
> tripleo-validations project. Florian is already core on tripleo-ui
> (well, tripleo technically so this means there is no changes to make
> to gerrit groups).
>
> Florian took over many of the stalled patches in tripleo-validations
> and is now the principal contributor in the project [1]. He has built
> a good expertise over the last months and I think it's time he has
> officially the right to approve changes in tripleo-validations.
>
> Consider this my +1 vote.
>
> Martin
>
> [1] 
> http://stackalytics.com/?module=tripleo-validations=patches=pike
>

+1!

__
OpenStack Development Mailing 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] [heat] i18n proposal for heat templates 'description' help strings

[Julie Pichon]

Hi,

Peng, thank you for looking into how we might be able to provide
translations for the THT content in TripleO UI! I think this would be
helpful for users, and we have a couple of translators interested in
helping as well.

On 23 March 2017 at 09:07, Thomas Herve  wrote:
> On Thu, Mar 23, 2017 at 9:39 AM, Peng Wu  wrote:
>> Hi,
>>
>>   For TripleO UI project, some users requested to translate the web UI.
>> But some web UI string are from heat template files in tripleo-heat-
>> templates project.
>>
>>   In order to get translated templates displayed in tripleo-ui, we
>> propose a blueprint as follows, which needs to change code in heat,
>> tripleo-heat-tempates and tripleo-ui projects.
>>
>>   I18n proposal for heat templates 'description' help strings
>>
>>   1. Update heat project to accept "translation-domain" header in
>> RESTful request, like "translation-domain: tripleo-heat-templates"
>>
>>  a. With "translation-domain" header, heat will try to translate
>> "title" and "description" field using "tripleo-heat-templates.po"
>>
>>  b. Without "translation-domain" header, heat will return the
>> fields like before
>>
>>  c. Add some field in config file for security to have a list of
>> allowed "translation-domain",
>> like "allowed-translation-domains: ['tripleo-heat-templates',
>> ...]"
>
> From the Heat side of things, that sounds like a big no-no to me.
> While we've done many things to cater to TripleO, this is way too
> specific of a use case. It doesn't even make sense for the general use
> case of passing user templates to Heat.

I would have thought maybe providing a standard mechanism for Heat
users to share templates with descriptions in multiple languages would
be interesting to Heat as well, but it looks like the workflow isn't
quite the same as I thought so that's fair enough.

>>   2. Update tripleo-heat-templates to generate the translation files,
>>  like "tripleo-heat-templates.pot"
>>
>>  a. May need to write python script to extract "title" and
>> "description" field from yaml files
>>
>>  b. May need to integrate into python babel config or use separate
>> po files
>>
>>
>>   3. Update tripleo-ui to use locale API with "translation-domain"
>> header to ask the RESTful response with translated "title" and
>> "description" fields from heat services
>>
>>  a. tripleo-ui will send request with two additional headers:
>> "Accept-Language" and "translation-domain: tripleo-heat-
>> templates"
>
> Those last 2 steps may make more sense. Possibly try to store those
> translation files somewhere and manage them in the UI?

If it's at all possible, I think it'd be good to figure out a mechanism
where we can keep the translations together with the templates that
have the original strings (so in the THT repo itself), rather than
store them all in the UI repository where it could easily get out of
sync and could never be reused outside of the UI use case.

Of course this means the translations would likely be stored in
standard PO files, while the tripleo-ui i18n library only understands
JSON for the message catalogues... so there'll probably be some
interesting things to figure out here. I imagine the PO files would end
up stored in Swift with the rest of the plan, maybe we could get to
them via a Mistral action that would convert them to JSON? Or modify
the current action that gets the titles/descriptions to look for the
new Accept-Language header, I'm not familiar with how it currently works.

If there is a blueprint or bug or spec where you're tracking the work,
I'd love to know so I can follow what's happening and see if there are
places where I might be able to help. If the new Python script requires
some additional infra work, I also have some experience with updating
the translation proposal jobs to work with different formats.

Thanks,

Julie

__
OpenStack Development Mailing 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] Propose Attila Darazs and Gabriele Cerami for tripleo-ci core

[Julie Pichon]

On 15 March 2017 at 15:44, John Trowbridge  wrote:
> Both Attila and Gabriele have been rockstars with the work to transition
> tripleo-ci to run via quickstart, and both have become extremely
> knowledgeable about how tripleo-ci works during that process. They are
> both very capable of providing thorough and thoughtful reviews of
> tripleo-ci patches.
>
> On top of this Attila has greatly increased the communication from the
> tripleo-ci squad as the liason, with weekly summary emails of our
> meetings to this list.

+1

__
OpenStack Development Mailing 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] Now with translations :)

[Julie Pichon]

On 6 February 2017 at 16:03, Ben Nemec <openst...@nemebean.com> wrote:
> On 02/06/2017 05:38 AM, Julie Pichon wrote:
>>
>> Hi folks,
>>
>> You may have noticed a new type of patch in our queue this morning
>> [1]. There's a nice link in the commit message [2][3] that describes
>> what to do with it (TL;DR: check the structure is correct, merge it
>> quickly - most projects have a single core approval policy for these
>> as well, which I wasn't aware of. Nice!).
>
> Can you propose adding this to the expedited approvals policy?
> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html

Done! https://review.openstack.org/#/c/430195/

TripleO UI cores, I also added you as reviewers since you are
currently the main people affected.

Thanks,

Julie

__
OpenStack Development Mailing 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] [tripleo][ui] Now with translations :)

[Julie Pichon]

Hi folks,

You may have noticed a new type of patch in our queue this morning
[1]. There's a nice link in the commit message [2][3] that describes
what to do with it (TL;DR: check the structure is correct, merge it
quickly - most projects have a single core approval policy for these
as well, which I wasn't aware of. Nice!).

While enabling this I received a couple a questions around the infra
workflows so I thought I'd give the team a quick overview of how our
repo is integrated with Zanata and what it means for the project.

How it works
--

1. Translations happen on Zanata at [4]. Never modify a translation in
a json file directly. You can join the i18n team for your language(s)
at [5] if you'd like to help translating!

2. Whenever a patch that contains new internationalised strings
merges, the strings on Zanata are updated.

3. Once a day a script checks for new translations, and proposes an
automated patch like [1] to our repo (if most of the strings for that
language are translated).

Things to be careful about from now on
---

1. Please don't hardcode strings anymore, always make them
internationalisable and keep an eye out for this during reviews. You
can look at one of the existing i18n patches to figure out how to do
it, and maybe we can update our docs with a how-to/point to the i18n
library docs.

2. We need to be careful about modifying strings, especially in
backports in the future as that invalidates translations.

3. We need to be careful about Soft String Freeze (don't modify
strings anymore, additions are ok) and Hard String Freeze (don't
accept patches with any of kind of string changes) in the schedule [6]
from now on, to give translators time to work. (We may have 1-2 weeks
of "cycle-trailing" wiggle room for each deadline.)

4. If you are a core reviewer, please try to review and get
translation patches merged as soon as possible, particularly after the
Freezes. It gives translators a chance to check and review the
translations on a test system before the release.

5. I proposed a new 'i18n' bug tag [7] for tracking i18n issues (most
likely, missing strings that were hardcoded). It'd be cool if we could
try to prioritise fixing these when they come up between Soft String
Freeze and RC, whenever it's possible/reasonable to do so. So that
translators may have a chance to update the translation for the
corrected string before the release.


The OpenStack i18n team is small and overloaded, so I don't think the
community will be able to prioritise translating the UI in general,
however we do have a couple of individual translators who will be
working on Ocata translations for us. Let's try to make their job as
easy as possible :)

Thank you!

Julie

[1] https://review.openstack.org/#/c/429203/
[2] http://docs.openstack.org/project-team-guide/i18n.html
[3] http://docs.openstack.org/developer/i18n/reviewing-translation-import.html
[4] https://translate.openstack.org/project/view/tripleo-ui
[5] http://docs.openstack.org/developer/i18n/contributing.html
[6] https://releases.openstack.org/ocata/schedule.html
[7] https://review.openstack.org/#/c/429613/

__
OpenStack Development Mailing 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] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

[Julie Pichon]

On 31 January 2017 at 16:02, Ben Nemec  wrote:
> In the spirit of all the core team changes, here are a couple more I'd like
> to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long time
> so this is way overdue.  I'm also going to propose that he be able to +2
> anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.

+1!

__
OpenStack Development Mailing 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] Proposing Honza Pokorny core on tripleo-ui

[Julie Pichon]

On 24 January 2017 at 13:52, Emilien Macchi  wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it would
> also help the other 2 core reviewers to accelerate the review process
> in UI component.
>
> Like usual, this is open for discussion, Tripleo UI core and TripleO
> core, please vote.

+1

__
OpenStack Development Mailing 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] Update TripleO core members

[Julie Pichon]

On 23 January 2017 at 19:03, Emilien Macchi  wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.

+1

__
OpenStack Development Mailing 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] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

[Julie Pichon]

On 24 January 2017 at 17:03, Juan Antonio Osorio  wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.

+1

__
OpenStack Development Mailing 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] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

On 18 January 2017 at 11:35, Julie Pichon <jpic...@redhat.com> wrote:
> I'm sorry to report we're finding ourselves in the same situation
> again - CI will fail on all the UI patches, please don't recheck until
> we have a new dependencies package available.
>
> On the plus side, with the help of amoralej on #rdo we figured out why
> this is happening: the tripleo-ui rpm used in CI is being built from
> the master branch, instead of using the patch under review. So,
> instead of happening on the patch itself the CI failures only happen
> after it merges. I filed [1] to track this. Any pointer from folks
> familiar with TripleO CI as to where we might want to poke to resolve
> this is appreciated :)

We're back in business! Recheck away, merge all the patches :)

Also thanks to panda we have a fix for the "CI not testing the patch
currently under review" issue merged so hopefully this time, we can
avoid the same kind of problems with new dependencies.

Thanks,

Julie

> [1] https://bugs.launchpad.net/tripleo/+bug/1657416

__
OpenStack Development Mailing 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] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

Hi all,

I'm sorry to report we're finding ourselves in the same situation
again - CI will fail on all the UI patches, please don't recheck until
we have a new dependencies package available.

On the plus side, with the help of amoralej on #rdo we figured out why
this is happening: the tripleo-ui rpm used in CI is being built from
the master branch, instead of using the patch under review. So,
instead of happening on the patch itself the CI failures only happen
after it merges. I filed [1] to track this. Any pointer from folks
familiar with TripleO CI as to where we might want to poke to resolve
this is appreciated :)

Thank you.

Julie

[1] https://bugs.launchpad.net/tripleo/+bug/1657416

On 10 January 2017 at 16:27, Julie Pichon <jpic...@redhat.com> wrote:
> On 9 January 2017 at 13:20, Julie Pichon <jpic...@redhat.com> wrote:
>> On 6 January 2017 at 14:52, Julie Pichon <jpic...@redhat.com> wrote:
>>> Hi folks,
>>>
>>> Just a heads-up that the DLRN "current"/dev package for the Tripleo UI
>>> is broken in Ocata and will cause the UI to only show a blank page,
>>> until we resolve some dependencies issues within the -deps package.
>>>
>>> If I understand correctly, we ended up with an incomplete package
>>> because we were silently ignoring errors during builds [1] - many
>>> thanks to Honza for the debugging work, and the patch!!
>>
>> The good news: the 'stop on error' patch merged, meaning we will catch
>> such errors early in the future, and won't be able to merge patches
>> until the dependencies are properly sorted out. A backport was also
>> proposed at [1].
>>
>> The bad news: because currently we're already in a "missing
>> dependencies" state due to patches that merged with silent errors and
>> the older -deps package, no patch can merge on tripleo-ui until the
>> -deps package gets updated. I'm not sure about the ETA for the new
>> -deps package but the good folks on #rdo are looking into it (see
>> also [2]).
>
> Hi all,
>
> The -deps package has been sorted out, so the CI jobs for tripleo-ui
> are passing again. Feel free to recheck away! There is a patch going
> through the gate as well [1], once that's merged I expect a new
> tripleo-ui package will be available at [2] and updating your local dev
> repos to the latest dlrn to get it should be sufficient to have a
> working UI again.
>
> Thank you for your patience, and many many thanks to apevec, honza and
> number80 for resolving this!
>
> Julie
>
> [1] https://review.openstack.org/#/c/416261/
> [2] http://trunk.rdoproject.org/centos7/current/
>
>> Thanks,
>>
>> Julie
>>
>> [1] https://review.openstack.org/#/c/417866/
>> [2] https://review.rdoproject.org/r/#/c/4215/
>>
>>> In the meantime, if you want to work with the UI package you should
>>> get a version built before December 19th, e.g. [2], or you're probably
>>> better off using the UI from source for the time being [3].
>>>
>>> I'll update this thread when this is resolved.
>>>
>>> Thanks,
>>>
>>> Julie
>>>
>>> [1] https://bugs.launchpad.net/tripleo/+bug/1654051
>>> [2] 
>>> https://trunk.rdoproject.org/centos7-master/04/15/0415ee80b5c8354124290ac933a34823f2567800_c211fbe8/openstack-tripleo-ui-2.0.0-0.20161212153814.2dfbb0b.el7.centos.noarch.rpm
>>> [3] 
>>> https://github.com/openstack/tripleo-ui/blob/master/README.md#install-tripleo-ui

__
OpenStack Development Mailing 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] [tripleo] [zaqar] Re: Attempting to proxy websockets through Apache or HAProxy for Zaqar

[Julie Pichon]

(Just adding a couple of topic tags for visibility)

On 17 January 2017 at 17:23, Dan Trainor  wrote:
> Hi -
>
> In an attempt to work on [0], I've been playing around with proxying all the
> service API endpoints that the UI needs to communicate with, through either
> haproxy or Apache to avoid a bug[1] around how non-Chrome browsers handle
> SSL connections to different ports on the same domain.
>
> The blueprint suggests using haproxy for this, but we're currently using the
> "old" notation of listen/server, not frontend/backend.  The distinction is
> important because the ACLs that would allow any kind of proxying to
> facilitate this are only available in the latter notation.  In order to do
> this in haproxy, tripleo::haproxy would need a rewrite (looks pretty
> trivial, but likely out of scope for this).  So I'd really like to isolate
> this to UI, which is convenient since UI runs largely self-contained inside
> Apache.
>
> I've made some good progress with most all of the services, since they were
> pretty straight-forward - mod_proxy handles them just fine.  The one I'm not
> able to make work right now is the websocket service that UI uses.
> Ultimately, I see the Websocket connection get upgraded and the Websocket
> opens, but stays open indefinitely and will never see more than 0 bytes.  No
> data is transferred from the browser over the Websocket.  This connection
> hangs indefinitely, and UI does not complete any operations that depend on
> the Zaqar Websocket.
>
> Observing trace6[4] output, I can see mod_proxy_wstunnel (which relies on
> mod_proxy) make the connection, I can see Zaqar recognize the request in
> logs, the client (UI) doesn't send or receive any data from it.  It's as if
> immediately after the Upgrade[2], the persistent Websocket connection just
> dies.
>
> I've had limited success using a couple different implementations of this in
> Apache.  ProxyPass/ProxyPassReverse looks as if it should work (so long as
> mod_proxy_wstunnel is loaded), but this is not my experience.  Using a
> mod_rewrite rule[3] to force the specific Websocket proxy for a specific URI
> (/zaqar) has the same outcome.
>
> In its most simple form, the ProxyPass rule I'm attempting to use is:
>
>   ProxyPass "/zaqar""ws://192.0.2.1:9000/"
>   ProxyPassReverse  "/zaqar""ws://192.0.2.1:9000/"
>
> Note that I've used several variations of both ProxyPass configurations and
> mod_rewrite rules using the [P] flag which all seem to net the same result.
> I've also tried writing the same functional equivalent in haproxy using a
> frontend/backend notation to confirm if this was a protocol thing or a
> software thing (if haproxy could do this, but Apache could not).
>
> From the top, here's some Apache logs (note that trace6 is noisy, I just
> grep'd for ws, wss, and the websocket port (9000); full logs of this request
> are [4]):
>
> [Tue Jan 17 12:08:16.639170 2017] [proxy_wstunnel:debug] [pid 32128]
> mod_proxy_wstunnel.c(253): [client 192.0.2.1:51508] AH02445: woke from
> poll(), i=1
> [Tue Jan 17 12:08:16.639220 2017] [proxy_wstunnel:debug] [pid 32128]
> mod_proxy_wstunnel.c(278): [client 192.0.2.1:51508] AH02448: client was
> readable
> [Tue Jan 17 12:08:16.639265 2017] [core:trace6] [pid 32128]
> core_filters.c(525): [remote 192.0.2.1:9000] core_output_filter: flushing
> because of FLUSH bucket
> [Tue Jan 17 12:08:16.639337 2017] [proxy_wstunnel:trace2] [pid 32128]
> mod_proxy_wstunnel.c(295): [client 192.0.2.1:51508] finished with poll() -
> cleaning up
> [Tue Jan 17 12:08:16.640023 2017] [proxy:debug] [pid 32128]
> proxy_util.c(2218): AH00943: WS: has released connection for (192.0.2.1)
> [Tue Jan 17 12:08:19.238044 2017] [core:trace5] [pid 32128] protocol.c(618):
> [client 192.0.2.1:51996] Request received from client: GET /zaqar HTTP/1.1
> [Tue Jan 17 12:08:19.238191 2017] [core:trace3] [pid 32128] request.c(293):
> [client 192.0.2.1:51996] request authorized without authentication by
> access_checker_ex hook: /zaqar
> [Tue Jan 17 12:08:19.238202 2017] [proxy_wstunnel:trace1] [pid 32128]
> mod_proxy_wstunnel.c(51): [client 192.0.2.1:51996] canonicalising URL
> //192.0.2.1:9000/
> [Tue Jan 17 12:08:19.238223 2017] [proxy:trace2] [pid 32128]
> proxy_util.c(1985): [client 192.0.2.1:51996] ws: found worker
> ws://192.0.2.1:9000/ for ws://192.0.2.1:9000/
> [Tue Jan 17 12:08:19.238227 2017] [proxy:debug] [pid 32128]
> mod_proxy.c(1117): [client 192.0.2.1:51996] AH01143: Running scheme ws
> handler (attempt 0)
> [Tue Jan 17 12:08:19.238231 2017] [proxy_http:debug] [pid 32128]
> mod_proxy_http.c(1925): [client 192.0.2.1:51996] AH01113: HTTP: declining
> URL ws://192.0.2.1:9000/
> [Tue Jan 17 12:08:19.238236 2017] [proxy_wstunnel:debug] [pid 32128]
> mod_proxy_wstunnel.c(333): [client 192.0.2.1:51996] AH02451: serving URL
> ws://192.0.2.1:9000/
> [Tue Jan 17 12:08:19.238239 2017] [proxy:debug] [pid 32128]
> proxy_util.c(2203): AH00942: WS: has acquired 

Re: [openstack-dev] [tripleo][ui] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

On 9 January 2017 at 13:20, Julie Pichon <jpic...@redhat.com> wrote:
> On 6 January 2017 at 14:52, Julie Pichon <jpic...@redhat.com> wrote:
>> Hi folks,
>>
>> Just a heads-up that the DLRN "current"/dev package for the Tripleo UI
>> is broken in Ocata and will cause the UI to only show a blank page,
>> until we resolve some dependencies issues within the -deps package.
>>
>> If I understand correctly, we ended up with an incomplete package
>> because we were silently ignoring errors during builds [1] - many
>> thanks to Honza for the debugging work, and the patch!!
>
> The good news: the 'stop on error' patch merged, meaning we will catch
> such errors early in the future, and won't be able to merge patches
> until the dependencies are properly sorted out. A backport was also
> proposed at [1].
>
> The bad news: because currently we're already in a "missing
> dependencies" state due to patches that merged with silent errors and
> the older -deps package, no patch can merge on tripleo-ui until the
> -deps package gets updated. I'm not sure about the ETA for the new
> -deps package but the good folks on #rdo are looking into it (see
> also [2]).

Hi all,

The -deps package has been sorted out, so the CI jobs for tripleo-ui
are passing again. Feel free to recheck away! There is a patch going
through the gate as well [1], once that's merged I expect a new
tripleo-ui package will be available at [2] and updating your local dev
repos to the latest dlrn to get it should be sufficient to have a
working UI again.

Thank you for your patience, and many many thanks to apevec, honza and
number80 for resolving this!

Julie

[1] https://review.openstack.org/#/c/416261/
[2] http://trunk.rdoproject.org/centos7/current/

> Thanks,
>
> Julie
>
> [1] https://review.openstack.org/#/c/417866/
> [2] https://review.rdoproject.org/r/#/c/4215/
>
>> In the meantime, if you want to work with the UI package you should
>> get a version built before December 19th, e.g. [2], or you're probably
>> better off using the UI from source for the time being [3].
>>
>> I'll update this thread when this is resolved.
>>
>> Thanks,
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo/+bug/1654051
>> [2] 
>> https://trunk.rdoproject.org/centos7-master/04/15/0415ee80b5c8354124290ac933a34823f2567800_c211fbe8/openstack-tripleo-ui-2.0.0-0.20161212153814.2dfbb0b.el7.centos.noarch.rpm
>> [3] 
>> https://github.com/openstack/tripleo-ui/blob/master/README.md#install-tripleo-ui

__
OpenStack Development Mailing 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] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

On 6 January 2017 at 14:52, Julie Pichon <jpic...@redhat.com> wrote:
> Hi folks,
>
> Just a heads-up that the DLRN "current"/dev package for the Tripleo UI
> is broken in Ocata and will cause the UI to only show a blank page,
> until we resolve some dependencies issues within the -deps package.
>
> If I understand correctly, we ended up with an incomplete package
> because we were silently ignoring errors during builds [1] - many
> thanks to Honza for the debugging work, and the patch!!

The good news: the 'stop on error' patch merged, meaning we will catch
such errors early in the future, and won't be able to merge patches
until the dependencies are properly sorted out. A backport was also
proposed at [1].

The bad news: because currently we're already in a "missing
dependencies" state due to patches that merged with silent errors and
the older -deps package, no patch can merge on tripleo-ui until the
-deps package gets updated. I'm not sure about the ETA for the new
-deps package but the good folks on #rdo are looking into it (see
also [2]).

Thanks,

Julie

[1] https://review.openstack.org/#/c/417866/
[2] https://review.rdoproject.org/r/#/c/4215/

> In the meantime, if you want to work with the UI package you should
> get a version built before December 19th, e.g. [2], or you're probably
> better off using the UI from source for the time being [3].
>
> I'll update this thread when this is resolved.
>
> Thanks,
>
> Julie
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1654051
> [2] 
> https://trunk.rdoproject.org/centos7-master/04/15/0415ee80b5c8354124290ac933a34823f2567800_c211fbe8/openstack-tripleo-ui-2.0.0-0.20161212153814.2dfbb0b.el7.centos.noarch.rpm
> [3] 
> https://github.com/openstack/tripleo-ui/blob/master/README.md#install-tripleo-ui

__
OpenStack Development Mailing 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] [tripleo][ui] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

Hi folks,

Just a heads-up that the DLRN "current"/dev package for the Tripleo UI
is broken in Ocata and will cause the UI to only show a blank page,
until we resolve some dependencies issues within the -deps package.

If I understand correctly, we ended up with an incomplete package
because we were silently ignoring errors during builds [1] - many
thanks to Honza for the debugging work, and the patch!!

In the meantime, if you want to work with the UI package you should
get a version built before December 19th, e.g. [2], or you're probably
better off using the UI from source for the time being [3].

I'll update this thread when this is resolved.

Thanks,

Julie

[1] https://bugs.launchpad.net/tripleo/+bug/1654051
[2] 
https://trunk.rdoproject.org/centos7-master/04/15/0415ee80b5c8354124290ac933a34823f2567800_c211fbe8/openstack-tripleo-ui-2.0.0-0.20161212153814.2dfbb0b.el7.centos.noarch.rpm
[3] 
https://github.com/openstack/tripleo-ui/blob/master/README.md#install-tripleo-ui

__
OpenStack Development Mailing 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][Upgrade Squad syncup]

[Julie Pichon]

On 14 December 2016 at 08:56, Dougal Matthews  wrote:
> On 13 December 2016 at 16:12, Emilien Macchi  wrote:
>>
>> On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou 
>> wrote:
>> > Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
>> > lets schedule a syncup on the Ocata composable upgrades work and how we
>> > will build on Steve Hardy's base ansible driven implementation.
>> >
>> > IMO a call would be the best format (I propose to schedule a bluejeans
>> > call, though I am open to any other suggestions). For now I've setup a
>> > doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
>> > you'd like to participate. Assuming we go with bluejeans (unless I hear
>> > strong pushback/other suggestions) then I'll try and make a recording
>> > available to address the concerns expressed at
>> >
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
>> > (thanks shardy for pointing that out).
>> >
>> > Moving forward we should probably switch to an irc based syncup,
>>
>> As long as:
>> - we have zero pushbash from our community members
>> - anyone can join the call
>> - our design and discussions stay open (mailing-list, tripleo-specs, IRC)
>> - a nice summary is sent to openstack-dev
>
> or maybe even better, a recording is posted online?

Personally, I find summaries easier to parse compared to finding an
hour to listen to people talking back and forth about something,
though it doesn't need to be an either/or proposition :) One of the
issues brought up in the other thread about video calls is that they
can be difficult to follow for folks who don't have English as a first
language. Having a few written notes about what came up during the
meeting and some of the conclusions would help with this I think.

Looking forward to seeing how the upgrade work comes along!

Julie

>> - we keep tripleo meeting on IRC every week
>>
>> I don't see any blocker to do video-conference between folks that work
>> together on a same topic.
>>
>> > I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
>> > ) and schedule the meeting accordingly with a followup mail here,
>> >
>> >
>> > thanks, marios
>> >
>> >
>> > [1]
>> >
>> > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.html

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

[openstack-dev] [TripleO] "Spec review process" now exists as a policy

[Julie Pichon]

Hi folks,

As discussed in the last couple of TripleO meeting, the information on
the wiki about how to review specs [1] was migrated into a policy at
[2]. Hopefully this will help make the information more visible, and
new additions (like the one that came up at [3]) will be easier to
consider for addition.

Thanks for all the work on the initial document, which is pretty awesome.

Julie

[1] https://wiki.openstack.org/wiki/TripleO/SpecReviews
[2] 
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/spec-review.html
[3] https://review.openstack.org/#/c/407533/

__
OpenStack Development Mailing 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] Proposing Alex Schultz core on puppet-tripleo

[Julie Pichon]

On 1 December 2016 at 22:26, Emilien Macchi  wrote:
> Team,
>
> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> months now.  While he's very active in different areas of TripleO, his
> reviews and contributions on puppet-tripleo have been very useful.
> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> think he perfectly understands how puppet-tripleo works. His
> involvement in the project and contributions on puppet-tripleo deserve
> that we allow him to +2 puppet-tripleo.
>
> Thanks Alex for your involvement and hard work in the project, this is
> very appreciated!

+1!

>
> As usual, I'll let the team to vote about this proposal.
>
> Thanks,
> --
> Emilien Macchi
>

__
OpenStack Development Mailing 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] Proposing Julie Pichon for tripleo core

[Julie Pichon]

On 23 November 2016 at 12:34, Emilien Macchi  wrote:
> 14 positive votes, I guess that's enough ;-)
> Congratulations, Julie!
>
> (added to tripleo-core in Gerrit)

Thanks, everyone!

Julie

>
> On Wed, Nov 23, 2016 at 6:15 AM, Jiri Tomasek  wrote:
>>
>>
>> On 22.11.2016 18:01, Dougal Matthews wrote:
>>
>> Hi all,
>>
>> I would like to propose we add Julie (jpich) to the TripleO core team for
>> python-tripleoclient and tripleo-common. This nomination is based partially
>> on review stats[1] and also my experience with her reviews and
>> contributions.
>>
>> Julie has consistently provided thoughtful and detailed reviews since the
>> start of the Newton cycle. She has made a number of contributions which
>> improve the CLI and has been extremely helpful with other tasks that don't
>> often get enough attention (backports, bug triaging/reporting and improving
>> our processes[2]).
>>
>> I think she will be a valuable addition to the review team
>>
>> Dougal
>>
>>
>> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
>> [2]: https://review.openstack.org/#/c/352852/
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> +1!
>>
>> -- Jirka
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Openstack TripleO Newton install [TripleO] [OpenStack-docs]

[Julie Pichon]

Hi Kent,

On 23 November 2016 at 16:08, Gordon, Kent
 wrote:
> Does documentation exist for a TripleO Newton install ?
>
> I have looked at both
>
> http://docs.openstack.org/developer/tripleo-docs/index.html
>
> http://tripleo.org/

I believe these are the correct places to look at. There was a pending
patch to add the Newton information at [1] which just merged, I'd
expect the documentation pages to reflect the change shortly.

Hope this helps,

Julie

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


>
>
>
> I see that the repo’s suggested are for Liberty or Mitaka.
>
>
>
> I have found one reference to upgrading to Newton.  I only found this link
> via google.  It does not seem to via menu system.
>
> http://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html
>
> but it still references Mitaka repo’s.
>
>
>
>
>
> Kent S. Gordon
>
> DMTS, NNO
>
> email: kent.gor...@verizonwireless.com desk: (682)831-3601  cell:
> (817)905-6518
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [TripleO] [UI] Adding a new job to the gate

[Julie Pichon]

Hi,

At the end of Newton we had a few issues where the packaged UI in DLRN
didn't work at all. To try and avoid similar problems happening again,
I've been working on a simple sanity check to be run on CI at [1]. All
the necessary patches are up, this is just a heads-up for folks working
in the tripleo-ui repository that a new job will be added to the
tripleo-ui gate once [2] merges. This job (the undercloud job) usually
takes about 30mn to complete so it will take slightly longer before
patches merge.

In the same patch I also proposed to run the undercloud job in
puppet-tripleo, as changes there can affect the UI configuration.

Let me know if there is any questions or concerns.

Thanks,

Julie

[1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-basic-ci-check
[2] https://review.openstack.org/#/c/392215/

__
OpenStack Development Mailing 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] Getting the UI to talk with Undercloud API service endpoints

[Julie Pichon]

On 7 October 2016 at 20:30, Dan Sneddon  wrote:
> Do you know how awesome it would be if you put this idea into a Blueprint at
> http://blueprints.launchpad.net? That would be super-awesome.
> File it under tripleo-ui project here if you have a few minutes:
>
> https://blueprints.launchpad.net/specs/+new

That does sound awesome! Slight correction: from Ocata the tripleo-ui
blueprints should live in the 'tripleo' Launchpad project as well [1],
the other tracker is/will be deprecated.

Additional thoughts:

> - Original Message -
>> Hi -
>>
>> Great suggestions, Dan.
>>
>> To recap, we followed that up with a few other ideas on irc and we eventually
>> came to a point to test some of this, with slight modification.
>>
>> UI also ships with a configuration file that can override the endpoint
>> information received from Keystone. The file is located at
>> /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js.
>>
>> Part of making this work means enabling SSL on the Undercloud when the UI
>> component is selected for installation in undercloud.conf. I think this is
>> going to be a pretty reasonable request, but I'm interested in hearing
>> feedback from this, and what other implications it may have, that I can't
>> think of. The changes I made were all one-off, unmanaged changes, just to
>> test this idea out. I'll be doing some more tests but will probably be
>> looking for acceptance shortly.

Just a note that the UI is currently installed by default on the
undercloud. So this may mean either the undercloud becomes SSL by
default, or that we need to switch the UI to not being installed by
default.

>> Once SSL was enabled on the Undercloud, I made two edits to haproxy.cfg that
>> were pretty straightforward: added a 'listen' server directive for UI to
>> both terminate SSL and forward the request to Apache, and added a 'bind'
>> statement for each service that UI expects to talk to (keystone, heat,
>> ironic, mistral, swift, zaqar-websocket).
>>
>> Once those configuration changes were made, I had a very pleasant experience
>> using the UI. It worked exactly as expected. I think this might be a viable
>> option.
>>
>> Thoughts?

Exciting stuff! Thank you for looking into this and I look forward to
seeing the blueprint. I'm happy to try and give a hand with
implementing/testing the changes to get this done as well.

Thanks,

Julie

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101747.html

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

Re: [openstack-dev] [tripleo][release] Plans re newton-3 release and feature freeze exceptions

[Julie Pichon]

On 26 August 2016 at 19:04, James Slagle  wrote:
> On Fri, Aug 26, 2016 at 12:14 PM, Steven Hardy  wrote:
>>
>> 1. Mistral API
>>
>> We've made good progress on this over recent weeks, but several patches
>> remain - this is the umbrella BP, and it links several dependent BPs which
>> are mostly posted but need code reviews, please help by testing and
>> reviewing these:
>>
>> https://blueprints.launchpad.net/tripleo/+spec/mistral-deployment-library
>
> Based on what's linked off of that blueprint, here's what's left:
>
> https://blueprints.launchpad.net/tripleo/+spec/cli-deployment-via-workflow
> topic branch: 
> https://review.openstack.org/#/q/status:open+project:openstack/python-tripleoclient+branch:master+topic:deploy
> 5 patches, 2 are marked WIP, all need reviews
>
> https://blueprints.launchpad.net/tripleo-ui/+spec/tripleo-ui-mistral-refactoring
> topic branch: 
> https://review.openstack.org/#/q/topic:bp/tripleo-ui-mistral-refactoring
> 1 tripleo-ui patch
> 1 tripleo-common patch that is Workflow -1
> 1 tripleoclient patch that I just approved

Thank you for moving the tripleoclient patch forward. The Workflow-1'd
patch can be ignored, I updated the topic name to avoid confusion.
(The approach was initially rejected but there's been small voices of
"maybe it would be handy after all" coming up afterwards; I'm keeping
it around to do some rework and perhaps re-discuss it at a later
point.)

Thanks,

Julie

__
OpenStack Development Mailing 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] New bug tagging policy

[Julie Pichon]

Hi Steve,

On 25 August 2016 at 23:41, Steve Baker <sba...@redhat.com> wrote:
> On 25/08/16 22:30, Julie Pichon wrote:
>>
>> Hi folks,
>>
>> The bug tagging proposal has merged, behold the new policy:
>>
>>
>> http://specs.openstack.org/openstack/tripleo-specs/specs/policy/bug-tagging.html
>>
>> TL;DR The TripleO Launchpad tracker encompasses a lot of sub-projects,
>> let's use a consistent list of Launchpad tags where they make sense in
>> order to help understand which area(s) are affected. The tags get
>> autocompleted by Launchpad (or will be soon).
>>
>>
>> There is one remaining action to create the missing tags: I don't have
>> bug wrangling permissions on the TripleO project so, if someone with
>> the appropriate permissions could update the list [1] to match the
>> policy I would appreciate it. Should I be deemed trustworthy enough
>> I'm just as happy to do it myself and help out with the occasional
>> bout of triaging as well.
>>
>> Thanks,
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo/+manage-official-tags
>>
> I'm not seeing any tag appropriate for the configuration agent projects
> os-collect-config, os-apply-config, os-refresh-config. Is it possible to add
> a tag like config-agent?

Totally! That list was a start, if you or anyone notices anything
missing feel free to propose a patch against
http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/policy/bug-tagging.rst
.

Thanks,

Julie

__
OpenStack Development Mailing 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] New bug tagging policy

[Julie Pichon]

On 25 August 2016 at 11:47, Swapnil Kulkarni <cools...@gmail.com> wrote:
> On Thu, Aug 25, 2016 at 4:00 PM, Julie Pichon <jpic...@redhat.com> wrote:
>> Hi folks,
>>
>> The bug tagging proposal has merged, behold the new policy:
>>
>> http://specs.openstack.org/openstack/tripleo-specs/specs/policy/bug-tagging.html
>>
>> TL;DR The TripleO Launchpad tracker encompasses a lot of sub-projects,
>> let's use a consistent list of Launchpad tags where they make sense in
>> order to help understand which area(s) are affected. The tags get
>> autocompleted by Launchpad (or will be soon).
>>
>>
>> There is one remaining action to create the missing tags: I don't have
>> bug wrangling permissions on the TripleO project so, if someone with
>> the appropriate permissions could update the list [1] to match the
>> policy I would appreciate it. Should I be deemed trustworthy enough
>> I'm just as happy to do it myself and help out with the occasional
>> bout of triaging as well.
>>
>> Thanks,
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo/+manage-official-tags
>>
>
> Done!

Awesome, thank you!!!

It seems a couple of the tags, like t-h-t don't quite match the names
in the document but well, it's all a start :)

Thanks,

Julie

__
OpenStack Development Mailing 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] [TripleO] New bug tagging policy

[Julie Pichon]

Hi folks,

The bug tagging proposal has merged, behold the new policy:

http://specs.openstack.org/openstack/tripleo-specs/specs/policy/bug-tagging.html

TL;DR The TripleO Launchpad tracker encompasses a lot of sub-projects,
let's use a consistent list of Launchpad tags where they make sense in
order to help understand which area(s) are affected. The tags get
autocompleted by Launchpad (or will be soon).


There is one remaining action to create the missing tags: I don't have
bug wrangling permissions on the TripleO project so, if someone with
the appropriate permissions could update the list [1] to match the
policy I would appreciate it. Should I be deemed trustworthy enough
I'm just as happy to do it myself and help out with the occasional
bout of triaging as well.

Thanks,

Julie

[1] https://bugs.launchpad.net/tripleo/+manage-official-tags

__
OpenStack Development Mailing 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] tripleo-common bugs, bug tracking and launchpad tags

[Julie Pichon]

On 19 July 2016 at 16:20, Steven Hardy <sha...@redhat.com> wrote:
> On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote:
>> Hi,
>>
>> On Friday Dougal mentioned on IRC that he hadn't realised there was a
>> separate project for tripleo-common bugs on Launchpad [1] and that he'd
>> been using the TripleO main tracker [2] instead.
>>
>> Since the TripleO tracker is also used for client bugs (as far as I can
>> tell?), and there doesn't seem to be a huge amount of tripleo-common
>> bugs perhaps it would make sense to also track those in the main
>> tracker? If there is a previous conversation or document about bug
>> triaging beyond [3] I apologise for missing it (and would love a
>> URL!). At the moment it's a bit confusing.
>
> Thanks for raising this, yes there is a bit of a proliferation of LP
> projects, but FWIW the only one I'm using to track coordinated milestone
> releases for Newton is this one:
>
> https://launchpad.net/tripleo/
>
>> If we do encourage using the same bug tracker for multiple components,
>> I think it would be useful to curate a list of official tags [4]. The
>> main advantage of doing that is that the tags will auto-complete so
>> it'd be easier to keep them consistent (and thus actually useful).
>
> +1 I'm fine with adding tags, but I would prefer that we stopped adding
> more LP projects unless the associated repos aren't planned to be part of
> the coordinated release (e.g I don't have to track them ;)
>
>> Personally, I wanted to look through open bugs against
>> python-tripleoclient but people use different ways of marking them at
>> the moment - e.g. [tripleoclient] or [python-tripleoclient] or
>> tripleoclient (or nothing?) in the bug name. I tried my luck at adding
>> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
>> something shorter like 'cli', 'common' would make more sense. If there
>> are other tags that come back regularly it'd probably be helpful to
>> list them explicitly as well.
>
> Sure, well I know that many python-*clients do have separate LP projects,
> but in the case of TripleO our client is quite highly coupled to the the
> other TripleO pieces, in particular tripleo-common.  So my vote is to
> create some tags in the main tripleo project and use that to filter bugs as
> needed.
>
> There are two projects we might consider removing, tripleo-common, which
> looks pretty much unused and tripleo-validations which was recently added
> by the sub-team working on validations.
>
> If folks find either useful then they can stay, but it's going to be easier
> to get a clear view on when to cut a release if we track everything
> considered part of the tripleo deliverable in one place IMHO.

Following up on this and related conversations (e.g. on today's TripleO
meeting), the tripleo-ui team would like to migrate to the main TripleO
tracker as well. It totally makes sense to me, seeing as the UI is just
as dependent on the other TripleO projects. It's a new language but we
already have multiple code bases so what's one more :-) That way the UI
can be more integrated with TripleO during the cycle and related issues
and features will show up during the weekly meeting.

I think there's some Launchpad magic we can use to migrate the bugs,
but I'm not sure if it's possible to move the blueprints themselves. To
avoid distractions when we're so close to Feature Freeze, in my opinion
it might be better to migrate the blueprints after Newton-3 anyway.

If there's no objections, I'll add the 'ui' tag to the bug tagging
policy at [1]. We can start filing new bugs into the TripleO
tracker [2], and blueprint authors can move their outstanding blueprints
when they have a chance.

Thanks,

Julie

[1] https://review.openstack.org/#/c/352852/
[2] https://bugs.launchpad.net/tripleo

> Thanks,
>
> Steve
>
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo-common
>> [2] https://bugs.launchpad.net/tripleo
>> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
>> [4] https://wiki.openstack.org/wiki/Bug_Tags
>> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient

__
OpenStack Development Mailing 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] tripleo-common bugs, bug tracking and launchpad tags

[Julie Pichon]

Thank you for the replies on this thread and apologies for the delay, I
didn't quite grasp what "this should be a policy" actually meant :-)

On 18 July 2016 at 17:23, Ben Nemec <openst...@nemebean.com> wrote:
> On 07/18/2016 06:28 AM, Julie Pichon wrote:
>> Hi,
>>
>> On Friday Dougal mentioned on IRC that he hadn't realised there was a
>> separate project for tripleo-common bugs on Launchpad [1] and that he'd
>> been using the TripleO main tracker [2] instead.
>>
>> Since the TripleO tracker is also used for client bugs (as far as I can
>> tell?), and there doesn't seem to be a huge amount of tripleo-common
>> bugs perhaps it would make sense to also track those in the main
>> tracker? If there is a previous conversation or document about bug
>> triaging beyond [3] I apologise for missing it (and would love a
>> URL!). At the moment it's a bit confusing.
>
> +1.  Given the heavily interconnected nature of tripleo-common,
> tripleoclient, t-h-t, puppet-triple, et al I think it would get a bit
> crazy trying to track bugs with repo-specific trackers.
>
> Rather than use the wiki, whose future is in doubt, I would like to
> propose that this become a policy like
> https://review.openstack.org/#/c/339236/

Thank you for the link. I made a first attempt at a policy over
there [1] based on this thread and taking some inspiration from the
Neutron folks [2]. The initial list is based on existing TripleO tags,
tags that came up in this conversation and the wider OpenStack project
tags. Let me know what you think!

Cheers,

Julie

[1] https://review.openstack.org/#/c/352852/
[2] http://docs.openstack.org/developer/neutron/policies/bugs.html#tagging-bugs

>> If we do encourage using the same bug tracker for multiple components,
>> I think it would be useful to curate a list of official tags [4]. The
>> main advantage of doing that is that the tags will auto-complete so
>> it'd be easier to keep them consistent (and thus actually useful).
>>
>> Personally, I wanted to look through open bugs against
>> python-tripleoclient but people use different ways of marking them at
>> the moment - e.g. [tripleoclient] or [python-tripleoclient] or
>> tripleoclient (or nothing?) in the bug name. I tried my luck at adding
>> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
>> something shorter like 'cli', 'common' would make more sense. If there
>> are other tags that come back regularly it'd probably be helpful to
>> list them explicitly as well.
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo-common
>> [2] https://bugs.launchpad.net/tripleo
>> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
>> [4] https://wiki.openstack.org/wiki/Bug_Tags
>> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient

__
OpenStack Development Mailing 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] [TripleO] tripleo-common bugs, bug tracking and launchpad tags

[Julie Pichon]

Hi,

On Friday Dougal mentioned on IRC that he hadn't realised there was a
separate project for tripleo-common bugs on Launchpad [1] and that he'd
been using the TripleO main tracker [2] instead.

Since the TripleO tracker is also used for client bugs (as far as I can
tell?), and there doesn't seem to be a huge amount of tripleo-common
bugs perhaps it would make sense to also track those in the main
tracker? If there is a previous conversation or document about bug
triaging beyond [3] I apologise for missing it (and would love a
URL!). At the moment it's a bit confusing.

If we do encourage using the same bug tracker for multiple components,
I think it would be useful to curate a list of official tags [4]. The
main advantage of doing that is that the tags will auto-complete so
it'd be easier to keep them consistent (and thus actually useful).

Personally, I wanted to look through open bugs against
python-tripleoclient but people use different ways of marking them at
the moment - e.g. [tripleoclient] or [python-tripleoclient] or
tripleoclient (or nothing?) in the bug name. I tried my luck at adding
a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
something shorter like 'cli', 'common' would make more sense. If there
are other tags that come back regularly it'd probably be helpful to
list them explicitly as well.

Julie

[1] https://bugs.launchpad.net/tripleo-common
[2] https://bugs.launchpad.net/tripleo
[3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
[4] https://wiki.openstack.org/wiki/Bug_Tags
[5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient

__
OpenStack Development Mailing 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] Stepping down as a Horizon core reviewer

[Julie Pichon]

Hi folks,

In the spirit of stepping down considerately [1], I'd like to ask to be
removed from the core and drivers team for Horizon and associated
projects. I'm embarking on some fun adventures far far away and won't
have any time to spare for OpenStack for a while.

I removed my name from places in the wiki where I was a point of
contact. Some activities I was involved with are left in good hands
already, but that does leave a couple more Cross-Project Liaisons [2]
spots now empty for Horizon. If you're interested in helping out as the
Horizon docs liaison (answer questions from the docs team, bonus points
for following the horizon tag in the openstack-manuals tracker) or QA
liaison (particular interest in integration testing and seeing
where/how our test suite might fit in with Tempest someday?), please
step up! Don't let all the tasks fall back onto the PTL :-)

Working on OpenStack and Horizon has been enlightening and
humbling. Thank you for the ride everyone, and wishing y'all all the
best! :)

Julie

[1] http://www.openstack.org/legal/community-code-of-conduct/
[2] https://wiki.openstack.org/wiki/CrossProjectLiaisons

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

[Julie Pichon]

On 26/01/15 06:34, A mailing list for the OpenStack Stable Branch test
reports. wrote:
 Build failed.
 
 - periodic-horizon-docs-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-icehouse/9382030/
  : SUCCESS in 4m 14s
 - periodic-horizon-python26-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-icehouse/b39cce4/
  : FAILURE in 2m 53s
 - periodic-horizon-python27-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-icehouse/2381739/
  : FAILURE in 3m 09s
 - periodic-horizon-docs-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-juno/3e9efb0/ 
 : SUCCESS in 5m 01s
 - periodic-horizon-python26-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-juno/efc60ca/
  : FAILURE in 3m 19s
 - periodic-horizon-python27-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-juno/59627d3/
  : FAILURE in 2m 22s

This is being debugged at
https://bugs.launchpad.net/horizon/+bug/1413876 , the patch for
django_openstack_auth is merging. Once a new version of the library is
released that includes the fix, this should resolve the problem on all
branches without the need for backports.

Cheers,

Julie



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

[Julie Pichon]

On 26/01/15 10:49, Ihar Hrachyshka wrote:
 On 01/26/2015 11:00 AM, Julie Pichon wrote:
 On 26/01/15 06:34, A mailing list for the OpenStack Stable Branch test
 reports. wrote:
 Build failed.

 - periodic-horizon-docs-icehouse
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-icehouse/9382030/
 : SUCCESS in 4m 14s
 - periodic-horizon-python26-icehouse
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-icehouse/b39cce4/
 : FAILURE in 2m 53s
 - periodic-horizon-python27-icehouse
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-icehouse/2381739/
 : FAILURE in 3m 09s
 - periodic-horizon-docs-juno
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-juno/3e9efb0/
 : SUCCESS in 5m 01s
 - periodic-horizon-python26-juno
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-juno/efc60ca/
 : FAILURE in 3m 19s
 - periodic-horizon-python27-juno
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-juno/59627d3/
 : FAILURE in 2m 22s
 This is being debugged at
 https://bugs.launchpad.net/horizon/+bug/1413876 , the patch for
 django_openstack_auth is merging. Once a new version of the library is
 released that includes the fix, this should resolve the problem on all
 branches without the need for backports.
 
 
 Should we also update openstack/requirements for all branches not to
 pick the failing version of the library?

There was a brief discussion about setting an upper limit pin, but a
negative version pin to avoid the broken release would be a lot
cleaner indeed. I'll prepare the patches. Thanks!

Julie


__
OpenStack Development Mailing 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] Integration tests on the gate

[Julie Pichon]

On 25/11/14 13:55, Julie Pichon wrote:
 Hi folks,
 
 You may have noticed a new job in the check queue for Horizon patches,
 gate-horizon-dsvm-integration. This job runs the integration tests suite
 from our repository. [1]
 
 The job is marked as non-voting but *it is meant to pass.* The plan is
 to leave it that way for a couple of weeks to make sure that it is
 stable. After that it will become a voting job.

After delaying due to an intermittent bug [1], it seems like the bug
stopped occurring (from checking now as well as before the holidays), so
I submitted the patch to switch the job to voting [2].

Cheers,

Julie

 [1] https://bugs.launchpad.net/horizon/+bug/1396194
 [2] https://review.openstack.org/#/c/145477/

 
 What to do if the job fails
 ---
 
 If you notice a failure, please look at the logs and make sure that it
 wasn't caused by your patch. If it doesn't look related or if you're not
 sure how to interpret the results, please ask on #openstack-horizon or
 reply to this thread. We really want to avoid people getting used to the
 job failing, getting annoyed at it and/or blindly rechecking. If there
 are any intermittent or strange issue we'll postpone making the job
 voting, but we need to know about it so we can investigate and fix them.
 
 How to help
 ---
 
 If you'd like to help, you're very welcome to do so either by reviewing
 new tests [2] or writing more of them [3]. As with everywhere else, all
 help is very welcome and review attention is particularly appreciated!
 
 I'm really looking forward to having the integration tests be part of
 the main voting gate and for us improve the coverage. I'd really like to
 thank in particular Daniel Korn and Tomáš Nováčik for their huge efforts
 on these tests over the past year.
 
 Thanks,
 
 Julie
 
 
 [1]
 https://github.com/openstack/horizon/tree/master/openstack_dashboard/test/integration_tests
 [2] https://wiki.openstack.org/wiki/Horizon/Testing/UI#Writing_a_test
 [3]
 https://review.openstack.org/#/q/project:openstack/horizon+file:%255E.*/integration_tests/.*+status:open,n,z
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [stable] Stable check of openstack/horizon failed

[Julie Pichon]

On 02/01/15 06:15, A mailing list for the OpenStack Stable Branch test
reports. wrote:
 Build failed.
 
 - periodic-horizon-docs-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-icehouse/b0d18a6/
  : SUCCESS in 4m 35s
 - periodic-horizon-python26-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-icehouse/b38b4c9/
  : FAILURE in 3m 23s
 - periodic-horizon-python27-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-icehouse/147df74/
  : FAILURE in 3m 42s
 - periodic-horizon-docs-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-docs-juno/f5e1427/ 
 : SUCCESS in 5m 19s
 - periodic-horizon-python26-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python26-juno/ef680e0/
  : FAILURE in 6m 34s
 - periodic-horizon-python27-juno 
 http://logs.openstack.org/periodic-stableperiodic-horizon-python27-juno/890ebda/
  : FAILURE in 4m 26s

This is due to https://bugs.launchpad.net/horizon/+bug/1407055 , the fix
for master just merged and the Juno and Icehouse backports are up for
review at https://review.openstack.org/#/c/144736/ and
https://review.openstack.org/#/c/144735/ respectively. Thanks!

Julie


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

[openstack-dev] [horizon] Integration tests on the gate

[Julie Pichon]

Hi folks,

You may have noticed a new job in the check queue for Horizon patches,
gate-horizon-dsvm-integration. This job runs the integration tests suite
from our repository. [1]

The job is marked as non-voting but *it is meant to pass.* The plan is
to leave it that way for a couple of weeks to make sure that it is
stable. After that it will become a voting job.

What to do if the job fails
---

If you notice a failure, please look at the logs and make sure that it
wasn't caused by your patch. If it doesn't look related or if you're not
sure how to interpret the results, please ask on #openstack-horizon or
reply to this thread. We really want to avoid people getting used to the
job failing, getting annoyed at it and/or blindly rechecking. If there
are any intermittent or strange issue we'll postpone making the job
voting, but we need to know about it so we can investigate and fix them.

How to help
---

If you'd like to help, you're very welcome to do so either by reviewing
new tests [2] or writing more of them [3]. As with everywhere else, all
help is very welcome and review attention is particularly appreciated!

I'm really looking forward to having the integration tests be part of
the main voting gate and for us improve the coverage. I'd really like to
thank in particular Daniel Korn and Tomáš Nováčik for their huge efforts
on these tests over the past year.

Thanks,

Julie


[1]
https://github.com/openstack/horizon/tree/master/openstack_dashboard/test/integration_tests
[2] https://wiki.openstack.org/wiki/Horizon/Testing/UI#Writing_a_test
[3]
https://review.openstack.org/#/q/project:openstack/horizon+file:%255E.*/integration_tests/.*+status:open,n,z

___
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

[Julie Pichon]

On 14/11/14 15:46, Wood, Matthew David (HP Cloud - Horizon) wrote:
 On 11/14/14, 4:24 AM, Jaromir Coufal jcou...@redhat.com wrote:

 My opinion and preference:
 * horizon_lib (framework) + horizon (UI)
 
 I agree with both the concept behind these names and the name selections
 given here.  People don¹t think of Nova as the framework, nor Neutron as
 the framework.  That¹s the server/service that we make rest calls against.
  I like:
 
 (horizon_lib or horizon_framework) and horizon

The concern with this raised by Matthias is that application developers
who currently do import horizon to build plug-ins will be surprised
and completely broken once they upgrade. Changing both names would
alleviate that a little.

Julie

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


___
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

[Julie Pichon]

On 12/11/14 15:12, Jiri Tomasek wrote:
 Approach on using Xstatic packages vs Js tooling:
 
 As only problem with using js tooling should be just actual packaging of
 it, I think it makes sense to use these tools and make development
 simpler then going other way around and using Xstatic packages - which
 means devs would have to care about getting stuff packaged as xstatic
 and added to the code, while maintaining proper versions and making sure
 that they work ok together. NPM and Bower do this for us. Common sense
 tells me packagers should take care of packaging.
 Packaging of these tools will have to get resolved somehow anyway, as
 there will be rise in requirements of using them not just from Horizon...

I can't speak for the rest but that part doesn't seem correct to me. The
XStatic packages are Python packages (as in, dependencies) that the
Horizon team is responsible for (when they don't already exist) and
maintains on stackforge, so we do have to create them and make sure they
all work well together. The later packaging as rpm or deb or others is
left to the distro packagers of course.

There are instructions already on how to create xstatic packages [1],
it's not very complicated and just takes some review time.

Thanks,

Julie

[1]
http://docs.openstack.org/developer/horizon/contributing.html#javascript-and-css-libraries


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

Re: [openstack-dev] [horizon] Passing multiple values in table.Column in Horizon DataTable

[Julie Pichon]

On 19/10/14 12:52, Rajdeep Dua wrote:
 Hi,
 I need to pass two values in the link generated from the table.Column as
 shown below.
 
 
 class DatasourcesTablesTable(tables.DataTable):
 data_source = tables.Column(column1, verbose_name=_(Column1))
 id = tables.Column(id, verbose_name=_(ID),
link=horizon:admin:path1:path2:rows_table )
 
  The existing link gets value of id in kwargs
 Also need to pass value of column1.
 
 Any pointers on how this can be done would be helpful

You should be able to do this by calling to a function instead of
hardcoding the link directly. That'll give you the flexibility to use
whatever attributes you want for building up the url. You can see an
example in the EventsTable on the stacks panel [1] on the
logical_resource column.

Hope this helps,

Julie

[1]
https://github.com/openstack/horizon/blob/2a9349bd67/openstack_dashboard/dashboards/project/stacks/tables.py#L131

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


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

Re: [openstack-dev] [All] [I18N] compiling translation message catalogs

[Julie Pichon]

I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE
packaging: the Horizon team would love to have your opinion on this (it
came up during our weekly meeting).

The current consensus is leaning toward removing the mo files for Juno
RC2 (in a couple of days) rather than wait until Kilo, as this has been
a pain point for (some/all?) distros for a while.

Thank you,

Julie

On 01/10/14 17:04, Akihiro Motoki wrote:
 Hi,
 
 To display localized strings, we need to compile translated message
 catalogs (PO files) into compiled one (MO files).
 I would like to discuss and get a consensus who and when generate
 compiled message catalogs.
 Inputs from packagers are really appreciated.
 
 [The current status]
 * Horizon contains compile message catalogs in the git repo. (It is
 just a history and there seems no strong reason to have compiled one
 in the repo. There is a bug report on it.)
 * Other all projects do not contain compiled message catalogs and have
 only PO files.
 
 [Possible choices]
 I think there are several options. (there may be other options)
 (a) OpenStack does not distribute compiled message catalogs, and only
 provides a command (setup.py integration) to compile message catalogs.
 Deployers or distributors need to compile message catalogs.
 (b) Similar to (a), but compile message catalogs as a part of pip install.
 (c) OpenStack distributes compiled message catalogs as a part of the release.
 (c1) the git repo maintains compiled message catalogs.
 (c2) only tarball contains compiled message catalogs
 
 Note that the current Horizon is (c1) and others are (a).
 
 [Pros/Cons]
 (a) It is a simplest way as OpenStack upstream.
  Packagers need to compile message catalogs and customize there scripts.
  Deployers who install openstack from the source need to compile them too.
 (b) It might be a simple approach from users perspective. However to compile
  message catalogs during installation, we need to install required modules
  (like babel or django) before running installation (or require
 them as the first
   citizen in setup.py require). I don't think it is much simpler
 compared to
   option (a).
 (c1) Compiled message catalogs are a kind of binary files and they can
   be generated from PO files. There is no need to manage two same data.
 (c2) OpenStack is downloaded in several ways (release tarballs is not the
   only option), so I don't see much merits that the only tarball contains
   compiled message catalogs. A merit is that compiled message catalogs
   are available and there is no additional step users need to do.
 
 My preference is (a), but would like to know broader opinions
 especially from packagers.
 
 Thanks,
 Akihiro
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] Having a problem regarding git review.

[Julie Pichon]

On 24/09/14 07:48, Tahmina Ahmed wrote:
 Hi,
 
 I am a newbie to openstack. I am just trying to submit my first fix but I
 am having problem to update my contact information. Without  contact
 information I cannot issue git review command. When I put my contact
 information in  https://review.openstack.org/#/settings/contact it shows
 
 
 Code Review - Error
 Server Error
 Cannot store contact information
 
 FYI : I have removed all the special characters from my contact information
 but still it is showing same.
 
 Has anyone faced this problem?

Hello Tahmina, and welcome!

This reminds me of the bug at [1], did you join the Foundation before
creating your Gerrit account? I believe this needs to be done first (and
make sure the email addresses match).

Hopefully this helps,

Julie

[1] https://bugs.launchpad.net/openstack-ci/+bug/1346833

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


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

Re: [openstack-dev] [horizon] Support for Django 1.7: there's a bit of work, though it looks fixable to me...

[Julie Pichon]

On 05/08/14 08:11, Thomas Goirand wrote:
 And there's also test_change_password_shows_message_on_login_page which
 fails. Here's the end of the stack dump:
 
   File /usr/lib/python2.7/dist-packages/requests/adapters.py, line
 375, in send
 raise ConnectionError(e, request=request)
 ConnectionError: HTTPConnectionPool(host='public.nova.example.com',
 port=8774): Max retries exceeded with url: /v2/extensions (Caused by
 class 'socket.gaierror': [Errno -2] Name or service not known)

This particular test is currently being skipped [1] due to issues with
the test itself. It's going to be replaced by an integration test.

Julie

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


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

Re: [openstack-dev] Mentor program?

[Julie Pichon]

On 23/07/14 18:29, Joshua Harlow wrote:
 Hi all,
 
 I was reading over a IMHO insightful hacker news thread last night:
 
 https://news.ycombinator.com/item?id=8068547
 
 Labeled/titled: 'I made a patch for Mozilla, and you can do it too'
 
 It made me wonder what kind of mentoring support are we as a
 community offering to newbies (a random google search for 'openstack
 mentoring' shows mentors for GSoC, mentors for interns, outreach for
 women... but no mention of mentors as a way for everyone to get
 involved)?

People listed various initiatives and plans in other replies, I'd like
to mention again OpenHatch which I talked a little bit about on the list
before [1]. Some projects like Horizon are set up on it, together with a
list of mentors. The folks that contacted us through OpenHatch had
usually never contributed to open-source before.

I agree mentoring is an excellent way to get people involved with the
community!

Julie

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026931.html


 Looking at the comments in that hacker news thread, the article
 itself it seems like mentoring is stressed over and over as the way
 to get involved.
 
 Has there been ongoing efforts to establish such a program (I know
 there is training work that has been worked on, but that's not
 exactly the same).
 
 Thoughts, comments...?
 
 -Josh ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
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

[Julie Pichon]

On 20/06/14 22:17, Lyle, David wrote:
 I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core.
 
 Zhenguo has been a prolific reviewer for the past two releases providing
 high quality reviews. And providing a significant number of patches over
 the past three releases.
 
 Ana has been a significant reviewer in the Icehouse and Juno release
 cycles. She has also contributed several patches in this timeframe to both
 Horizon and tuskar-ui.
 
 Please feel free to respond in public or private your support or any
 concerns.

+1 to both!

Julie


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


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

Re: [openstack-dev] [Horizon][dashboards] Running the 'profile' specific unit tests

[Julie Pichon]

On 24/04/14 16:05, Abishek Subramanian (absubram) wrote:
 Just to add to this - Akihiro did mention the usage of @override_settings
 I've seen examples of this in existing unit tests and I can implement
 something 
 similar. 
 
 This will mean however that we will have the test with the default setting
 and then the same test again with the override which accepts the
 profile_id yes?

That's fine. We do this in places already, for example for testing with
and without domains [1] or with different services or extensions enabled
[2] [3].

Julie


[1]
https://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/admin/users/tests.py
[2]
https://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/overview/tests.py#n321
[3]
https://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/overview/tests.py#n275


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

Re: [openstack-dev] [Horizon] Accessibility

[Julie Pichon]

Hi Doug,

On 24/04/14 16:06, Douglas Fish wrote:
 
 I've proposed a design session for accessibility for the Juno summit, and
 I'd like to get a discussion started on the work that needs to be done.
 (Thanks Julie P for pushing that!)

Thanks for starting the conversation!

 I've started to add information to the wiki that Joonwon Lee created:
 https://wiki.openstack.org/wiki/Horizon/WebAccessibility
 I think that's going to be a good place to gather material.  I'd like to
 see additional information added about what tools we can use to verify
 accessibility.  I'd like to try to summarize the WCAG guidelines into some
 broad areas where Horzion needs work.  I expect to add a checklist of
 accessibility-related items to consider while reviewing code.

This is a really good action item, the Review Checklist [1] definitely
needs to be updated with Horizon-specific items.

 Joonwon (or anyone else with an interest in accessibility):  It would be
 great if you could re-inspect the icehouse level code and create bugs for
 any issues that remain.  I'll do the same for issues that I am aware of.
 In each bug we should include a link to the WCAG guideline that has been
 violated.  Also, we should describe the testing technique:  How was this
 bug discovered?  How could a developer (or reviewer) determine the issue
 has actually been fixed?  We should probably put that in each bug at first,
 but as we go they should be gathered up into the wiki page.

That sounds very reasonable to me as well. Making it clear to developers
and reviewers why something is needed (and how to check it's fixed) will
be very helpful as we learn to watch out for the issues around this.

 There are some broad areas of need that might justify blueprints (I'm
 thinking of WAI-ARIA tagging, and making sure external UI widgets that we
 pull in are accessible).

That sounds already like a good item for the Review Checklist: things to
keep in mind when pulling in new Javascript libraries, since these tend
to happen independently of the requirements repository. I'm thinking of
a recent case where a JS library was later discovered not to be localised.

 Any suggestions on how to best share info, or organize bugs and blueprints
 are welcome!

The wiki page is great work already, with specific links to different
types of issues and why they're important. Definitely should be linked
from the review checklist (perhaps once we have better foundations for
accessibility?).

From your understanding of the work to be done based on earlier
inspections of the code, do you think we should start with a largeish
blueprint that gets us to a reasonable-though-not-yet-perfect state, or
will this be workable as a series of independent bugs?

Either way it'd probably be nice to have an overall blueprint that links
to the different bugs so interested parties can track the work and know
where to help if they wish to.

I'm looking forward to the session! I'll be doing some reading before
that, thanks for linking again to that wiki page.

Julie

[1] https://wiki.openstack.org/wiki/ReviewChecklist

 
 Doug Fish
 IBM STG Cloud Solution Development
 T/L 553-6879, External Phone 507-253-6879
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [Ironic] detailed git commit messages

[Julie Pichon]

On 28/04/14 12:52, Roman Prykhodchenko wrote:
 That seems to be reasonable to me.
 
 Perhaps we should define a more or less formal format for commit 
 messages? That might
 both help newcomers to write them make it easier for us to write 
 sensible What's changed
 documents basing on those commit messages.

I usually point newcomers to [1] though the whole page is excellent.

[1]
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure


 
 
 - Roman
 
 


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

Re: [openstack-dev] [UX] Proposed tools and workflows for OpenStack User Experience contributors

[Julie Pichon]

Hi Liz and Jarda,

Very happy to see this discussion happen! We regularly have people show
up who are interested in helping to improve the Horizon UX and it's good
to know where to direct them for more information. Great job with the wiki!

On 23/04/14 15:46, Liz Blanchard wrote:
 On Apr 23, 2014, at 8:13 AM, Jaromir Coufal jcou...@redhat.com
 wrote:
 Mailing list - [UX] --- = discussions about various
 issues = openstack-dev mailing list, using [UX] tag in the subject 
 + brings more attention to the UX issues + not separated from
 other OpenStack's projects + threading is already there (e-mail
 clients) + no need for setting up and maintaining additional
 server to run our own forum - requires to store attachments
 somewhere else (some other server) ... similar case with current
 askbot anyway - requires contributors to register to the
 openstack-dev mailing list ... each contributor should do that
 anyway
 
 A big +1 to this. Currently there is a mailing list called
 openstack-personas that has been meant just for the persona effort,
 but I’ve been trying to get folks who have been involved in that
 effort to be sure to subscribe to this list and start generating any
 conversations that are pure UX here on the dev list instead of that
 personas mailing list. The personas mailing list was really just
 meant to kick off all of the work that would be done and then we’d
 bring high level details to this list anyways. Having more or less
 all UX conversations in one place makes way more sense to me.

I also think it would be good to have the discussions on the dev list to
help with the problem of much less visibility when taking the
conversation elsewhere. Could the personas list perhaps be deleted now
and the work around it continue on the dev list as well? (Probably at
the same time as providing advice on filtering!)

 Discussion forum - (terminate) -- +
 more interactive + easier for newcomers - separating UX outside
 the OpenStack world - we haven't found any other suitable tool
 for discussions yet (current AskBot is not doing very well) - in
 order not to fragment discussions into multiple places, I am
 suggesting termination of current AskBot and keeping discussions in
 mailing list
 
 Another idea would be to use the general OpenStack Askbot, but I
 agree it is yet another place to go to review things and the current
 way of using Askbot has been difficult to keep up with and follow
 active discussions. +1 to finding a way to use the mailing list
 efficiently for design reviews.

I don't think the general AskBot would be appropriate to use for this,
it has a very different goal (user troubleshooting) as opposed to being
a tool to help with future development.

On Ask UX, I found it difficult to understand the status of older
questions that seem resolved (but actually aren't) and not implemented
yet, I would welcome a better way to understand e.g. the current status
of the Horizon IA work. Perhaps a wiki page that summarises a discussion
would help, at the end of a ML conversation...? Definitely the Launchpad
blueprints / bugs around UX issues should include a reference to the
related ML discussion.

 IRC meetings  = regular meetings, each 2-3 weeks, short
 meeting, mostly dealing with organizational stuff and bringing
 attention on hot topics + brings people together + helps with
 UX organization - requires people to make a time for it ...
 should be short though, so it shouldn't be big deal
 
 Again, a huge +1 from me. I think this is the biggest thing that we
 are missing as a UX community. It will definitely help with
 organization and communication on who is actively working on what.
 Agreed they should be short and shouldn’t be a big time commitment to
 those who are active in UX in the community.

I agree this would be very helpful. When Horizon started having regular
meetings, it really helped with building a stronger sense of community.
Definitely worth experimenting with!

 Wishlist (currently Launchpad) -- =
 list of areas where other projects need a help from UX and UX
 person can take tasks + easy way of other teams how to interact
 with UX team when they look for a help + easy way for UXers to
 see areas where is a need for help
 
 +1. There could also be a section on the wiki describing the process
 of contacting the UX team around work that is needed for components
 and adding items to the launchpad list.

+1 to clearly defining how to ask for UX help and advice, whatever it
ends up being :)

 Storage place (GitHUb) -- = server where we can
 store temporary materials as well as final solutions - github for
 permanent solutions (guidelines, final designs, …)?
 
 I like this idea. I think we just need to try it out like we did with
 AskBot and see how it goes. How will GitHub handle the large files
 that designs produce? Will pure designers be able to fit Git into
 their workflow 

Re: [openstack-dev] Congrats and welcome to OPW interns!

[Julie Pichon]

On 22/04/14 23:00, Anne Gentle wrote:
 Hi all,
 I want to warmly welcome our new interns joining us through the GNOME
 Outreach Program for Women. Here's a little bit of information about the
 participants and their projects.
 
 Virginia Gresham is in Guilford, CT and Deer Isle, ME (east coast US,
 represent!) She'll work on a persona research and design project for the
 Horizon dashboard. That'll include Horizon usability tests. Liz Blanchard
 and Ju Lim are her mentors.
 
 Ana Malagon will work out of New Haven, CT doing period-spanning statistics
 for Ceilometer with mentor Eoghan Glynn.
 
 Nataliia Uvarova (AAzza on IRC) is in Gjøvik, Norway and Kiev, Ukraine
 (that's a commute to me, maybe I will check that geography).  She'll work
 on Py3K support in Marconi with Flavio Percoco and Alejandro Cabrera.

Congratulations on getting accepted everyone, and welcome to the
OpenStack community! I hope to see you around on IRC and that you'll
find your internship to be both productive and fun. Don't hesitate to
ask questions!

 I also want to show our appreciation to the mentors who worked with many
 applicants and who did such a great job gathering projects and getting
 first patches submitted and reviewed. Julie Pichon especially shone while
 sorting through the many applicants and working with other organizations
 who also get great interns through this program. One of our prior interns,
 Terri Yu, did a fantastic job helping applicants and recruiting great
 people for OpenStack. I know there are many more who helped this round and
 I can't say enough about what super humans we have here.

Thanks Anne :)

 The official announcement is here:
 https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#OpenStack
 
 With OPW and GSoC, we have 10 interns with many more mentors working on
 OpenStack. This is fantastic! Thanks everyone who is making these programs
 a reality for our community.

Agreed! Many thanks especially to the mentors for volunteering their
time and being so helpful.

Cheers,

Julie

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


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

Re: [openstack-dev] OpenStack/GSoC - Welcome!

[Julie Pichon]

On 21/04/14 22:15, Davanum Srinivas wrote:
 Hi Team,
 
 Please join me in welcoming the following students to our GSoC program
 [1]. Congrats everyone. Now the hard work begins :) Have fun as well.
 
 Artem Shepelev
 Kumar Rishabh
 Manishanker Talusani
 Masaru Nomura
 Prashanth Raghu
 Tzanetos Balitsaris
 Victoria Martínez de la Cruz

Congratulations and welcome, everyone! I hope you have a very
interesting summer with OpenStack.

It's really great to see OpenStack participate in GSoC. Thanks to all
the people who helped make it happen!

Julie


 
 -- dims
 
 [1] https://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] Quota Management

[Julie Pichon]

On 03/04/14 23:20, Jay Pipes wrote:
 On Thu, 2014-04-03 at 14:41 -0500, Kevin L. Mitchell wrote:
 On Thu, 2014-04-03 at 19:16 +, Cazzolato, Sergio J wrote:
 Jay, thanks for taking ownership on this idea, we are really
 interested to contribute to this, so what do you think are the next
 steps to move on?

 Perhaps a summit session on quota management would be in order?
 
 Done:
 
 http://summit.openstack.org/cfp/details/221

Thank you for proposing the session, I'm hopeful having this in the new
cross-project track will have a positive impact on the discussion. I'm
under the impression that this comes back regularly as a session topic
but keeps hitting barriers when it comes to actual implementation
(perhaps because important stakeholders were missing from the session
before).

I'd like to bring up the cross-project discussion from last time this
was discussed in December [1] as a reference, since the same
questions/objections will likely come back again. One of the main issues
was that this shouldn't live in Keystone, which could be resolved by
using Boson, but the rest shows a reluctance from the projects to
delegate quota management, and uncertainty around the use cases. Oslo
was also mentioned as a possible place to help with improving the
consistency.

I'd love a more consistent way to handle and manage quotas across
multiple projects as this would help Horizon too, for very similar
reasons than are mentioned here.

Thanks,

Julie

[1]
http://eavesdrop.openstack.org/meetings/project/2013/project.2013-12-10-21.02.log.html
from 21:10

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


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

[openstack-dev] [depfreeze] [horizon] Exception request: python-keystoneclient=0.7.0

[Julie Pichon]

Hi,

I would like to request a depfreeze exception to bump up the keystone
client requirement [1], in order to reenable the ability for users to
update their own password with Keystone v3 in Horizon in time for
Icehouse [2]. This capability is requested by end-users quite often but
had to be deactivated at the end of Havana due to some issues that are
now resolved, thanks to the latest keystone client release. Since this
is a library we control, hopefully this shouldn't cause too much trouble
for packagers.

Thank you for your consideration.

Julie


[1] https://review.openstack.org/#/c/83287/
[2] https://review.openstack.org/#/c/59918/

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

Re: [openstack-dev] [depfreeze] [horizon] Exception request: python-keystoneclient=0.7.0

[Julie Pichon]

On 27/03/14 14:46, Sergey Lukjanov wrote:
 NOTE: It's approved now.

Thanks everyone!

Julie

 
 On Thu, Mar 27, 2014 at 6:12 PM, Mark McLoughlin mar...@redhat.com wrote:
 On Thu, 2014-03-27 at 13:53 +, Julie Pichon wrote:
 Hi,

 I would like to request a depfreeze exception to bump up the keystone
 client requirement [1], in order to reenable the ability for users to
 update their own password with Keystone v3 in Horizon in time for
 Icehouse [2]. This capability is requested by end-users quite often but
 had to be deactivated at the end of Havana due to some issues that are
 now resolved, thanks to the latest keystone client release. Since this
 is a library we control, hopefully this shouldn't cause too much trouble
 for packagers.

 Thank you for your consideration.

 Julie


 [1] https://review.openstack.org/#/c/83287/
 [2] https://review.openstack.org/#/c/59918/

 IMHO, it's hard to imagine that Icehouse requiring a more recent version
 of keystoneclient being a problem or risk for anyone.

 Mark.


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


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

Re: [openstack-dev] [depfreeze][horizon] Exception for lesscpy=0.10.1

[Julie Pichon]

On 26/03/14 12:14, Sascha Peilicke wrote:
 Hi,
 
 there's been a review up for some time [0] that wants to raise the version of 
 lesscpy to 0.10.1. It's specific to horizon and contains some important fixes 
 that we'll likely want to include. So I'd like to ask for an exception for 
 this one.
 
 [0] https://review.openstack.org/#/c/70619/
 

The review comments indicate this is needed for Bootstrap 3, which was
deferred to Juno. Is it needed for something else in Icehouse? Is
something broken without it? If not, it seems to me it's probably ok to
merge only at the beginning of Juno.

Otherwise, apparently I've been running with 0.10.1 in some of my VMs
for a few weeks and didn't notice any problems, FWIW. It also has the
advantage of being a proper release as opposed to beta.

Thanks,

Julie


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

Re: [openstack-dev] [horizon] Selenium (which is non-free) is back again in Horizon (Icehouse Beta 3)

[Julie Pichon]

On 14/03/14 11:31, Thomas Goirand wrote:
 Hi,
 
 A few months ago, I raised the fact that Selenium *CANNOT* be a hard
 test-requirements.txt build-dependency of Horizon, because it is
 non-free (because of binaries like the browser plug-ins not being
 build-able from source). So it was removed.
 
 Now, on the new Icehouse beta 3, it's back again, and I get some unit
 tests errors (see below).
 
 Guys, could we stop having this kind of regressions, and make Selenium
 tests not mandatory? They aren't runnable in Debian.

We're aware of the issue, a fix [1] was merged in RC1 if that helps.

Julie

[1] https://bugs.launchpad.net/horizon/+bug/1289270

 
 Cheers,
 
 Thomas Goirand (zigo)
 
 ==
 ERROR: Failure: ImportError (No module named selenium)
 --
   File openstack_dashboard/test/integration_tests/helpers.py, line 17,
 in module
 import selenium
 ImportError: No module named selenium
 
 ==
 ERROR: Failure: ImportError (No module named selenium.webdriver.common.keys)
  File openstack_dashboard/test/integration_tests/tests/test_login.py,
 line 15, in module
 import selenium.webdriver.common.keys as keys
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [I18n][Horizon] I18n compliance test string freeze exception

[Julie Pichon]

On 13/03/14 09:28, Akihiro Motoki wrote:
 +1
 
 In my understanding String Freeze is a SOFT freeze as Daisy describes.
 Applying string freeze to incorrect or incomprehensible messages is
 not good from UX point of view
 and shipping the release with such strings will make the situation
 worse and people feel OpenStack is not mature
 and can misunderstand OpenStack doesn't care for such detail :-(
 
 From my experience of working as a translator and bridging Horizon and
 I18N community
 in the previous releases, the proposed policy sounds good and it can
 be accepted by translators.

That sounds good to me as well. I think we should modify the
StringFreeze page [1] to reflect this, as it sounds a lot more strict
than what the translation team actually wishes for.

Thanks,

Julie

[1] https://wiki.openstack.org/wiki/StringFreeze

 Thanks,
 Akihiro
 
 
 On Thu, Mar 13, 2014 at 5:41 PM, Ying Chun Guo guoyi...@cn.ibm.com wrote:
 Hello, all

 Our translators start translation and I18n compliance test since string
 frozen date.
 During the translation and test, we may report bugs.
 Some bugs are incorrect and incomprehensible messages.
 Some bugs are user facing messages but not marked with _().
 All of these bugs might introduce string changes and add new strings to be
 translated.
 I noticed some patches to fix these bugs got -1 because of string freeze.
 For example, https://review.openstack.org/#/c/79679/
 and https://review.openstack.org/#/c/79948/

 StringFreeze - Start translation  test - Report bugs which may cause
 string changes - Cannot fix these bugs because of StringFreeze.
 So I'd like to bring this question to dev: when shall we fix these errors
 then?

 From my point of view, FeatureFreeze means not accept new features, and
 doesn't mean cannot fix bugs in features.
 StringFreeze should mean not to add new strings. But we could be able to
 improve strings and fix bugs.
 I think shipping with incorrect messages is worse than strict string freeze.

 From my experiences in Havana release, since StringFreeze, there are
 volunteers from Horizon team who would
 keep an eye on strings changes. If string changes happen, they would send
 email
 to I18n ML to inform these changes. Many thanks to their work.
 In Havana release, we kept on those kind of bug reporting and fixing till
 RC2.
 Most of them are happened before RC1.

 Now I hope to hear your input to this situation: when and how should we fix
 these kind of bugs in Icehouse?

 Best regards
 Ying Chun Guo (Daisy)


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

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


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

Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core

[Julie Pichon]

On 05/03/14 22:36, Lyle, David wrote:
 I'd like to nominate Radomir Dopieralski to Horizon Core.  I find his
 reviews very insightful and more importantly have come to rely on
 their quality. He has contributed to several areas in Horizon and he
 understands the code base well.  Radomir is also very active in
 tuskar-ui both contributing and reviewing.

+1 from me. I find Radomir's reviews useful, and highly value the deep
knowledge of Python shown in both his patches and reviews. He would make
a great addition to the core team.

Julie

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


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

Re: [openstack-dev] Interested in attracting new contributors?

[Julie Pichon]

Dolph Mathews dolph.math...@gmail.com wrote:
 On Wed, Feb 12, 2014 at 8:30 AM, Julie Pichon jpic...@redhat.com wrote:
 
 
  I can definitely sympathise with the comment in Stefano's article that
  there are not enough easy tasks / simple issues for newcomers. There's
  a lot to learn already when you're starting out (git, gerrit, python,
  devstack, ...) and simple bugs are so hard to find - something that
  will take a few minutes to an existing contributor will take much
  longer for someone who's still figuring out where to get the code
  from.
 
 
 My counterargument to this is to jump straight into
 http://review.openstack.org/ (which happens to be publicly available to
 newcomers).
 
 Easy tasks / simple issues (i.e. nits!) are *frequently* cited in code
 review, and although our community tends to get hung up on seeing them
 fixed prior merging the patchset in question (sometimes with good reason,
 sometimes due to arbitrary opinion), that doesn't always happen (for
 example, it's not worth delaying approval of an important patch to see a
 typo fixed in an inline comment) and isn't always appropriate (such as,
 this other thing over here should be refactored).
 
 There's a lot of such scenarios where new contributors can quickly find
 things to contribute, or at lest provide incredibly valuable feedback to
 the project in the form of reviews! As a bonus, new contributors jumping
 straight into reviews tend to get up to speed on the code base *much* more
 quickly than they otherwise would (IMO), as they become directly involved
 in design discussions, etc.

I wouldn't consider this a counterargument but complementary, it's a
great suggestion. I try to find out what people are interested in
helping out with first and not assume that it's necessarily about
submitting a code contribution either (though so far it's mostly been
the case). Different approaches.

I just realised that Reviewing isn't in the table of contents on the
how to contribute landing page [1] and was probably low visibility. I
made a first stab at adding something more explicit about it, feel free
to expand and clarify.

Thanks to the people who contributed to this thread. I look forward to
seeing new projects popping up on OpenHatch soon :-)

Julie

[1] https://wiki.openstack.org/wiki/HowToContribute

 
 
 
  [1]
  http://opensource.com/business/14/2/analyzing-contributions-to-openstack
  [2] http://openhatch.org/
  [3] http://openhatch.org/+projects/OpenStack%20dashboard%20%28Horizon%29
  [4] https://openhatch.org/wiki/Contacting_new_contributors
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

[openstack-dev] Interested in attracting new contributors?

[Julie Pichon]

Hi folks,

Stefano's post on how to make contributions to OpenStack easier [1]
finally stirred me into writing about something that vkmc and myself
have been doing on the side for a few months to help new contributors
to get involved.

Some of you may be aware of OpenHatch [2], a non-profit dedicated to
helping newcomers get started in open-source. About 6 months ago we
created a project page for Horizon [3], filled in a few high level
details, set ourselves up as mentors. Since then people have been
expressing interest in the project and a number of them got a patch
submitted and approved, a couple are sticking around (often helping out
with bug triaging, as confirming new bugs is one of the few tasks one
can help out with when only having limited time).

I can definitely sympathise with the comment in Stefano's article that
there are not enough easy tasks / simple issues for newcomers. There's
a lot to learn already when you're starting out (git, gerrit, python,
devstack, ...) and simple bugs are so hard to find - something that
will take a few minutes to an existing contributor will take much
longer for someone who's still figuring out where to get the code
from. Unfortunately it's not uncommon for existing contributors to take
on tasks marked as low-hanging-fruit because it's only 5 minutes (I
can understand this coming up to an RC but otherwise low-hanging-fruits
are often low priority nits that could wait a little bit longer). In
Horizon the low-hanging-fruits definitely get snatched up quickly and I
try to keep a list of typos or other low impact, trivial bugs that
would make good first tasks for people reaching out via OpenHatch.

OpenHatch doesn't spam, you get one email a week if one or more people
indicated they want to help. The initial effort is not time-consuming,
following OpenHatch's advice [4] you can refine a nice initial
contact email that helps you get people started and understand what
they are interested in quickly. I don't find the time commitment to be
too much so far, and it's incredibly gratifying to see someone
submitting their first patch after you answered a couple of questions
or helped resolve a hairy git issue. I'm happy to chat about it more,
if you're curious or have any questions.

In any case if you'd like to attract more contributors to your project,
and/or help newcomers get started in open-source, consider adding your
project to OpenHatch too!

Cheers,

Julie

[1] http://opensource.com/business/14/2/analyzing-contributions-to-openstack
[2] http://openhatch.org/
[3] http://openhatch.org/+projects/OpenStack%20dashboard%20%28Horizon%29
[4] https://openhatch.org/wiki/Contacting_new_contributors

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

Re: [openstack-dev] [Horizon] web accessibility issues

[Julie Pichon]

Hi Joowoon and Douglas.

Thanks a lot for starting this conversation! I think this is important and
we'd all be delighted to make Horizon be usable by even more people.

We were discussing the topic somewhat recently [1] in the context of dropping
the no-Javascript fallback mode. We couldn't really find one web accessibility
standard that is agreed upon either. In general, work to improve accessibility
would be very very welcome, and I believe the main thing we've lacked so far
are actionable items (AFAICT there's only one open bug about accessibility [3]
at the moment?). Your lists should help with that!

People here on the mailing list and on IRC (#openstack-horizon) would be
delighted to help you if you have any question while filing bugs/blueprints/
fixing the problems you've found. Make sure to let us know how we can assist.

Many thanks for looking into this, and welcome!

Julie

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2013/horizon.2013-11-19-22.01.log.html
[2] https://bugs.launchpad.net/horizon/+bug/1018570

Douglas Fish drf...@us.ibm.com wrote:
 Hi Joowon, Stackers,
 
 Joowon, thanks for initiating this discussion.  Web accessibility is a
 priority for my company as well.  I've taken a quick look at Icehouse
 horizon and share similar concerns.  later, I'm going to go to your wiki
 page and share my concerns and thoughts.
 
 I have experience with web accessibility, but I'm still quite new to the
 Horizon project.  Part of my long term interest in the project is to see
 Horizon become accessible.  I look forward to being involved in
 accessibility work.
 
 Below are my initial, unprocessed notes on accessibility issues I've
 informally observed.  I expect to turn these into bug reports or blueprints
 and I get a better understanding of the project.
 Several Tables:
 - more button doesn't show focus
 - more menu doesn't close when focus is elsewhere
 - column headers don't have tabstops
 - filter button traps keyboard
 
 Overview:
 - calendar widget isn't reachable (in date range selection)
 - calendar widget never closes once its opened via tabbing
 
 Modal Dialog:
 - can tab outside of the modal dialog (observed on Domains, but I suspect
 its a global issue)
 - cancel button is not tabbable
 
 I don't see wai-aria tagging anywhere.  It's really needed on divs that are
 used as widgets, like the more button pop-up - I assume but haven't
 verified this will cause problems with screen readers.
 
 I _think_ horizon uses jqueryUI widgets which aren't accessible.  This guy
 has forked a set of accessible jQueryUI widgets, but I'm not sure that
 helps us any:
 http://hanshillen.github.io/jqtest/#goto_dialog
 
 It does look like bootstrap is committed to accessibility.  Maybe this will
 be a path to getting accessible widgets?
 
 Doug Fish
 IBM STG Cloud Solution Development
 T/L 553-6879, External Phone 507-253-6879
 
 
 
 
 From: Joonwon Lee joonwon7@samsung.com
 To:   openstack-dev@lists.openstack.org,
 Date: 01/23/2014 01:39 AM
 Subject:  [openstack-dev]  [Horizon] web accessibility issues
 
 
 
 Dear stackers,
 We inspected the Horizon (Havana release) for web accessibility and
 found the following problems, as it's required by our domestic standards.
 
 1.1.1 Non-text Contents
 - A few non-text contents such as Network Topology (for Neutron) and
   Resource Usage (for Ceilometer) have no text alternatives.
 
 1.3.1 Info and Relationships
 - There is no caption element, summary attribute in tables such as
   instances, volumes, images, so on.
 - There is no scope attribute in th elements.
 
 1.4.3 Contrast (Minimum)
 - text color and background color in the left menu
 - text color and background color in the top menu
 - link color and background color in the main content area
 - text color and background color of the some buttons
 
 2.1.1 Keyboard
 - It's not easy to handle the layered message window by keyboard only.
 - It may be difficult for a blind person to notice this layered error
   message.
 
 2.4.1 Bypass Blocks
 - There is no mechanism to skip repeated contents such as menu.
   For example, we can add a link at the top of each page that goes
   directly to the main content area.
 
 2.4.3 Focus Order
 - The order of navigation doesn't match the visual order in some cases.
 - The focus movement is not restricted to the layered pop-up window.
 
 3.1.1 Language of Page
 - There is no lang attribute on the html element.
 
 3.3.2 Labels or Instructions
 - Is it better to use label element to associate text labels with
   input elements?
 
 The above items are in the WCAG 2.0 W3C Recommendation:
 http://www.w3.org/TR/WCAG20/ (Web Content Accessibility Guidelines 2.0)
 
 I'd like to discuss in public how to solve these issues in the Horizon
 with the people who have the similar interests. However, I'm not an expert
 on this issues at all. Please correct me if I'm wrong at any points.
 
 I also created the wiki page. Feel free to edit it.
 

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge

[Julie Pichon]

Jaromir Coufal jcou...@redhat.com wrote:
 Hi All,
 
 After yesterday's weekly meeting it seems that majority of us is leaning
 towards this approach (codebase merge). However there are few concerns
 regarding speed of development and resources especially for reviews.
 With this e-mail, I'd like to kick off discussion about how we might
 assure to get enough people so that we can fulfill Horizon as well as
 Tuskar-UI goals.

It seems to me the opinions were still divided in the meeting, and this
is why we are continuing the discussion. Personally I'm more favourable
to the initial proposal, of moving the tuskar-ui repository under the
Horizon program. Existing Horizon cores add it to their Watched Changes
under Gerrit, just like for Horizon and django_openstack_auth now, and
get familiar with the project during its development. Tuskar-ui cores
can move their discussions to the #openstack-horizon channel and that's
another way that we all become part of the same horizon community, and
another chance for the horizon folks to understand what's important to
Tuskar.

There's a number of exceptions that are being requested, that make me
think now is not the right time to just merge the code into the main
horizon codebase. A few that have come up during the IRC meeting:

 - Request for more attention due to the need to move very fast
 - (Possibly) Request for an exception to the same company approval
   rule
 - Request to be able to check in broken stuff at times

In my mind these requirements come from being an incubated project with
different priorities, which is fine but make the project not suitable
for the main horizon codebase yet.

I think it makes more sense to merge once the project is integrated,
like we've done so far. Another discussion on list ([1]) makes it clear
that there's no promise an incubated project will become integrated,
and that it can be dropped from incubation. IMHO that's another
argument for waiting for a project to be integrated before merging
it. This doesn't mean it doesn't get any attention from the existing
Horizon team.

I think extending this rule to all - moving dashboard components from
incubated projects under the Horizon program - would be more reasonable
and easier to scale, than the proposed alternative.

 With respect to the e-mail which was sent Dec 17 (quoted below), I think
 all of what was written applies, we just need to clarify couple more
 details. And I hope we can get to consensus by the end of this week so
 that we can make things happen.
 
 
 *Blueprints:*
 Currently there is couple of already existing blueprints for Tuskar-UI
 and there will appear more based on wireframes around deployment setup
 (which are not finished yet).
 
 https://blueprints.launchpad.net/tuskar-ui
 
 We want to make sure, that Horizoners are fine with these blueprints
 being merged with Horizon ones, keeping their priorities and that there
 will appear couple more in time.
 
 
 *Cores:*
 To make sure that we have enough people to get the code in and also to
 help Horizoners to free load of reviews on their side, we propose to
 merge our core team (plus rdopieralski). All of them contributes to
 Horizon so they know the code well.
 
 People we are talking about:
 - jomara
 - jtomasek
 - lsmola
 - rdopieralski
 - tzumainn
 
 - (jcoufal) - At the moment I am in the core team but not doing reviews
 that often. From time to time I check implementation if it matches
 vision. With speeding up development, I will try to do more but not that
 often as above mentioned guys. My role there is more about helping to
 triage bugs and blueprints based on wireframes, project goals and
 direction. I am completely OK with not being included in core team after
 merger, I just want to ask if I can keep being able to help with
 blueprints and bugs triaging.
 
 Of course, everybody in core team needs to keep on track. We can
 evaluate the list in time and if anybody is not doing reviews properly,
 they should be removed from the list.
 
 So the question here is, if Horizoners are OK with above listed guys
 being merged to horizon-core team?
 
 
 *Reviews:*
 Even after merger we would love to keep cross-company reviews culture.
 And here are the main concerns I believe. I envision that the code will
 be developed really fast and will need attention for reviews. If we
 can't get code in, in reasonable time, Tuskar UI goals for Icehouse are
 jeopardized. So we should try to at least get to consensus about notion
 of future cores cooperation, so we feel that it can work well.
 
 My proposal:
 I think we are able to keep cross-company reviews approach. As was said
 there are about 6 non-redhat cores in Horizon. What can we do to ease
 the load for them?
 
 * Tuskar UI cores will help with reviews in Horizon (this will decrease
 the number of needed reviews in Horizon in general)
 * Tuskar UI cores will review the Tuskar UI code, their main
 responsibility will be that the code works well from functional and
 

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

[Julie Pichon]

David Lyle david.l...@hp.com wrote:
 I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been a
 significant code contributor in the last two releases, understands the code
 base well and has been doing a significant number of reviews for the last to
 milestones.

+1

 Additionally, I'd like to remove some inactive members of Horizon-core who
 have been inactive since the early Grizzly release at the latest.
 Devin Carlen
 Jake Dahn
 Jesse Andrews
 Joe Heck
 John Postlethwait
 Paul McMillan
 Todd Willey
 Tres Henry
 paul-tashima
 sleepsonthefloor

+1. Thank you for your work in creating and building up Horizon!

Julie

 
 Please respond with a +1/-1 by this Friday.
 
 -David Lyle
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

Maxime Vidori maxime.vid...@enovance.com wrote:
 Hi all, I know it is pretty annoying but I have to resurrect this subject.
 
 With the integration of Angularjs into Horizon we will encounter a lot of
 issues with javascript. I ask you to reconsider to bring back Nodejs as a
 development platform. I am not talking about production, we are all agree
 that Node is not ready for production, and we do not want it as a backend.
 But the facts are that we need a lot of its features, which will increase
 the tests and the development. Currently, we do not have any javascript code
 quality: jslint is a great tool and can be used easily into node. Angularjs
 also provides end-to-end testing based on nodejs again, testing is important
 especially if we start to put more logic into JS. Selenium is used just to
 run qUnit tests, we can bring back these tests into node and have a clean
 unified testing platform. Tests will be easier to perform.

It seems a bit crazy to me to introduce NodeJS as a dependency just for
the sake of an easy way to run jslint. There are other options
available that run without NodeJS as a dependency.

There are more implications to running NodeJS even only for
development. It will likely have an impact on our infrastructure as
well, since we'll want these checks running on patches up for
review. Then if it's there for development it increases the risk it
will creep in as a dependency for our runtime.

As for Selenium, are you talking about rewriting our existing Selenium
tests in Javascript? If so I am opposed to this. The strength of our
community is in Python, if we want to encourage people to write more
tests we should make it easy for them to do so.

I think you bring up great points, we do need to control our Javascript
quality better especially as we bring in more of it into our
codebase. But, style checks, CSS, and unit testing, shouldn't require
NodeJS.

Julie
 
 Finally, (do not punch me in the face) lessc which is used for bootstrap is
 completely integrated into it. I am afraid that modern javascript
 development can not be perform without this tool.
 
 Regards
 
 Maxime Vidori
 

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

Maxime Vidori maxime.vid...@enovance.com wrote:
 There is at least one bug open against Ubuntu[1], asking to install
 python-lesscpy as well, as customers often need to re-create or change
 stylesheets.
 
 This would imply nodejs in a production environment, when going back to
 less.
 
 As long as the css will be the only one included into the package, we cannot
 run into this issue. If someone wants to modify the less file he could
 compile it and just copy paste the result into the proper directory.

This doesn't sound particularly friendly, I think what Matthias was
getting at is that there are requests from users who want to be able to
modify the CSS directly.

 It seems a bit crazy to me to introduce NodeJS as a dependency just for
 the sake of an easy way to run jslint. There are other options
 available that run without NodeJS as a dependency.
 
 Sadly, the only solutions which try to implement jslint in pure python are in
 alpha or abandoned. If you have a python library which has the same quality
 as jslint (which is written by Douglas Crockford himself), I will be glad to
 take a look at it.

Sure, I'll look into it. There seems to be also Javascript-based
solutions that could be viable. If anyone has recommendations based on
past experience, please let me know. The patch Imre linked to looks
like a good start!

 There are more implications to running NodeJS even only for
 development. It will likely have an impact on our infrastructure as
 well, since we'll want these checks running on patches up for
 review. Then if it's there for development it increases the risk it
 will creep in as a dependency for our runtime.
 
 That is a good point, but Selenium also provides external dependencies, like
 a browser to run into. I do not really know the infrastructure used by
 jenkins and how we can integrate our solution into, but I do not think it is
 impossible (I have never got any trouble with the installation of node with
 the sources in any distro).

Selenium is already integrated with our Jenkins gate. I don't think it
hurts either to run the tests in an environment similar to what they
need to work in in the end.

 As for Selenium, are you talking about rewriting our existing Selenium
 tests in Javascript? If so I am opposed to this. The strength of our
 community is in Python, if we want to encourage people to write more
 tests we should make it easy for them to do so.
 
 Currently we have two Selenium tests in pure python, and all the others are
 running in a page with qUnit, which is a javascript unit testing framework.
 
 Lastly, we will start using angularjs as a front-end framework, it provides
 an advanced testing framework which allows us to get rid of selenium.

I don't think Selenium is going away, and efforts have started around
using it as well for our integration tests [0]. Looking at the current
AngularJS patch up for review, it is testable without requiring
NodeJS. From the initial mailing list discussion [1], my understanding
is that we're planning on using a specific AngularJS feature, not
rewriting everything with it. Changing our build system to accommodate
this seems like getting a bit ahead of ourselves.

Julie

[0] https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

Imre Farkas ifar...@redhat.com wrote:
 On 11/22/2013 02:49 PM, Maxime Vidori wrote:
  It seems a bit crazy to me to introduce NodeJS as a dependency just for
  the sake of an easy way to run jslint. There are other options
  available that run without NodeJS as a dependency.
 
  Sadly, the only solutions which try to implement jslint in pure python are
  in alpha or abandoned. If you have a python library which has the same
  quality as jslint (which is written by Douglas Crockford himself), I will
  be glad to take a look at it.
 
 There's a jslint fork called jshint which is able to run in the browser
 without any node.js dependency.
 
 I created a POC patch [1] long time ago to demonstrate its capabilities.
 It's integrated with qunit and runs automatically with the horizon test
 suite.

Thanks Imre, this is interesting. Would you mind restoring the patch? If
you don't have time to work on it please indicate so (I don't think it's
possible to pick up a patch if the status is 'Abandoned') and someone else
can look into the test failures.

 The patch also contains a .jshintrc file for the node.js package but you
 can remove it since it's not used by the qunit+jshint test at all.

Sounds good.

Julie

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

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

[openstack-dev] [UX] Automatically post new threads from AskBot to the list

[Julie Pichon]

Hi folks,

I've been thinking about the AskBot UX website [0] and its lack of
visibility, particularly for new community members.

I think it would be valuable to have the first post from new
conversation threads be posted to the -dev list with the appropriate
[UX] tag, with a link to AskBot and a request to continue the
conversation over there. This would help newcomers realising there is a
space for UX conversations, and existing community members to pop by
when a topic comes up around an area of interest. The traffic has been
low so far, and I wouldn't expect it to become more overwhelming than
any of the current projects currently communicating via the developers
list.

Would there be any concern or objections?

Julie

[0] ask-openstackux.rhcloud.com/

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

Re: [openstack-dev] [openstack][metering] Contributing to ceilometer while participating in GSoC

[Julie Pichon]

Hi Ajay,

Ajay Phogat letsgot...@gmail.com wrote:
 Hello, all!
 
 I am a student of Computer Science and have learnt some basics of OpenStack
 for implementing one of my projects in college. While learning about
 OpenStack, I came to know about the metering project, ceilometer.
 
 I would love to contribute to ceilometer, which according to
 ohlohhttp://www.ohloh.net/p?ref=homepageq=ceilometer has
 88 contributors presently. Also, I wanted to participate in Google Summer
 of Code while being associated with ceilometer. I wanted to know if
 contributing to ceilometer can be a valid project for GSoC.

Thanks for your interest in OpenStack and Ceilometer, that's great! Many
members of the community were away in Hong Kong for the OpenStack Summit last
week, sorry for the delay.

OpenStack has never participated in GSoC before - we never quite managed to
match the organisation requirements in time for the deadline. Maybe this will
change next year but I wouldn't necessarily count on it. I still encourage you
to get involved with the community even outside of a program like GSoC. There's
a lot of things we could use your help with!

Maybe a current Ceilometer contributor can point you toward a suitable first
task, in the meantime there's a lot of information you can read about to get
yourself started contributing: see [0] to learn the general OpenStack
contribution guidelines, [1] for finding something small to work on that you
find interesting, [2] to get an OpenStack dev environment set up in a VM.

Consider also popping by on IRC [3], on #openstack-metering for Ceilometer
related questions and #openstack-101 if you encounter any hiccup getting
started contributing. There are lots of people happy to help and guide you!

Kind regards,

Julie

[0] https://wiki.openstack.org/wiki/HowToContribute
[1] https://bugs.launchpad.net/ceilometer/
[2] http://devstack.org/
[3] https://wiki.openstack.org/IRC

 
 Thanks a lot for your time and effort!
 
 
 Ajay Phogat

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

Re: [openstack-dev] [nova] Closes-Bug and Launchpad

[Julie Pichon]

Hi Gary,

Gary Kotton gkot...@vmware.com wrote:
 Hi,
 Over the last few days I have noticed that bug fixes posted to gerrit are not
 updated in Launchpad. Am I doing something wrong? I think that the commit
 message is the correct format: Closes-Bug: #bug number.
 Any ideas?

I've seen the linking fail when the bug number is followed by a period.

That seems to match the regexp, if I'm looking at the right place:

https://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/update_bug.py#n250

Julie

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

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

Re: [openstack-dev] [Horizon] The source language of Horizon in Transifex

[Julie Pichon]

Hi Daisy,

Ying Chun Guo guoyi...@cn.ibm.com wrote:
 Now the source language of Horizon in Transifex is set as en_US, not en. So
 when pulling the translations
 from Transifex, there will be some dummy characters in en.po, which will
 cause errors in unit
 tests.
 
 I don't find a way to change the setting in Transifex. I think the only way
 to fix it is to
 re-upload the resources with source language setting as en, and delete the
 existing resources.
 
 Please let me know if Horizon development team know the issue and have any
 plans to fix it. Thanks

We have a bug open for tracking this, 1179526 [0]. Akihiro Motoki
suggested a temporary change that prevents the issues we saw with
unit tests, which we should implement. I think at this point we
were planning on reaching out to our contacts at Transifex (...if
we have any?) to see if it would be possible to fix this without
having to delete and recreate the project.

Regards,

Julie

[0] https://bugs.launchpad.net/horizon/+bug/1179526


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

Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it

[Julie Pichon]

Hi Thomas,

Thomas Goirand z...@debian.org wrote:
 Horizon seems to use python-selenium. The problem is that, in Debian,
 this package is in the non-free repository. So I strongly suggest to not
 use it for Havana. That otherwise would put Horizon into the contrib
 repository of Debian (eg: not officially in Debian), or eventually,
 remove any possibility to run the unit tests, which isn't nice.

Why is Selenium considered non-free? The code is Apache-licensed, including the 
Python bindings.

FWIW only a few of the unit tests use Selenium (and those that do, need to), 
and they're not run by default unless you set a flag to do so.

Julie

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

Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it

[Julie Pichon]

Hi Sascha,

Sascha Peilicke speili...@suse.com wrote:
 On 07/04/2013 02:34 PM, Sascha Peilicke wrote:
  On 07/04/2013 12:03 PM, Matthias Runge wrote:
  On 04/07/13 11:27, Thomas Goirand wrote:
  Horizon seems to use python-selenium. The problem is that, in Debian,
  this package is in the non-free repository. So I strongly suggest to not
  use it for Havana. That otherwise would put Horizon into the contrib
  repository of Debian (eg: not officially in Debian), or eventually,
  remove any possibility to run the unit tests, which isn't nice.
 
  Thank you for the heads-up.
 
  Selenium is used for tests during development, it is not a runtime
  requirement at all.
 
  Would that still make it non-free for Debian?
 
  BTW. this is identical for openSUSE.
 
  How did Horizon went into Debian packages at all, since the situation in
  this front is unchanged for at least a year (just curious).
 
  At least here, our horizon test package just doesn't depend on selenium.
 
 This could help: https://review.openstack.org/#/c/35649/

Could you explain why Selenium is considered to be non-free?

Thanks,

Julie

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

Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it

[Julie Pichon]

Matthias Runge mru...@redhat.com wrote:
 On 04/07/13 15:55, Daniel P. Berrange wrote:
  
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677
  
the package ships some files which are not yet built from source.
  
  Whether this is still accurate or not, is another matter, since that
  bz is 2 years old...
 I remember that I filed a bug, because selenium shipped a binary web
 driver adapter for firefox.
 
 E.g there are prebuilt files checked into seleniums svn:
 http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/prebuilt/
 which are/were required to build the whole thing.
 
 That was the point where I stopped packaging it for Fedora.

Thanks for the link Daniel, and Matthias for the extra information. I assume 
this is the same issue openSUSE has with the package (my google-fu is failing 
me for finding a bug).

Cheers,

Julie

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

Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it

[Julie Pichon]

Sascha Peilicke speili...@suse.com wrote:
 On 07/04/2013 04:06 PM, Thomas Goirand wrote:
  On 07/04/2013 06:10 PM, Julien Danjou wrote:
  On Thu, Jul 04 2013, Julie Pichon wrote:
  Why is Selenium considered non-free? The code is Apache-licensed,
  including the Python bindings.
 
  FWIW only a few of the unit tests use Selenium (and those that do, need
  to),
  and they're not run by default unless you set a flag to do so.
 
  Yes, that seems like a mistake from the Debian packager as far as I can
  tell. There's nothing that requires it to be in non-free.
 
  (Cc'ing Sascha, the maintainer)
 
  Well, see this:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677
 
  There are files not built from source. Also, when looking at the
  package, it seems that it isn't maintained as good as it deserves.
  #700061 was opened in 08 Feb 2013, and there's no answer at all from
  Sascha to this bug (which is RC).
 
 I am sorry, but I'm an openSUSE guy. But I can tell you we had similar
 bugs :-)

I think Thomas was talking about Sascha Girrulat, the maintainer for the Debian 
package.
 
 https://bugzilla.novell.com/show_bug.cgi?id=755619

It looks like I am not authorised to access this bug, thanks for the link 
though. I understand the idea :)

Julie

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