Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Anton Zemlyanov]

Hi,

I have a question on js-openstacklib. If it is intended for browsers, there
will be lots of issues with cross-domain security policy, browser cannot
just go to any REST resource it wants. There is either some server-side
proxy required or cooperation of the all the REST services we want to talk
to. How we want to handle the cross-domain stuff?

Anton

On Thu, Apr 21, 2016 at 5:35 PM, Michael Krotscheck 
wrote:

> This post contains the current working draft of the JavaScript roadmap
> which myself and Beth Elwell will be working on in Newton. It’s a big list,
> and we need help - Overall themes for this cycle are Consistency,
> Interoperability, and engaging with the JavaScript community at large. Our
> end goal is to build the foundations of a JavaScript ecosystem, which
> permits the creation of entirely custom interfaces.
>
> Note: We are not trying to replace Horizon, we are aiming to help those
> downstream who need something more than “Vanilla OpenStack”. If you'd like
> to have a discussion on this point, I'd be happy to have that under a
> different subject.
>
> Continue Development: ironic-webclient
>
> The ironic-webclient will release its first version during the Newton
> cycle. We’re awfully close to having the basic set of features supported,
> and with some excellent feedback from the OpenStack UX team, will also have
> a sexy new user interface that’s currently in the review queue. Once this
> work is complete, we will begin extracting common components into a new
> project, named…
>
> New: js-openstacklib
>
> This new project will be incubated as a single, gate-tested JavaScript API
> client library for the OpenStack API’s. Its audience is software engineers
> who wish to build their own user interface using modern javascript tools.
> As we cannot predict downstream use cases, special care will be taken to
> ensure the project’s release artifacts can eventually support both browser
> and server based applications.
>
> Philosophically, we will be taking a page from the python-openstackclient
> book, and avoid creating a new project for each of OpenStack’s services. We
> can make sure our release artifacts can be used piecemeal, however trying
> to maintain code consistency across multiple different projects is a hard
> lesson that others have already learned for us. Let’s not do that again.
>
> New: js-generator-openstack
>
> Yeoman is JavaScript’s equivalent of cookiecutter, providing a scaffolding
> engine which can rapidly set up, and maintain, new projects. Creating and
> maintaining a yeoman generator will be a critical part of engaging with the
> JavaScript community, and can drive adoption and consistency across
> OpenStack as well. Furthermore, it is sophisticated enough that it could
> also support many things that exist in today’s Python toolchain, such as
> dependency management, and common tooling maintenance.
>
> Development of the yeoman generator will draw in lessons learned from
> OpenStack’s current UI Projects, including Fuel, StoryBoard, Ironic,
> Horizon, Refstack, and Health Dashboard, and attempt to converge on common
> practices across projects.
>
> New (exploration): js-npm-publish-xstatic
>
> This project aims to bridge the gap between our JavaScript projects, and
> Horizon’s measured migration to AngularJS. We don’t believe in duplicating
> work, so if it is feasible to publish our libraries in a way that Horizon
> may consume (via the existing xstatic toolchain), then we certainly should
> pursue that. The notable difference is that our own projects, such as
> js-openstacklib, don’t have to go through the repackaging step that our
> current xstatic packages do; thus, if it is possible for us to publish to
> npm and to xstatic/pypi at the same time, that would be best.
>
> New: Xenial Build Nodes
>
> As of two weeks ago, OpenStack’s Infrastructure is running a version of
> Node.js and npm more recent than what is available on Trusty LTS.
> Ultimately, we would like to converge this version on Node4 LTS, the
> release version maintained by the Node foundation. The easiest way to do
> this is to simply piggyback on Infra’s impending adoption of Xenial build
> nodes, though some work is required to ensure this transition goes smoothly.
>
> Maintain: eslint-config-openstack
>
> eslint has updated to version 2.x, and no more rule bugfixes are being
> landed in 1.x. eslint-config-openstack will follow in kind, updating itself
> to use eslint 2.x. We will releases this version as eslint-config-openstack
> v2.0.0, and continue to track the eslint version numbers from there.
> Downstream projects are encouraged to adopt this, as it is unlikely that
> automated dependency updates for JavaScript projects will land this cycle.
>
> Maintain: NPM Mirrors
>
> We are currently synchronizing all npm packages to our AFS master disks,
> which should be the final step in getting functional npm mirrors. Some
> minor tweaking will be required to make them functional, and they will n

