[openstack-dev] Novnc switch to sockjs-client instead of websockify

[Thomas Goirand]

Hi,

I was wondering if it would be possible for NoVNC to switch from
websockify to sockjs-client, which is available here:

https://github.com/sockjs/sockjs-client

This has the advantage of not using flash at all (pure javascript), and
continuing to work on all browsers, with a much cleaner licensing.

Thoughts welcome!

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [TripleO] Docker and TripleO

[Robert Collins]

So, we've spoken about using containers on baremetal - e.g. the lxc
provider - in the past, and with the [righteously deserved] noise
Docker is receiving, I think we need to have a short
expectation-setting discussion.

Previously we've said that deploying machines to deploy containers to
deploy OpenStack was overly meta - I stand by it being strictly
unnecessary, but since Docker seems to have gotten a really good sweet
spot together, I think we're going to want to revisit those
discussions.

However, I think we should do so no sooner than 6 months, and probably
more like a year out.

I say 6-12 months because:
 - Docker currently describes itself as 'not for production use'
 - It's really an optimisation from our perspective
 - We need to ship a production ready version of TripleO ASAP, and I
think retooling would delay us more than it would benefit us.
 - There are going to be some nasty bootstrapping issues - we have to
deploy the bare metal substrate and update it in all cases anyway
   - And I think pushing ahead with (any) container without those
resolved is unwise
   - because our goal as always has to be to push the necessary
support into the rest of OpenStack, *not* as a TripleO unique
facility.

This all ties into other threads that have been raised about future
architectures we could use: I think we want to evolve to have better
flexability and performance, but lets get a v1 minimal but functional
- HA, scalable, usable - version in place before we advance.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [Tripleo] reviewer review Jan

[Robert Collins]

I'm going to skip this this month: with most folk having ~2 weeks of
leave there's only an effective 2 weeks of delta - both in practice
for new reviewers, and in changes to track for existing -core since
the last review - it seems a little pointless.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility

[Joe Gordon]

On Sun, Dec 29, 2013 at 5:04 AM, Sean Dague  wrote:

> On 12/29/2013 03:06 AM, Day, Phil wrote:
> 
>
>  Basically, I'm not sure what problem you're trying to solve - lets tease
>>> that
>>> out, and then talk about how to solve it. "Backwards incompatible change
>>> landed" might be the problem - but since every reviewer knew it, having a
>>> longer review period is clearly not connected to solving the problem :).
>>>
>>>
>> That assumes that a longer review period wouldn't of allowed more
>> reviewers to provide input - and I'm arguing the opposite.   I also think
>> that some clear guidelines might have led to the core reviewers holding
>> this up for longer.   As I said in my original post, the intent to get more
>> input was clear in the reviews, but the period wasn't IMO long enough to
>> make sure all the folks who may have something to contribute could.   I'd
>> rather see some established guidelines than have to be constantly on the
>> lookout for changes every day or so and hoping to catch them in time.
>>
>
> Honestly, there are currently 397 open reviews in Nova. I am not convinced
> that waiting on this one would have come up with a better decision. I'll
> given an alternative point of view of the graceful shutdown patch, where we
> sat on that for months, had many iterations, landed it, it added 25 minutes
> to all the test runs (which had been hinted at sometime in month 2 of the
> review, but got lots in the mists of time), and we had to revert it.
>
> I'm not convinced more time brings more wisdom. We did take it to the
> list, and there were no objections. I did tell Robert to wait because I
> wanted to get those points of view. But they didn't show up. Because it was
> holidays could we have waited longer? Sure. I'll take a bad on that in
> feeling that Dec 19th wasn't really holidays yet because I was still
> working. :) But, honestly, given no negative feedback on the thread in
> question and no -1 on the review, the fact that folks like google skipped
> ext3 entirely, means this review was probably landing regardless.
>
> Every time we need to do a revert, we need to figure out how to catch it
> the next time. "Humans be better" is really not a solution. So this sounds
> like we need a guest compatibility test where we boot a ton of different
> guests on each commit and make sure they all work. I'd whole heartily
> support getting that in if someone wants to champion that. That's really
> going to be the only way we have a systematic way of knowing that we break
> SLES in the future.
>
> So the net, we're all human, and sometimes make mistakes. I don't think
> we're going to fix this with review policy changes, but we could with
> actual CI enhancements.


