Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

[Kevin Conway]

I understand, and appreciate, the concern for licensing, but it would be a
real shame to discount some of the most widely used linters because of a
clause that prevents us from being evil.

Any chance we could run this by legal-disc...@lists.openstack.org and hear
their reactions before we axe the JS*int projects from OpenStack?

On 4/2/14 8:43 AM, "Radomir Dopieralski"  wrote:

>On 02/04/14 15:26, Kevin Conway wrote:
>> What licensing issues were brought up that prevent the use of JSLint or
>> JSHint? Both are MIT licensed.
>> 
>> Granted, JSLint has an additional clause:
>> 
>> The Software shall be used for Good, not Evil.
>> 
>> 
>> Maybe that's it? If so, Crockford has been known to make exceptions for
>> organizations that wish to use his code for potentially evil
>> purposes: 
>>https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2
>>480s.
>
>Yes, that's exactly it. An exception is not enough -- that clause simply
>makes that license incompatible with OpenStack's license. To use it, we
>would need to change OpenStack's license too, and it quickly becomes
>quite complex.
>
>You have to remember that organizations like NSA use OpenStack, so we
>can't possibly include that clause in its license ;)
>
>-- 
>Radomir Dopieralski
>
>
>___
>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] [Tuskar][Horizon] Javascript linter

[Kevin Conway]

What licensing issues were brought up that prevent the use of JSLint or
JSHint? Both are MIT licensed.

Granted, JSLint has an additional clause:

> The Software shall be used for Good, not Evil.


Maybe that's it? If so, Crockford has been known to make exceptions for
organizations that wish to use his code for potentially evil purposes:
https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s
.


On Wed, Apr 2, 2014 at 4:23 AM, Peter Belanyi  wrote:

> Hi all,
>
> Recently we have been discussing the topic of Javascript linters for
> Horizon and Tuskar-UI with Radomir, and he told me that JSLint and JSHint
> can not be integrated into the test environment due to some license issues.
>
> I did some search and found Closure Linter [1] by Google which might be an
> alternative, and I wanted to get some feedback on it.
>
> Pros:
> - Open source, Apache License
> - Written in Python, available from pip
> - Used by Google, so probably it's production ready (or at least beta)
>
> Cons:
> - Javascript style is not configurable, it is hard coded to check The
> Google JavaScript Style [2], which might not exactly match OpenStack's
> desired coding style
> - It could take a long time to fix all js code to be accepted by the linter
>
> Does it look like something we could use?
>
> Thanks,
> Peter
>
>
> [1] https://developers.google.com/closure/utilities/
> [2] http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

[Kevin Conway]

ntly poll some queue and spawn a
> greenthread for each incoming request.
>
>  Both kinds to basically the same job: receive a request, run a handler
> in a greenthread. Sounds very much like a job for some application server
> that does just that and does it good.
> If we remove all dependencies from eventlet or any other async framework,
> we would not only be able to write Python code without need to keep in mind
> that we're running in some reactor (that's why eventlet was chosen over
> Twisted IIRC), but we can also forget about all these frameworks altogether.
>
>  I suggest approach like this:
> - for API services use dead-simple threaded WSGI server (we have one in
> the stdlib by the way - in wsgiref);
> - for workers use simple threading-based oslo.messaging loop (it's on its
> way).
>
>  Of course, it won't be production-ready. Dumb threaded approach won't
> scale but we don't have to write our own scaling here. There are other
> tools around to do this: Apache httpd, Gunicorn, uWSGI, etc. And they will
> work better in production environment than any code we write because they
> are proven with time and on huge scales.
>
>  So once we want to go to production, we can deploy things this way for
> example:
> - API services can be deployed within Apache server or any other HTTP
> server with WSGI backend (Keystone already can be deployed within Apache);
> - workers can be deployed in any non-HTTP application server, uWSGI is a
> great example of one that can work in this mode.
>
>  With this approach we can leave the burden of process management, load
> balancing, etc. to the services that are really good at it.
>
>  What do you think about this?
>
>  --
>
> Kind regards, Yuriy.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

[Kevin Conway]

On 2/4/14 12:07 PM, "victor stinner"  wrote:


>The purpose of replacing eventlet with asyncio is to get a well defined
>control flow, no more surprising task switching at random points.

