[all][tc][horizon] A web tool which helps administrators in managing openstack clusters

Douglas Zhang lychzhz at gmail.com
Sun Aug 25 10:28:01 UTC 2019


Hello everyone,

Thanks for your attention and advice for this project. We have read each
reply thoroughly and the good news is that we’re able to give answers to
some questions raised by them.

As Lingxian Kong said:

I have a few questions/suggestions:

   1.

   It'd be great and gain more attractions if you could provide a demo
   about how "openstack-admin" looks like
   2.

   What OpenStack services has "openstack-admin" already integrated? Is it
   easy to integrate with others?


   1.

   We have deployed openstack-admin <http://218.205.220.13:9384/login> on a
   mini openstack cluster as a demo, any access would be welcomed.
   -

      Username: openstack-admin
      -

      Password: @Dem0
      2.

   Since openstack-admin gets information it needs by querying the sql
   database, it’s fairly easy to integrate with all openstack services.
   -

      As the demo shows, openstack-admin has integrated *nova*(almost all
      GET and part of POST), *cinder*(GET and snapshot-creation),
*neutron*(subnets
      and ports), *keystone*(projects) and *glance*(images), that’s all we
      need in our own working environment.
      -

      If we need to integrate more services to openstack-admin(e.g. adding
      a create instance button or integrating with swift), it would not be
      a complex task, either.

As Adrian Turjak said:

The first major issue is that you connect to the databases of the services
directly. That's a major issue, both for long term compatibility, and
security. The APIs should always be the main point of contact and the ONLY
contract that the services have to maintain. By connecting to the database
directly you are now relying on a data structure that can, and likely will
change, and any security and sanity checking on filters and queries is now
handled on your layer rather than the application itself. Not only that,
but your dashboard also now needs passwords for all the databases, and by
the sounds of it all the message queues.

And as Mohammed Naser said:

While I agree with you that querying database is much faster, this
introduces two issues that I imagine for users:

   -

   Dashboards generally having direct access via SQL is a scary thing from
   an operators perspective


   -

   also, it will make maintaining the project quite hard because I don't
   think any projects expose a *stable* database API.

Well, we’re not surprised that our querying approach would be challenged
since it does sound unsafe. However, we have made some efforts to solve
problems which have been posed:

   -

   We use a ORM library to create all queries, which ensures that only
   those instructions we have specified in the backend(i.e. select, order by,
   where and other harmless querying instructions) could be executed,
   protecting our databases from dangerous attacks like SQL injection. All
   sanity or security checkings would be automatically completed by those
   library functions.
   -

   All instructions that *may* change the database(e.g. start, shutoff,
   migrate) would be executed by calling standard openstack API, only pure
   GET instructions were implemented by querying databases directly. We
   have wrapped each API call with a go func() { ... }() to avoid the
   extremely long calling period. The results of API calls would be sent back
   to frontend by websocket asynchronously.


   -

   Passwords of databases and message queues(and many other kinds of
   information) are stored in a config file which would be loaded by
   openstack-admin. Simply by modifying this file, we could be consistent with
   all changes about sql databases and MQs.

I hope my explanation is clear enough, and we’re willing to solve other
possible issues existing.

Cheers,

Douglas Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190825/ae9e5000/attachment-0001.html>


More information about the openstack-discuss mailing list