++, I think this sums up things very well.  Leaving a review open for
longer makes the somewhat incorrect assumption that eventually the right
person would review this. Perhaps that assumption is true for some people
but I doubt its true for everyone (it's definitely not for me).  Every time
an issue like this gets through we should be asking ourselves how can we
make the gate detect this next time? (That question is why I wrote the
large-ops test.) It sounds like we have two leads on how to prevent this in
the future:

* Guest compatibility testing.
* Better backwards compatibility/upgrade testing (As a later email
mentions).


>
> -Sean
>
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> http://dague.net
>
>
> ___
> 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] [Openstack] Quota delegation tool (for nova) ?

[Joe Gordon]

On Wed, Dec 25, 2013 at 11:00 PM, Ulrich Schwickerath <
ulrich.schwicker...@cern.ch> wrote:

> Dear all,
>
> I'd like to trigger a new discussion about the future of quota management
> in OpenStack. Let me start with our main user story to clarify what we need.
> I'm working for CERN for the IT departement. We're providing computing
> resources to our customers, either through traditional batch farms or
> through an OpenStack IaaS
> infrastructure. Our main customers are the LHC experiments, which by
> themselves are fairly large dynamic organizations with complex internal
> structures, with specific requirements
> and many thousand users from many different countries and regions.
> Computing resources are centralized, and each customer organization gets
> it's share of the cake.
>
> Instead of trying to keep track of the internal structures of our
> customers and their changing needs, we need a way to allocate one piece of
> the big cake to each customer (and adjust it regularely), and give them the
> possibility to manage these resources themselves. What I have in mind here
> is the idea of a "Quota delegation":
>
> - The main resource manager determines the fractions of the resources for
> each customer
> - He allocates a quota to each customer by giving it to a "computing
> coordinater" which is nominated by the customer
> - the computing coordinater in turn takes his piece of the cake, chops it
> up and gives it to the coordinators of the different research groups in his
> experiment
>
> and so on.
>
>
This sounds like what I would imagine should be a very common use case, so
it would be really great if we can support this. And as always support
means tested in gate.