I disagree with this. Eventlet and gevent yield the execution context
anytime an IO call is made or the 'sleep()' function is called explicitly.
The order in which greenthreads grain execution context is deterministic
even if not entirely obvious. There is no context switching at random.
What's more is it shouldn't matter when the context switch happens. When
writing green threaded code you just pretend you have real threads and
understand that things happen in an order other than A => B => C.

One of the great benefits of using a green thread abstraction, like
eventlet or gevent, is that it lets you write normal Python code and slap
your concurrency management over the top. It even lets us program in
familiar models by pretending like we are using threads. There are some
subtle distinctions between green threading and threading that can confuse
developers, but overall programming with green threads is plain old
python. The asyncio is a completely different model for providing the same
feature set as the green thread abstractions.

Switching our async IO management from eventlet to asyncio would not be a
trivial task. Tell me when I'm wrong, but it would require that we
completely change our programming model from typical, function-call based
programming to use generator-iterators for everything. The only way to
actually use the async IO portion of asyncio is to "yield from" a
generator-iterator that ties into some kind of SELECT poll. Granted, it's
conceptually not that different from what we're already doing but why
would we want to go through the effort of changing our programming model
to get the same thing.

Honestly, if I wanted to write a bunch of utilities that provide async
behavior by calling loop.call_later() then I would just write Node.js and
call process.nextTick().



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

[openstack-dev] [Trove] API extention update in order to support multi-databases integration

[Kevin Conway]

Denis,

It seems that you are hitting on a couple of points here. 1) You aren't a
fan of the fact that calls to user/db are routed through an extensions
written for mysql. 2) This creates a conflict when a datastore does not
support those calls. I am confused about your solution.

Your suggestion is to require each datastore manager to define the same
extension and implement the API even if it only returns NotImplemented. If
every datastore must define the same API extension then it is not an
extension. It is a part of the core API. If anything, we should be promoting
the user and database API to core since we already require that datastore
account for it in some way.

As far as communicating to a user whether or not their datastore supports an
API call, I thought we already solved this problem by 1) setting the guest
agents to raise NotImplmentedError for unsupported calls, 2) starting work
on a capabilities api:
https://wiki.openstack.org/wiki/Trove/trove-capabilities, and 3) drafting
the feature compatibility of our current target data stores at
https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix.

If the question, instead, is "How do we provide single-datastore specific
functionality in Trove?" then that is a whole different conversation.

** This is a side note for whoever added it, but I am also confused why
MongoDB and Cassandra cannot support the users API according to the
compatibility matrix. MongoDB has user/role management and even has a
superuser which is equivalent to the mysql root. Cassandra also supports
user/pass authentication as a part of its simple-auth protocol.

From:  Denis Makogon 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, February 3, 2014 9:54 AM
To:  OpenStack Development Mailing List 
Subject:  [openstack-dev] [Trove] API extention update in order to support
multi-databases integration

Goodday, OpenStack DBaaS users/contributors.


I'd like to start topic related to refactoring of API extensions. Since
Trove already supports more than one db engines (mysql and redis in
single-instance mode).


At this moment if contributors will decide that one of the integrated db
engines would support users/databases CRUD operations they will come into
the issue of non-pluggable extensions for described operations. Here [1] you
can see that users/databases CRUD operations will go through routes defined
for mysql database integration.

I would like to suggest more flexible mechanism for such API extensions:
1. Extensions should be implemented per datastore manager, such as mysql,
redis, cassandra, mongodb.
2. 
3. ReST service routes for API extensions should be common for all of
datastores. It means that implemention should be imported/used according to
uniq attribute, best option for such attribute ­ datastore manager.
4. 
5. Even if datastore doesn't supports users ACL or storage distinction
(databases in terms of mysql, keyspaces in terms of cassandra) API extension
should be implemented, each method should raise NotImplmented exception with
meaningful message ³Not supported².


As you can see at [2], mechanism implemented according to rules given
above. So, I would like to hear all your thoughts about that.


[1] 
https://github.com/openstack/trove/blob/master/trove/extensions/routes/mysql
.py 
 
[2] https://review.openstack.org/70742


 
 
Best regards,
Denis Makogon
Mirantis, Inc.


Kharkov, Ukraine
www.mirantis.com 
www.mirantis.ru 
dmako...@mirantis.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

