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

[Timur Sufiev]

I still think this one
https://wtf.jpg.wtf/0c/10/1479414543-0c1052f7c2f9990b6b0c472076594cb1.jpeg is
the best :).

On Wed, Dec 7, 2016 at 1:07 AM Jason Rist  wrote:

> On 12/06/2016 01:48 PM, Richard Jones wrote:
> > >> On 6 Dec 2016, at 20:19, Richard Jones 
> wrote:
> > >> Please let me know what you think (by December 12) of this draft for
> > >> our Horizon team mascot.
> > >
> > On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
> >  wrote:
> > > Are we missing an attachment / link ?
> >
> > Weird! Trying again:
> >
> >
> >
> >
> __
> > 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
> >
> Much UI, such OpenStack, wow.
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack User Interfaces
> Red Hat, Inc.
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> 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] [Horizon] Proposing Kenji Ishii for core

[Timur Sufiev]

+1

On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran  wrote:

> +1 from me. Kenji is also very active in the plugin space.
>
>
> - Original message -
> From: David Lyle 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc:
> Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
> Date: Thu, Nov 17, 2016 11:51 AM
>
> +1
>
> On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
>  wrote:
> > +1
> >
> > 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) :
> >>
> >> Big +1 from me
> >>
> >> > On 14 Nov 2016, at 00:24, Richard Jones 
> wrote:
> >> >
> >> > Hi Horizon core team,
> >> >
> >> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> >> > solid Horizon contributor for some time, with thoughtful and helpful
> >> > reviews showing good judgment and good knowledge of Horizion and
> >> > related systems. Please respond with your votes by Friday.
> >> >
> >> >
> >> > Thanks,
> >> >
> >> >Richard
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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][DataTables] how to generate a confirmation dialog

[Timur Sufiev]

Hi, John,

the code you're looking for is located here:
https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.tables.js#L227-L312
This is bound at
https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.forms.js#L368-L373

On Sun, Nov 6, 2016 at 10:32 PM John Calcote  wrote:

> Ping. No thoughts on this from anyone?
>
> On Nov 4, 2016 9:26 PM, "John Calcote"  wrote:
>
> Hi all -
>
> I don't see a better forum anywhere for this post - please correct me
> if I'm wrong.
>
> I have a django/horizon application. On one page users may delete
> objects. I'd like to display a modal dialog confirming the delete
> before submit. Can anyone tell me if there's a way to tie a
> confirmation dialog to a table's DeleteAction?
>
> Note - my template is a trivial table.render with multi-select enabled -
> e.g.,
>
> {% block main %}
> {{ table.render }}
> {% endblock %}
>
> I've searched the docs and the code, but nothing sticks out at me. I'm
> not a client-side expert, but I can usually find my way around in the
> chrome debugger.
>
> Thanks,
> John
>
> __
> 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] [horizon] ListField in Horizon

[Timur Sufiev]

Hi, Janki

What do you mean by ListField? A list of arbitrary tags? List of numbers?
List of predefined values that you can choose from? Options may vary widely
depending on your particular needs.

On Sun, Sep 18, 2016 at 6:32 PM Janki Chhatbar  wrote:

> Hi
>
> I am working on a dashboard's panel that needs an input as a "list". I
> couldnot find any "ListField" (like CharFiled) in Horizon forms.
>
> Is there any other field type that takes input as a list or this needs to
> be developed?
>
> Any pointer would be appreciated.
>
> --
> Thanking you
>
> Janki Chhatbar
> OpenStack | Docker | SDN
> simplyexplainedblog.wordpress.com
> __
> 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] [Horizon] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

[Timur Sufiev]

David,

I understand your concerns. Early Ocata instead of late Newton makes sense
to me. Thank you for a quick response.

On Wed, Aug 31, 2016 at 5:54 PM David Lyle <dkly...@gmail.com> wrote:

> As a developer feature, I would vote for merging in early Ocata rather
> than as a FFE. Since the potential risk is to users and operators and
> they won't generally benefit from the feature, I don't see the upside
> outweighing the potential risk.  It's not a localized change either.
>
> That said, I think the profiler work will be extremely valuable in
> Ocata and beyond. Thanks for your continued efforts on bringing it to
> life.
>
> David
>
> On Wed, Aug 31, 2016 at 6:14 AM, Timur Sufiev <tsuf...@mirantis.com>
> wrote:
> > Hello, folks!
> >
> > I'd like to ask for a feature-freeze exception for a Horizon Profiler
> > feature [1], that has been demoed long ago (during Portland midcycle Feb
> > 2016) and is finally ready. The actual request applies to the 3 patches
> [2]
> > that provide the bulk of Profiler functionality.
> >
> > It is a quite useful feature that is aimed mostly to developers, thus it
> is
> > constrained within Developer dashboard and disabled by default - so it
> > shouldn't have any impact on User-facing Horizon capabilities.
> >
> > [1]
> >
> https://blueprints.launchpad.net/horizon/+spec/openstack-profiler-at-developer-dashboard
> > [2]
> >
> https://review.openstack.org/#/q/topic:bp/openstack-profiler-at-developer-dashboard+status:open
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

[Timur Sufiev]

Hello, folks!

I'd like to ask for a feature-freeze exception for a Horizon Profiler
feature [1], that has been demoed long ago (during Portland midcycle Feb
2016) and is finally ready. The actual request applies to the 3 patches [2]
that provide the bulk of Profiler functionality.

It is a quite useful feature that is aimed mostly to developers, thus it is
constrained within Developer dashboard and disabled by default - so it
shouldn't have any impact on User-facing Horizon capabilities.

[1]
https://blueprints.launchpad.net/horizon/+spec/openstack-profiler-at-developer-dashboard
[2]
https://review.openstack.org/#/q/topic:bp/openstack-profiler-at-developer-dashboard+status:open
__
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] [Glance][Heat][Horizon] Glance v2 and custom locations

[Timur Sufiev]

Can we have a special way (i.e. restricted) of setting Image locations, to
be used by clients like Horizon (where an end-users create images)? It
would be hard to explain different set of Image Sources depending on their
adminness.

Anoher question that I'm asking myself about Horizon is how affordable
would be the loss of 'URL Image Source', since 'copy-from' is missing for
sure already. Are there many valuable use cases for URL source in absence
of 'copy-from' feature?

On Tue, Jul 26, 2016 at 5:33 PM  wrote:

> Hi Mike,
>
> Here's my $0.02 on setting locations directly:
>
> I think there will always be some (probably public cloud) operators who
> are wary of allowing regular users to do this. For this reason,
> and also because the API calls are backend specific (setting location
> isn't supported for a filesystem backend [1]), my guess is it's unlikely
> that
> API calls for setting locations directly will become part of DefCore.
>
> In general I'm not a huge fan of setting the image locations directly
> because:
>
> * Any time you allow setting the location directly you're risking the
> database and the image data getting out of sync. Eg an 'active' image's
> data can be deleted from under it.
> * Some ways of setting the locations directly give you images without
> a known checksum.
>
> In my mind, the feature is probably best restricted (by default at least)
> to power users (admins) and other services -- eg Cinder can do this
> to reduce copying data around in some cases. Existing policies can be
> used to restrict to admin; something like service tokens [1] could be
> used to allow other services (eg Cinder) to do this on behalf of users,
> while preventing users from doing it directly themselves.
>
> To keep things as inter-operable as possible it might be good to ensure
> that services are able to use Glance even if setting locations directly
> is completely disabled.
>
> -Stuart
>
> [1] https://review.openstack.org/#/c/141706
> [2]
> https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html
>
> > Hello!
> >
> > As you may know glance v1 is going to be deprecated in Newton cycle.
> Almost
> > all projects support glance v2 at this moment, Nova uses it by default.
> > Only one thing that blocks us from complete adoption is a possibility to
> > set custom locations to images. In v1 any user can set a location to his
> > image, but in v2 this functionality is not allowed by default, which
> > prevents v2 adoption in services like Horizon or Heat.
> >
> > It all happens because of differences between v1 and v2 locations. In v1
> it
> > is pretty easy - user specifies an url and send a request, glance adds
> this
> > url to the image and activates it.
> > In v2 things are more complicated: v2 supports multiple locations per
> > image, which means that when user wants to download image file glance
> will
> > choose the best one from the list of locations. It leads to some
> > inconsistencies: user can add or delete locations from his image even if
> it
> > is active.
> >
> > To enable adding custom locations operator has to set True to config
> option
> > 'show_multiple_locations'. After that any user will be able to add or
> > remove his image locations, update locations metadata, and finally see
> > locations of all images even if they were uploaded to local storage. All
> > this things are not desired if glance v2 has public interface, because it
> > exposes inner cloud architecture. It leads to the fact that Heat and
> > Horizon and Nova in some cases and other services that used to set custom
> > locations in glance v1 won't be able to adopt glance v2. Unfortunately,
> > removing this behavior in v2 isn't easy, because it requires serious
> > architecture changes and breaks API. Moreover, many vendors use these
> > features in their clouds for private glance deployments and they really
> > won't like if we break anything.
> >
> > So, I want to hear opinions from Glance community and other involved
> > people.
> >
> > Best regards,
> > Mikhail Fedosin
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL:
> > <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.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 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] On testing...

[Timur Sufiev]

I'm not sure if (3) was the thing we agreed upon (and if it will help us to
detect issues in Horizon) but the rest of options definitely make sense to
me.

Also there is

5. Parallelize integration tests.

On Wed, Jul 20, 2016 at 4:28 PM Richard Jones 
wrote:

> Hi folks,
>
> Sorry I didn't make the meeting this morning :-(
>
> We touched on testing at the mid-cycle and again it came up in the meeting
> this morning. We identified two issues:
>
> 1. Our integration test suite cannot grow to too many more tests because
> they take too long to run (and get auto-killed). We could increase the
> amount of time allowed for them, but we agreed that we shouldn't do this.
> 2. We don't have enough higher-level (integration leve) test coverage for
> our newer angular interfaces.
>
> These two are obviously at odds :-)
>
> What we agreed on, I think, is that we're going to:
>
> 1. Reduce the granularity of the integration tests - use them to broadly
> test whether an interface works at all when presented to a browser,
> 2. Replace many single interface tests with a fewer tests that poke at
> many interfaces (thus removing the significant per-test overhead) - even
> potentially having a single test that attempts to access every panel (as a
> guard against gross Javascript incompatibilities or configuration issues
> breaking panels),
> 3. Move the integration tests to tempest, and
> 4. Write some "django unit test suite" functional tests for our angular
> code that tests more than just the single units we currently test (ie. mock
> at a more remote level, checking that broader interactions work).
>
> Does this sound about right?
>
>
>  Richard
>
> __
> 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] [horizon] Logo

[Timur Sufiev]

Let's take it before anybody else did :)!

On Sat, Jul 16, 2016 at 6:15 PM Richard Jones 
wrote:

> +2 very appropriate
>
> On 17 July 2016 at 11:01, Diana Whitten  wrote:
>
>> Dunno if there have been any suggestions, but I'd like to suggest a Shiba
>> Inu for the Horizon logo mascot.
>>
>> If you unfamiliar with a Shiba Inu, take a look here:
>> http://vignette1.wikia.nocookie.net/sanicsource/images/9/97/Doge.jpg/revision/latest?cb=20160112233015
>>
>> Our Shiba should definitely look shocked too.
>>
>> - Diana
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

[Timur Sufiev]

Hello, vigilant folks of OpenStack Security team!

The commit(s) I'd like you to take a look at introduces a new Horizon
feature, Create (Glance) Image using CORS (AKA Cross-Origin Resource
Sharing) [1].

The main idea is to bypass Horizon web-server when uploading large local
image and to send it directly to Glance server, thus saving network
bandwidth and disk space on the controller node where Horizon web-server is
deployed. However there is one possible security trade-off I had to make so
that Glance service would allow me to upload an image - I'm passing the
Keystone token to the Horizon JS runtime [2], and then pass it to Glance
service [3] or [4] (different links here correspond to different versions
of new Create Image - Django and Angular). This trade-off made Horizon
community somewhat hesitant if we should push these changes forward, but
nobody yet voiced a viable alternative, so here I'm writing this letter to
you.

The usual Horizon workflow for working with Keystone tokens is the
following: retrieve scoped token and put it into web-server session, which
is itself not exposed to browser (unless SESSION_STORAGE signed_cookies
backend was chosen, but even in that case session contents are encrypted in
some way), but is kept on web-server and referenced using the session key
which is kept in browser cookies - so one may say that in existing setup
keystone token never leaks to browser.

On the other hand, in some not so far (I hope) future, when more logic is
moved to client-side UI (i.e. browser), the issue of browser authenticating
to some OpenStack services directly would become more widespread, it just
happened that this work on Create Image in Horizon is pioneering this area
(AFAIK). So, what do you think of possible security implications of this
setup?

Just for the reference, three patches mentioned in [1-3] implement most of
the logic of new Create Image feature.

[1]
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
[2]
https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
[3]
https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
[4]
https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151
__
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] npm lint and test problems in gate

[Timur Sufiev]

JFYI, CR [1] which fixes the corresponding bug [2] was merged on Jun 28, so
it may make sense to recheck you perfectly looking commit if it has been
staying in Gerrit for a while.

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

On Mon, Jun 27, 2016 at 10:42 PM Jeremy Stanley  wrote:

> On 2016-06-24 22:08:40 + (+), Jeremy Stanley wrote:
> [...]
> > the gate-horizon-npm-run-test job uses that same configuration
> > (just passing a different {command}) and we're still seeing
> > failures registered for it even now.
> [...]
>
> Just following up since I got a few more minutes to poke at this
> after discussing in IRC: I have confirmed the stats we have in
> graphite seem to match what's recorded by logstash, and dug up
> three example failure logs from today.
>
>
> http://logs.openstack.org/00/334300/1/check/gate-horizon-npm-run-test/469ff89/console.html
>
>
> http://logs.openstack.org/03/320203/9/check/gate-horizon-npm-run-test/e71f803/console.html
>
>
> http://logs.openstack.org/28/333628/5/check/gate-horizon-npm-run-test/5ae2085/console.html
>
> However, there's (thankfully) a consistent explanation. Take a look
> at the timestamp gaps between the penultimate and ultimate lines of
> each log... timeouts! So I agree the issue seems to be lack of
> errexit in the npm-run builder. The old failures observed for
> gate-horizon-npm-run-lint are probably similarly explained as
> timeout issues we've just been lucky enough not to hit in the past
> week or so. Unfortunately those failures fall just outside our
> elasticsearch retention window so confirming that would be a very
> time-intensive exercise at this point.
> --
> Jeremy Stanley
>
> __
> 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] [horizon] Horizon in devstack is broken, rechecks are futile

[Timur Sufiev]

The final patch https://review.openstack.org/#/c/321640/ has just merged,
Devstack Horizon is fully functional and integration tests should be
passing from this moment. If any of your patches are still failing due to
dsvm-integration job's multiple failures, please rebase them.

On Fri, May 27, 2016 at 4:59 PM Brant Knudson <b...@acm.org> wrote:

> On Fri, May 27, 2016 at 8:39 AM, Timur Sufiev <tsuf...@mirantis.com>
> wrote:
>
>> The root cause of Horizon issue has been identified and fixed at
>> https://review.openstack.org/#/c/321639/
>> The next steps are to release new version of django-openstack-auth
>> library (which the above fix belongs to), update global-requirements (if
>> it's not automatic, I'm not very into the details of release managing of
>> openstack components), update horizon requirements from global
>> requirements, and then merge the final patch
>> https://review.openstack.org/#/c/321640/ - this time into horizon repo.
>> Once all that is done, gate should be unblocked.
>>
>> Optimistic ETA is by tonight.
>>
>> On Wed, May 25, 2016 at 10:57 PM Timur Sufiev <tsuf...@mirantis.com>
>> wrote:
>>
>>> Dear Horizon contributors,
>>>
>>> The test job dsvm-integration fails for a reason for the last ~24 hours,
>>> please do not recheck your patches if you see that almost all integration
>>> tests fail (and only these tests) - it won't help. The fix for
>>> django_openstack_auth issue which has been uncovered by the recent devstack
>>> change (see https://bugs.launchpad.net/horizon/+bug/1585682) is being
>>> worked on. Stay tuned, there will be another notification when rechecks
>>> will become meaningful again.
>>>
>>
>>
> Thanks for working on this. It will help us eventually get to a devstack
> where keystone and potentially the rest of the API servers are listening on
> paths rather than on ports. I had to fix a similar issue in tempest.
>
> To request a release send a review with to update
> http://git.openstack.org/cgit/openstack/releases/tree/deliverables/mitaka/django-openstack-auth.yaml
> with the new library version and commit hash. You'll have to create a new
> yaml file for newton since there hasn't been a release yet.
>
> --
> - Brant
> __
> 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] [horizon] Horizon in devstack is broken, rechecks are futile

[Timur Sufiev]

The root cause of Horizon issue has been identified and fixed at
https://review.openstack.org/#/c/321639/
The next steps are to release new version of django-openstack-auth library
(which the above fix belongs to), update global-requirements (if it's not
automatic, I'm not very into the details of release managing of openstack
components), update horizon requirements from global requirements, and then
merge the final patch https://review.openstack.org/#/c/321640/ - this time
into horizon repo. Once all that is done, gate should be unblocked.

Optimistic ETA is by tonight.

On Wed, May 25, 2016 at 10:57 PM Timur Sufiev <tsuf...@mirantis.com> wrote:

> Dear Horizon contributors,
>
> The test job dsvm-integration fails for a reason for the last ~24 hours,
> please do not recheck your patches if you see that almost all integration
> tests fail (and only these tests) - it won't help. The fix for
> django_openstack_auth issue which has been uncovered by the recent devstack
> change (see https://bugs.launchpad.net/horizon/+bug/1585682) is being
> worked on. Stay tuned, there will be another notification when rechecks
> will become meaningful again.
>
__
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] Horizon in devstack is broken, rechecks are futile

[Timur Sufiev]

Dear Horizon contributors,

The test job dsvm-integration fails for a reason for the last ~24 hours,
please do not recheck your patches if you see that almost all integration
tests fail (and only these tests) - it won't help. The fix for
django_openstack_auth issue which has been uncovered by the recent devstack
change (see https://bugs.launchpad.net/horizon/+bug/1585682) is being
worked on. Stay tuned, there will be another notification when rechecks
will become meaningful again.
__
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] [javascript] Async file uploads in a new JS-centric UI

[Timur Sufiev]

Since 10 lines of code > 1000 words, here are references to 2 patch chains:

* New Swift UI file upload https://review.openstack.org/#/c/316143/
* New Angular Create Image file upload
https://review.openstack.org/#/c/317456/

I like Create Image solution more because it doesn't use Django csrf_exempt
and single FileField form hacks just to accept a binary stream on Django
side. So CORS offers us a shorter and more elegant solution to the task of
file uploads.

I got an off-ML feedback that the question / intention of original mail is
not clear. My intention / proposal is to adopt the approach used for
uploading files in Create Image workflow as the standard way for other
interactions (which include file uploads) between Web Clients and OpenStack
services.

On Sat, May 14, 2016 at 2:48 AM Timur Sufiev <tsuf...@mirantis.com> wrote:

> Hello, fellow web developers!
>
> I'd like to share some of my thoughts and findings that I made during
> playing with ng-file-upload [1] for file uploads in Swift UI and Create
> Image wizard in Horizon (both Angular). Sorry for a long letter, couldn't
> put it shorter (TL;DR => go to CONCLUSION section).
>
> As a foreword: it's a really useful library, both for customizing stubborn
>  widget appearance (hello, themability!) and behavior
> and for the actual file transfer. More on the file transfer below, since
> it's the topic that really interests me.
>
> MAIN PART
>
> First, in modern browsers (by modern I mean HTML5 support and particularly
> FileReader API) you don't need a single-purposed library to upload file
> asynchronously, both jQuery $.ajax() and vanilla Angular $http calls
> support it - just pass File()/Blob() object as data (no wrapping {} please)
> and it works - browser transparently reads data chunk by chunk  from a
> local file system and sends it to the server. There is even a working
> solution for Django and jQuery-based 'Create Image' form [2]. There are a
> few subtleties though. Most importantly, there should be no other data
> (like other key-value pairs from form fields), just the file blob - and
> then the server endpoint must support raw byte stream as well. This rules
> out Django views which expect certain headers and body structure.
>
> (Second,) What ng-file-upload offers us to solve the challenge of file
> transfers? There are 2 methods in Upload service: .http() and .upload().
> First one is a very thin wrapper around Angular $http, with one difference
> that it allows to notify() browser of file upload progress (when just a
> single file blob is passed in .http(), as in case of $http() as well). The
> second method offers more features, like abortable/resumable uploads and
> transparent handling of data like {key1: value1, key2: value2, file:
> FileBlob}. Uploading such data is implemented using standard
> multipart/form-data content type, so actually, it's just a convenient
> wrapper around facilities we've already seen. Anyways it's better to just
> feed the data into Upload.upload() than to construct FormData() on your own
> (still the same is happening under the bonnet).
>
> Third, and most important point, we still have to couple Upload.http() /
> Upload.upload() with a server-side machinery. If it's a single file upload
> with Upload.http(), then the server must be able to work with raw binary
> stream (I'm repeating myself here). If it's a form data including file
> blob, it's easily handled on front-end with Upload.upload(), then the
> server must be able to parse multipart/form-data (Django perfectly does
> that). What's bad in this situation is that it also needs to store any
> sufficiently sized file in a web server's file system - which is both
> bug-prone [4] and suboptimal from performance POV. First we need to send a
> file (possibly GB-sized) from browser to web server, then from web server
> to the Glance/Swift/any other service host. So, blindly using
> Upload.upload() won't solve our _real_ problems with file uploads.
>
> CONCLUSION
>
> What can be done here to help JS UI to handle really large uploads? Split
> any API calls / views / whatever server things we have into 2 parts:
> lightweight JSON metadata + heavyweight binary stream. Moreover, use CORS
> for the second part to send binary streams directly to that data consumers
> (I know of 2 services atm - Glance & Swift, maybe there are more?). That
> will reduce the processing time, increasing the possibility that an
> operation will complete successfully before Keystone token expires :). IMO
> any new Angular wizard in Horizon should be designed with this thing in
> mind: a separate API call for binary stream transfer.
>
> Thoughts, suggestions?
>
> P.S. None of above means that we shouldn't use ng-file-upload, it's still
> a very convenient tool

[openstack-dev] [horizon] [javascript] Async file uploads in a new JS-centric UI

[Timur Sufiev]

Hello, fellow web developers!

I'd like to share some of my thoughts and findings that I made during
playing with ng-file-upload [1] for file uploads in Swift UI and Create
Image wizard in Horizon (both Angular). Sorry for a long letter, couldn't
put it shorter (TL;DR => go to CONCLUSION section).

As a foreword: it's a really useful library, both for customizing stubborn
 widget appearance (hello, themability!) and behavior
and for the actual file transfer. More on the file transfer below, since
it's the topic that really interests me.

MAIN PART

First, in modern browsers (by modern I mean HTML5 support and particularly
FileReader API) you don't need a single-purposed library to upload file
asynchronously, both jQuery $.ajax() and vanilla Angular $http calls
support it - just pass File()/Blob() object as data (no wrapping {} please)
and it works - browser transparently reads data chunk by chunk  from a
local file system and sends it to the server. There is even a working
solution for Django and jQuery-based 'Create Image' form [2]. There are a
few subtleties though. Most importantly, there should be no other data
(like other key-value pairs from form fields), just the file blob - and
then the server endpoint must support raw byte stream as well. This rules
out Django views which expect certain headers and body structure.

(Second,) What ng-file-upload offers us to solve the challenge of file
transfers? There are 2 methods in Upload service: .http() and .upload().
First one is a very thin wrapper around Angular $http, with one difference
that it allows to notify() browser of file upload progress (when just a
single file blob is passed in .http(), as in case of $http() as well). The
second method offers more features, like abortable/resumable uploads and
transparent handling of data like {key1: value1, key2: value2, file:
FileBlob}. Uploading such data is implemented using standard
multipart/form-data content type, so actually, it's just a convenient
wrapper around facilities we've already seen. Anyways it's better to just
feed the data into Upload.upload() than to construct FormData() on your own
(still the same is happening under the bonnet).

Third, and most important point, we still have to couple Upload.http() /
Upload.upload() with a server-side machinery. If it's a single file upload
with Upload.http(), then the server must be able to work with raw binary
stream (I'm repeating myself here). If it's a form data including file
blob, it's easily handled on front-end with Upload.upload(), then the
server must be able to parse multipart/form-data (Django perfectly does
that). What's bad in this situation is that it also needs to store any
sufficiently sized file in a web server's file system - which is both
bug-prone [4] and suboptimal from performance POV. First we need to send a
file (possibly GB-sized) from browser to web server, then from web server
to the Glance/Swift/any other service host. So, blindly using
Upload.upload() won't solve our _real_ problems with file uploads.

CONCLUSION

What can be done here to help JS UI to handle really large uploads? Split
any API calls / views / whatever server things we have into 2 parts:
lightweight JSON metadata + heavyweight binary stream. Moreover, use CORS
for the second part to send binary streams directly to that data consumers
(I know of 2 services atm - Glance & Swift, maybe there are more?). That
will reduce the processing time, increasing the possibility that an
operation will complete successfully before Keystone token expires :). IMO
any new Angular wizard in Horizon should be designed with this thing in
mind: a separate API call for binary stream transfer.

Thoughts, suggestions?

P.S. None of above means that we shouldn't use ng-file-upload, it's still a
very convenient tool.

[1] https://github.com/danialfarid/ng-file-upload
[2] https://review.openstack.org/#/c/230434/
[3]
https://github.com/openstack/horizon/blob/master/horizon/static/horizon/js/horizon.modals.js#L216
[4] https://bugs.launchpad.net/horizon/+bug/1403129
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] How to paginate Data Table to display only 5 rows every page ?

[Timur Sufiev]

Yes, you can maintain a downstream fork if you wish.
On Thu, 28 Apr 2016 at 05:34, 严超 <yanchao...@gmail.com> wrote:

> Can we hard code only one table to 5 rows limit default ? And leave other
> tables not touched.
> Thank you very much !
>
> 严超 <yanchao...@gmail.com>于2016年4月28日周四 上午6:58写道：
>
>> Oh, sorry, I mean, can we hard code only one table to 5 rows default ?
>> And leave others not touched.
>> Thank you very much !
>>
>> *Best Regards！*
>>
>>
>> *Chao Yan--About me ： http://about.me/chao_yan
>> <http://about.me/chao_yan>*
>>
>> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
>> *My Weibo： http://weibo.com/herewearenow <http://weibo.com/herewearenow>*
>> *--*
>>
>> 2016-04-28 1:51 GMT+08:00 Timur Sufiev <tsuf...@mirantis.com>:
>>
>>> Definitely, yes
>>>
>>> See how it's done for Images:
>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/images/views.py#L35
>>>
>>> Also, limit of items per table page is set in User Settings
>>> (->Settings at top right corner of the dashboard), it's not
>>> hard-coded. Once you set it, all tables which support pagination (see the
>>> pattern above) display the specified number of items per page.
>>>
>>> On Wed, Apr 27, 2016 at 1:00 PM 严超 <yanchao...@gmail.com> wrote:
>>>
>>>> Hi, Everyone:
>>>> Is there a possible way to paginate DataTable to display only 5
>>>> rows every page ?
>>>> I'm very grateful for reply.
>>>>
>>>> *Best Regards！*
>>>>
>>>>
>>>> *Chao Yan--About me ： http://about.me/chao_yan
>>>> <http://about.me/chao_yan>*
>>>>
>>>> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
>>>> *My Weibo： http://weibo.com/herewearenow
>>>> <http://weibo.com/herewearenow>**--*
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] How to paginate Data Table to display only 5 rows every page ?

[Timur Sufiev]

Definitely, yes

See how it's done for Images:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/images/views.py#L35

Also, limit of items per table page is set in User Settings
(->Settings at top right corner of the dashboard), it's not
hard-coded. Once you set it, all tables which support pagination (see the
pattern above) display the specified number of items per page.

On Wed, Apr 27, 2016 at 1:00 PM 严超  wrote:

> Hi, Everyone:
> Is there a possible way to paginate DataTable to display only 5 rows
> every page ?
> I'm very grateful for reply.
>
> *Best Regards！*
>
>
> *Chao Yan--About me ： http://about.me/chao_yan
> *
>
> *My twitter： @yanchao727 *
> *My Weibo： http://weibo.com/herewearenow *
> *--*
> __
> 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] [horizon] Can we have multiple tab groups in one page?

[Timur Sufiev]

That would be too complicated using current Django-based tabs and tables.
You could either split Zone1 and Zone2 to separate panels or look towards
new Angular-based facilities.
On Tue, 19 Apr 2016 at 10:59, 严超 <yanchao...@gmail.com> wrote:

> Something like this GUI, two tab_group_class needed. Each tab contains a
> couple of tables.
> [image: 内嵌图片 1]
>
> *Best Regards！*
>
>
> *Chao Yan--About me ： http://about.me/chao_yan
> <http://about.me/chao_yan>*
>
> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
> *My Weibo： http://weibo.com/herewearenow <http://weibo.com/herewearenow>*
> *--*
>
> 2016-04-19 15:37 GMT+08:00 Timur Sufiev <tsuf...@mirantis.com>:
>
>> Horizon is moving away from showing more than one table on the same
>> page/tab, because it doesn't work well with pagination. So it's better to
>> reorganize your data to be coherent with how tabs work. By the way, do you
>> have a wireframe displaying how the overall picture should look like? I
>> suspect that you may have understood 'tab groups' differently from Horizon
>> notion of that thing.
>>
>> On Tue, 19 Apr 2016 at 10:20, 严超 <yanchao...@gmail.com> wrote:
>>
>>> Because I may need two groups of tables to display, each of the group
>>> may contain 5 or 6 tables. Is there any workaround for this case?
>>> Thank you very much for your replay.
>>>
>>> *Best Regards！*
>>>
>>>
>>> *Chao Yan--About me ： http://about.me/chao_yan
>>> <http://about.me/chao_yan>*
>>>
>>> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
>>> *My Weibo： http://weibo.com/herewearenow <http://weibo.com/herewearenow>*
>>> *--*
>>>
>>> 2016-04-19 14:29 GMT+08:00 Timur Sufiev <tsuf...@mirantis.com>:
>>>
>>>> Hello!
>>>>
>>>> Judging by
>>>> https://github.com/openstack/horizon/blob/master/horizon/tabs/views.py#L44
>>>> it wasn't designed to have more than 1 class. Why do you need it?
>>>> On Tue, 19 Apr 2016 at 06:32, 严超 <yanchao...@gmail.com> wrote:
>>>>
>>>>> HI, Everyone:
>>>>> Document says :
>>>>> .. attribute:: tab_group_class
>>>>>
>>>>>   The only required attribute for ``TabView``. It should
>>>>> be a class which
>>>>>   inherits from :class:`horizon.tabs.TabGroup`.
>>>>> """
>>>>> Can we have multiple tab groups in one page? Seems
>>>>> Tab_group_class only use one CLASS.
>>>>> Very grateful for answering.
>>>>>
>>>>>
>>>>> *Best Regards！*
>>>>>
>>>>>
>>>>> *Chao Yan--About me ： http://about.me/chao_yan
>>>>> <http://about.me/chao_yan>*
>>>>>
>>>>> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
>>>>> *My Weibo： http://weibo.com/herewearenow
>>>>> <http://weibo.com/herewearenow>**--*
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] Can we have multiple tab groups in one page?

[Timur Sufiev]

Horizon is moving away from showing more than one table on the same
page/tab, because it doesn't work well with pagination. So it's better to
reorganize your data to be coherent with how tabs work. By the way, do you
have a wireframe displaying how the overall picture should look like? I
suspect that you may have understood 'tab groups' differently from Horizon
notion of that thing.
On Tue, 19 Apr 2016 at 10:20, 严超 <yanchao...@gmail.com> wrote:

> Because I may need two groups of tables to display, each of the group may
> contain 5 or 6 tables. Is there any workaround for this case?
> Thank you very much for your replay.
>
> *Best Regards！*
>
>
> *Chao Yan--About me ： http://about.me/chao_yan
> <http://about.me/chao_yan>*
>
> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
> *My Weibo： http://weibo.com/herewearenow <http://weibo.com/herewearenow>*
> *--*
>
> 2016-04-19 14:29 GMT+08:00 Timur Sufiev <tsuf...@mirantis.com>:
>
>> Hello!
>>
>> Judging by
>> https://github.com/openstack/horizon/blob/master/horizon/tabs/views.py#L44
>> it wasn't designed to have more than 1 class. Why do you need it?
>> On Tue, 19 Apr 2016 at 06:32, 严超 <yanchao...@gmail.com> wrote:
>>
>>> HI, Everyone:
>>> Document says :
>>> .. attribute:: tab_group_class
>>>
>>>   The only required attribute for ``TabView``. It should be
>>> a class which
>>>   inherits from :class:`horizon.tabs.TabGroup`.
>>> """
>>> Can we have multiple tab groups in one page? Seems
>>> Tab_group_class only use one CLASS.
>>> Very grateful for answering.
>>>
>>>
>>> *Best Regards！*
>>>
>>>
>>> *Chao Yan--About me ： http://about.me/chao_yan
>>> <http://about.me/chao_yan>*
>>>
>>> *My twitter： @yanchao727 <https://twitter.com/yanchao727>*
>>> *My Weibo： http://weibo.com/herewearenow <http://weibo.com/herewearenow>*
>>> *--*
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Can we have multiple tab groups in one page?

[Timur Sufiev]

Hello!

Judging by
https://github.com/openstack/horizon/blob/master/horizon/tabs/views.py#L44
it wasn't designed to have more than 1 class. Why do you need it?
On Tue, 19 Apr 2016 at 06:32, 严超  wrote:

> HI, Everyone:
> Document says :
> .. attribute:: tab_group_class
>
>   The only required attribute for ``TabView``. It should be a
> class which
>   inherits from :class:`horizon.tabs.TabGroup`.
> """
> Can we have multiple tab groups in one page? Seems Tab_group_class
> only use one CLASS.
> Very grateful for answering.
>
>
> *Best Regards！*
>
>
> *Chao Yan--About me ： http://about.me/chao_yan
> *
>
> *My twitter： @yanchao727 *
> *My Weibo： http://weibo.com/herewearenow *
> *--*
> __
> 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] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

[Timur Sufiev]

+1
Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia :

> Im still not sure if non-cores (i.e. peasants like me) can vote but I
> will do it anyway :D
>
> A big +1 from me.
>
> Itxaka
>
> On 04/07/2016 12:01 PM, Matthias Runge wrote:
> > Hello,
> >
> > I'm proposing Rob Cresswell to become stable core for Horizon. I
> > thought, in the past all PTL were in stable team, but this doesn't seem
> > to be true any more.
> >
> > Please chime in with +1/-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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTL noncandidacy

[Timur Sufiev]

David,

It's sad news for us, and a well-deserved vacation from bureaucratic
hassles for you! Will try hard to not break Horizon in your absence.
On Mon, 14 Mar 2016 at 22:46, Doug Fish  wrote:

> David, congratulations on a job well done!
>
> Doug
>
> On Mar 14, 2016, at 8:39 AM, Liz Blanchard  wrote:
>
>
>
> On Fri, Mar 11, 2016 at 12:19 PM, David Lyle  wrote:
>
>> After five cycles as PTL of Horizon, I've decided not to run for the
>> Newton cycle.
>>
>
> David,
>
> Thank you for everything you've done for Horizon, especially around
> helping push a focus on User Experience.
>
> Best,
> Liz
>
>
>>
>> I am exceptionally proud of the things we've accomplished over this
>> time. I'm amazed by how much our project's community has grown and
>> evolved.
>>
>> Looking at the community now, I believe we have a tremendous group of
>> contributors for moving forward. There are several people capable of
>> becoming great PTLs and overall the community will be healthier with
>> some turnover in the PTL role. I feel honored to have had your trust
>> over this time and lucky to have worked with such great people.
>>
>> I will still be around and will help the next PTL make a smooth
>> transition where requested.
>>
>> David
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

[Timur Sufiev]

+1, Diana's contribution to the front-end aspect of Horizon during several
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones  wrote:

> +1 we need Diana's perspective, knowledge and enthusiasm
>
> On 9 March 2016 at 10:03, Tripp, Travis S  wrote:
>
>> +1, no questions asked. It is rare to find somebody with the passion that
>> Diana has shown.
>>
>> From: Lin Hua Cheng >
>> Reply-To: OpenStack List  openstack-dev@lists.openstack.org>>
>> Date: Tuesday, March 8, 2016 at 3:48 PM
>> To: OpenStack List  openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>>
>> big +1 from me.
>>
>> She made a lot of contribution in making theming better for horizon and
>> also prevented potential issues through reviews.
>> Thanks for all the hard work, Diana.
>>
>> -Lin
>>
>> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  dkly...@gmail.com>> wrote:
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Okay, with https://review.openstack.org/#/c/276123/ finally merged tests
should pass more predictably now. Please, recheck and reverify your patches
now. I hope that recheck/reverify alone is enough to consume merged test
fix, if I'm wrong please correct me.

On Thu, Feb 4, 2016 at 5:46 PM Timur Sufiev <tsuf...@mirantis.com> wrote:

> That has been a hard week for integration tests, as soon as API-breaking
> change in xvfbwrapper had been worked around, we have been hit by a new
> Selenium release, see https://bugs.launchpad.net/horizon/+bug/1541876
>
> Investigation of a root cause is still in progress.
>
> On Mon, Feb 1, 2016 at 11:31 PM Richard Jones <r1chardj0...@gmail.com>
> wrote:
>
>> Ugh, dependencies with breaking API changes in minor point releases :/
>>
>> On 2 February 2016 at 04:53, Timur Sufiev <tsuf...@mirantis.com> wrote:
>>
>>> Maintainers of outside dependencies continue to break our stuff :(. New
>>> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
>>> currently being checked by Jenkins
>>>
>>> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev <tsuf...@mirantis.com>
>>> wrote:
>>>
>>>> Problematic Selenium versions have been successfully excluded from
>>>> Horizon test-requirements, if you still experiencing the error described
>>>> above, rebase your patch onto the latest master.
>>>> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia <itx...@redhat.com>
>>>> wrote:
>>>>
>>>>> Can confirm, had the same issue locally, was fixed after a downgrade to
>>>>> selenium 2.48.
>>>>>
>>>>>
>>>>> Good catch!
>>>>>
>>>>> Itxaka
>>>>>
>>>>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>>>>> > According to the results at
>>>>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>>>>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>>>>> > here: https://review.openstack.org/#/c/273750/
>>>>> >
>>>>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev <tsuf...@mirantis.com
>>>>> > <mailto:tsuf...@mirantis.com>> wrote:
>>>>> >
>>>>> > Hello, Horizoneers
>>>>> >
>>>>> > You may have noticed recent integration tests failures seemingly
>>>>> > unrelated to you patches, with a stacktrace like:
>>>>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>>>>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>>>>> > Selenium issue, currently investigating it.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> __
>>>>> > OpenStack Development Mailing List (not for usage questions)
>>>>> > Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

That has been a hard week for integration tests, as soon as API-breaking
change in xvfbwrapper had been worked around, we have been hit by a new
Selenium release, see https://bugs.launchpad.net/horizon/+bug/1541876

Investigation of a root cause is still in progress.

On Mon, Feb 1, 2016 at 11:31 PM Richard Jones <r1chardj0...@gmail.com>
wrote:

> Ugh, dependencies with breaking API changes in minor point releases :/
>
> On 2 February 2016 at 04:53, Timur Sufiev <tsuf...@mirantis.com> wrote:
>
>> Maintainers of outside dependencies continue to break our stuff :(. New
>> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
>> currently being checked by Jenkins
>>
>> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev <tsuf...@mirantis.com>
>> wrote:
>>
>>> Problematic Selenium versions have been successfully excluded from
>>> Horizon test-requirements, if you still experiencing the error described
>>> above, rebase your patch onto the latest master.
>>> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia <itx...@redhat.com>
>>> wrote:
>>>
>>>> Can confirm, had the same issue locally, was fixed after a downgrade to
>>>> selenium 2.48.
>>>>
>>>>
>>>> Good catch!
>>>>
>>>> Itxaka
>>>>
>>>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>>>> > According to the results at
>>>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>>>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>>>> > here: https://review.openstack.org/#/c/273750/
>>>> >
>>>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev <tsuf...@mirantis.com
>>>> > <mailto:tsuf...@mirantis.com>> wrote:
>>>> >
>>>> > Hello, Horizoneers
>>>> >
>>>> > You may have noticed recent integration tests failures seemingly
>>>> > unrelated to you patches, with a stacktrace like:
>>>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>>>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>>>> > Selenium issue, currently investigating it.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> __
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Maintainers of outside dependencies continue to break our stuff :(. New
issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is currently
being checked by Jenkins

On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev <tsuf...@mirantis.com> wrote:

> Problematic Selenium versions have been successfully excluded from Horizon
> test-requirements, if you still experiencing the error described above,
> rebase your patch onto the latest master.
> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia <itx...@redhat.com>
> wrote:
>
>> Can confirm, had the same issue locally, was fixed after a downgrade to
>> selenium 2.48.
>>
>>
>> Good catch!
>>
>> Itxaka
>>
>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>> > According to the results at
>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>> > here: https://review.openstack.org/#/c/273750/
>> >
>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev <tsuf...@mirantis.com
>> > <mailto:tsuf...@mirantis.com>> wrote:
>> >
>> > Hello, Horizoneers
>> >
>> > You may have noticed recent integration tests failures seemingly
>> > unrelated to you patches, with a stacktrace like:
>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>> > Selenium issue, currently investigating it.
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Problematic Selenium versions have been successfully excluded from Horizon
test-requirements, if you still experiencing the error described above,
rebase your patch onto the latest master.
On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia <itx...@redhat.com>
wrote:

> Can confirm, had the same issue locally, was fixed after a downgrade to
> selenium 2.48.
>
>
> Good catch!
>
> Itxaka
>
> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
> > According to the results at
> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
> > greater than 2.49 fixes broken tests. Patch to global-requirements is
> > here: https://review.openstack.org/#/c/273750/
> >
> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev <tsuf...@mirantis.com
> > <mailto:tsuf...@mirantis.com>> wrote:
> >
> > Hello, Horizoneers
> >
> > You may have noticed recent integration tests failures seemingly
> > unrelated to you patches, with a stacktrace like:
> > http://paste2.org/2Hk9138U I've already filed a bug for that,
> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
> > Selenium issue, currently investigating it.
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

According to the results at https://review.openstack.org/#/c/273697/1 capping
Selenium to be not greater than 2.49 fixes broken tests. Patch to
global-requirements is here: https://review.openstack.org/#/c/273750/

On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev <tsuf...@mirantis.com> wrote:

> Hello, Horizoneers
>
> You may have noticed recent integration tests failures seemingly unrelated
> to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've
> already filed a bug for that,
> https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium
> issue, currently investigating it.
>
>
>
__
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] Recent integration tests failures

[Timur Sufiev]

Hello, Horizoneers

You may have noticed recent integration tests failures seemingly unrelated
to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've
already filed a bug for that,
https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium
issue, currently investigating it.
__
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] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Duncan,

Thank you for the suggestion, will do.
On Wed, 23 Dec 2015 at 10:55, Duncan Thomas <duncan.tho...@gmail.com> wrote:

> On a cloud with a large number of tenants, this is going to involve a
> large number of API calls. I'd suggest you put a spec into cinder to add an
> API call for getting the totals straight out of the DB - it should be easy
> enough to add.
>
> On 18 December 2015 at 20:35, Timur Sufiev <tsuf...@mirantis.com> wrote:
>
>> Matt,
>>
>> actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
>> that I needed. Now I know how to retrieve Cinder quota usage info
>> per-tenant, seems that to retrieve the same info cloud-wide I should sum up
>> all the available tenant usages.
>>
>> With Cinder quota usages being sorted out, my next goal is Nova and
>> Neutron. As for Neutron, there are plenty of quota-related calls I'm going
>> to play with next week, perhaps there is something suitable for my use
>> case. But as for Nova, I haven't found something similar to 'usage' of
>> cinderclient call, so help from someone familiar with Nova is very
>> appreciated :).
>>
>> [0]
>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
>>
>> On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <
>> mrie...@linux.vnet.ibm.com> wrote:
>>
>>>
>>>
>>> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>>> > Hi Timur,
>>> >
>>> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>>> >
>>> >
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
>>> > [2] http://paste.openstack.org/show/482225/
>>> >
>>> > Regards,
>>> > Ivan Kolodyazhny,
>>> > http://blog.e0ne.info/
>>> >
>>> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev <tsuf...@mirantis.com
>>> > <mailto:tsuf...@mirantis.com>> wrote:
>>> >
>>> > Hello, folks!
>>> >
>>> > I'd like to initiate a discussion of the feature request I'm going
>>> > to make on behalf of Horizon to every core OpenStack service which
>>> > supports Quota feature, namely Cinder, Nova and Neutron.
>>> >
>>> > Although all three services' APIs support special calls to get
>>> > current quota limitations (Nova and Cinder allows to get and update
>>> > both per-tenant and default cloud-wide limitations, Neutron allows
>>> > to do it only for per-tenant limitations), there is no special call
>>> > in any of these services to get current per-tenant usage of quota.
>>> > Because of that Horizon needs to get, say for 'volumes' quota, a
>>> > list of Cinder volumes in the current tenant and then just
>>> calculate
>>> > its length [1]. When there are really a lot of entities in tenant -
>>> > instances/volumes/security groups/whatever - all this calls sum up
>>> > and make rendering pages in Horizon much more slower than it could
>>> > be. Is it possible to provide special API calls to alleviate this?
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>>> >
>>> >
>>>  __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > <
>>> http://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
>>> >
>>>
>>> I think Timur is asking for a way to filter on only certain resources
>>> for quota usage/limits, like volumes in cinder or instances in nova,
>>> rather than getting back all resource usage/lim

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Hello, Matt

Just checked it, nova quota-show command just shows current quota limits
for a given tenant, below is an output for may Devstack admin tenant:

timur@devstack:~/devstack$ nova quota-show --tenant
9f6cc244fd9d41668d49c00f12b70219
+-+---+
| Quota   | Limit |
+-+---+
| instances   | 10|
| cores   | 20|
| ram | 51200 |
| floating_ips| 10|
| fixed_ips   | -1|
| metadata_items  | 128   |
| injected_files  | 5 |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes| 255   |
| key_pairs   | 100   |
| security_groups | 10|
| security_group_rules| 20|
| server_groups   | 10|
| server_group_members| 10|
+-+---+


On Sat, Dec 19, 2015 at 5:58 PM Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 12/18/2015 12:35 PM, Timur Sufiev wrote:
> > Matt,
> >
> > actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient
> > call that I needed. Now I know how to retrieve Cinder quota usage info
> > per-tenant, seems that to retrieve the same info cloud-wide I should sum
> > up all the available tenant usages.
> >
> > With Cinder quota usages being sorted out, my next goal is Nova and
> > Neutron. As for Neutron, there are plenty of quota-related calls I'm
> > going to play with next week, perhaps there is something suitable for my
> > use case. But as for Nova, I haven't found something similar to 'usage'
> > of cinderclient call, so help from someone familiar with Nova is very
> > appreciated :).
> >
> > [0]
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
> >
> > On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann
> > <mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote:
> >
> >
> >
> > On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
> >  > Hi Timur,
> >  >
> >  > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
> >  >
> >  >
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
> >  > [2] http://paste.openstack.org/show/482225/
> >  >
> >  > Regards,
> >  > Ivan Kolodyazhny,
> >  > http://blog.e0ne.info/
> >  >
> >  > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev
> > <tsuf...@mirantis.com <mailto:tsuf...@mirantis.com>
> >  > <mailto:tsuf...@mirantis.com <mailto:tsuf...@mirantis.com>>>
> wrote:
> >  >
> >  > Hello, folks!
> >  >
> >  > I'd like to initiate a discussion of the feature request I'm
> > going
> >  > to make on behalf of Horizon to every core OpenStack service
> > which
> >  > supports Quota feature, namely Cinder, Nova and Neutron.
> >  >
> >  > Although all three services' APIs support special calls to get
> >  > current quota limitations (Nova and Cinder allows to get and
> > update
> >  > both per-tenant and default cloud-wide limitations, Neutron
> > allows
> >  > to do it only for per-tenant limitations), there is no
> > special call
> >  > in any of these services to get current per-tenant usage of
> > quota.
> >  > Because of that Horizon needs to get, say for 'volumes'
> quota, a
> >  > list of Cinder volumes in the current tenant and then just
> > calculate
> >  > its length [1]. When there are really a lot of entities in
> > tenant -
> >  > instances/volumes/security groups/whatever - all this calls
> > sum up
> >  > and make rendering pages in Horizon much more slower than it
> > could
> >  > be. Is it possible to provide special API calls to alleviate
> > this?
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  &g

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Matt,

actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
that I needed. Now I know how to retrieve Cinder quota usage info
per-tenant, seems that to retrieve the same info cloud-wide I should sum up
all the available tenant usages.

With Cinder quota usages being sorted out, my next goal is Nova and
Neutron. As for Neutron, there are plenty of quota-related calls I'm going
to play with next week, perhaps there is something suitable for my use
case. But as for Nova, I haven't found something similar to 'usage' of
cinderclient call, so help from someone familiar with Nova is very
appreciated :).

[0]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36

On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
> > Hi Timur,
> >
> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
> >
> >
> >
> > [1]
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
> > [2] http://paste.openstack.org/show/482225/
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
> >
> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev <tsuf...@mirantis.com
> > <mailto:tsuf...@mirantis.com>> wrote:
> >
> > Hello, folks!
> >
> > I'd like to initiate a discussion of the feature request I'm going
> > to make on behalf of Horizon to every core OpenStack service which
> > supports Quota feature, namely Cinder, Nova and Neutron.
> >
> > Although all three services' APIs support special calls to get
> > current quota limitations (Nova and Cinder allows to get and update
> > both per-tenant and default cloud-wide limitations, Neutron allows
> > to do it only for per-tenant limitations), there is no special call
> > in any of these services to get current per-tenant usage of quota.
> > Because of that Horizon needs to get, say for 'volumes' quota, a
> > list of Cinder volumes in the current tenant and then just calculate
> > its length [1]. When there are really a lot of entities in tenant -
> > instances/volumes/security groups/whatever - all this calls sum up
> > and make rendering pages in Horizon much more slower than it could
> > be. Is it possible to provide special API calls to alleviate this?
> >
> > [1]
> >
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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
> >
>
> I think Timur is asking for a way to filter on only certain resources
> for quota usage/limits, like volumes in cinder or instances in nova,
> rather than getting back all resource usage/limits per tenant.
>
> Is that correct, Timur?
>
> While it's possible to add this, I'm not sure how much time it's
> actually going to save in the DB query time to get the quota information
> for a tenant.
>
> Anyway, it's an API change so it would require a spec for nova which
> means we wouldn't be getting to that until at least N since we're in
> spec freeze for mitaka.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Hello, folks!

I'd like to initiate a discussion of the feature request I'm going to make
on behalf of Horizon to every core OpenStack service which supports Quota
feature, namely Cinder, Nova and Neutron.

Although all three services' APIs support special calls to get current
quota limitations (Nova and Cinder allows to get and update both per-tenant
and default cloud-wide limitations, Neutron allows to do it only for
per-tenant limitations), there is no special call in any of these services
to get current per-tenant usage of quota. Because of that Horizon needs to
get, say for 'volumes' quota, a list of Cinder volumes in the current
tenant and then just calculate its length [1]. When there are really a lot
of entities in tenant - instances/volumes/security groups/whatever - all
this calls sum up and make rendering pages in Horizon much more slower than
it could be. Is it possible to provide special API calls to alleviate this?

[1]
https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev tohorizon-core

[Timur Sufiev]

David and all the fellow Horizoneers,

Thank you very much for the trust you put in me :). I'll do my best to be
up to it!

On Tue, 8 Dec 2015 at 22:47, David Lyle <dkly...@gmail.com> wrote:

> Since the results are unanimous, closing early. Welcome Timur!
>
> David
>
> On Thu, Dec 3, 2015 at 12:06 PM, Thai Q Tran <tqt...@us.ibm.com> wrote:
> > BIG +1 for me. Thanks for all of the great work Timur!
> >
> >
> > - Original message -
> > From: David Lyle <dkly...@gmail.com>
> > To: OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> > Cc:
> > Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to
> > horizon-core
> > Date: Wed, Dec 2, 2015 10:54 AM
> >
> > I propose adding Timur Sufiev[1] to horizon-core.
> >
> > Over the last several cycles Timur has consistently been providing
> > great reviews, actively participating in the Horizon community, and
> > making meaningful contributions particularly around testing and
> > stability.
> >
> > Please respond with comments, +1s, or objections within one week.
> >
> > Thanks,
> > David
> >
> > [1]
> >
> http://stackalytics.com/?module=horizon-group_id=tsufiev-x=all
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [QA] Improving Horizon Integration Tests

[Timur Sufiev]

Hello, folks!

As you probably already know, integration tests were recently made voting
again in Horizon. Next logical step in ensuring Horizon/OpenStack stability
is increasing their coverage. I've reworked initial GoogleDoc version of
tests breakdown (wasn't very popular due to the restricted access) as an
etherpad doc [1].

First I suggest to discuss it inline,
* leaving your '+1' marks (if the test case seems really important to you)
inline -> this will help us to prioritize the further work (in a manner
similar we usually prioritize topics for summit)
* or making comments about some tests being excessive/ unnecessary/ missing

Then, once we consider the tests breakdown mature enough, it will be used
for coordination of work, so developers won't write the same test
simultaneously. Finally, this will be used for reviewing purposes (what
test should I review first? - again, as we already do with release cycle
priorities in Horizon), embedding the bug/ review link into the general
document.

In the meantime, I'm going to write additional docs about writing
integration tests.  There is already a good starting section [2], but it's
more aimed for experienced developers, who need debugging clues. So, that
is another area where your feedback is greatly appreciated. If you ever
have tried writing an integration test in Horizon and went away feeling
confused and lost, please describe what was the greatest source of your
confusion.

[1] https://etherpad.openstack.org/p/horizon-integration-tests
[2] https://review.openstack.org/#/c/238959/
__
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]

[Timur Sufiev]

Please take a look at
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload

On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov  wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
> __
> 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] [horizon]

[Timur Sufiev]

It all depends on Glance support, you'd better ask them.

On Thu, Dec 3, 2015 at 7:08 PM Kyrylo Galanov <kgala...@mirantis.com> wrote:

> Looks great. What is the estimated date / release for this feature to be
> delivered?
>
> On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev <tsuf...@mirantis.com> wrote:
>
>> Please take a look at
>> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
>>
>> On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov <kgala...@mirantis.com>
>> wrote:
>>
>>> Hello,
>>>
>>> When a file is uploaded to Glance, Swift through Horizon it is stored
>>> locally in a temporary directory in Horizon server. This is inefficient
>>> approach especially for big files.
>>>
>>> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
>>> buffer instead of storing a file locally. It would eliminate such drawbacks
>>> as potential free space exhaustion.
>>>
>>> It would be awesome to add upload progress bar as well.
>>>
>>> I look forward to your constructive replies.
>>>
>>> Best regards,
>>> Kyrylo
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-core

[Timur Sufiev]

Well, I'm not sure if I'm eligible to chime in (yet), but IMO Richard is
the first candidate here (and me is the second one) :).

On Wed, Dec 2, 2015 at 9:59 PM Rob Cresswell (rcresswe) 
wrote:

> An equally big +1!
>
> On 02/12/2015 18:56, "David Lyle"  wrote:
>
> >I propose adding Richard Jones[1] to horizon-core.
> >
> >Over the last several cycles Timur has consistently been providing
> >great reviews, actively participating in the Horizon community, and
> >making meaningful contributions around angularJS and overall project
> >stability and health.
> >
> >Please respond with comments, +1s, or objections within one week.
> >
> >Thanks,
> >David
> >
> >[1]
> >
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s
> >=all
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Timur Sufiev]

Count me in as well.

On Mon, Nov 23, 2015 at 1:53 PM Martin Pavlásek  wrote:

> Count with me tomorrow! :-)
>
>
> Martin
>
>
>
> On 20/11/15 01:02, Lin Hua Cheng wrote:
>
> Great, I'll be around next Tuesday.
>
> -Lin
>
> On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe) <
> rcres...@cisco.com> wrote:
>
>> As requested,
>> https://etherpad.openstack.org/p/horizon-bug-day
>>
>> Rob
>>
>> From: Richard Jones 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday, 19 November 2015 20:39
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Horizon] Bug day! Yeah!
>>
>> Let's do it. I'd like to suggest we use an etherpad to keep track of what
>> people have done. If it's not created when I start my day, I'll make one.
>>
>>
>>  Richard
>>
>> On 19 November 2015 at 22:19, Rob Cresswell (rcresswe) <
>> rcres...@cisco.com> wrote:
>>
>>> Hey folks,
>>>
>>> Our bug list is… rather large. We’ve discussed having a bug day, where
>>> as a community we all dedicate some time to triaging bugs and discussing in
>>> the IRC channel as we go.
>>>
>>> First off, see the docs about bug triage:
>>> https://wiki.openstack.org/wiki/BugTriage
>>>
>>> Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if
>>> that doesn’t work for a good number of us, then the following Tuesday (1st
>>> December). Trying to account for Thanksgiving :)
>>>
>>> Rob
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] unit test improvements: work with DOM, not raw HTML strings?

[Timur Sufiev]

+1 here. While the exact library choice may still be a topic for the
discussion, unit tests clearly shouldn't hardcode html stings inside, it is
too fragile.
On Fri, 23 Oct 2015 at 02:00, Diana Whitten  wrote:

> Richard,
>
> I'm absolutely with you ... I've been bitten by these very tests recently
> when changing a class in a simple template.  If anyone wants to override
> these templates in the future, then they are forced to fight this
> 'expected_string' test as well.
>
> I think this is a good idea.
>
> - Diana
>
> On Thu, Oct 22, 2015 at 3:52 PM, Richard Jones 
> wrote:
>
>> Hi all,
>>
>> I've noticed that we have quite a few places in our unit test suite that
>> test for correctness of behaviour by searching for quite complex HTML
>> fragments in page renders. An example would be
>> openstack_dashboard/dashboards/project/access_and_security/floating_ips/tests.py
>>
>> (there's plenty more - search for "expected_string")
>>
>> The code in question is testing far more than it should. We are testing
>> for the presence of the "disabled" class in an element which has a clear id
>> attribute by constructing the whole element HTML, including label and title
>> text, glyph icon, other classes, the tag type itself, etc. All of those
>> things are quite irrelevant to the test in question, but any change to
>> those will cause the test to break unnecessarily.
>>
>> In these cases a far more robust and targeted unit test would construct a
>> DOM from the rendered HTML and use semantic searches to determine the
>> correctness of behaviour. I would recommend we consider using something
>> like https://django-with-asserts.rtfd.org/ which allow us to write:
>>
>>  with self.assertHTML(res, element_id='security_groups__action_create')
>> as elem:
>> self.assertContains(elem.attrib['class'], 'disabled')
>>
>> Who's with me?
>>
>>
>> Richard
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [Cinder] [Keystone] Showing Cinder quotas for non-admin users in Horizon

[Timur Sufiev]

If I understand correctly, the issue has been properly fixed with the
Ivan's patch [1]. Thanks, Ivan!

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

On Wed, Sep 16, 2015 at 2:53 PM Ivan Kolodyazhny <e...@e0ne.info> wrote:

> Hi Timur,
>
> To get quotas  we need to retrieve project information from the
> Keystone. Unfortunately, Keystone set "admin_required" rule by default [1]
> in their API. We can handle it and raise 403 if Keystone return this error
> only.
>
> [1] https://github.com/openstack/keystone/blob/master/etc/policy.json#L37
>
> Regards,
> Ivan Kolodyazhny
>
> On Mon, Sep 14, 2015 at 1:49 PM, Timur Sufiev <tsuf...@mirantis.com>
> wrote:
>
>> Hi all!
>>
>> It seems that recent changes in Cinder policies [1] forbade non-admin
>> users to see the disk quotas. Yet the volume creation is allowed for
>> non-admins, which effectively means that from now on a volume creation in
>> Horizon is free for non-admins (as soon as quotas:show rule is propagated
>> into Horizon policies). Along with understanding that this is not a desired
>> UX for Volumes panel in Horizon, I know as well that [1] wasn't responsible
>> for this quota behavior change on its own. It merely tried to alleviate the
>> situation caused by [2], which changed the requirements of quota show being
>> authorized. From this point I'm starting to sense that my knowledge of
>> Cinder and Keystone (because the hierarchical feature is involved) is
>> insufficient to suggest the proper solution from the Horizon point of view.
>> Yet hiding quota values from non-admin users makes no sense to me.
>> Suggestions?
>>
>> [1] https://review.openstack.org/#/c/219231/7/etc/cinder/policy.json line
>> 36
>> [2]
>> https://review.openstack.org/#/c/205369/29/cinder/api/contrib/quotas.py line
>> 135
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] [Cinder] [Keystone] Showing Cinder quotas for non-admin users in Horizon

[Timur Sufiev]

Hi all!

It seems that recent changes in Cinder policies [1] forbade non-admin users
to see the disk quotas. Yet the volume creation is allowed for non-admins,
which effectively means that from now on a volume creation in Horizon is
free for non-admins (as soon as quotas:show rule is propagated into Horizon
policies). Along with understanding that this is not a desired UX for
Volumes panel in Horizon, I know as well that [1] wasn't responsible for
this quota behavior change on its own. It merely tried to alleviate the
situation caused by [2], which changed the requirements of quota show being
authorized. From this point I'm starting to sense that my knowledge of
Cinder and Keystone (because the hierarchical feature is involved) is
insufficient to suggest the proper solution from the Horizon point of view.
Yet hiding quota values from non-admin users makes no sense to me.
Suggestions?

[1] https://review.openstack.org/#/c/219231/7/etc/cinder/policy.json line 36
[2] https://review.openstack.org/#/c/205369/29/cinder/api/contrib/quotas.py
line
135
__
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] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Timur Sufiev]

I went forward and filed a bug for this issue (since we agreed that it
should be fixed): https://bugs.launchpad.net/horizon/+bug/1494251
The code is already in gerrit (see links in bug), feel free to review.

On Fri, Jul 10, 2015 at 1:51 AM Douglas Fish <drf...@us.ibm.com> wrote:

> I think another important question is how to represent this to the user on
> the login screen. "Keystone Endpoint:" matches the setting, but seems like
> a weird choice to me. Is there a better terminology to use for the label
> for this on the login screen?
>
> I see the related selector has no label at all in the header. Maybe using
> the same label there would be a good idea.
>
> Doug
>
> Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM:
>
> > From: Thai Q Tran/Silicon Valley/IBM@IBMUS
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > <openstack-dev@lists.openstack.org>
> > Date: 07/09/2015 01:17 PM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
> >
> > Had the same issue when I worked on the context selection menu for
> > switching domain and project. I think it make sense to rename it to
> > AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its
> > going to affect some folks (maybe even break) until they also update
> > their setting, something that would have to be done manually.
> >
> > -Jay Pipes <jaypi...@gmail.com> wrote: -
> > To: openstack-dev@lists.openstack.org
> > From: Jay Pipes <jaypi...@gmail.com>
> > Date: 07/08/2015 07:14AM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
>
> > Got it, thanks for the excellent explanation, Timur! Yeah, I think
> > renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.
> >
> > Best,
> > -jay
> >
> > On 07/08/2015 09:53 AM, Timur Sufiev wrote:
> > > Hi, Jay!
> > >
> > > As Doug said, Horizon regions are just different Keystone endpoints
> that
> > > Horizon could use to authorize against (and retrieve the whole catalog
> > > from any of them afterwards).
> > >
> > > Another example of how complicated things could be: imagine that
> Horizon
> > > config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
> > > http://keystone.europe and http://keystone.asia, each of them hosting
> a
> > > different catalog with service endpoint pointing to Europe/Asia located
> > > services. For European Keystone all Europe-based services are marked as
> > > 'RegionOne', for Asian Keystone all its Asia-based services are marked
> > > as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
> > > region, for European Keystone the Asian services are marked so, for
> > > Asian Keystone the opposite is true. One of customers did roughly the
> > > same thing (with both Keystones using common LDAP backend), and
> > > understanding what exactly in Horizon didn't work well was a puzzling
> > > experience.
> > >
> > > On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes <jaypi...@gmail.com
> > > <mailto:jaypi...@gmail.com>> wrote:
> > >
> > > On 07/08/2015 08:50 AM, Timur Sufiev wrote:
> > >  > Hello, folks!
> > >  >
> > >  > Somehow it happened that we have 2 different kinds of regions:
> the
> > >  > service regions inside Keystone catalog and AVAILABLE_REGIONS
> setting
> > >  > inside Horizon, yet use the same name 'regions' for both of
> them.
> > > That
> > >  > creates a lot of confusion when solving some
> region-relatedissues at
> > >  > the Horizon/Keystone junction, even explaining what is exactly
> being
> > >  > broken poses a serious challenge when our common language has
> > > such a flaw!
> > >  >
> > >  > I propose to invent 2 distinct terms for these entities, so at
> > > least we
> > >  > won't be terminologically challenged when fixing the related
> bugs.
> > >
> > > Hi!
> > >
> > > I understand what the Keystone region represents: a simple,
> > > non-geographically-connotated division of the entire OpenStack
> > > deployment.
> > >
> > > Unfortunately, I don't know what the Horizon regions represent.
> Could
> > > you explain?
> > >

Re: [openstack-dev] [Neutron] [horizon] Netaddr 0.7.16 and gate breakage

[Timur Sufiev]

Given that Horizon unit test breakage was introduced simultaneously with
the breakage of 2 integration tests, the latter ones have the same nature.
Thus integration tests are going to fail until the related Neutron patch is
merged.

On Mon, Aug 31, 2015 at 5:50 PM Akihiro Motoki  wrote:

> For Horizon, the fix is now in the gate queue.
> https://review.openstack.org/#/c/218786/
> It only skips the related test, but the failing test is specific to vendor
> plugin implementation
> and we can explore the fix later.
>
> Regarding the stable releases, Horizon may also need the similar version
> cap for what we did for Neutron.
> I will check it.
>
> Akihiro
>
> 2015-08-31 20:54 GMT+09:00 Sean Dague :
>
>> On 08/31/2015 06:48 AM, Ihar Hrachyshka wrote:
>> >> On 31 Aug 2015, at 08:19, Kevin Benton  wrote:
>> >>
>> >> Even if this version is fixed for valid_mac, it appears the netaddr
>> authors made the decision to make a backwards incompatible change WRT to
>> the 'broadcast' attribute on IPNetwork objects that have CIDRs of /31 and
>> /32. This means that all future versions of netaddr will be incompatible
>> with the current releases of Neutron.
>> >>
>> >> I have a fix for master here: https://review.openstack.org/#/c/218723/,
>> but we will need to cap netaddr in global requirements for kilo and juno
>> and then consider back-porting the changes. Additionally, we should
>> probably release a note indicating that upgrading netaddr is disastrous for
>> all released versions of openstack using Neutron.
>> >>
>> >> Cheers
>> >
>> > For Juno, we already cap the version of the library to <= 0.7.13. As
>> for kilo, I pushed the following change:
>> https://review.openstack.org/#/c/218805/
>>
>> This looks like it's tanking Horizon unit tests as well -
>>
>> http://logs.openstack.org/00/207800/1/gate/gate-horizon-python27/980e8a1/console.html#_2015-08-31_11_36_16_378
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Timur Sufiev]

IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity-Users, since most likely production-grade OpenStack installations
will have LDAP instead of MySQL storage. So I'm for gathering more
operators/deployers feedback on the pagination (Users panel particularly).

I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but because
LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of course,
'unavoidable' thing is open to discussion.

On Tue, Aug 18, 2015 at 6:30 AM Adam Young ayo...@redhat.com wrote:

 On 08/17/2015 09:53 PM, David Lyle wrote:

 I think we've conveniently been led off track here. The original
 request/subject was regarding pagination of projects in the v3 API. Since
 this is purely a keystone construct it seems implausible to me that ldap or
 the IdP of choice would be limiting the ability to return a paginated list
 of all projects. Or groups or domains or roles for that matter.


 Yeah, SQL can support it.  LDAP assignment can't.  But that is not going
 to have a long life.

 With Hierarchical projects, we'll probably also have to keep nesting in
 mind for how we display a project list:  do we always show a flat list, or
 is a tree closer to what users expect?

 Both are going to work poorly for some deployments and work well for
 others.


 There is no reason to punt on pagination across the API for one resource
 type, which actually would also work with select backends. Give me
 something that I can exhaustively list in the API I can build from.

 David
 On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov wrote:

 1. yes, but probably only if its a short list. It may be feasible to show
 it only if there are 5 or less pages, and maybe just load all pages of data
 and paginate it on the client. If too big, ask the user to refine their
 search? Or always paginate to 5, and then the 6th page have a page
 requesting further refinement?

 2. Not sure what the difference between searching and filtering is in
 this context? something like facets? If so, probably the 5 or less thing
 would work here too.

 3. Yes, but again, probably within a smaller set of pages?

 Thanks,
 Kevin
 
 From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
 Sent: Sunday, August 16, 2015 9:41 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
 for Identity dashboard entities

 I like Michael’s response because it moved the thread towards identifying
 actual user needs before digging into the technical feasibility.  IMHO, it
 would be helpful to have a few people on the list answer his questions:

 1 - Do users want to page through search results?


 2 - Do users want to page through filter results? (do they use filter
 results?)


 3 - If they want to page, do they want to be able to go back a page
 and/or know their current page?


 I understand that even if we answer “yes” to all three questions that
 there could be issues around implementation, but at least we’ll know a gap
 exists.


 Piet Kruithof
 Sr UX Architect, HP Helion Cloud
 PTL, OpenStack UX project

 For every complex problem, there is a solution that is simple, neat and
 wrong.”

 H L Menken


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

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



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


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

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

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Timur Sufiev]

Morgan,

Your reasoning is perfectly fine from the Keystone point of view. Yet I
believe this approach is harmful for both Horizon and the whole OpenStack
ecosystem.

It is harmful for the ecosystem, because it breaks API uniformity in one of
the few areas where this uniformity could be achieved. Imagine if Nova or
Cinder start saying the same thing: we have too much drivers/backends to
provide the uniform interface for all of them, let's delegate the choice of
handling them differently to our consumers. It'll propagate the knowledge
of different backends throughout the stack and it's obviously not good.

Not having pagination on Identity-Users page means that even with
filtering being fully supported there will be problems. At least the first
time the Users page with all the Users piped from production-grade LDAP
through Keystone is shown in Horizon, it takes a lot time to render them
all (before an unhappy admin had any chance to narrow the list), which
eventually may result in connection being dropped by some HA balancer. We
did these kinds of tests, the results weren't reassuring. Well, I might
miss some of new Horizon angularization steps, so please regard this
paragraph as my personal opinion - I don't think Horizon could be lighting
fast on its own (i.e. without additional services) with a lot of data
without pagination.

On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 For the identity (users and groups) backend as long as we support LDAP
 (and as side note federated users never show up in this list anyway) and
 with the drive towards pushing all user management out of keystone itself
 to ldap or other tools that do it better, I don't see pagination as
 something we should be providing. Providing an inconsistent user experience
 based on leaking underlying implementation details is something I am very
 against. This stance ensures that horizon and other tools like it will not
 need to know underlying implementation details to provide a consistent user
 experience. Unfortunately here we do need to cater to the lowest common
 denominator and filtering/searching/limiting is the clear common mechanism

 With regards to resources (projects, domains, etc) since we no longer
 support using LDAP (deprecated with removal in mitaka) I have less strong
 feelings towards and wouldn't block efforts to implement if it is not
 already available (if not available this is likely a mitaka goal).

 --Morgan

 Sent via mobile

  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination is not a good UX even
  where it works - the simple question is: if you can filter the results
  how many pages deep do you go before refining the query; think of your
  use of search engines.
 
  In light of these issues Keystone has opted for a filter / limit
  (config). If the results exceed the limit there is a truncation that
  occurs and it is recommended extra filtering be applied to reduce the
  total number of results.
 
  This discussion has gone around a few times, pagination in keystone is
  not currently on the roadmap. In addition to the above doc bug, we
  should work to better socialize this filter-over-paginate methodology.
 
  I understand all the things you write above about the problems that
 Keystone's underlying architecture (driver-based, not always able to do
 pagination in the individual drivers). However, it really does mean that
 Keystone is the only project in OpenStack that behaves this way. All other
 services provide limit/marker paginations, AFAIK, which is efficient and,
 while not the same UX as a filtering methodology, is entirely compatible
 and complementary to filtering.
 
  Best,
  -jay
 
 
 __
  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 

[openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Timur Sufiev]

Hello, Keystone folks!

I've just discovered an unfortunate fact that Horizon pagination for
Tenants/Projects list that worked with Keystone v2 doesn't work with
Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
parameters [1] that Horizon is relying upon. Meanwhile having looked
through [2] and [3] I'm a bit confused: while Keystone v3 API states it
supports [2] pagination for every kind of entities (by using 'page' and
'per_page' parameters), the related blueprint [3] is not yet approved,
meaning that most likely the API implementation did not make it into
existing Keystone codebase. So I wonder whether there are some plans to
implement pagination for Keystone API calls that list its entities?

P.S. I'm aware of SearchLight project that tries to help Horizon with other
OpenStack APIs (part of its mission), what I'm trying to understand here is
are we going to have some fallback pagination mechanism for Horizon's
Identity in a short-term/mid-term perspective.

[1] http://developer.openstack.org/api-ref-identity-admin-v2.html
[2] http://developer.openstack.org/api-ref-identity-v3.html
[3] https://blueprints.launchpad.net/keystone/+spec/pagination
__
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] [Keystone] [Horizon] UI for Keystone dynamic policies editing

[Timur Sufiev]

Hello, folks!

A word has come to me that on the recent Keystone mid-cycle summit dynamic
policies have been discussed - as well as the lack of means to edit them in
UX-friendly manner. I had my own share of editing *_policy.json files
inside openstack_dashboard/conf and can hardly state it's easy. At least,
when dynamic policies are fully supported by all OpenStack services we will
have no longer to edit the same files on every controller node in case of
HA installations. Still, the problem of editing a single policy file
remains. AFAIK, the obscurity of policy rules' format had lead may
deployers to the copy-pasting existing rules with minimal changes - when
they were meant to a flexible tool for RBAC definitions.

But I wouldn't write this letter, if I didn't have some kind of solution to
the task of editing the policies. During my work on Merlin
framework/Mistral Workbook Builder I've achieved some results that might be
useful for a Keystone community. More specifically, visual structure and
type of relations between Workbook entities appeared to me to be similar to
the entities of Keystone policies. Understanding that some things are
better seen in dynamic than in static screenshots, I'm sharing the address
of the VM where the Workbook builder is deployed inside Horizon:
http://horizon-merlin.mirantis.com/horizon/project/ Credentials are
demo/demo. Some features like saving the workbooks to db or the rest
OpenStack control plane are disabled for security reasons, leaving only the
Workbook Builder UI there.

I'd like to start the discussion about the extent of reusing Merlin UI
elements for making a dynamic policies editor.
__
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] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Timur Sufiev]

Hi, Jay!

As Doug said, Horizon regions are just different Keystone endpoints that
Horizon could use to authorize against (and retrieve the whole catalog from
any of them afterwards).

Another example of how complicated things could be: imagine that Horizon
config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
http://keystone.europe and http://keystone.asia, each of them hosting a
different catalog with service endpoint pointing to Europe/Asia located
services. For European Keystone all Europe-based services are marked as
'RegionOne', for Asian Keystone all its Asia-based services are marked as
'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo' region,
for European Keystone the Asian services are marked so, for Asian Keystone
the opposite is true. One of customers did roughly the same thing (with
both Keystones using common LDAP backend), and understanding what exactly
in Horizon didn't work well was a puzzling experience.

On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes jaypi...@gmail.com wrote:

 On 07/08/2015 08:50 AM, Timur Sufiev wrote:
  Hello, folks!
 
  Somehow it happened that we have 2 different kinds of regions: the
  service regions inside Keystone catalog and AVAILABLE_REGIONS setting
  inside Horizon, yet use the same name 'regions' for both of them. That
  creates a lot of confusion when solving some region-related issues at
  the Horizon/Keystone junction, even explaining what is exactly being
  broken poses a serious challenge when our common language has such a
 flaw!
 
  I propose to invent 2 distinct terms for these entities, so at least we
  won't be terminologically challenged when fixing the related bugs.

 Hi!

 I understand what the Keystone region represents: a simple,
 non-geographically-connotated division of the entire OpenStack deployment.

 Unfortunately, I don't know what the Horizon regions represent. Could
 you explain?

 Best,
 -jay

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

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

[openstack-dev] [Horizon] [UX] [Glance] Enabling Horizon-Glance images streaming: request for early feedback

[Timur Sufiev]

Hi folks!

Some of you might had hit the problems with uploading large Glance images
via Horizon, the problem was so well known that it got its own solution
in Horizon settings named HORIZON_IMAGES_ALLOW_UPLOAD. So the exact problem
is that large images being uploaded to Glance via Horizon may easily
exhaust the place on controller node where Horizon server is located -
because any sufficiently large file is put into /tmp folder by Django.

It seems that I have found more-or-less decent solution [1], I've tested it
with 600MB file and it works. I'd like to ask any of you who are willing to
get rid of this issue for some early technical feedback. Well, the tests
are still failing, I'm aware of this - just want to know that I'm heading
in a right direction.

Another issue that may be exposed with this solution is how the
long-running requests in Horizon should be done from the UX point of view.
If an asynchronous request that takes ~several hours to complete needs the
Horizon page to remain opened, how should we prevent the user from leaving
that page?

[1] https://review.openstack.org/#/c/166969
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] [tests] [dsvm] Tests failed because of timeout during the images upload

[Timur Sufiev]

Timur,

If old jQuery code (not AngularJS) is still used for processing 'Create
Image' form, then the spinner is shown just before submitting the form
contents [1] and hidden right after the request completes [2] in case the
form is being redrawn or the whole page is redrawn in case of redirect -
which in case of Image means that it was successfully created. Speaking of
your scenario it should be redirect. It could mean that either the request
to server takes too long, or the redirect doesn't redraw the page.

[1]
https://github.com/openstack/horizon/blob/2f7a2dd891396f848278dc1bc2216e5720b602f6/horizon/static/horizon/js/horizon.modals.js#L229
[2]
https://github.com/openstack/horizon/blob/2f7a2dd891396f848278dc1bc2216e5720b602f6/horizon/static/horizon/js/horizon.modals.js#L232
[3]
https://github.com/openstack/horizon/blob/2f7a2dd891396f848278dc1bc2216e5720b602f6/horizon/static/horizon/js/horizon.modals.js#L245

On Tue, Jun 16, 2015 at 12:31 PM Matthias Runge mru...@redhat.com wrote:

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

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

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

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

 Matthias


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

__
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] [merlin] [horizon] [heat] [mistral] Merlin HotBuilder - what's next?

[Timur Sufiev]

Hello there!

First, for those of you who hadn't been at Horizon design session where I
was telling  showing the Merlin framework, here is the related etherpad
[1] and the demo slides themselves [2]. Merlin wasn't the only thing shown
at that design session, I hope that some video of HotBuilder demo Drago was
showing there will soon appear in this thread.

So, the good news: the next big thing we're going to implement is to adopt
the Merlin framework as an UI toolkit for HotBuilder project (UI for
composing HOT templates using both diagrams and forms with suggestions 
validations). Thus the overarching goal for Merlin - provide a reusable
toolkit for every OpenStack project's UI which heavily relies upon YAML
templates editing - is starting to come true. (Given that we've already got
quite decent Mistral Workbook Builder UI built with Merlin). That's the
very-very high-level roadmap for Merlin project for the Liberty release
cycle, I promise to come up with a more detailed roadmap soon.

Also it seems to me that Horizon folks are still quite fine with including
Merlin toolkit as a part of core Horizon, since Merlin brings additional
value into it (consider it as a general framework for YAML-editing
widgets). They just need to take a look at it [3].

Moreover I believe that not only people in Mirantis  Rackspace are
interested in making HotBuilder available as part of upstream OpenStack. So
I'd like to reach out to every UI developer who's willing to facilitate the
adoption of Merlin (and all good Angular.js things practiced in Horizon) in
HotBuilder = making HotBuilder a Horizon plugin which is well-documented,
has a clearly understandable codebase and a good set of tests = and is
easily maintainable [by the community, eventually]. Happy hacking to us all
:).

[1] https://etherpad.openstack.org/p/YVR-horizon-new-tech
[2]
https://docs.google.com/presentation/d/1Xf9urNOOKIRL8VmvBM1fDVbgPdIbhTFyLdb2AqZYaDw/edit#slide=id.p
[3] https://etherpad.openstack.org/p/YVR-horizon-collab-meetup line 57
-- 
Timur Sufiev
__
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] [Merlin] Cannot log into the dashboard

[Timur Sufiev]

Hello, Fablo!

Sorry, it was my fault :(. In one of the most recent commits I've added
persistent storage of Mistral workbooks via Django models - and to enable
them, you must add add a DATABASES setting to openstack_dashboard.settings
module as described at
https://docs.djangoproject.com/en/1.8/ref/settings/#databases (use sqlite3
driver)

This change is a temporary one - just as we'll have a real Mistral API
backing up the Merlin, I'll remove these models, because they're contrary
to how things are done in the Horizon. Nevertheless I'll update the docs at
github ASAP.

If you need any further assistance, please contact me in #openstack-merlin
channel at Freenode IRC server.

On Thu, May 14, 2015 at 4:44 PM, Fabio Imperato 
fabio.imper...@dektech.com.au wrote:

  Hello all,

 I am trying to install Merlin and integrate it into Horizon as reported at
 https://github.com/stackforge/merlin, but I cannot log into the
 OpenStack's dashboard because the dashboard does not work anymore.

 It occurs after that I copied the pluggable config (
 _50_add_mistral_panel.py) for the Mistral panel to add it in Horizon. If
 I remove it then the dashboard returns operational.

 Is it a known issue?

 Is there another installation guide or something like that or some
 workarounds?

 Thanks in advance!

 __
 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




-- 
Timur Sufiev
__
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] [Nova] [Horizon] Insufficient (?) features in current Nova API

[Timur Sufiev]

Hello!

While analyzing Horizon behavior on a large scale we faced some performance
issues which are most probably caused by inefficient calls to Nova API from
Horizon, more specifically described at
https://bugs.launchpad.net/nova/+bug/1442310

Since my knowledge of Nova existing APIs is not very comprehensive I am not
quite sure whether current Nova API indeed doesn't support requesting the
details of a multiple instances limited by their instance_id-s (passed as
part of `search_opts` parameter) or I just failed to find the proper REST
call at http://developer.openstack.org/api-ref-compute-v2.1.html

Nova developers, could you please help me on that matter?

-- 
Timur Sufiev
__
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] [Launchpad] Fwd: How to correctly change the bug milestone...

[Timur Sufiev]

The mail being forwarded was originally intended for MIrantis internal
mailing list, but then I've realized that it fits as well to the general
Openstack mailing list.

-- Forwarded message --
From: Timur Sufiev tsuf...@mirantis.com
Date: Wed, Apr 8, 2015 at 6:22 PM
Subject: How to correctly change the bug milestone...
To: mos-dev mos-...@mirantis.com


... or why we shouldn't use Launchpad at all

Hello all!

Recently thanks to our new LP reports tool I've discovered that we lost 3
bugs in MOS Horizon. Well, they weren't actually deleted, instead they were
set to Won't fix in the Milestone/Series they were originally filed to.
I've decided to find out what it takes to correctly change the bug
milestone to not lose it. Here is the absolute minimum of steps tested on
~10 bugs I've just moved from 6.1 milestone to 7.0.

1. Nominate the bug for series 7.0 (and make sure it's also nominated for
6.1)
2. Change status in 6.1 to Won't fix
3. Refresh the page (it's important!)
4. Observe the new link in the rightmost column of the top row in a list of
affected series - 'Mirantis Openstack 6.1' and change it to 'Mirantis
Openstack 7.0'.
5. Repeat for whatever number of bugs you have for the milestone that's
almost soft code-freezed.

That's it! Now, you will see all the bugs (in my case, with 'horizon' tag,
query https://bugs.launchpad.net/mos/+bugs?field.tag=horizon) in the
standard Launchpad view, which wouldn't be the case if they were still
tracked as of 'Mirantis Openstack 6.1' series which got Won't Fix status.
Of course, you could also use LP Reports tool, but it's still slower than
native LP UI due to a larger number of calls it makes.

And frankly speaking, I'm eager to see Storyboard project ready to finally
move away from this sordid piece of software called 'Launchpad'.

-- 
Timur Sufiev



-- 
Timur Sufiev
__
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][heat]Vote for Openstack L summit topic The Heat Orchestration Template Builder: A demonstration

[Timur Sufiev]

-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




-- 
Timur Sufiev
__
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] Stepping down as a Horizon core reviewer

[Timur Sufiev]

I've been away from Horizon activities for a while, so this sad news has
come to me just a moment ago.

Julie, you were of great help on #openstack-horizon, especially to
newcomers, I'll be missing you there.

Wish you luck in any of your new endeavors :)!

On Fri, Feb 13, 2015 at 5:18 PM, David Lyle dkly...@gmail.com wrote:


 On Fri, Feb 13, 2015 at 6:14 AM, Thierry Carrez thie...@openstack.org
 wrote:

 Julie Pichon wrote:
  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.

 Aw. Sad to hear that. Please come back to us when said adventures start
 to become unfun!

 --
 Thierry Carrez (ttx)


 Thank you Julie for all of your contributions. You've been an integral
 part of the Horizon team. We will miss you.

 We'll always have room for you, if you ever want to take us back.

 Best wishes on your next adventures.

 David

 __
 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




-- 
Timur Sufiev
__
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] [Murano] Nominating Kate Chernova for murano-core

[Timur Sufiev]

+1 from me.

On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan smelik...@mirantis.com
wrote:

 I'd like to propose that we add Kate Chernova to the murano-core.

 Kate is active member of our community for more than a year, she is
 regular participant in our IRC meeting and maintains a good score as
 contributor:

 http://stackalytics.com/report/users/efedorova

 Please vote by replying to this thread. As a reminder of your options, +1
 votes from 5 cores is sufficient; a -1 is a veto.
 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

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




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

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

[Timur Sufiev]

Thomas,

I could only point you to the Radomir's patch
https://review.openstack.org/#/c/100521/

It's still a work in progress, so you may ask him for more details.

On Thu, Dec 25, 2014 at 1:59 AM, Thomas Goirand z...@debian.org wrote:

 Hi,

 There's been talks about Horizon switching to the normal .ini format
 that all other projects have been using so far. It would really be
 awesome if this could happen. Though I don't see the light at the end of
 the tunnel. Quite the opposite way: the settings.py is every day
 becoming more complicated.

 Is anyone at least working on the .ini switch idea? Or will we continue
 to see the Django style settings.py forever? Is there any blockers?

 Cheers,

 Thomas Goirand (zigo)

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




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

Re: [openstack-dev] FW: [horizon] [ux] Changing how the modals are closed in Horizon

[Timur Sufiev]

It seems to me that the consensus on keeping the simpler approach -- to
make Bootstrap data-backdrop=static as the default behavior -- has been
reached. Am I right?

On Thu, Dec 4, 2014 at 10:59 PM, Kruithof, Piet pieter.c.kruithof...@hp.com
 wrote:

 My preference would be “change the default behavior to 'static’” for the
 following reasons:

 - There are plenty of ways to close the modal, so there’s not really a
 need for this feature.
 - There are no visual cues, such as an “X” or a Cancel button, that
 selecting outside of the modal closes it.
 - Downside is losing all of your data.

 My two cents…

 Begin forwarded message:

 From: Rob Cresswell (rcresswe) rcres...@cisco.commailto:
 rcres...@cisco.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 
 Date: December 3, 2014 at 5:21:51 AM PST
 Subject: Re: [openstack-dev] [horizon] [ux] Changing how the modals are
 closed in Horizon
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 

 +1 to changing the behaviour to ‘static'. Modal inside a modal is
 potentially slightly more useful, but looks messy and inconsistent, which I
 think outweighs the functionality.

 Rob


 On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.commailto:
 tsuf...@mirantis.com wrote:

 Hello, Horizoneers and UX-ers!

 The default behavior of modals in Horizon (defined in turn by Bootstrap
 defaults) regarding their closing is to simply close the modal once user
 clicks somewhere outside of it (on the backdrop element below and around
 the modal). This is not very convenient for the modal forms containing a
 lot of input - when it is closed without a warning all the data the user
 has already provided is lost. Keeping this in mind, I've made a patch [1]
 changing default Bootstrap 'modal_backdrop' parameter to 'static', which
 means that forms are not closed once the user clicks on a backdrop, while
 it's still possible to close them by pressing 'Esc' or clicking on the 'X'
 link at the top right border of the form. Also the patch [1] allows to
 customize this behavior (between 'true'-current one/'false' - no backdrop
 element/'static') on a per-form basis.

 What I didn't know at the moment I was uploading my patch is that David
 Lyle had been working on a similar solution [2] some time ago. It's a bit
 more elaborate than mine: if the user has already filled some some inputs
 in the form, then a confirmation dialog is shown, otherwise the form is
 silently dismissed as it happens now.

 The whole point of writing about this in the ML is to gather opinions
 which approach is better:
 * stick to the current behavior;
 * change the default behavior to 'static';
 * use the David's solution with confirmation dialog (once it'll be rebased
 to the current codebase).

 What do you think?

 [1] https://review.openstack.org/#/c/113206/
 [2] https://review.openstack.org/#/c/23037/

 P.S. I remember that I promised to write this email a week ago, but better
 late than never :).

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

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto: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



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

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

[Timur Sufiev]

Hi Aaron,

The only way to combine 2 aforementioned solutions I've been thinking of is
to implement David's solution as the 4th option (in addition to
true|false|static) on a per-form basis, leaving the possibility to change
the default value in configs. I guess this sort of combining would be as
simple as just putting both patches together (perhaps, changing a bit
David's js-code for catching 'click' event - to work only for the modal
forms with [data-modal-backdrop='confirm']).

On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin asah...@linux.vnet.ibm.com
wrote:

  I would be happy with either the two proposed solutions (both
 improvements over the what we have now).
 Any thoughts on combining them?   Only close if esc or 'x' is clicked, but
 also warn them if data was entered.



 On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote:

 +1 to changing the behaviour to ‘static'. Modal inside a modal is
 potentially slightly more useful, but looks messy and inconsistent, which I
 think outweighs the functionality.

  Rob


  On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.com wrote:

  Hello, Horizoneers and UX-ers!

  The default behavior of modals in Horizon (defined in turn by Bootstrap
 defaults) regarding their closing is to simply close the modal once user
 clicks somewhere outside of it (on the backdrop element below and around
 the modal). This is not very convenient for the modal forms containing a
 lot of input - when it is closed without a warning all the data the user
 has already provided is lost. Keeping this in mind, I've made a patch [1]
 changing default Bootstrap 'modal_backdrop' parameter to 'static', which
 means that forms are not closed once the user clicks on a backdrop, while
 it's still possible to close them by pressing 'Esc' or clicking on the 'X'
 link at the top right border of the form. Also the patch [1] allows to
 customize this behavior (between 'true'-current one/'false' - no backdrop
 element/'static') on a per-form basis.

  What I didn't know at the moment I was uploading my patch is that David
 Lyle had been working on a similar solution [2] some time ago. It's a bit
 more elaborate than mine: if the user has already filled some some inputs
 in the form, then a confirmation dialog is shown, otherwise the form is
 silently dismissed as it happens now.

  The whole point of writing about this in the ML is to gather opinions
 which approach is better:
 * stick to the current behavior;
 * change the default behavior to 'static';
  * use the David's solution with confirmation dialog (once it'll be
 rebased to the current codebase).

  What do you think?

  [1] https://review.openstack.org/#/c/113206/
 [2] https://review.openstack.org/#/c/23037/

  P.S. I remember that I promised to write this email a week ago, but
 better late than never :).

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




 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://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




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

[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

[Timur Sufiev]

Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap
defaults) regarding their closing is to simply close the modal once user
clicks somewhere outside of it (on the backdrop element below and around
the modal). This is not very convenient for the modal forms containing a
lot of input - when it is closed without a warning all the data the user
has already provided is lost. Keeping this in mind, I've made a patch [1]
changing default Bootstrap 'modal_backdrop' parameter to 'static', which
means that forms are not closed once the user clicks on a backdrop, while
it's still possible to close them by pressing 'Esc' or clicking on the 'X'
link at the top right border of the form. Also the patch [1] allows to
customize this behavior (between 'true'-current one/'false' - no backdrop
element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David
Lyle had been working on a similar solution [2] some time ago. It's a bit
more elaborate than mine: if the user has already filled some some inputs
in the form, then a confirmation dialog is shown, otherwise the form is
silently dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased
to the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better
late than never :).

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

Re: [openstack-dev] [UX] [Heat] [Mistral] [Horizon] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

[Timur Sufiev]

Drago,

great news indeed! In the meantime I've started integrating Merlin PoC with
the MIstral Workbook builder into Horizon. In case you follow the
instructions at https://github.com/stackforge/merlin/blob/master/README.md
you'll get working Project-Orchestration-Mistral panel with the Workbook
Builder. It has the same functionality as before, though is currently
looking inconsistent with overall Horizon UI - I'll fix that in a day or
two, adding along the way some stub code to display more than one Mistral
workbooks.

I propose to join our efforts in integration different builders into
Horizon, feel free to ask me on various aspects of getting HOT builder work
with the Horizon! There is one bug in Horizon that can prevent your panel
added via pluggable settings mechanism from appearing in the proper group,
https://bugs.launchpad.net/horizon/+bug/1378558 - the proposed fix already
works.

On Tue, Oct 14, 2014 at 12:51 AM, Drago Rosson drago.ros...@rackspace.com
wrote:

  The HOT Builder code is available now at
 https://github.com/rackerlabs/hotbuilder although at the moment it is
 non-functional because it has not been ported over to Horizon.

  Drago

   From: Angus Salkeld asalk...@mirantis.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Tuesday, September 30, 2014 at 2:42 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [UX] [Heat] [Mistral] Merlin project PoC
 update: shift from HOT builder to Mistral Workbook builder

On Fri, Sep 26, 2014 at 7:04 AM, Steve Baker sba...@redhat.com wrote:

 On 26/09/14 05:36, Timur Sufiev wrote:

 Hello, folks!

 Following Drago Rosson's introduction of Barricade.js and our discussion
 in ML about possibility of using it in Merlin [1], I've decided to change
 the plans for PoC: now the goal for Merlin's PoC is to implement Mistral
 Workbook builder on top of Barricade.js. The reasons for that are:

 * To better understand Barricade.js potential as data abstraction layer
 in Merlin, I need to learn much more about its possibilities and
 limitations than simple examining/reviewing of its source code allows. The
 best way to do this is by building upon it.
 * It's becoming too crowded in the HOT builder's sandbox - doing the
 same work as Drago currently does [2] seems like a waste of resources to me
 (especially in case he'll opensource his HOT builder someday just as he did
 with Barricade.js).


 Drago, it would be to everyone's benefit if your HOT builder efforts were
 developed on a public git repository, no matter how functional it is
 currently.

 Is there any chance you can publish what you're working on to
 https://github.com/dragorosson or rackerlabs for a start?


  Drago any news of this? This would prevent a lot of duplication of work
 and later merging of code. The sooner this is done the better.

  -Angus



  * Why Mistral and not Murano or Solum? Because Mistral's YAML templates
 have simpler structure than Murano's ones do and is better defined at that
 moment than the ones in Solum.

 There already some commits in https://github.com/stackforge/merlin and
 since client-side app doesn't talk to the Mistral's server yet, it is
 pretty easy to run it (just follow the instructions in README.md) and then
 see it in browser at http://localhost:8080. UI is yet not great, as the
 current focus is data abstraction layer exploration, i.e. how to exploit
 Barricade.js capabilities to reflect all relations between Mistral's
 entities. I hope to finish the minimal set of features in a few weeks - and
 will certainly announce it in the ML.

 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-
 September/044591.html
 [2] http://lists.openstack.org/pipermail/openstack-dev/2014-
 August/044186.html


 ___
 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




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

Re: [openstack-dev] [horizon] Packaging Sinon.JS as xstatic

[Timur Sufiev]

Adding yesterday discussion of JS libs for unit-testing in
#openstack-horizon: http://paste2.org/B9xN1yI4

On Mon, Oct 13, 2014 at 5:01 PM, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello folks!

 Discussing the proposed Sinon.js dependency to Horizon on the last meeting
 has brought quite an expected question: why should we add it when there is
 already such wonderful testing framework as Jasmine? And if you need some
 testing feature present in Jasmine, why not rewrite your QUnit test in
 Jasmine? I was not ready to answer the question at that moment so I took a
 pause to learn more about Jasmine capabilities compared to Sinon.JS.

 First of all, I googled to see if someone did this investigation before.
 Unfortunately, I haven't found much: judging from the links [1], [2] both
 Jasmine and Sinon.JS provide the same functionality, while Sinon.JS is a
 bit more flexible and could be more convenient in some cases (I guess those
 cases are specific to the project being tested).

 Then I had studied Jasmine/Sinon.JS docs and repos myself and have found
 that:
 * both project repos have lots of contributors and fresh commits
 * indeed, they provide roughly the same functionality: matchers/testing
 spies/stubs/mocks/faking timers/AJAX mocking, but
 * to use AJAX mocking in Jasmine, you need to use a separate library [5],
 which I guess means another xstatic dependency besides xstatic-jasmine if
 you want to mock AJAX calls via Jasmine
 * Sinon.JS has a much more comprehensive documentation [6] than Jasmine
 [3], [4]

 So, while Horizon doesn't have too many QUnit tests meaning that they
 could be rewritten in Jasmine in a relatively short time, it seems that in
 order to mock AJAX requests (the reason I looked to the Sinon.JS) in
 Jasmine another xstatic dependency should be added (Radomir Dopieralski
 could correct me here if I'm wrong). Also, I've found quite an interesting
 feature in Sinon.JS's AJAX mocks: it is possible to mock only a filtered
 set of server calls and let others pass through [7] - didn't find such
 feature in Jasmine ajax.js docs. On the other hand, reducing all JS
 unit-tests to one framework is good thing also, and given that Jasmine is
 officially used for Angular.js testing, I'd rather see Jasmine as the 'only
 Horizon JS unit-testing framework' than the QUnit. But then, again: want to
 have AJAX mocks = add 'jasmine-ajax' dependency to the already existing
 'jasmine' (why not add Sinon.JS then?).

 Summarizing all the things I've written so far, I would:
 * replace QUnit with Jasmine (=remove QUnit dependency)
 * add Sinon.JS just to have its AJAX-mocking features.

 [1] http://stackoverflow.com/questions/15002541/does-jasmine-need-sinon-js
 [2]
 http://stackoverflow.com/questions/12216053/whats-the-advantage-of-using-sinon-js-over-jasmines-built-in-spys
 [3] http://jasmine.github.io/1.3/introduction.html
 [4] http://jasmine.github.io/2.0/ajax.html
 [5] https://github.com/pivotal/jasmine-ajax
 [6] http://sinonjs.org/docs/
 [7] http://sinonjs.org/docs/#server search for 'Filtered requests'

 On Tue, Oct 7, 2014 at 1:19 PM, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello all!

 Recently I've stumbled upon wonderful Sinon.JS library [1] for stubs and
 mocks in JS unit tests and found that it can be used for simplifying unit
 test I've made in [2] and speeding it up. Just before wrapping it as
 xstatic package I'd like to clarify 2 questions regarding Sinon.JS:

 * Are Horizon folks fine with adding this dependency? Right now it will
 be used just for one test, but it would be useful for anybody who wants to
 mock AJAX requests in tests or emulate timeout events being fired up
 (again, see very brief and concise examples at [1]).
 * Is it okay to include QUnit and Jasmine adapters for Sinon.JS in the
 same xstatic package? Well, personally I'd vote for including QUnit adapter
 [3] since it has very little code and allows for seamless integration of
 Sinon.JS with QUnit testing framework. If someone is interested in using
 Jasmine matchers for Sinon [4], please let me know.

 [1] http://sinonjs.org/
 [2]
 https://review.openstack.org/#/c/113855/2/horizon/static/horizon/tests/tables.js
 [3] http://sinonjs.org/qunit/
 [4] https://github.com/froots/jasmine-sinon

 --
 Timur Sufiev




 --
 Timur Sufiev




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

Re: [openstack-dev] [horizon] Packaging Sinon.JS as xstatic

[Timur Sufiev]

Hello folks!

Discussing the proposed Sinon.js dependency to Horizon on the last meeting
has brought quite an expected question: why should we add it when there is
already such wonderful testing framework as Jasmine? And if you need some
testing feature present in Jasmine, why not rewrite your QUnit test in
Jasmine? I was not ready to answer the question at that moment so I took a
pause to learn more about Jasmine capabilities compared to Sinon.JS.

First of all, I googled to see if someone did this investigation before.
Unfortunately, I haven't found much: judging from the links [1], [2] both
Jasmine and Sinon.JS provide the same functionality, while Sinon.JS is a
bit more flexible and could be more convenient in some cases (I guess those
cases are specific to the project being tested).

Then I had studied Jasmine/Sinon.JS docs and repos myself and have found
that:
* both project repos have lots of contributors and fresh commits
* indeed, they provide roughly the same functionality: matchers/testing
spies/stubs/mocks/faking timers/AJAX mocking, but
* to use AJAX mocking in Jasmine, you need to use a separate library [5],
which I guess means another xstatic dependency besides xstatic-jasmine if
you want to mock AJAX calls via Jasmine
* Sinon.JS has a much more comprehensive documentation [6] than Jasmine
[3], [4]

So, while Horizon doesn't have too many QUnit tests meaning that they could
be rewritten in Jasmine in a relatively short time, it seems that in order
to mock AJAX requests (the reason I looked to the Sinon.JS) in Jasmine
another xstatic dependency should be added (Radomir Dopieralski could
correct me here if I'm wrong). Also, I've found quite an interesting
feature in Sinon.JS's AJAX mocks: it is possible to mock only a filtered
set of server calls and let others pass through [7] - didn't find such
feature in Jasmine ajax.js docs. On the other hand, reducing all JS
unit-tests to one framework is good thing also, and given that Jasmine is
officially used for Angular.js testing, I'd rather see Jasmine as the 'only
Horizon JS unit-testing framework' than the QUnit. But then, again: want to
have AJAX mocks = add 'jasmine-ajax' dependency to the already existing
'jasmine' (why not add Sinon.JS then?).

Summarizing all the things I've written so far, I would:
* replace QUnit with Jasmine (=remove QUnit dependency)
* add Sinon.JS just to have its AJAX-mocking features.

[1] http://stackoverflow.com/questions/15002541/does-jasmine-need-sinon-js
[2]
http://stackoverflow.com/questions/12216053/whats-the-advantage-of-using-sinon-js-over-jasmines-built-in-spys
[3] http://jasmine.github.io/1.3/introduction.html
[4] http://jasmine.github.io/2.0/ajax.html
[5] https://github.com/pivotal/jasmine-ajax
[6] http://sinonjs.org/docs/
[7] http://sinonjs.org/docs/#server search for 'Filtered requests'

On Tue, Oct 7, 2014 at 1:19 PM, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello all!

 Recently I've stumbled upon wonderful Sinon.JS library [1] for stubs and
 mocks in JS unit tests and found that it can be used for simplifying unit
 test I've made in [2] and speeding it up. Just before wrapping it as
 xstatic package I'd like to clarify 2 questions regarding Sinon.JS:

 * Are Horizon folks fine with adding this dependency? Right now it will be
 used just for one test, but it would be useful for anybody who wants to
 mock AJAX requests in tests or emulate timeout events being fired up
 (again, see very brief and concise examples at [1]).
 * Is it okay to include QUnit and Jasmine adapters for Sinon.JS in the
 same xstatic package? Well, personally I'd vote for including QUnit adapter
 [3] since it has very little code and allows for seamless integration of
 Sinon.JS with QUnit testing framework. If someone is interested in using
 Jasmine matchers for Sinon [4], please let me know.

 [1] http://sinonjs.org/
 [2]
 https://review.openstack.org/#/c/113855/2/horizon/static/horizon/tests/tables.js
 [3] http://sinonjs.org/qunit/
 [4] https://github.com/froots/jasmine-sinon

 --
 Timur Sufiev




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

[openstack-dev] [horizon] Packaging Sinon.JS as xstatic

[Timur Sufiev]

Hello all!

Recently I've stumbled upon wonderful Sinon.JS library [1] for stubs and
mocks in JS unit tests and found that it can be used for simplifying unit
test I've made in [2] and speeding it up. Just before wrapping it as
xstatic package I'd like to clarify 2 questions regarding Sinon.JS:

* Are Horizon folks fine with adding this dependency? Right now it will be
used just for one test, but it would be useful for anybody who wants to
mock AJAX requests in tests or emulate timeout events being fired up
(again, see very brief and concise examples at [1]).
* Is it okay to include QUnit and Jasmine adapters for Sinon.JS in the same
xstatic package? Well, personally I'd vote for including QUnit adapter [3]
since it has very little code and allows for seamless integration of
Sinon.JS with QUnit testing framework. If someone is interested in using
Jasmine matchers for Sinon [4], please let me know.

[1] http://sinonjs.org/
[2]
https://review.openstack.org/#/c/113855/2/horizon/static/horizon/tests/tables.js
[3] http://sinonjs.org/qunit/
[4] https://github.com/froots/jasmine-sinon

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

Re: [openstack-dev] [UX] [Heat] [Mistral] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

[Timur Sufiev]

Renat,

I've addressed a number of Mistral Workbook builder's issues, including:

* separating workflow-based Tasks from action-based ones, including
distinct set of fields for each one;
* restricting the range of values that can be selected for 'required' field
of Task inside reverse-type Workflow to already existing tasks of that
Workflow;
* removing 'Add' button that cluttered UI considerably - now Barricade
entities are updated on field's 'change' event;
* updating the Merlin/Mistral schema with the latest version of Mistral
workbook schema
* and some bugfixing...

Regarding the field validation which is the last goal for Merlin/Mistral
PoC I haven't implemented yet, your feedback would be very helpful, namely:
* what validation constraints should be added?
* which fields should be validated?

Any other feedback (not only related to validation issues) is also greatly
appreciated. Once we deal with validation and some UI awkwardness, I plan
to begin with Horizon integration.

P.S. As usual, you can find the latest version of Merlin/Mistral Workbook
builder at https://github.com/stackforge/merlin

On Tue, Sep 30, 2014 at 11:06 AM, Renat Akhmerov rakhme...@mirantis.com
wrote:

 Timur,

 For us, undoubtedly, it’s a great news. Visualization of any kind is
 really important for Mistral for a number of reasons. You can count on any
 help(including code contribution) from our side.

 Thanks

 Renat Akhmerov
 @ Mirantis Inc.



 On 26 Sep 2014, at 04:04, Steve Baker sba...@redhat.com wrote:

  On 26/09/14 05:36, Timur Sufiev wrote:
  Hello, folks!
 
  Following Drago Rosson's introduction of Barricade.js and our
 discussion in ML about possibility of using it in Merlin [1], I've decided
 to change the plans for PoC: now the goal for Merlin's PoC is to implement
 Mistral Workbook builder on top of Barricade.js. The reasons for that are:
 
  * To better understand Barricade.js potential as data abstraction layer
 in Merlin, I need to learn much more about its possibilities and
 limitations than simple examining/reviewing of its source code allows. The
 best way to do this is by building upon it.
  * It's becoming too crowded in the HOT builder's sandbox - doing the
 same work as Drago currently does [2] seems like a waste of resources to me
 (especially in case he'll opensource his HOT builder someday just as he did
 with Barricade.js).
 
  Drago, it would be to everyone's benefit if your HOT builder efforts
 were developed on a public git repository, no matter how functional it is
 currently.
 
  Is there any chance you can publish what you're working on to
 https://github.com/dragorosson or rackerlabs for a start?
 
  * Why Mistral and not Murano or Solum? Because Mistral's YAML templates
 have simpler structure than Murano's ones do and is better defined at that
 moment than the ones in Solum.
 
  There already some commits in https://github.com/stackforge/merlin and
 since client-side app doesn't talk to the Mistral's server yet, it is
 pretty easy to run it (just follow the instructions in README.md) and then
 see it in browser at http://localhost:8080. UI is yet not great, as the
 current focus is data abstraction layer exploration, i.e. how to exploit
 Barricade.js capabilities to reflect all relations between Mistral's
 entities. I hope to finish the minimal set of features in a few weeks - and
 will certainly announce it in the ML.
 
  [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/044591.html
  [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044186.html
 
 
  ___
  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




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

[openstack-dev] [UX] [Heat] [Mistral] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

[Timur Sufiev]

Hello, folks!

Following Drago Rosson's introduction of Barricade.js and our discussion in
ML about possibility of using it in Merlin [1], I've decided to change the
plans for PoC: now the goal for Merlin's PoC is to implement Mistral
Workbook builder on top of Barricade.js. The reasons for that are:

* To better understand Barricade.js potential as data abstraction layer in
Merlin, I need to learn much more about its possibilities and limitations
than simple examining/reviewing of its source code allows. The best way to
do this is by building upon it.
* It's becoming too crowded in the HOT builder's sandbox - doing the same
work as Drago currently does [2] seems like a waste of resources to me
(especially in case he'll opensource his HOT builder someday just as he did
with Barricade.js).
* Why Mistral and not Murano or Solum? Because Mistral's YAML templates
have simpler structure than Murano's ones do and is better defined at that
moment than the ones in Solum.

There already some commits in https://github.com/stackforge/merlin and
since client-side app doesn't talk to the Mistral's server yet, it is
pretty easy to run it (just follow the instructions in README.md) and then
see it in browser at http://localhost:8080. UI is yet not great, as the
current focus is data abstraction layer exploration, i.e. how to exploit
Barricade.js capabilities to reflect all relations between Mistral's
entities. I hope to finish the minimal set of features in a few weeks - and
will certainly announce it in the ML.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044591.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/044186.html

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

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

[Timur Sufiev]

Drago,

It sounds like you convinced me to give D3.js a second chance :). I'll
experiment with what can be achieved using force-directed graph layout
combined with some composable svg object, hopefully this will save me
from placing objects on the canvas on my own.

I've read the barricade_Spec.js several times and part of
barricade.js. Code is very interesting and allowed me to refresh some
JavaScript knowledge I used a looong ago :). The topic I definitely
haven't fully grasped is deferred/deferrable/referenced objects. The
thing I've understood is that if some scheme includes '@ref' key, then
it tries to get value returned from the resolver function no matter
what value has provided during scheme instantiation. Am I right? Is
'needs' section required for the value to be resolved? The examples
in file with tests are a bit mind-bending, so I failed to imagine how
it works for real use-cases. Also I'm interested whether it is
possible to define a schema that allows both to provide the value
directly and via reference? Among other things that inclined me to
give some feedback are:
* '@type' vs. '@class' - is the only difference between them that
'@type' refers to primitive type and '@class' refers to Barricade.js
scheme? Perhaps it could be reduced to a single word to make things
simpler?
* '?' vs '*' - seems they are used in different contexts, '?' is for
Object and '*' for Array - are 2 distinct markers actually needed?
* Is it better for objects with fixed schema to fail when unexpected
key is passed to them? Currently they don't.
* Pushing an element of wrong type into an arraylike scheme still
creates an element with empty default value.
* Is it possible to create schemas with arbitrary default values (the
example from spec caused me to think that default values cannot be
specified)?
* 'required' property does not really force such key to be provided
during schema instantiation - I presume this is going to change when
the real validation arrives?
* What are the conceptual changes between objects instantiated from
mutable (with '?') and from immutable (with fixed keys) schema?

Thank you very much for your efforts, I think that Barricade.js could
provide a solid foundation for Merlin!

On Thu, Aug 28, 2014 at 9:31 PM, Drago Rosson
drago.ros...@rackspace.com wrote:
 Timur,

 Composable entities can be a real need for Heat if provider templates
 (which allow templates to be used as a resource, with a template’s
 parameters and outputs becoming properties and attributes, respectively)
 are to be included in the app. A provider template resource, since it is a
 template itself, would be composed of resources which would require a
 composable entity. What is great about D3’s force graph is that it’s nodes
 and links can be completely arbitrary - meaning they can be any JavaScript
 object (including an SVG or DOM element). Additionally, the force graph
 simulation updates x and y properties on those elements and calls a
 user-defined “tick” function. The tick function can use the x and y
 properties in any way it wants to do the *actual* update to the position
 of each element. For example, this is how multiple foci can be implemented
 [1]. Lots of other customization is available, including starting and
 stopping the simulation, updating the node and link data, and having
 per-element control of most (all?) properties such as charge or link
 distance.

 Composability can be achieved using SVG’s g elements to group multiple
 graphical elements together. The tick function would need to update the
 g’s transform attribute [2]. This is how it is done in my app since my
 nodes and links are composed of icons, labels, backgrounds, etc. I think
 that D3’s force graph is not a limiting factor since it itself does not
 concern itself with graphics at all. Therefore, the question seems to be
 whether D3 can do everything graphically that Merlin needs. D3 is not a
 graphics API, but it does have support for graphical manipulation,
 animations, and events. They have sufficed for me so far. Plus, D3 can do
 these things without having to use its fancy data transformations so it
 can be used as a low-level SVG library where necessary. D3 can do a lot
 [3] so hopefully it could also do what Merlin needs.

 You are in luck, because I have just now open-sourced Barricade! Check it
 out [4]. I am working on getting documentation written for it but to see
 some ways it can be used, look at its test suite [5].

 [1] http://bl.ocks.org/mbostock/1021953
 [2] node.attr(transform, function (d) {
 return translate( + d.x + ,  + d.y + );
 });
 [3] http://christopheviau.com/d3list/
 [4] https://github.com/rackerlabs/barricade

 [5]
 https://github.com/rackerlabs/barricade/blob/master/test/barricade_Spec.js

 On 8/28/14, 10:03 AM, Timur Sufiev tsuf...@mirantis.com wrote:

Hello, Drago!

I'm extremely interested in learning more about your HOT graphical
builder. The screenshots you had attached look gorgeous! Yours visual

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

[Timur Sufiev]

 value
 or a description to go along with each property in a Heat resource.

 - Validation. Soon, the schema will allow defining validators that will
 run whenever a new value is attempted to be set on data. Messages about
 failed validation will be available so that the UI can display it. This
 system seems to be very similar to dynamic UI’s.

 What this all boils down to is that all of the logic required to ensure
 JSON’s integrity is rolled into Barricade instead of sprinkled into all of
 the UI code. This way, UI components can be confident in the data that
 they are working with, which makes their code more concise and faster to
 develop.

 Barricade seems like a great fit for Merlin because the projects it
 targets (Heat, Solum, Mistral, Murano) use YAML files that can be used
 with Barricade once they are converted to JSON.


 About the template builder (see screenshots attached):

 - Uses an interactive canvas (powered by a D3.js force-directed graph) to
 display Heat resources and the dependencies in between them. New resources
 can be drag-and-dropped from a panel onto the canvas. Different resource
 types are attracted to different respective areas so that they
 automatically arrange themselves in a familiar network topology hierarchy.
  A form/panel is displayed when a resource on the canvas is clicked so
 that the resource’s properties can be edited.

 - Has two―way data binding provided by Knockout.js interfacing with
 Barricade.js so that editing values in forms automatically updates the
 topology on the canvas (e.g. Changing resource IDs or creating/removing
 dependencies between resources).

 - Allows for direct-editing of the template (via text input) and loading
 templates via URLs.


 Please, let me know if you would like a demo of the template builder and
 Barricade!

 Thanks,
 Drago Rosson




 On 8/18/14, 5:19 AM, Timur Sufiev tsuf...@mirantis.com wrote:

David,

I'm happy to hear that :)! After thinking a bit, I came up with the
following strategy for further Merlin development: make all the
commits into a separate repository (stackforge/merlin) at least until
the PoC is ready. This will allow to keep project history more
granular instead of updating one large commit inside openstack/horizon
gerrit (thus also lessening the burden on Horizon reviewers). Once the
Merlin proceeds from the experimental/PoC phase to the implementing of
a more elaborated spec, it will be just the time for it to join with
the Horizon.

On Wed, Aug 13, 2014 at 2:48 AM, Lyle, David david.l...@hp.com wrote:
 On 8/6/14, 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote:

Hi, folks!

Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails that followed convinced me
that I'm not the only person interested in it :), so I'm happy to make
the next announcement.

The project finally has got its name - 'Merlin' (making complex UIs is
a kind of magic), Openstack wiki page [3] and all other stuff like
stackforge repo, launchpad page and IRC channel (they are all
referenced in [3]). For those who don't like clicking the links, here
is quick summary.

Merlin aims to provide a convenient client side framework for building
rich UIs for Openstack projects dealing with complex input data with
lot of dependencies and constraints (usually encoded in YAML format
via some DSL) - projects like Heat, Murano, Mistral or Solum. The
ultimate goal for such UI is to save users from reading comprehensive
documentation just in order to provide correct input data, thus making
the UI of these projects more user-friendly. If things go well for
Merlin, it could be eventually merged into Horizon library (I¹ll spare
another option for the end of this letter).

The framework trying to solve this ambitious task is facing at least 2
challenges:
(1) enabling the proper UX patterns and
(2) dealing with complexities of different projects' DSLs.

Having worked on DSL things in Murano project before, I'm planning at
first to deal with the challenge (2) in the upcoming Merlin PoC. So,
here is the initial plan: design an in-framework object model (OM)
that could translated forth and back into target project's DSL. This
OM is meant to be synchronised with visual elements shown on browser
canvas. Target project is the Heat with its HOT templates - it has the
most well-established syntax among other projects and comprehensive
documentation.

Considering the challenge (1), not being a dedicated UX engineer, I'm
planning to start with some rough UI concepts [4] and gradually
improve them relying on community feedback, and especially, Openstack
UX group. If anybody from the UX team (or any other team!) is willing
to be involved to a greater degree than just giving some feedback,
you're are enormously welcome! Join Merlin, it will be fun :)!

Finally, with this announcement I¹d like to start

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

[Timur Sufiev]

David,

I'm happy to hear that :)! After thinking a bit, I came up with the
following strategy for further Merlin development: make all the
commits into a separate repository (stackforge/merlin) at least until
the PoC is ready. This will allow to keep project history more
granular instead of updating one large commit inside openstack/horizon
gerrit (thus also lessening the burden on Horizon reviewers). Once the
Merlin proceeds from the experimental/PoC phase to the implementing of
a more elaborated spec, it will be just the time for it to join with
the Horizon.

On Wed, Aug 13, 2014 at 2:48 AM, Lyle, David david.l...@hp.com wrote:
 On 8/6/14, 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote:

Hi, folks!

Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails that followed convinced me
that I'm not the only person interested in it :), so I'm happy to make
the next announcement.

The project finally has got its name - 'Merlin' (making complex UIs is
a kind of magic), Openstack wiki page [3] and all other stuff like
stackforge repo, launchpad page and IRC channel (they are all
referenced in [3]). For those who don't like clicking the links, here
is quick summary.

Merlin aims to provide a convenient client side framework for building
rich UIs for Openstack projects dealing with complex input data with
lot of dependencies and constraints (usually encoded in YAML format
via some DSL) - projects like Heat, Murano, Mistral or Solum. The
ultimate goal for such UI is to save users from reading comprehensive
documentation just in order to provide correct input data, thus making
the UI of these projects more user-friendly. If things go well for
Merlin, it could be eventually merged into Horizon library (I¹ll spare
another option for the end of this letter).

The framework trying to solve this ambitious task is facing at least 2
challenges:
(1) enabling the proper UX patterns and
(2) dealing with complexities of different projects' DSLs.

Having worked on DSL things in Murano project before, I'm planning at
first to deal with the challenge (2) in the upcoming Merlin PoC. So,
here is the initial plan: design an in-framework object model (OM)
that could translated forth and back into target project's DSL. This
OM is meant to be synchronised with visual elements shown on browser
canvas. Target project is the Heat with its HOT templates - it has the
most well-established syntax among other projects and comprehensive
documentation.

Considering the challenge (1), not being a dedicated UX engineer, I'm
planning to start with some rough UI concepts [4] and gradually
improve them relying on community feedback, and especially, Openstack
UX group. If anybody from the UX team (or any other team!) is willing
to be involved to a greater degree than just giving some feedback,
you're are enormously welcome! Join Merlin, it will be fun :)!

Finally, with this announcement I¹d like to start a discussion with
Horizon community. As far as I know, Horizon in its current state
lacks such UI toolkit as Merlin aims to provide. Would it be by any
chance possible for the Merlin project to be developed from the very
beginning as part of Horizon library? This choice has its pros and
cons I¹m aware of, but I¹d like to hear the opinions of Horizon
developers on that matter.

 I would like to see this toolset built into Horizon. That will make it
 accessible to integrated projects like Heat that Horizon already supports,
 but will also allow other projects to use the horizon library as a
 building block to providing managing project specific DSLs.

 David


[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-June/037054.html
[2]
https://docs.google.com/a/mirantis.com/document/d/19Q9JwoO77724RyOp7XkpYmA
Lwmdb7JjoQHcDv4ffZ-I/edit#
[3] https://wiki.openstack.org/wiki/Merlin
[4] https://wiki.openstack.org/wiki/Merlin/SampleUI

--
Timur Sufiev

___
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



-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

[Timur Sufiev]

Thanks,

now it is clear that this requirement can be safely dropped.

On Thu, Aug 7, 2014 at 11:33 AM, Matthias Runge mru...@redhat.com wrote:
 On 06/08/14 14:01, Timur Sufiev wrote:

 Hi!

 Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113

 The question is whether the python-pillow package really needed for
 proper compiling css from scss in Horizon or is it an optional
 requirement which can be safely dropped? The problem with
 python-pillow is that it pulls a lot of unneeded deps (like tk, qt,
 etc...) which is better avoided.

 If you're looking at the spec[1], you'd see it's a test requirement, not a
 runtime requirement.


 Matthias

 [1]
 http://pkgs.fedoraproject.org/cgit/python-django-pyscss.git/tree/python-django-pyscss.spec

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



-- 
Timur Sufiev

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

[openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

[Timur Sufiev]

Hi!

Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113

The question is whether the python-pillow package really needed for
proper compiling css from scss in Horizon or is it an optional
requirement which can be safely dropped? The problem with
python-pillow is that it pulls a lot of unneeded deps (like tk, qt,
etc...) which is better avoided.

-- 
Timur Sufiev

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

[openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

[Timur Sufiev]

Hi, folks!

Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails that followed convinced me
that I'm not the only person interested in it :), so I'm happy to make
the next announcement.

The project finally has got its name - 'Merlin' (making complex UIs is
a kind of magic), Openstack wiki page [3] and all other stuff like
stackforge repo, launchpad page and IRC channel (they are all
referenced in [3]). For those who don't like clicking the links, here
is quick summary.

Merlin aims to provide a convenient client side framework for building
rich UIs for Openstack projects dealing with complex input data with
lot of dependencies and constraints (usually encoded in YAML format
via some DSL) - projects like Heat, Murano, Mistral or Solum. The
ultimate goal for such UI is to save users from reading comprehensive
documentation just in order to provide correct input data, thus making
the UI of these projects more user-friendly. If things go well for
Merlin, it could be eventually merged into Horizon library (I’ll spare
another option for the end of this letter).

The framework trying to solve this ambitious task is facing at least 2
challenges:
(1) enabling the proper UX patterns and
(2) dealing with complexities of different projects' DSLs.

Having worked on DSL things in Murano project before, I'm planning at
first to deal with the challenge (2) in the upcoming Merlin PoC. So,
here is the initial plan: design an in-framework object model (OM)
that could translated forth and back into target project's DSL. This
OM is meant to be synchronised with visual elements shown on browser
canvas. Target project is the Heat with its HOT templates - it has the
most well-established syntax among other projects and comprehensive
documentation.

Considering the challenge (1), not being a dedicated UX engineer, I'm
planning to start with some rough UI concepts [4] and gradually
improve them relying on community feedback, and especially, Openstack
UX group. If anybody from the UX team (or any other team!) is willing
to be involved to a greater degree than just giving some feedback,
you're are enormously welcome! Join Merlin, it will be fun :)!

Finally, with this announcement I’d like to start a discussion with
Horizon community. As far as I know, Horizon in its current state
lacks such UI toolkit as Merlin aims to provide. Would it be by any
chance possible for the Merlin project to be developed from the very
beginning as part of Horizon library? This choice has its pros and
cons I’m aware of, but I’d like to hear the opinions of Horizon
developers on that matter.

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037054.html
[2] 
https://docs.google.com/a/mirantis.com/document/d/19Q9JwoO77724RyOp7XkpYmALwmdb7JjoQHcDv4ffZ-I/edit#
[3] https://wiki.openstack.org/wiki/Merlin
[4] https://wiki.openstack.org/wiki/Merlin/SampleUI

-- 
Timur Sufiev

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

Re: [openstack-dev] [Murano] Field 'name' is removed from Apps dynamic UI markup, should 'Version' be changed?

[Timur Sufiev]

Seems we have agreed on increasing minor version of UI markup to 2.1.
I've updated 
https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field

On Thu, Jul 10, 2014 at 1:08 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 Also agree with Stan.

 I'd like to refrain from bumping version to the next integer each time some
 change is done to the markup format. It's quite a small change after all,
 also big numbers in format's version imply that it's changed every friday
 and should not be relied on.

 08.07.2014 22:10 пользователь Ekaterina Chernova efedor...@mirantis.com
 написал:

 Hi guys!

 I agreed with Stan suggestion. We also need to track somewhere in the
 documentation for mapping between the Murano version and Dynamic UI version.

 BTW, what about to keep version values in integer, so the next one would
 be 3?

 Regards, Kate.


 On Sun, Jul 6, 2014 at 4:21 PM, Stan Lagun sla...@mirantis.com wrote:

 I we increment version to say 2.1 we could add code to dashboard to check
 for markup version and if it encounters version 2.0 to print verbose error
 telling how to migrate markup to 2.1.
 I don't see how both version can be supported simulteniously but at lease
 Version attribute must be checked and forms older version must fail with
 descriptive message rather than causing unpredictable behavior.

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis



 On Fri, Jul 4, 2014 at 8:24 PM, Timur Sufiev tsuf...@mirantis.com
 wrote:

 Hi, folks!

 Recently we had decided to change a bit how Murano's dynamic UI works,
 namely do not explicitly specify 'name' field in first 'Add
 Application' form, but add it here automatically, since every
 component in Murano has a name. To avoid confusion with the 'name'
 field added by hand to the first form's markup, 'name' field on the
 first step will be forbidden and processing of an old UI markup which
 has such field will cause an exception. All these changes are
 described in the blueprint [1] in a greater detail.

 What is not entirely clear to me is whether should we increase
 'Version' attribute of UI markup or not? On one hand, the format of UI
 markup is definitely changing - and old UI definitions won't work with
 the UI processor after [1] is implemented. It is quite reasonable to
 bump a format's version to reflect that fact. On the other hand, we
 will hardly support both format versions, instead we'll rewrite UI
 markup in all existing Murano Apps (there are not so many of them yet)
 and eventually forget that once upon a time the user needed to specify
 'name' field explicitly.

 What do you think?

 [1]
 https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field

 --
 Timur Sufiev

 ___
 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





-- 
Timur Sufiev

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

Re: [openstack-dev] [Murano] Field 'name' is removed from Apps dynamic UI markup, should 'Version' be changed?

[Timur Sufiev]

Also agree with Stan.

I'd like to refrain from bumping version to the next integer each time some
change is done to the markup format. It's quite a small change after all,
also big numbers in format's version imply that it's changed every friday
and should not be relied on.
08.07.2014 22:10 пользователь Ekaterina Chernova efedor...@mirantis.com
написал:

 Hi guys!

 I agreed with Stan suggestion. We also need to track somewhere in the
 documentation for mapping between the Murano version and Dynamic UI
 version.

 BTW, what about to keep version values in integer, so the next one would
 be 3?

 Regards, Kate.


 On Sun, Jul 6, 2014 at 4:21 PM, Stan Lagun sla...@mirantis.com wrote:

 I we increment version to say 2.1 we could add code to dashboard to check
 for markup version and if it encounters version 2.0 to print verbose error
 telling how to migrate markup to 2.1.
 I don't see how both version can be supported simulteniously but at lease
 Version attribute must be checked and forms older version must fail with
 descriptive message rather than causing unpredictable behavior.

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis

  sla...@mirantis.com


 On Fri, Jul 4, 2014 at 8:24 PM, Timur Sufiev tsuf...@mirantis.com
 wrote:

 Hi, folks!

 Recently we had decided to change a bit how Murano's dynamic UI works,
 namely do not explicitly specify 'name' field in first 'Add
 Application' form, but add it here automatically, since every
 component in Murano has a name. To avoid confusion with the 'name'
 field added by hand to the first form's markup, 'name' field on the
 first step will be forbidden and processing of an old UI markup which
 has such field will cause an exception. All these changes are
 described in the blueprint [1] in a greater detail.

 What is not entirely clear to me is whether should we increase
 'Version' attribute of UI markup or not? On one hand, the format of UI
 markup is definitely changing - and old UI definitions won't work with
 the UI processor after [1] is implemented. It is quite reasonable to
 bump a format's version to reflect that fact. On the other hand, we
 will hardly support both format versions, instead we'll rewrite UI
 markup in all existing Murano Apps (there are not so many of them yet)
 and eventually forget that once upon a time the user needed to specify
 'name' field explicitly.

 What do you think?

 [1]
 https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field

 --
 Timur Sufiev

 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSSG][OSSN] [Horizon] Session-fixation vulnerability in Horizon when using the default signed cookie sessions

[Timur Sufiev]

/kFVKfgf7FN0e9zS9ZSqFfXevZSAIY9cEP7E0V5XtyfY=
 =FDu2
 -END PGP SIGNATURE-

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



-- 
Timur Sufiev

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

[openstack-dev] [Murano] Field 'name' is removed from Apps dynamic UI markup, should 'Version' be changed?

[Timur Sufiev]

Hi, folks!

Recently we had decided to change a bit how Murano's dynamic UI works,
namely do not explicitly specify 'name' field in first 'Add
Application' form, but add it here automatically, since every
component in Murano has a name. To avoid confusion with the 'name'
field added by hand to the first form's markup, 'name' field on the
first step will be forbidden and processing of an old UI markup which
has such field will cause an exception. All these changes are
described in the blueprint [1] in a greater detail.

What is not entirely clear to me is whether should we increase
'Version' attribute of UI markup or not? On one hand, the format of UI
markup is definitely changing - and old UI definitions won't work with
the UI processor after [1] is implemented. It is quite reasonable to
bump a format's version to reflect that fact. On the other hand, we
will hardly support both format versions, instead we'll rewrite UI
markup in all existing Murano Apps (there are not so many of them yet)
and eventually forget that once upon a time the user needed to specify
'name' field explicitly.

What do you think?

[1] 
https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field

-- 
Timur Sufiev

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

[openstack-dev] [horizon] [neutron] Disassociating Instance's floating IP from Instances table with Neutron

[Timur Sufiev]

Hello!

So, we have a little problem with 'Disassociate IP' button in
Instances table when 'simple_ip_management' option is not specified in
Horizon's config - it is absent
(https://bugs.launchpad.net/fuel/+bug/1325575). Having investigated
the problem a little bit, I found the following note in Neutron code:
# NOTE: There are two reason that simple association support
# needs more considerations. (1) Neutron does not support the
# default floating IP pool at the moment. It can be avoided
# in case where only one floating IP pool exists.
# (2) Neutron floating IP is associated with each VIF and
# we need to check whether such VIF is only one for an instance
# to enable simple association support.
(and it is reflected in current Horizon docs for 'simple_ip_management' option).

So, the first question is whether any kind of simple association (and
both disassociation) is planned to be added to Neutron in the nearest
future (say, Juno cycle)?

The second question is more to Horizon team: if simple_ip_management
won't make it to Neutron soon, what's about supporting poor man's
'Disassociate IP' functionality (opposing 'Simple Disassociate IP') in
Horizon? I have the following scenario off the top of my head:
* user presses 'Disassociate IP' button
* he is redirected to
horizon:project:access_and_security:floating_ips, where only IPs for a
given Instance are shown
* user disassociates the right IP
* and returns to Intances table manually

What do you think?

P.S. I know that the appropriate Horizon bug exists
(https://bugs.launchpad.net/horizon/+bug/1226003), but decided to ask
here to get a feedback from Neutron team.

-- 
Timur Sufiev

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

Re: [openstack-dev] [Murano] Nominations to Murano core

[Timur Sufiev]

+1 for both.

On Thu, Jun 26, 2014 at 3:29 PM, Stan Lagun sla...@mirantis.com wrote:
 +1 for both (or should I say +2?)

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis



 On Thu, Jun 26, 2014 at 1:49 PM, Alexander Tivelkov ativel...@mirantis.com
 wrote:

 +1 on both Serge and Steve

 --
 Regards,
 Alexander Tivelkov


 On Thu, Jun 26, 2014 at 1:37 PM, Ruslan Kamaldinov
 rkamaldi...@mirantis.com wrote:

 I would like to nominate Serg Melikyan and Steve McLellan to Murano core.

 Serge has been a significant reviewer in the Icehouse and Juno release
 cycles.

 Steve has been providing consistent quality reviews and they continue
 to get more frequent and better over time.


 Thanks,
 Ruslan

 ___
 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




-- 
Timur Sufiev

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

[openstack-dev] [UX] [Heat] [Mistral] [Murano] [Neutron] [Solum] Cross-project UI library: gathering the requirements

[Timur Sufiev]

Hi All,

At the Solum-Murano-Heat cross-project session [1] during the
Openstack Juno Summit it was decided that it would be beneficial for
the Solum, Murano and Heat projects to implement common UX patterns in
separate library. During an early discussion several more projects
were added (Mistral and Neutron), and an initial UI draft was proposed
[2]. That initial concept is just a first step in finding the common
ground between the needs of aforementioned projects and is much likely
to be reworked in future. So I’d like to initiate a discussion to
gather specific use cases from Solum, Heat and Neutron projects
(Murano and Mistral are already somehow covered) as well as gather in
this thread all people who are interested in the project.

[1] https://etherpad.openstack.org/p/9XQ7Q2NQdv
[2] 
https://docs.google.com/a/mirantis.com/document/d/19Q9JwoO77724RyOp7XkpYmALwmdb7JjoQHcDv4ffZ-I/edit#

-- 
Timur Sufiev

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

Re: [openstack-dev] [Horizon] How to conditionally modify attributes in CreateNetwork class.

[Timur Sufiev]

Hello, Nader!

As for `contributes` attribute, you could override `contribute(self,
data, context)` method in your descendant of `workflows.Step` which by
default simply iterates over all keys in `contributes`.

Either you could use even more flexible approach (which also fits for
`default_steps`): define in your `workflows.Step` descendants methods
`contributes(self)` and `default_steps(self)` (with the conditional
logic you need) and then decorate them with @property.

On Fri, May 30, 2014 at 10:15 AM, Nader Lahouti nader.laho...@gmail.com wrote:
 Hi All,

 Currently in the
 horizon/openstack_dashboard/dashboards/project/networks/workflows.py in
 classes such as CreateNetwork, CreateNetworkInfo and CreateSubnetInfo, the
 contributes or default_steps as shown below are fixed. Is it possible to add
 entries to those attributes conditionally?

 156class CreateSubnetInfo(workflows.Step):
 157action_class = CreateSubnetInfoAction
 158contributes = (with_subnet, subnet_name, cidr,
 159   ip_version, gateway_ip, no_gateway)
 160

 262class CreateNetwork(workflows.Workflow):
 263slug = create_network
 264name = _(Create Network)
 265finalize_button_name = _(Create)
 266success_message = _('Created network %s.')
 267failure_message = _('Unable to create network %s.')
 268default_steps = (CreateNetworkInfo,
 269 CreateSubnetInfo,
 270 CreateSubnetDetail)

 Thanks for your input.

 Nader.


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




-- 
Timur Sufiev

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

[openstack-dev] [Murano] A new version of python-muranoclient (0.5.2) is to be released

[Timur Sufiev]

Hi there!

Recently we've changed the way application packages are paginated in
murano-dashboard (AppCatalog and Package Definitions panels) -
adopting the Glance approach with generators and 'next_marker'
property. This change concerns all 3 murano components - murano-api
[1], python-muranoclient [2] and murano-dashboard [3]. In order to use
proper version of python-muranoclient in murano-dashboard, a new
version of python-muranoclient will be released, namely 0.5.2.

[1] https://review.openstack.org/#/c/93900/
[2] https://review.openstack.org/#/c/93899/
[3] https://review.openstack.org/#/c/93939/

-- 
Timur Sufiev

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

Re: [openstack-dev] [murano] Proposal to add Ruslan Kamaldinov to murano-core team

[Timur Sufiev]

Ruslan,

welcome to the Murano core team :)!

On Thu, Apr 17, 2014 at 7:32 PM, Anastasia Kuznetsova
akuznets...@mirantis.com wrote:
 +1


 On Thu, Apr 17, 2014 at 7:11 PM, Stan Lagun sla...@mirantis.com wrote:

 +1

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis



 On Thu, Apr 17, 2014 at 6:51 PM, Georgy Okrokvertskhov
 gokrokvertsk...@mirantis.com wrote:

 +1


 On Thu, Apr 17, 2014 at 6:01 AM, Dmitry Teselkin dtesel...@mirantis.com
 wrote:

 +1

 Agree


 On Thu, Apr 17, 2014 at 4:51 PM, Alexander Tivelkov
 ativel...@mirantis.com wrote:

 +1

 Totally agree

 --
 Regards,
 Alexander Tivelkov


 On Thu, Apr 17, 2014 at 4:37 PM, Timur Sufiev tsuf...@mirantis.com
 wrote:

 Guys,

 Ruslan Kamaldinov has been doing a lot of things for Murano recently
 (including devstack integration, automation scripts, making Murano
 more compliant with OpenStack standards and doing many reviews). He's
 actively participating in our ML discussions as well. I suggest to add
 him to the core team.

 Murano folks, please say your +1/-1 word.

 --
 Timur Sufiev

 ___
 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




 --
 Thanks,
 Dmitry Teselkin
 Deployment Engineer
 Mirantis
 http://www.mirantis.com

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




 --
 Georgy Okrokvertskhov
 Architect,
 OpenStack Platform Products,
 Mirantis
 http://www.mirantis.com
 Tel. +1 650 963 9828
 Mob. +1 650 996 3284

 ___
 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




-- 
Timur Sufiev

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

[openstack-dev] [murano] Proposal to add Ruslan Kamaldinov to murano-core team

[Timur Sufiev]

Guys,

Ruslan Kamaldinov has been doing a lot of things for Murano recently
(including devstack integration, automation scripts, making Murano
more compliant with OpenStack standards and doing many reviews). He's
actively participating in our ML discussions as well. I suggest to add
him to the core team.

Murano folks, please say your +1/-1 word.

-- 
Timur Sufiev

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

[openstack-dev] [Murano] MuranoPL = UML visualization - best implementation practices?

[Timur Sufiev]

Hello!

Recently we've made an attempt to make MuranoPL class definitions more
conceivable for everyone, and decided to use UML diagrams for that
purpose. The most obvious (and quick) solution was to use a well-known
tool [1], the command-line script which uses it is almost ready [2],
and the final result seems quite satisfying to us [3] (pictures are
drawn using current version of script). Moreover, we liked these
diagrams so much that decided to show them also in Murano's WebUI
(right after the uploaded App Package has been validated).

But we're little uncertain about using Java-based tool in the long
run: it doesn't seem to fit very well with OpenStack common practices.
So could you advice some good enough Python and/or Javascript library
for generating UML diagrams? The most important criteria is an ability
to produce graphics as beautiful as Plant UML does.

[1] http://plantuml.sourceforge.net/
[2] https://review.openstack.org/#/c/83348/
[3] 
https://www.dropbox.com/sh/pesyejyjo624o34/fCe1_OM-OH#lh:null-io.murano.Environment.png

-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

[Timur Sufiev]

Hello, Akihiro

Thanks for the advice (and sorry for not very timely response)! I've
added last stable/havana release to the test-requirements, and
received some new error from the Jenknins' side: [1]. At first I
thought that the problem is caused by the reverse order of settings
modules inclusion (and almost renounced the idea of change [2]), but
today read the code and traceback again and realized that this error
happens even before muranodashboard settings come into play! So now it
seems to me that there are some inherent problems with horizon package
installation with pip even if the source different from the PyPi is
used. Is that a known issue or am I doing something wrong?

[1] 
http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
[2] https://review.openstack.org/#/c/68125/

On Thu, Mar 20, 2014 at 9:50 PM, Akihiro Motoki amot...@gmail.com wrote:
 As a workaround you can use tarball in requirements.txt (or
 test-requirements.txt).
 Each versions of Horizon/openstack_dashboard is available at
 http://tarballs.openstack.org/horizon/.
 Each tarball is generated every time corresponding branch or tag is updated.
 If you would like to use horizon I-3 as a requirement, please add the
 following line to your requirements.txt:

 http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz

 Thanks,
 Akihiro

 On Fri, Mar 21, 2014 at 2:22 AM, Paul Belanger
 paul.belan...@polybeacon.com wrote:
 On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 It depends on openstack_dashboard, namely on
 openstack_dashboard.settings. So it is fine from Murano's point of
 view to have openstack_dashboard published on PyPi. Many thanks for
 considering my request :).

 We are having this issue too, for now we have worked around it with
 pip switches allowing to download from an external source, but
 hopefully we'll get horizon and openstack_dashboard split out in the
 near future.

 Like you, we've built a dashboard atop of horizon, mostly because of
 the existing keystone integration.  Everything else we do is external
 to OpenStack.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter: 
 https://twitter.com/pabelanger

 ___
 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



-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

[Timur Sufiev]

Hello, Paul

Thank you for the reply (and sorry for not timely response from my
side)! Are you passing external sources to pip the way Akihiro
described in this thread? Or are you using some custom install script
that installs package dependencies in its own way? I'm asking because
I've tried the solution suggested by Akihiro and it didn't go
smoothly.

On Thu, Mar 20, 2014 at 9:22 PM, Paul Belanger
paul.belan...@polybeacon.com wrote:
 On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 It depends on openstack_dashboard, namely on
 openstack_dashboard.settings. So it is fine from Murano's point of
 view to have openstack_dashboard published on PyPi. Many thanks for
 considering my request :).

 We are having this issue too, for now we have worked around it with
 pip switches allowing to download from an external source, but
 hopefully we'll get horizon and openstack_dashboard split out in the
 near future.

 Like you, we've built a dashboard atop of horizon, mostly because of
 the existing keystone integration.  Everything else we do is external
 to OpenStack.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter: 
 https://twitter.com/pabelanger

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



-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

[Timur Sufiev]

Thank you,

that was the actual cause of the error. I got the wrong year, my fault.

On Mon, Mar 31, 2014 at 3:55 PM, Akihiro Motoki amot...@gmail.com wrote:
 According to the failure log, you seem to try to install 2012.2.4 (== Folsom).
 I don't think this is the intended version you want to use. Please check it.

 http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_917
 2014-03-24 11:08:50.917 |   Running setup.py install for horizon-2012.2.4

 Thanks,
 Akihiro

 On Mon, Mar 31, 2014 at 6:05 PM, Timur Sufiev tsuf...@mirantis.com wrote:
 Hello, Akihiro

 Thanks for the advice (and sorry for not very timely response)! I've
 added last stable/havana release to the test-requirements, and
 received some new error from the Jenknins' side: [1]. At first I
 thought that the problem is caused by the reverse order of settings
 modules inclusion (and almost renounced the idea of change [2]), but
 today read the code and traceback again and realized that this error
 happens even before muranodashboard settings come into play! So now it
 seems to me that there are some inherent problems with horizon package
 installation with pip even if the source different from the PyPi is
 used. Is that a known issue or am I doing something wrong?

 [1] 
 http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
 [2] https://review.openstack.org/#/c/68125/

 On Thu, Mar 20, 2014 at 9:50 PM, Akihiro Motoki amot...@gmail.com wrote:
 As a workaround you can use tarball in requirements.txt (or
 test-requirements.txt).
 Each versions of Horizon/openstack_dashboard is available at
 http://tarballs.openstack.org/horizon/.
 Each tarball is generated every time corresponding branch or tag is updated.
 If you would like to use horizon I-3 as a requirement, please add the
 following line to your requirements.txt:

 http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz

 Thanks,
 Akihiro

 On Fri, Mar 21, 2014 at 2:22 AM, Paul Belanger
 paul.belan...@polybeacon.com wrote:
 On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 It depends on openstack_dashboard, namely on
 openstack_dashboard.settings. So it is fine from Murano's point of
 view to have openstack_dashboard published on PyPi. Many thanks for
 considering my request :).

 We are having this issue too, for now we have worked around it with
 pip switches allowing to download from an external source, but
 hopefully we'll get horizon and openstack_dashboard split out in the
 near future.

 Like you, we've built a dashboard atop of horizon, mostly because of
 the existing keystone integration.  Everything else we do is external
 to OpenStack.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter: 
 https://twitter.com/pabelanger

 ___
 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



 --
 Timur Sufiev

 ___
 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



-- 
Timur Sufiev

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

Re: [openstack-dev] Separating our Murano PL core in own package

[Timur Sufiev]

+1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too broad.

On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
tnurlygaya...@mirantis.com wrote:
 Hi Serg,

 This idea sounds good, I suggest to use name 'murano.engine.murano_pl' (not
 just common name like 'language' or 'dsl', but name, which will be based on
 'MuranoPL')

 Do we plan to support the ability to define different languages for Murano
 Engine?


 Thank you!


 On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.com
 wrote:

 There is a idea to separate core of Murano PL implementation from engine
 specific code, like it was done in PoC. When this two things are separated
 in different packages, we will be able to track and maintain our language
 core as clean as possible from engine specific code. This will give to us an
 ability to easily separate our language implementation to a library.

 Questions is under what name we should place core of Murano PL?

 1) muranoapi.engine.language;
 2) muranoapi.engine.dsl;
 3) suggestions?

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

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




 --

 Timur,
 QA Engineer
 OpenStack Projects
 Mirantis Inc

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




-- 
Timur Sufiev

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

[openstack-dev] [Murano] API/data formats version change and compatibility

[Timur Sufiev]

Hi all!

While adapting Murano's Dynamic UI to the new MuranoPL data input
format, I've encountered the need to add some new fields to it, which
meant that the 'Version' field also had to be added to Dynamic UI. So,
Dynamic UI definition without Version field is supposed to be of v.1
while upcoming Murano 0.5 release will support Dynamic UI v.2
processing (which produces data suitable for the MuranoPL in 0.5).

But then the next questions arised. What if Murano 0.5 Dynamic UI
processor gets definition in v.1 format? Should it be able to process
it as well? If it should, then to which murano-api endpoint should it
pass the resulting object model?

I suspect that we have to deal with a slightly broader scope: to which
extent should Murano components of each new version support the data
formats and APIs from the previous versions? I suggest to discuss this
question on the upcoming Murano's community meeting.

-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

[Timur Sufiev]

It depends on openstack_dashboard, namely on
openstack_dashboard.settings. So it is fine from Murano's point of
view to have openstack_dashboard published on PyPi. Many thanks for
considering my request :).

On Mon, Mar 17, 2014 at 12:19 PM, Akihiro Motoki mot...@da.jp.nec.com wrote:
 Does muranodashboard depend on only horizon or require
 openstack_dashboard too?

 I think we can publish openstack_dashboard (including horizon) even if
 horizon and openstack_dashboard are not separeted.
 Once we separate them successfully, we can publish horizon module
 and add dependency on horizon to openstack_dashboard module.
 Am I missing somothing?

 Another point we need to consider is that Horizon includes
 a lot of Javascirpt files and it fits PyPI.

 Thanks,
 Akihiro

 (2014/03/17 15:12), Timur Sufiev wrote:
 Is there any chance of having horizon distribution in its current
 state (i.e., with openstack_dashboard and other 3rd-party stuff) on
 PyPi? Because the 'next' milestone assigned to this blueprint suggests
 (at least to me) that the separation is not going to happen soon :).

 On Thu, Mar 13, 2014 at 1:40 PM, Matthias Runge mru...@redhat.com wrote:
 On Thu, Mar 13, 2014 at 01:10:06PM +0400, Timur Sufiev wrote:
 Recently I've discovered (and it was really surprising for me) that
 horizon package isn't published on PyPi (see
 http://paste.openstack.org/show/73348/). The reason why I needed to
 install horizon this way is that it is desirable for muranodashboard
 unittests to have horizon in the test environment (and it currently
 seems not possible).

 I'd expect this to change, when horizon and OpenStack Dashboard
 are finally separated. I agree, it makes sense to have something
 comparable to the package now called horizon on PyPi.

 https://blueprints.launchpad.net/horizon/+spec/separate-horizon-from-dashboard
 --
 Matthias Runge mru...@redhat.com

 ___
 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



-- 
Timur Sufiev

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

[openstack-dev] [horizon] horizon PyPi distribution missing

[Timur Sufiev]

Hello!

Recently I've discovered (and it was really surprising for me) that
horizon package isn't published on PyPi (see
http://paste.openstack.org/show/73348/). The reason why I needed to
install horizon this way is that it is desirable for muranodashboard
unittests to have horizon in the test environment (and it currently
seems not possible).

Could you please give me a clue why horizon distribution is missing at PyPi?

-- 
Timur Sufiev

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

Re: [openstack-dev] [horizon] Augmenting openstack_dashboard settings and possible horizon bug

[Timur Sufiev]

Thanks to the Ana Krivokapic's comment in
https://bugs.launchpad.net/horizon/+bug/1271151 I've found a typo in my
code, so it's not Horizon's bug but mine. So, the original approach I used
for augmenting openstack_dashboard settings (which is described in the
initial letter of this thread) works fine, and it's still more flexible
than a new Horizon's mechanism for adding separate dashboards settings, so
we'll stick to our approach. Just to keep you informed :).

Also, the thing that bothered me most when I thought about how Murano could
use this new Horizon's config facility, is changing DATABASES parameter
(muranodashboard app needs it to be set) - and more generally, resolving
conflicts when different dashboards change some common parameters (such as
DATABASES or SESSION_BACKEND) affecting all Django applications. Current
algorithm of determining which dashboard sets the actual value of a
parameter such as DATABASES seems unreliable to me in sense that it can
break other dashboards which failed to set this parameter to the value they
needed.


On Thu, Jan 16, 2014 at 1:57 PM, Timur Sufiev tsuf...@mirantis.com wrote:

 Radomir,

 it looks interesting indeed. I think Murano could use it in case several
 additional parameters were added. I will submit a patch with my ideas a bit
 later.

 One thing that seemed tricky to me in your patchset is determining which
 dashboard will actually be the default one, but I have yet no clue on how
 it could be made simpler using pluggable architecture.


 On Wed, Jan 15, 2014 at 6:57 PM, Radomir Dopieralski 
 openst...@sheep.art.pl wrote:

 On 15/01/14 15:30, Timur Sufiev wrote:
  Recently I've decided to fix situation with Murano's dashboard and move
  all Murano-specific django settings into a separate file (previously
  they were appended to
  /usr/share/openstack-dashboard/openstack_dashboard/settings.py). But, as
  I knew, /etc/openstack_dashboard/local_settings.py is for customization
  by admins and is distro-specific also - so I couldn't use it for
  Murano's dashboard customization.

 [snip]

  2. What is the sensible approach for customizing settings for some
  Horizon's dashboard in that case?

 We recently added a way for dashboards to have (some) of their
 configuration provided in separate files, maybe that would be
 helpful for Murano?

 The patch is https://review.openstack.org/#/c/56367/

 We can add more settings that can be changed, we just have to know what
 is needed.

 --
 Radomir Dopieralski


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




 --
 Timur Sufiev




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

Re: [openstack-dev] [horizon] Augmenting openstack_dashboard settings and possible horizon bug

[Timur Sufiev]

Radomir,

it looks interesting indeed. I think Murano could use it in case several
additional parameters were added. I will submit a patch with my ideas a bit
later.

One thing that seemed tricky to me in your patchset is determining which
dashboard will actually be the default one, but I have yet no clue on how
it could be made simpler using pluggable architecture.


On Wed, Jan 15, 2014 at 6:57 PM, Radomir Dopieralski openst...@sheep.art.pl
 wrote:

 On 15/01/14 15:30, Timur Sufiev wrote:
  Recently I've decided to fix situation with Murano's dashboard and move
  all Murano-specific django settings into a separate file (previously
  they were appended to
  /usr/share/openstack-dashboard/openstack_dashboard/settings.py). But, as
  I knew, /etc/openstack_dashboard/local_settings.py is for customization
  by admins and is distro-specific also - so I couldn't use it for
  Murano's dashboard customization.

 [snip]

  2. What is the sensible approach for customizing settings for some
  Horizon's dashboard in that case?

 We recently added a way for dashboards to have (some) of their
 configuration provided in separate files, maybe that would be
 helpful for Murano?

 The patch is https://review.openstack.org/#/c/56367/

 We can add more settings that can be changed, we just have to know what
 is needed.

 --
 Radomir Dopieralski


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




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

[openstack-dev] [horizon] Augmenting openstack_dashboard settings and possible horizon bug

[Timur Sufiev]

Hi there!

Recently I've decided to fix situation with Murano's dashboard and move all
Murano-specific django settings into a separate file (previously they were
appended to
/usr/share/openstack-dashboard/openstack_dashboard/settings.py). But, as I
knew, /etc/openstack_dashboard/local_settings.py is for customization by
admins and is distro-specific also - so I couldn't use it for Murano's
dashboard customization.

So the following scheme was devised: change DJANGO_SETTINGS_MODULE in
Apache config/WSGI python module to 'muranodashboard.settings' which
contains all Murano-specific settings and imports
openstack_dashboard.settings, which in turn imports local.local_settings.
This approach seemed fine until I coded it and ran: it immediately failed
with 'ImproperlyConfigured: The SECRET_KEY setting must not be empty.'
exception.

After spending some time in debugger, I found out that during
'openstack_dashboard.settings' module evaluation 'django.conf.Settings'
class is instantiated and it requires the 'SECRET_KEY' parameter to be
present in settings module referenced by DJANGO_SETTINGS_MODULE environment
variable (which, in my case is 'muranodashboard.settings'). But if I try to
avoid this error and define my own SECRET_KEY in
'muranodashboard.settings', I end up with 2 different SECRET_KEY values
(one from muranodashboard.settings, the other hanging somewhere in
horizon's machinery from local.local_settings /
openstack_dashboard.settings) which is not good either.

I have 2 questions:

1. Should this behaviour be considered as a Horizon bug or a Django bug?
2. What is the sensible approach for customizing settings for some
Horizon's dashboard in that case?

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

[openstack-dev] [Murano] Murano Release 0.4 Announcement

[Timur Sufiev]

I'm very glad to announce that a new stable version of Murano
v0.4https://launchpad.net/murano/1.0/0.4 has
been released!

The most noticeable change Murano Team is proud of is the Metadata
Repository feature, consisting of a new Web UI for managing metadata
objects via Horizon panel and the murano-repository service itself (along
with all the required changes in Dashboard and Conductor components). This
new feature moves Murano several steps closer to an implementation of its new
mission https://wiki.openstack.org/wiki/Murano/ApplicationCatalog, though
we're still at the beginning of a long road.

Among other improvements are full Havana and Neutron support, as well as
numerous improvements in Conductor's networking machinery (also known as
Advanced Networking). The latter allows Conductor to work with either Nova
Networking or Neutron by changing just one parameter in Conductor's config
file.

A full list of changes and much more details can be found in Release
Noteshttps://wiki.openstack.org/wiki/Murano/ReleaseNotes_v0.4 on
the project wiki.

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

[openstack-dev] [Convection] Murano and Convection proposal discussion

[Timur Sufiev]

Hello!


I am an engineer from Murano team. Murano is an OpenStack project built
around Windows components deployment. Currently we (Murano team) are
working on improving Murano architecture to fit better in OpenStack
ecosystem and reuse more functionality from the other projects. As part of
that we’ve realized that we need task execution workflow. We see a lot of
value in Convection proposal for what we need as well as OpenStack users in
general.

*
*

We have some ideas around possible design approach as well as bits and
pieces that we can potentially reuse from the existing codebase. We would
like to start contributing to Convection and get it moving forward. As the
first step it would be good to start a discussion with you on how to unify
our vision and start the development.

*
*

Here are some of the areas that we would like to discuss:

   -

   Workflow definition proposal. We propose YAML as a task workflow
   definition format. Each node in the workflow has state, dependencies and an
   action associated with it. Action is defined as a generic instruction to
   call some other component using a specific transport (e.g. RabbitMQ).
   Dependency means “in order to execute this task it is required that some
   other tasks be in a certain state”.
   -

   Workflow definitions API proposal. We are discussing and prototyping an
   API for uploading workflow definitions, modifying them, adding the sources
   triggering new tasks to be scheduled for execution and so forth. We propose
   to adapt this API to Convection needs and possible rewrite and extend it.
   -

   Task dependencies resolution engine proposal. We already have a generic
   engine which processes workflows. It is essentially a parallel
   multithreaded state machine. We propose to use this engine as a basis for
   Convection and extend it by adding external event sources like timers and
   Ceilometer alarms.


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

Re: [openstack-dev] [Convection] Murano and Convection proposal discussion

[Timur Sufiev]

Hi!

I just forgot to ask about the best way for discussion: what will it be? We
have an IRC channel #murano at FreeNode, so you can find someone from our
team here. The best way probably will be a Google hangout or Webex meeting
for a live discussion and document sharing.


On Wed, Oct 9, 2013 at 12:44 AM, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello!


 I am an engineer from Murano team. Murano is an OpenStack project built
 around Windows components deployment. Currently we (Murano team) are
 working on improving Murano architecture to fit better in OpenStack
 ecosystem and reuse more functionality from the other projects. As part of
 that we’ve realized that we need task execution workflow. We see a lot of
 value in Convection proposal for what we need as well as OpenStack users in
 general.

 *
 *

 We have some ideas around possible design approach as well as bits and
 pieces that we can potentially reuse from the existing codebase. We would
 like to start contributing to Convection and get it moving forward. As the
 first step it would be good to start a discussion with you on how to unify
 our vision and start the development.

 *
 *

 Here are some of the areas that we would like to discuss:

-

Workflow definition proposal. We propose YAML as a task workflow
definition format. Each node in the workflow has state, dependencies and an
action associated with it. Action is defined as a generic instruction to
call some other component using a specific transport (e.g. RabbitMQ).
Dependency means “in order to execute this task it is required that some
other tasks be in a certain state”.
-

Workflow definitions API proposal. We are discussing and prototyping
an API for uploading workflow definitions, modifying them, adding the
sources triggering new tasks to be scheduled for execution and so forth. We
propose to adapt this API to Convection needs and possible rewrite and
extend it.
-

Task dependencies resolution engine proposal. We already have a
generic engine which processes workflows. It is essentially a parallel
multithreaded state machine. We propose to use this engine as a basis for
Convection and extend it by adding external event sources like timers and
Ceilometer alarms.


 --
 Timur Sufiev




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