To put this in other terms, it sounds like you want one role to set per
project quota's, and another role to set user quotas for that specific
project (https://blueprints.launchpad.net/nova/+spec/per-user-quotas).

Both of those quota mechanisms exist today, but the roles you desire do not
exist by default.  So I think all that is needed to support your use case
is make sure nova works with your desired roles. That involves fixing any
issues and writing a test we can gate on.

So I think the outcome of this work will consist of:

* Changing the default policy.json file we use
* An easy upgrade path
* Documentation explaining the new default roles
* Some small changes to nova to understand the new roles, along with unit
tests.
* Tempest tests

I'd like to ask people for their opinion on how such a schema should be
> implemented. There are several aspects which need to be taken into account
> here:
> - There are people with different roles in this game:
>   +- the main resource manager role is a super user role which can but
> does not have to be identical to the cloud manager.
>  Persons with this role should be able to change all numbers down in
> the tree. In general, the cloud manager and the resource manager role are
>  not identical in my opinion. Persons with this role should also be
> able to nominate other resource managers and give them a fraction of the
> resources
>  +- a normal resource manager is a bit like the main resource manager,
> with the exception that he can only manage the fraction of the resources he
> was allocated by a person "above" him
>  +- a normal user: persons with this role can only consume resources
>

This can be supported via our policy logic (
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json). By
default we don't define that many roles by default.


>
> - several people can have the same role. This is necessary to be able to
> cover eg. holiday season or sick leave periods where one manager is not
> available. Maybe introducing a group concept here would be appropriate, in
> a way that roles are assigned to groups and people are assigned to the
> groups instead of assigning roles directly to individuals.
>

I think keystone supports this today.


>
> - When I say "Quota" what I'm talking about is actually just a number,
> eventually assigned with some unit. It could be a static limit on a
> specific resource like number of VMs or the amount of memory or disk space,
> or it could be something different like computing performance or even
> something like a currency at the longer term
>
> - What is the right place to store such "groups" or "roles" ? What do
> people think ?
>
> We are currently only interested in limit settings for Nova. The described
> ideas could be implemented as part of Nova, or as an entirely independent
> external tool (which might be incorporated later). IMO the latter approach
> has some advantages but I'd like to hear peoples opinion about this.
>

I think this should be directly in nova.


>
> We'll have some man power available to work on the design and the
> implementation of this so I'd expect to see some rapid progress if everbody
> agrees that this is a useful thing to do.
>


Great!


>
> Thanks a lot for your comments/opinions!
>
> Kind regard

Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

[John Griffith]

On Tue, Dec 31, 2013 at 3:33 PM, Robert Collins
 wrote:
> On 1 January 2014 06:07, Joe Gordon  wrote:
>>
>>
>
>>
>> I am not sure if this is the global .gitignore you are thinking of but this
>> is the one I am in favor of:
>>
>> https://help.github.com/articles/ignoring-files#global-gitignore
>>
>>
>> Maintaining .gitignore in 30+ repositories for a potentially infinite number
>> of editors is very hard, and thankfully we have an easier way to do it.
>
> This is a strawman argument: noone (that I know of) has proposed
> adding all editors to all repositories. There are in reality a few
> very common editors and having their extensions present in per
> repository .gitignores does absolutely *no harm*. There is no reason
> not to have sane and sensible defaults in our repositories.
>
> If we are wasting time adding and removing patterns, then I think that
> counts as a harm, so it is a sensible discussion to have to come to a
> project standard, but the standard should be inclusive and useful, not
> just useful for power users that have everything setup 'just so'. Many
> contributors are using git for the first time when they contribute to
> OpenStack, and getting git setup correctly is itself daunting [for new
> users].
>
> So I'm very much +1 on having tolerance for the top 5-10 editor
> patterns in our .gitignores, -1 on *ever* having a bug open to change
> this in any repository, and getting on with our actual task here of
> writing fantastic code.
>
> If folk *really* don't want editor files in .gitignore (and given the
> complete lack of harm I would -really- like a explanation for this
> mindset) then we could solve the problem more permanently: we know
> what files need to be added - *.rst, *.py, *.ini, [!.]* and a few
> others. Everything else is junk and shouldn't be added. By
> whitelisting patterns w
e will support all editors except those whose
> working file names match names we'd genuinely want to add.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


> If we are wasting time adding and removing patterns, then I think that
> counts as a harm, so it is a sensible discussion to have to come to a
> project standard, but the standard should be inclusive and useful, not
> just useful for power users that have everything setup 'just so'. Many
> contributors are using git for the first time when they contribute to
> OpenStack, and getting git setup correctly is itself daunting [for new
> users].

My point exactly is that this is creating churn and there is some back
and forth (see links to LP items below).  Like I said, I don't have an
objection, I just want to be consistent and move on.  This has come up
in commits in past releases as well.  As I said, I see little harm in
having them present, however I see significant harm in racking up
commits to take them in and out as well as the ugliness in having
inconsistent policies in different projects.

https://bugs.launchpad.net/ceilometer/+bug/1256043
https://bugs.launchpad.net/trove/+bug/1257279
https://bugs.launchpad.net/python-cinderclient/+bug/1255876

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

Re: [openstack-dev] [style] () vs \ continuations

[Joe Gordon]

On Dec 31, 2013 3:00 PM, "Michael Still"  wrote:
>
> On Wed, Jan 1, 2014 at 9:46 AM, Joe Gordon  wrote:
> > A little late, but here is the patch to put this into hacking.
> >
> > https://review.openstack.org/#/c/64584/
> >
> >
> > And here is it running against nova:
> >
http://logs.openstack.org/84/64584/1/check/gate-hacking-integration-nova/b31c47e/console.html
>
> Wow, that's a lot of failures. Can we please not fix these in
> dedicated patches and just tweak them as we refactor surrounding code?
> I fear the code churn from these.

Agreed.

>
> Michael
>
> --
> Rackspace Australia
>
> ___
> 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] [style] () vs \ continuations

[Michael Still]

On Wed, Jan 1, 2014 at 9:46 AM, Joe Gordon  wrote:
> A little late, but here is the patch to put this into hacking.
>
> https://review.openstack.org/#/c/64584/
>
>
> And here is it running against nova:
> http://logs.openstack.org/84/64584/1/check/gate-hacking-integration-nova/b31c47e/console.html