Re: [openstack-dev] [infra] [fuel] [javascript] Supporting ES6

[Anton Zemlyanov]

ES6 is risk-free solution. Browsers do not support it properly, but it is
not a problem. ES6 code can be compiled to ES5 and be used in browsers
until proper ES6 support appear. Fuel uses Babel (https://babeljs.io/) to
compile ES6 to ES5. Node 6.x supports it almost completely.

Anton

On Tue, May 3, 2016 at 9:42 PM, Michael Krotscheck 
wrote:

> TL/DR: Should we support EcmaScript 6?
>
> Discussions I've had on the topic:
>
> Vancouver:
> - Browser support is not yet broad enough, so no- we shouldn't support
> ES6.
> - TypeScript is too closely tied to Corporations (tm), not really an open
> standard. Do not support TypeScript.
>
> Austin:
> - Fuel is using ES6, is now an official project (?).
> - We have non-browser projects that could use it, assuming that we have a
> recent version of Node.js that we can test on.
> - We now have Node4 LTS on our infra build nodes, which support _most_ of
> EcmaScript 6 things.
> - EcmaScript continues to be moving target (And will likely always be a
> moving target).
> - Xenial contains Node 4 LTS. Ubuntu does _not_ have an upgrade exception
> for node (akin to Firefox).
> - Node 6 LTS was released during the summit.
>
> Body of work required:
> - Discuss and enable linting rules for ES6 in eslint-config-openstack.
> - Smoke-test fuel's unit and functional testing for ES6 components.
>
> Personal Assessment:
>
> Frankly, we already have ES6 in our infra, so that train has left the
> building. What we need to do is make sure it has the same level of support
> as other languages, which, I believe, isn't going to be too difficult. I
> also have some commitments of mutual assistance from Vitaly (Fuel) to keep
> things sane and keep communication open. As for the upcoming Node4 vs.
> Node6 question, I recommend that we _not_ upgrade to Node 6 LTS in the
> Newton cycle, however strongly consider it for the Ocata cycle.
>
> Am I missing anything? Does anyone have opinions?
>
> Michael
>
> __
> 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][keystone] SSO

[Anton Zemlyanov]

SSO (Single sign-on) is great. There are some problems, though:

1) If the cloud is private without Internet access, then a private SSO
service should be up and runnning
2) There is no such a thing as OpenStack ID. Should we use Launchpad?
Facebook login? Twitter?
3) Technical difficulties embedding SSO into website.

As SSO service is often located on the different domain, the browser opens
a new window, then open the SSO page there, then redirects to "our" page
that uses some cross domain messageing like postMessage to inform main page
of login results. The main page closes the popup. The stuff is rather
complex, Facebook and other social nets have SDKs that do all the stufff.

That's certainly not an easy task to make an SSO service, implement SSO SDK
and embed in into Horizon.

Anton

On Fri, Feb 6, 2015 at 11:03 PM, Tim Bell  wrote:

>
>
> From the sound of things, we’re not actually talking about SSO. If so, we
> would not be talking about the design of a login screen.
>
>
>
> An SSO application such as Horizon would not have a login page. If the
> user was logged in already through corporate/organisation SSO page, nothing
> would appear before the standard Horizon page.
>
>
>
> We strongly encourage our user community that if there is any web page
> asking for your credentials which is not the CERN standard SSO page, it is
> not authorised. Our SSO also supports Google/Twitter/Eduroam etc. logins.
> Some of these will be refused for OpenStack login so that having a twitter
> account alone does not get you access to CERN’s cloud resources (but this
> is an authorisation rather than authentication problem).
>
>
>
> Is there really the use case for a site where there is SSO from a
> corporate perspective but there is not a federated login SSO capability ? I
> don’t have a fundamental problem with the approach but we should position
> it with respect to the use case which is that I login in the morning and
> all applications I use (cloud and all) are able to recognise that.
>
>
>
> Tim
>
>
>
>
>
> *From:* Adam Young [mailto:ayo...@redhat.com]
> *Sent:* 06 February 2015 19:48
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] [horizon][keystone]
>
>
>
> On 02/04/2015 03:54 PM, Thai Q Tran wrote:
>
> Hi all,
>
> I have been helping with the websso effort and wanted to get some feedback.
> Basically, users are presented with a login screen where they can select:
> credentials, default protocol, or discovery service.
> If user selects credentials, it works exactly the same way it works today.
> If user selects default protocol or discovery service, they can choose to
> be redirected to those pages.
>
> Keep in mind that this is a prototype, early feedback will be good.
> Here are the relevant patches:
> https://review.openstack.org/#/c/136177/
> https://review.openstack.org/#/c/136178/
> https://review.openstack.org/#/c/151842/
>
> I have attached the files and present them below:
>
>
>
>
> Replace the dropdown with a specific link for each protocol type:
>
> SAML and OpenID  are the only real contenders at the moment, but we will
> not likely have so many that it will clutter up the page.
>
> Thanks for doing this.
>
>
>
>
>
>
>
>
>  __
>
> 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] JavaScript docs?

[Anton Zemlyanov]

JSDoc (ngdoc) is good thing. It allows to describe files, functions and
it's parameters, constructors, classes in case of ES6.

The problem is it tends to diverge with reality. The code is being fixed
and evolved, but comments are often not updated (who want to do much more
work)? And JSDoc generated documentation loses the connection to reality.

Anton

On Thu, Feb 5, 2015 at 12:04 PM, Radomir Dopieralski  wrote:

> On 02/04/2015 06:06 PM, Thai Q Tran wrote:
> > As we're moving toward Angular, might make sense for us to adopt ngdoc
> > as well.
>
> I don't think it makes much sense. We don't have any style guide for the
> JavaScript documentation simply because it's not needed. We don't really
> have any for Python either (although there might be a lot of
> python-specific stuff in what we have). We just have guidelines for
> documenting code. Any code. JavaScript, Python, even templates.
>
> Plus, the documentation generator that we are using already, Sphinx,
> supports JavaScript perfectly fine, so I see no reason to add another tool.
>
> I agree it would be nice to actually start using it for JavaScript code
> too, though.
>
> --
> Radomir Dopieralski
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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][keystone]

[Anton Zemlyanov]

Hi,

I guess "Credentials" is login and password. I have no idea what is
"Default Protocol" or "Discovery Service".
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran  wrote:

> Hi all,
>
> I have been helping with the websso effort and wanted to get some feedback.
> Basically, users are presented with a login screen where they can select:
> credentials, default protocol, or discovery service.
> If user selects credentials, it works exactly the same way it works today.
> If user selects default protocol or discovery service, they can choose to
> be redirected to those pages.
>
> Keep in mind that this is a prototype, early feedback will be good.
> Here are the relevant patches:
> https://review.openstack.org/#/c/136177/
> https://review.openstack.org/#/c/136178/
> https://review.openstack.org/#/c/151842/
>
> I have attached the files and present them below:
>
>
>
>
>
> __
> 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] static files handling, bower/

[Anton Zemlyanov]

Solaris is supported by node.js:

Solaris 32-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
Solaris 64-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz

I think Solaris is no longer relevant

On Tue, Jan 13, 2015 at 7:13 PM, Drew Fisher  wrote:

>
>
> On 1/13/15 7:59 AM, Jeremy Stanley wrote:
> > On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
> > [...]
> >> But, as far as I understand, node.js will become a development
> >> requirement (and most probably a requirement for testing), but not for
> >> deployment.
> > [...]
> >
> > A requirement for testing _is_ a requirement for deployment. If it's
> > not tested, it's broken. If you're deploying software on a platform
> > where it can't be tested then you're simply _hoping_ that it's not
> > broken, and that is almost certainly a false hope.
> >
>
> Exactly.  We have to test this code base extensively before we package
> it up for Solaris.  Under no circumstances do we just blindly repackage
> the releases and push them out to customers.  Node.js is a total
> incompatibility for Solaris.  If upstream moves to using Bower we'll be
> forced to look for alternatives at managing the JavaScript libraries.
>
> Why were the libraries ripped from the Horizon codebase in the first
> place?  It seems to me they belong with the code using it.
>
> -Drew
>
> __
> 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] [Fuel] update existing plugin and add new ones

[Anton Zemlyanov]

There was a discussion on whether to put all the fuel plugins into the
single repository or have them separate. The problems with all the fuel
plugins in single repository are following:

- it is impossible to make a branch on a single plugin, branch is applied
to the whole repository and all the plugins
- plugins may have different release cycles, we will get lots of
unnecessary merges/rebases
- rebasing can be a pain. If I have a branch, I have to rebase when some
other plugins change
- there should be someone who manage merging to master, the person who
"owns" all the plugins

Having all the plugins in single repository will cause interference. if I
do some plugin, I have to consider what developers of other plugins do.

Anton


On Tue, Jan 6, 2015 at 7:00 PM,  wrote:

>  Hello,
>
>
>
> Actually there is two different fuel plugins git repositories. One in
> stackforge and the other in mirantis:
>
> https://github.com/stackforge/fuel-plugins
>
> https://github.com/Mirantis/fuel-plugins
>
>
>
> it is a little bit confusing. Why needing two different repositories?
>
>
>
> which one should be used in order to:
>
> -add new plugin
>
> -update/correct exisiting one (for example adding 7-mode and e-series
> support to cinder netapp plugin according to
> https://bugs.launchpad.net/fuel/+bug/1405186)
>
> How are going to be manage version? There is a stable/6.0 branch from
> stackforge repo but not mirantis one
>
>
>
> Regards,
>
>
>
> Samuel Bartel
>
> Orange
>
>
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 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] [Fuel] Building Fuel plugins with UI part

[Anton Zemlyanov]

The building of the UI plugin has several things I do not like

1) I need to extract the UI part of the plugin and copy/symlink it to
fuel-web
2) I have to run grunt build on the whole fuel-web
3) I have to copy files back to original location to pack them
4) I cannot easily switch between development/production versions (no way
to easily change entry point)

The only way to install plugin is `fuel plugins --install`, no matter
development or production, so even development plugins should be packed to
tar.gz

Anton