Re: [openstack-dev] [trove] scheduled tasks redux

[Kevin Conway]

>
>Will we be doing more complex things than "every day at some time"? ie,
>does the user base see value in configuring backups every 12th day of
>every other month? I think this is easy to write the schedule code, but i
>fear that it will be hard to build a smarter scheduler that would only
>allow X tasks in a given hour for a window. If we limit to daily at X
>time, it seems easier to estimate how a given window for backup will look
>for now and into the future given a constant user base :P Plz note, I
>think its viable to schedule more than 1 per day, in cron "* 0,12" or "*
>*/12".

Scheduling tasks on something other than a daily basis can be a legitimate
requirement. It's not uncommon for organizations to have "audit dates"
where they need to be able to snapshot their data on non-daily, regular
intervals (quarterly, annually, etc.).

I also like the idea of windows. I know that one of the features that has
also been requested that might be satisfied by this is allowing operators
to define maintenance windows for users to select. Maintenance could
simply be a task that a user schedules in an available window.

If the concern over allowing hard times for scheduled tasks, backups as
the given example, is saturation of external resources like networking or
Swift then it might be more beneficial to use windows as a way of
scheduling the availability of task artifacts rather than the task itself.
When I used to work in government/higher education, for example, there
were multiple dates throughout the year where the organization was
mandated by the state to provide figures for particular calendar dates.
The systems they used to manage these figures typically did not provide
any means of retrieving historic values (think trying to audit the state
of a trove instance at a specific point in the past). As a result they
would use automated backups to create a snapshot of their data for the
state mandated reporting. For them, the backup had to begin a 00:00
because waiting until 04:00 would result in skewed figures.

I'm not certain how common this scenario is in other industries, but I
thought I should mention it.



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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Kevin Conway]

What is the major motivation not to simply use a glance image named "MySQL
5.5" or "MongoDB 2.4"?

Wouldn't that give service providers all the flexibility they need for
providing different types? For example, I could offer a simple "MySQL"
image that creates a MySQL instance. If all my users use the one "MySQL"
image then I can update that image deploy the latest version (or any
version that I, as the service provider, want to deploy). Alternatively,
my users could have a choice of versions if I roll a "MySQL 5.1" and
"MySQL 5.5" image.

Want to deactivate a version: delete the image. Want to offer a new
version: create a new image.

It seems like this is parallel to a NOVA deploy offering multiple version
of the same OS (Ubuntu 12 vs Ubuntu 13). Images work nicely for that. Why
couldn't they work for us?

On 10/21/13 3:12 PM, "Michael Basnight"  wrote:

>
>On Oct 18, 2013, at 12:30 PM, Tim Simpson wrote:
>
>> 1. I think since we have two fields in the instance object we should
>>make a new object for datastore and avoid the name prefixing, like this:
>
>I agree with this.
>
>> 2. I also think a datastore_version alone should be sufficient since
>>the associated datastore type will be implied:
>
>When i brought this up it was generally discussed as being confusing. Id
>like to use type and rely on having a default (or active) version behind
>the scenes.
>
>> 3. Additionally, while a datastore_type should have an ID in the Trove
>>infastructure database, it should also be possible to pass just the name
>>of the datastore type to the instance call, such as "mysql" or "mongo".
>>Maybe we could allow this in addition to the ID? I think this form
>>should actually use the argument "type", and the id should then be
>>passed as "type_id" instead.
>
>Id prefer this honestly.
>
>> 4. Additionally, in the current pull request to implement this it is
>>possible to avoid passing a version, but only if no more than one
>>version of the datastore_type exists in the database.
>> 
>> I think instead the datastore_type row in the database should also have
>>a "default_version_id" property, that an operator could update to the
>>most recent version or whatever other criteria they wish to use, meaning
>>the call could become this simple:
>
>Since we have determined from this email thread that we have an active
>status, and that > 1 version can be active, we have to think about the
>precedence of active vs default. My question would be, if we have a
>default_version_id and a active version, what do we choose on behalf of
>the user? If there is > 1 active version and a user does not specify the
>version, the api will error out, unless a default is defined. We also
>need a default_type in the config so the existing APIs can maintain
>compatibility. We can re-discuss this for v2 of the API.
>___
>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