Wow, that's a lot of failures. Can we please not fix these in
dedicated patches and just tweak them as we refactor surrounding code?
I fear the code churn from these.

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [style] () vs \ continuations

[Joe Gordon]

A little late, but here is the patch to put this into hacking.

https://review.openstack.org/#/c/64584/


And here is it running against nova:
http://logs.openstack.org/84/64584/1/check/gate-hacking-integration-nova/b31c47e/console.html


On Mon, Nov 18, 2013 at 5:23 PM, Vishvananda Ishaya
wrote:

>
> On Nov 14, 2013, at 10:00 AM, Monty Taylor  wrote:
>
> >
> >
> > On 11/13/2013 08:08 PM, Robert Collins wrote:
> >> On 14 November 2013 13:59, Sean Dague  wrote:
> >>
> >>> This is an area where we actually have consensus in our docs (have had
> >>> for a while), the reviewer was being consistent with them, and it feels
> >>> like you are reopening that for personal preference.
> >>
> >> Sorry that it feels that way. My personal code also uses ()
> >> overwhelmingly - so this isn't a personal agenda issue. I brought it
> >> up because the person that wrote the code had chosen to use \, and as
> >> far as I knew we didn't have a hard decision either way - and the
> >> style guide we have talks preference not requirement, but the review
> >> didn't distinguish between whether it's a suggestion or a requirement.
> >> I'm seeking clarity so I can review more effectively and so that our
> >> code doesn't end up consistent but hard to read.
> >
> > I'd say we've got an expression of clarity here - which means
> > potentially a patch to the hacking guide to clarify the language on what
> > our choice is, as well as the addition of a hacking check to enforce it
> > would be in bounds.
>
> +1 to sticking something in hacking. FWIW I would probably do the following
> to avoid the debate altogether:
>
> result = self._path_file_exists(ds_browser, folder_path, file_name)
> folder_exists, file_exists, file_size_in_kb, disk_extents = result
>
> Vish
>
>
> >
> >>> Honestly I find \ at the end of a line ugly as sin, and completely
> >>> jarring to read. I actually do like the second one better. I don't care
> >>> enough to change a policy on it, but we do already have a policy, so it
> >>> seems pretty pedantic, and not useful.
> >>
> >> Ok, thats interesting. Readability matters, and if most folk find that
> >> even this case - which is pretty much the one case where I would argue
> >> for \ - is still easier to read with (), then thats cool.
> >>
> >>> Bringing up for debate the style guide every time it disagrees with
> your
> >>> personal preference isn't a very effective use of people's time.
> >>> Especially on settled matters.
> >>
> >> Totally not what I'm doing. I've been told that much of our style
> >> guide was copied lock stock and barrel from some Google Python style
> >> guide, so I can't tell what is consensus and what is 'what someone
> >> copied down one day'. Particularly when there is no rationale included
> >> against the point - its a black box and entirely opaque.
> >>
> >> -Rob
> >>
> >
> > ___
> > 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] [OpenStack-Dev] IDE extensions in .gitignore

[Robert Collins]

On 1 January 2014 06:07, Joe Gordon  wrote:
>
>

>
> I am not sure if this is the global .gitignore you are thinking of but this
> is the one I am in favor of:
>
> https://help.github.com/articles/ignoring-files#global-gitignore
>
>
> Maintaining .gitignore in 30+ repositories for a potentially infinite number
> of editors is very hard, and thankfully we have an easier way to do it.

This is a strawman argument: noone (that I know of) has proposed
adding all editors to all repositories. There are in reality a few
very common editors and having their extensions present in per
repository .gitignores does absolutely *no harm*. There is no reason
not to have sane and sensible defaults in our repositories.

If we are wasting time adding and removing patterns, then I think that
counts as a harm, so it is a sensible discussion to have to come to a
project standard, but the standard should be inclusive and useful, not
just useful for power users that have everything setup 'just so'. Many
contributors are using git for the first time when they contribute to
OpenStack, and getting git setup correctly is itself daunting [for new
users].

