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

2016-05-12 Thread 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 

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

2016-05-11 Thread 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

2015-02-09 Thread 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 tim.b...@cern.ch 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?

2015-02-05 Thread 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 openst...@sheep.art.pl
 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]

2015-02-05 Thread 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 tqt...@us.ibm.com 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/

2015-01-14 Thread 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 drew.fis...@oracle.com 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

2015-01-12 Thread 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, samuel.bar...@orange.com 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


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

2014-12-15 Thread 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] [Fuel] Building Fuel plugins with UI part

2014-12-15 Thread 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 pkamin...@mirantis.com
 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


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

2014-12-03 Thread 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 tqt...@us.ibm.com 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 tsuf...@mirantis.com
 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/*
 https://review.openstack.org/#/c/113206/
 [2] *https://review.openstack.org/#/c/23037/*
 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

2014-11-12 Thread 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 darren.ke...@oracle.com
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

2014-11-11 Thread 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 r1chardj0...@gmail.com
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

2014-11-06 Thread 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 pkamin...@mirantis.com
 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 azemlya...@mirantis.com
 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

2014-11-05 Thread 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 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


Re: [openstack-dev] [Fuel] Fuel standards

2014-10-23 Thread 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