On Mon, Dec 15, 2014 at 3:30 PM, Przemyslaw Kaminski  wrote:
>
>  First of all, compiling of statics shouldn't be a required step. No one
> does this during development.
> For production-ready plugins, the compiled files should already be
> included in the GitHub repos and installation of plugin should just be a
> matter of downloading it. The API should then take care of informing the UI
> what plugins are installed.
> The npm install step is mostly one-time.
> The grunt build step for the plugin should basically just compile the
> staticfiles of the plugin and not the whole project. Besides with one file
> this is not extendable -- for N plugins we would build 2^N files with all
> possible combinations of including the plugins? :)
>
> P.
>
>
> On 12/15/2014 11:35 AM, Anton Zemlyanov wrote:
>
> My experience with building Fuel plugins with UI part is following. To
> build a ui-less plugin, it takes 3 seconds and those commands:
>
>  git clone https://github.com/AlgoTrader/test-plugin.git
>  cd ./test-plugin
> fpb --build ./
>
>  When UI added, build start to look like this and takes many minutes:
>
>  git clone https://github.com/AlgoTrader/test-plugin.git
> git clone https://github.com/stackforge/fuel-web.git
> cd ./fuel-web
> git fetch https://review.openstack.org/stackforge/fuel-web
> refs/changes/00/112600/24 && git checkout FETCH_HEAD
> cd ..
> mkdir -p ./fuel-web/nailgun/static/plugins/test-plugin
> cp -R ./test-plugin/ui/* ./fuel-web/nailgun/static/plugins/test-plugin
> cd ./fuel-web/nailgun
> npm install && npm update
> grunt build --static-dir=static_compressed
> cd ../..
> rm -rf ./test-plugin/ui
> mkdir ./test-plugin/ui
> cp -R ./fuel-web/nailgun/static_compressed/plugins/test-plugin/*
> ./test-plugin/ui
> cd ./test-plugin
> fpb --build ./
>
>  I think we need something not so complex and fragile
>
>  Anton
>
>
>
>
> ___
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Building Fuel plugins with UI part

[Anton Zemlyanov]

My experience with building Fuel plugins with UI part is following. To
build a ui-less plugin, it takes 3 seconds and those commands:

git clone https://github.com/AlgoTrader/test-plugin.git
cd ./test-plugin
fpb --build ./

When UI added, build start to look like this and takes many minutes:

git clone https://github.com/AlgoTrader/test-plugin.git
git clone https://github.com/stackforge/fuel-web.git
cd ./fuel-web
git fetch https://review.openstack.org/stackforge/fuel-web
refs/changes/00/112600/24 && git checkout FETCH_HEAD
cd ..
mkdir -p ./fuel-web/nailgun/static/plugins/test-plugin
cp -R ./test-plugin/ui/* ./fuel-web/nailgun/static/plugins/test-plugin
cd ./fuel-web/nailgun
npm install && npm update
grunt build --static-dir=static_compressed
cd ../..
rm -rf ./test-plugin/ui
mkdir ./test-plugin/ui
cp -R ./fuel-web/nailgun/static_compressed/plugins/test-plugin/*
./test-plugin/ui
cd ./test-plugin
fpb --build ./

I think we need something not so complex and fragile

Anton
___
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

[Anton Zemlyanov]

The confirmation modal on the top of the other modal is weird and
cumbersome. I think disabling clicking outside space (staic backdrop) is
the right way to go.

Anton

On Tue, Dec 2, 2014 at 8:30 PM, Thai Q Tran  wrote:

> I like David's approach, but having two modals (one for the form, one for
> the confirmation) on top of each other is a bit weird and would require
> constant checks for input.
> We already have three ways to close the dialog today: via the cancel
> button, X button, and ESC key. It's more important to me that I don't lose
> work by accidentally clicking outside. So from this perspective, I think
> that having a static behavior is the way to go. Regardless of what approach
> we pick, its an improvement over what we have today.
>
>
> [image: Inactive hide details for Timur Sufiev ---12/02/2014 04:22:00
> AM---Hello, Horizoneers and UX-ers! The default behavior of modal]Timur
> Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The
> default behavior of modals in Horizon (defined in turn by Bootstr
>
> From: Timur Sufiev 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 12/02/2014 04:22 AM
> Subject: [openstack-dev] [horizon] [ux] Changing how the modals are
> closed in Horizon
> --
>
>
>
> 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 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] URLs

[Anton Zemlyanov]

For the REST API to be visible from browser it should either be on the same
domain and port or it should implement CORS spec (Cross-site HTTP requests,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).

If REST API implements CORS, then every HTTP request will be preceded with
OPTIONS request to check the real invocation is allowed. In practice, all
the API services are usually proxied from a single location, so URL naming
scheme is very desirable.

Anton

On Wed, Nov 12, 2014 at 3:21 PM, Darren Kenny 
wrote:

> Chris Dent wrote:
>
>> On Tue, 11 Nov 2014, Adam Young wrote:
>>
>>  My suggestion, from a while ago, was to have a naming scheme that
>>> deconflicts putting all of the services onto a single server, on port 443.
>>>
>>
>> +1
>>
>> The current state of affairs is indeed weird.
>>
>
> It is, and as BUIs move more towards client's doing the access of the
> URLs, it
> is something we need to fix - since most browsers restrict cross-domain
> access (including different ports on the same host) for security reasons.
>
> This is the reason that the Horizon guys wrote a kind of reverse-proxy
> WSGI to enable demonstrations of the AngularJS work last week - so that
> all the REST API calls were back to the origin of Horizon itself.
>
>
>> Is this something that ought to be considered in the api-wg's
>> discussions?
>>
>>
> That would appear to fit within the aims of that working group.
>
> Thanks,
>
> Darren.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Anton Zemlyanov]

Modernizing Horizon using Angular is really great. I would suggest a couple
of minor things to consider.

First, font-awesome is excellent and free font, but there are two problems:
it has lots of icons that are not used, it also miss some other icons worth
to have. I would suggest Fontello, it is tool for picking glyphs from all
the free fonts round there and building custom fonts

Grunt is being forced out by Gulp that is times faster while having the
same level of plugins and tools and is easier to use

Anton

On Tue, Nov 11, 2014 at 11:02 AM, Richard Jones 
wrote:

> Hi all,
>
> At the summit last week, we developed a plan for moving forward with
> modernising Horizon's UI using AngularJS. If you weren't at that meeting
> and are interested in helping out with this effort please let me know!
>
> The relevant etherpad from the meeting:
> https://etherpad.openstack.org/p/kilo-horizon-contributors-meetup
>
> TL;DR: piece by piece we will replace Django views in Horizon with angular
> views, and we're going to start with Identity
>
> First up, I'd like to ask the UX folk who raised their hands in that
> meeting to indicate which of the Identity panes we should start with. I
> believe a wizard was mentioned, as a way to exercise the new wizard code
> from Maxime.
>
> At the same time, I'm looking at updating the AngularJS recommendations in
> the wiki. I believe other aspects of the current approach to angular code
> should also be revisited, if we're to scale up to the full angular
> front-end envisaged. I'd appreciate if those interested in this aspect in
> particular could contact me so we can sort this out as a team!
>
> I'd like to start the design work for the new REST API layer we'll be
> exposing to the angular application code, but that is also part of the
> broader discussion about the structure of the angular code in the Horizon
> application as mentioned above. Should it be a new blueprint/spec?
>
> There were some discussions around tooling. We're using xstatic to manage
> 3rd party components, but there's a lot missing from that environment. I
> hesitate to add supporting xstatic components on to the already large pile
> of work we have to do, so would recommend we switch to managing those
> components with bower instead. For reference the list of 3rd party
> components I used in angboard* (which is really only a teensy fraction of
> the total application we'd end up with, so this components list is probably
> reduced):
>
> json3
> es5-shim
> angular
> angular-route
> angular-cookies
> angular-animate
> angular-sanitize
> angular-smart-table
> angular-local-storage
> angular-bootstrap
> angular-translate
> font-awesome
> boot
> underscore
> ng-websocket
>
> Just looking at PyPI, it looks like only a few of those are in xstatic,
> and those are out of date.
>
> grunt provides a lot of features for developing an angular interface. In
> particular LiveReload accelerates development significantly. There's a
> django-livereload but it uses tiny-lr under the hood, so we're still using
> a node application for LiveReload support... so it might make sense to just
> use grunt. grunt provides many other features as well (wiredep integration
> with bower, build facilities with ngMin, test monitoring and reload etc).
>
> There seemed to be agreement to move to jasmine (from qunit) for writing
> the tests. It's not noted in the etherpad, but I recall karma was accepted
> as a given for the test runner. For those not in the meeting, angboard uses
> mocha+chai for test writing, but I agreed that jasmine is acceptable, and
> is already used by Storyboard (see below).
>
> Also, phantomjs so we don't have to fire up a browser for exercising (what
> should hopefully be an extensive) unit test suite.
>
> The Storyboard project has successfully integrated these tools into the
> OpenStack CI environment.
>
>
>  Richard
>
> * https://github.com/r1chardj0n3s/angboard
>
> ___
> 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] [Fuel] fuel master monitoring

[Anton Zemlyanov]

We can add a notification to FuelWeb, no additional software or user
actions are required. I would not overestimate this method though, it is in
no way the robust monitoring system. Forcing user to do something on a
regular basis is unlikely to work.

Anton

On Thu, Nov 6, 2014 at 11:55 AM, Przemyslaw Kaminski  wrote:

>  I think we're missing the point here. What I meant adding a simple
> monitoring system that informed the user via UI/CLI/email/whatever of low
> resources on fuel master node. That's it. HA here is not an option -- if,
> despite of warnings, the user still continues to use fuel and disk becomes
> full, it's the user's fault. By adding these warnings we have a way of
> saying "We told you so!" Without warnings we get bugs like [1] I mentioned
> in the first post.
>
> Of course user can check disk space by hand but since we do have a
> full-blown UI telling the user to periodically log in to the console and
> check disks by hand seems a bit of a burden.
>
> We can even implement such monitoring functionality as a Nailgun plugin --
> installing it would be optional and at the same time we would grow our
> plugin ecosystem.
>
> P.
>
>
> On 11/05/2014 08:42 PM, Dmitry Borodaenko wrote:
>
> Even one additional hardware node required to host the Fuel master is seen
> by many users as excessive. Unless you can come up with an architecture
> that adds HA capability to Fuel without increasing its hardware footprint
> by 2 more nodes, it's just not worth it.
>
> The only operational aspect of the Fuel master node that you don't want to
> lose even for a short while is logging. You'd be better off redirecting
> OpenStack environments' logs to a dedicated highly available logging server
> (which, of course, you already have in your environment), and deal with
> Fuel master node failures by restoring it from backups.
>
> On Wed, Nov 5, 2014 at 8:26 AM, Anton Zemlyanov 
> wrote:
>
>>  Monitoring of the Fuel master's disk space is the special case. I
>> really wonder why Fuel master have no HA option, disk overflow can be
>> predicted but many other failures cannot. HA is a solution of the 'single
>> point of failure' problem.
>>
>>  The current monitoring recommendations (
>> http://docs.openstack.org/openstack-ops/content/logging_monitoring.html)
>> are based on analyzing logs and manual checks, that are rather reactive way
>> of fixing problems. Zabbix is quite good for preventing failures that are
>> predictable but for the abrupt problems Zabbix just reports them 'post
>> mortem'.
>>
>>  The only way to remove the single failure point is to implement
>> redundancy/HA
>>
>>  Anton
>>
>> On Tue, Nov 4, 2014 at 6:26 PM, Przemyslaw Kaminski <
>> pkamin...@mirantis.com> wrote:
>>
>>> Hello,
>>>
>>> In extension to my comment in this bug [1] I'd like to discuss the
>>> possibility of adding Fuel master node monitoring. As I wrote in the
>>> comment, when disk is full it might be already too late to perform any
>>> action since for example Nailgun could be down because DB shut itself down.
>>> So we should somehow warn the user that disk is running low (in the UI and
>>> fuel CLI on stderr for example) before it actually happens.
>>>
>>> For now the only meaningful value to monitor would be disk usage -- do
>>> you have other suggestions? If not then probably a simple API endpoint with
>>> statvfs calls would suffice. If you see other usages of this then maybe it
>>> would be better to have some daemon collecting the stats we want.
>>>
>>> If we opted for a daemon, then I'm aware that the user can optionally
>>> install Zabbix server although looking at blueprints in [2] I don't see
>>> anything about monitoring Fuel master itself -- is it possible to do?
>>> Though the installation of Zabbix though is not mandatory so it still
>>> doesn't completely solve the problem.
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1371757
>>> [2] https://blueprints.launchpad.net/fuel/+spec/monitoring-system
>>>
>>> Przemek
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
>  Dmitry Borodaenko
>
>
> ___
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] fuel master monitoring

[Anton Zemlyanov]

Monitoring of the Fuel master's disk space is the special case. I really
wonder why Fuel master have no HA option, disk overflow can be predicted
but many other failures cannot. HA is a solution of the 'single point of
failure' problem.

The current monitoring recommendations (
http://docs.openstack.org/openstack-ops/content/logging_monitoring.html)
are based on analyzing logs and manual checks, that are rather reactive way
of fixing problems. Zabbix is quite good for preventing failures that are
predictable but for the abrupt problems Zabbix just reports them 'post
mortem'.

The only way to remove the single failure point is to implement
redundancy/HA

Anton

On Tue, Nov 4, 2014 at 6:26 PM, Przemyslaw Kaminski 
wrote:

> Hello,
>
> In extension to my comment in this bug [1] I'd like to discuss the
> possibility of adding Fuel master node monitoring. As I wrote in the
> comment, when disk is full it might be already too late to perform any
> action since for example Nailgun could be down because DB shut itself down.
> So we should somehow warn the user that disk is running low (in the UI and
> fuel CLI on stderr for example) before it actually happens.
>
> For now the only meaningful value to monitor would be disk usage -- do you
> have other suggestions? If not then probably a simple API endpoint with
> statvfs calls would suffice. If you see other usages of this then maybe it
> would be better to have some daemon collecting the stats we want.
>
> If we opted for a daemon, then I'm aware that the user can optionally
> install Zabbix server although looking at blueprints in [2] I don't see
> anything about monitoring Fuel master itself -- is it possible to do?
> Though the installation of Zabbix though is not mandatory so it still
> doesn't completely solve the problem.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1371757
> [2] https://blueprints.launchpad.net/fuel/+spec/monitoring-system
>
> Przemek
>
> ___
> 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] [Fuel] Fuel standards

[Anton Zemlyanov]

I have another example, nailgun and UI are bundled in FuelWeb being quite
independent components. Nailgun is python REST API, while UI is HTML/CSS/JS
+ libs. I also support the idea making CLI a separate project, it is
similar to FuelWeb UI, it uses the same REST API. Fuelclient lib is also
good idea, REPL can be separated from command execution logic.

Multiple simple components are usually easier to maintain, bigger
components tend to become complex and tightly coupled.

I also fully support standards of naming files and directories, although it
relates to Python stuff mostly.

Anton Zemlyanov


> 1) Standard for an architecture.
> Most of OpenStack services are split into several independent parts
> (raughly service-api, serivce-engine, python-serivceclient) and those parts
> interact with each other via REST and AMQP. python-serivceclient is usually
> located in a separate repository. Do we actually need to do the same for
> Fuel? According to fuelclient it means it should be moved into a separate
> repository. Fortunately, it already uses REST API for interacting with
> nailgun. But it should be possible to use it not only as a CLI tool, but
> also as a library.
>
> 2) Standard for project directory structure (directory names for api, db
> models,  drivers, cli related code, plugins, common code, etc.)
> Do we actually need to standardize a directory structure?
>
> 3) Standard for third party libraries
> As far as Fuel is a deployment tool for OpenStack, let's make a decision
> about using OpenStack components wherever it is possible.
> 3.1) oslo.config for configuring.
> 3.2) oslo.db for database layer
> 3.3) oslo.messaging for AMQP layer
> 3.4) cliff for CLI (should we refactor fuelclient so as to make based on
> cliff?)
> 3.5) oslo.log for logging
> 3.6) stevedore for plugins
> etc.
> What about third party components which are not OpenStack related? What
> could be the requirements for an arbitrary PyPi package?
>
> 4) Standard for testing.
> It requires a separate discussion.
>
> 5) Standard for documentation.
> It requires a separate discussion.
>
>
> Vladimir Kozhukalov
>
> ___
> 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