So I'm very much +1 on having tolerance for the top 5-10 editor
patterns in our .gitignores, -1 on *ever* having a bug open to change
this in any repository, and getting on with our actual task here of
writing fantastic code.

If folk *really* don't want editor files in .gitignore (and given the
complete lack of harm I would -really- like a explanation for this
mindset) then we could solve the problem more permanently: we know
what files need to be added - *.rst, *.py, *.ini, [!.]* and a few
others. Everything else is junk and shouldn't be added. By
whitelisting patterns we will support all editors except those whose
working file names match names we'd genuinely want to add.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova] Turbo-hipster

[Michael Still]

Hi.

So while turbo hipster is new, I've been reading every failure message
it produces to make sure its not too badly wrong. There were four
failures posted last night while I slept:

https://review.openstack.org/#/c/64521


This one is a TH bug. We shouldn't be testing stable branches.
bug/1265238 has been filed to track this.

https://review.openstack.org/#/c/61753


This is your review. The failed run's log is
https://ssl.rcbops.com/turbo_hipster/logviewer/?q=/turbo_hipster/results/61/61753/8/check/gate-real-db-upgrade_nova_percona_user_001/1326092/user_001.log
and you can see from the failure message that migrations 152 and 206
took "too long".

Migration 152 took 326 seconds, where our historical data of 2,846
test migrations says it should take 222 seconds. Migration 206 took 81
seconds, where we think it should take 56 seconds based on 2,940 test
runs.

Whilst I can't explain why those migrations took too long this time
around, they are certainly exactly the sort of thing TH is meant to
catch. If you think your patch isn't responsible (perhaps the machine
is just being slow or something), you can always retest by leaving a
review comment of "recheck migrations". I have done this for you on
this patch.

https://review.openstack.org/#/c/61717


This review also had similar unexplained slowness, but has already
been rechecked by someone else and now passes. I note that the
slowness in both cases was from the same TH worker node, and I will
keep an eye on that node today.

https://review.openstack.org/#/c/56420


This review also had slowness in migration 206, but has been rechecked
by the developer and now passes. It wasn't on the percona-001 worker
that the other two were on, so perhaps this indicates that we need to
relax the timing requirements for migration 206.

Hope this helps,
Michael

On Wed, Jan 1, 2014 at 12:34 AM, Gary Kotton  wrote:
> Hi,
> It seems that she/he is behaving oddly again. I have posted a patch that
> does not have any database changes and it has give me a –1….
> Happy new year
> Gary
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia

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

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

[Greg Hill]

I guess this isn't a new discussion.  I did some more digging and apparently 
this is what came out of the last discussion:

https://wiki.openstack.org/wiki/EventScheduler

That definitely seems like it would be something simple we could use, since it 
only provides scheduling and that's all we need, but it doesn't appear that 
it's had any traction since that time.  I guess that got absorbed along with 
Convection into Mistral (is that right?).

I tend to agree with the sentiment that the scheduling component should live 
outside the workflow service, especially for use cases like this where we just 
need scheduling and not the workflow portions as we're just scheduling things 
that are already achievable via single API calls (to my knowledge).

It seems like we basically have 4 options at this point:

1. Wait for/help finish the scheduling component of mistral and use that
2. Build Qonos workers to do the trove needful and integrate with that
3. Build this proposed EventScheduler thing and have trove use that
4. Build something simple internal to trove for now and revisit when things 
have matured more

Despite my initial enthusiasm about Qonos after it was mentioned earlier today, 
the more I look into it, the more it seems like the wrong fit.  It could 
definitely do it, but the way it's structured, it appears that we'd have to add 
code to qonos/worker for each action we wanted to schedule, which just seems 
like a pain for what amounts to "make this API call to trove".

My gut says working on EventScheduler is probably the best/most ideal option, 
but time constraints and what-not make "build it into trove" the most likely 
course of action for now.

Greg

On Dec 31, 2013, at 10:06 AM, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>> wrote:

Agreed taskflow doesn't currently provide scheduling as it was thought that 
reliable execution that can be restarted and resumed is the foundation that 
someone using taskflow can easily provide scheduling ontop of... Better IMHO to 
have a project doing this foundation well (since openstack would benefit from 
this) than try to pack so many features in that it does none of them well (this 
kind of kitchen sink approach seems to happen more often than not, sadly).

But in reality it's all about compromises and finding the solution that makes 
sense and works, and happy new year!! :P

Sent from my really tiny device...

On Dec 30, 2013, at 9:03 PM, "Renat Akhmerov" 
mailto:rakhme...@mirantis.com>> wrote:

Greg,

Georgy is right. We’re now actively working on PoC and we’ve already 
implemented the functionality we initially planned, including cron-based 
scheduling. You can take a look at our repo and evaluate what we’ve done, we’d 
be very glad to hear some feedback from anyone potentially interested in 
Mistral. We were supposed to deliver PoC in the end of December, however, we 
decided not to rush and include several really cool things that we came up with 
while working on PoC, they should demonstrate the whole idea of Mistral much 
better and expose functionality for more potential use cases. A couple of days 
ago I sent out the information about additional changes in DSL that we want to 
implement (etherpad: https://etherpad.openstack.org/p/mistral-poc), so if you’d 
like please join the discussion and let us know how we can evolve the project 
to better fit your needs. In fact, even though we call it PoC it’s already in a 
good shape and pretty soon (~1.5 month) is going to be mature enough to use it 
as a dependency for other projects.

As far as security, we thought about this and and we have a vision of how it 
could be implemented. Generally, later on we’re planning to implement sort of 
Role Based Access Control (RBAC) to, first of all, isolate user workbooks 
(definition of tasks, actions, events) from each other and deal with access 
patterns to OpenStack services. We would encourage you to file a BP with a 
description of what would be needed by Trove in that regard.

I looked at https://wiki.openstack.org/wiki/Trove/scheduled-tasks and at the 
first glance Mistral looks a good fit here, especially if you’re interested in 
a standalone REST service with its capabilities like execution monitoring, 
history, language independence and HA (i.e. you schedule backups via Mistral 
and Trove itself shouldn’t care about availability of any functionality related 
to scheduling). TaskFlow may also be helpful in case your scheduled jobs are 
representable as flows using one of TaskFlow patterns. However, in my 
understanding you’ll have to implement scheduling yourself since TaskFlow does 
not support it now, at least I didn’t find anything like that (Joshua can 
provide more details on that).

Thanks.

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

Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

[John Griffith]

On Tue, Dec 31, 2013 at 10:07 AM, Joe Gordon  wrote:
>
>
>
> On Tue, Dec 31, 2013 at 8:45 AM, John Griffith 
> wrote:
>>
>> Hey Everyone,
>>
>> I wanted to see where we stand on IDE extensions in .gitignore files.
>> We seem to have some back and forth, one cycle there's a bug and a
>> patch to add things like eclipse, idea etc and the next there's a bug
>> and a patch to remove them.  I'd like to have some sort of consensus
>> on what we want here.  I personally don't have a preference, I would
>> just like to have consistency and quit thrashing back and forth.
>>
>> Anyway, I'd like to see all of the projects agree on this... or even
>> consider moving to a global .gitignore.  Thoughts??
>
>
> I am not sure if this is the global .gitignore you are thinking of but this
> is the one I am in favor of:
>
> https://help.github.com/articles/ignoring-files#global-gitignore

Yep

>
>
> Maintaining .gitignore in 30+ repositories for a potentially infinite number
> of editors is very hard, and thankfully we have an easier way to do it.

Exactly

>
>>
>>
>> John
>>
>>
>> ___
>> 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] [OpenStack-Dev] IDE extensions in .gitignore

[Chmouel Boudjnah]

I am not sure if this is the global .gitignore you are thinking of but this
> is the one I am in favor of:
>
> https://help.github.com/articles/ignoring-files#global-gitignore
>
>
> Maintaining .gitignore in 30+ repositories for a potentially infinite
> number of editors is very hard, and thankfully we have an easier way to do
> it.
>

I hereby +1 this I think we should just remove all editors specifics in
.gitignore and leave it to the user to set this up which would be useful
for him as well on other projects (i.e: not openstack) that doesn't have
such .gitignore .

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

Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

[Joe Gordon]

On Tue, Dec 31, 2013 at 8:45 AM, John Griffith
wrote:

> Hey Everyone,
>
> I wanted to see where we stand on IDE extensions in .gitignore files.
> We seem to have some back and forth, one cycle there's a bug and a
> patch to add things like eclipse, idea etc and the next there's a bug
> and a patch to remove them.  I'd like to have some sort of consensus
> on what we want here.  I personally don't have a preference, I would
> just like to have consistency and quit thrashing back and forth.
>
> Anyway, I'd like to see all of the projects agree on this... or even
> consider moving to a global .gitignore.  Thoughts??
>

I am not sure if this is the global .gitignore you are thinking of but this
is the one I am in favor of:

https://help.github.com/articles/ignoring-files#global-gitignore


Maintaining .gitignore in 30+ repositories for a potentially infinite
number of editors is very hard, and thankfully we have an easier way to do
it.


>
> John
>
> ___
> 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] [OpenStack-Dev] IDE extensions in .gitignore

[Jeremy Stanley]

On 2013-12-31 09:45:38 -0700 (-0700), John Griffith wrote:
[...]
> Anyway, I'd like to see all of the projects agree on this... or even
> consider moving to a global .gitignore.  Thoughts??

Personal opinion, the per-project .gitignore should be reserved
exclusively for autogenerated artifacts tools and scripts embedded
in the source (AUTHORS, dist, cover) or ephemeral files created by
tools which are part of the documented and recommended workflow
(.tox, .testrepository). The place for ignoring files created by
your preferred tools (editors, IDEs) is within your own ~/.gitconfig
instead... you can even set core.excludesfile to something like
~/.gitignore if you want to inherit common exclusions from a
separate file.

As for a global .gitignore synchronized across all projects, I think
this is not likely to work well. Consider, as an example, that some
projects may want ChangeLog autogenerated by PBR from the Git commit
log while others prefer to hand-curate their ChangeLog file instead.
The first project will want ChangeLog listed in .gitignore while the
second will want it to actually get checked into the repo.
-- 
Jeremy Stanley

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

[openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

[John Griffith]

Hey Everyone,

I wanted to see where we stand on IDE extensions in .gitignore files.
We seem to have some back and forth, one cycle there's a bug and a
patch to add things like eclipse, idea etc and the next there's a bug
and a patch to remove them.  I'd like to have some sort of consensus
on what we want here.  I personally don't have a preference, I would
just like to have consistency and quit thrashing back and forth.

Anyway, I'd like to see all of the projects agree on this... or even
consider moving to a global .gitignore.  Thoughts??

John

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

Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router

[Randy Tuttle]

Hi Nir

Good question. There's absolutely no reason not to allow more than 2
subnets, or even 2 of the same IP versions on the gateway port. In fact, in
our POC we allowed this (or, more specifically, we did not disallow it).
However, for the gateway port to the provider's next-hop router, we did not
have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron
today, only a single subnet is allowed per interface (either v4 or v6). So
all we are doing is opening up the gateway port to support what it does
today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the
gateway port (and same network/vlan). Our principle use case is to enable
IPv6 in an existing IPv4 environment.

Do you have a specific use case requiring 2 or more of the same
IP-versioned subnets on a gateway port?

Thanks
Randy


On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel  wrote:

> Hi,
>
> With regards to
> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port,can
>  you please clarify this statement: "We will disallow more that two
> subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets".
> The use case for dual-stack with one IPv4 and one IPv6 address associated
> to the same port is clear, but what is the reason to disallow more than two
> IPv4/IPv6 subnets to a port?
>
> Thanks and happy holidays!
> Nir
>
>
>
> ___
> 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][mistral] scheduled tasks

[Joshua Harlow]

Agreed taskflow doesn't currently provide scheduling as it was thought that 
reliable execution that can be restarted and resumed is the foundation that 
someone using taskflow can easily provide scheduling ontop of... Better IMHO to 
have a project doing this foundation well (since openstack would benefit from 
this) than try to pack so many features in that it does none of them well (this 
kind of kitchen sink approach seems to happen more often than not, sadly).

But in reality it's all about compromises and finding the solution that makes 
sense and works, and happy new year!! :P

Sent from my really tiny device...

On Dec 30, 2013, at 9:03 PM, "Renat Akhmerov" 
mailto:rakhme...@mirantis.com>> wrote:

Greg,

Georgy is right. We’re now actively working on PoC and we’ve already 
implemented the functionality we initially planned, including cron-based 
scheduling. You can take a look at our repo and evaluate what we’ve done, we’d 
be very glad to hear some feedback from anyone potentially interested in 
Mistral. We were supposed to deliver PoC in the end of December, however, we 
decided not to rush and include several really cool things that we came up with 
while working on PoC, they should demonstrate the whole idea of Mistral much 
better and expose functionality for more potential use cases. A couple of days 
ago I sent out the information about additional changes in DSL that we want to 
implement (etherpad: https://etherpad.openstack.org/p/mistral-poc), so if you’d 
like please join the discussion and let us know how we can evolve the project 
to better fit your needs. In fact, even though we call it PoC it’s already in a 
good shape and pretty soon (~1.5 month) is going to be mature enough to use it 
as a dependency for other projects.

As far as security, we thought about this and and we have a vision of how it 
could be implemented. Generally, later on we’re planning to implement sort of 
Role Based Access Control (RBAC) to, first of all, isolate user workbooks 
(definition of tasks, actions, events) from each other and deal with access 
patterns to OpenStack services. We would encourage you to file a BP with a 
description of what would be needed by Trove in that regard.

I looked at https://wiki.openstack.org/wiki/Trove/scheduled-tasks and at the 
first glance Mistral looks a good fit here, especially if you’re interested in 
a standalone REST service with its capabilities like execution monitoring, 
history, language independence and HA (i.e. you schedule backups via Mistral 
and Trove itself shouldn’t care about availability of any functionality related 
to scheduling). TaskFlow may also be helpful in case your scheduled jobs are 
representable as flows using one of TaskFlow patterns. However, in my 
understanding you’ll have to implement scheduling yourself since TaskFlow does 
not support it now, at least I didn’t find anything like that (Joshua can 
provide more details on that).

Thanks.

Renat Akhmerov
@Mirantis Inc.
___
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] Proposal to add Auston McReynolds to trove-core

[Paul Marshall]

+1

On Dec 30, 2013, at 1:13 PM, Vipul Sabhaya  wrote:

> +1
> 
> Sent from my iPhone
> 
> On Dec 30, 2013, at 10:50 AM, Craig Vyvial  wrote:
> 
>> +1
>> 
>> 
>> On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill  wrote:
>> +1
>> 
>> On Dec 27, 2013, at 4:48 PM, Michael Basnight  wrote:
>> 
>>> Howdy,
>>> 
>>> Im proposing Auston McReynolds (amcrn) to trove-core.
>>> 
>>> Auston has been working with trove for a while now. He is a great reviewer. 
>>> He is incredibly thorough, and has caught more than one critical error with 
>>> reviews and helps connect large features that may overlap (config edits + 
>>> multi datastores comes to mind). The code he submits is top notch, and we 
>>> frequently ask for his opinion on architecture / feature / design.
>>> 
>>> https://review.openstack.org/#/dashboard/8214
>>> https://review.openstack.org/#/q/owner:8214,n,z
>>> https://review.openstack.org/#/q/reviewer:8214,n,z
>>> 
>>> Please respond with +1/-1, or any further comments.
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [nova] Turbo-hipster

[Gary Kotton]

Hi,
It seems that she/he is behaving oddly again. I have posted a patch that does 
not have any database changes and it has give me a –1….
Happy new year
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Allow multiple subnets on gateway port for router

[Nir Yechiel]

Hi, 

With regards to 
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port,
 can you please clarify this statement: "We will disallow more that two 
subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets". 
The use case for dual-stack with one IPv4 and one IPv6 address associated to 
the same port is clear, but what is the reason to disallow more than two 
IPv4/IPv6 subnets to a port? 

Thanks and happy holidays! 
Nir 


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

[openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)]

Hi,

Currently there is no way to enable or disable meters without restarting 
ceilometer.

There are cases where operators do not want to run all the meters continuously.
In these cases, there should be a way to disable or enable them dynamically.

We are working on this feature right now. I have also created a blueprint for 
the same.
https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters

We would love to hear your views on this feature.

Regards,
VijayKumar Kodam



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