Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

[Flavio Percoco]

On 07/10/15 10:17 -0400, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2015-10-07 16:50:16 +0900:

On 06/10/15 23:36 +0900, Flavio Percoco wrote:
>Greetings,
>
>Not so long ago, Erno started a thread[0] in this list to discuss the
>abandon policies for patches that haven't been updated in Glance.
>
>I'd like to go forward and start following that policy with some
>changes that you can find below:
>
>1) Lets do this on patches that haven't had any activity in the last 2
>months. This adds one more month to Erno's proposal. The reason being
>that during the lat cycle, there were some ups and downs in the review
>flow that caused some patches to get stuck.
>
>2) Do this just on master, for all patches regardless they fix a
>bug or implement a spec and for all patches regardless their review
>status.
>
>3) The patch will be first marked as a WIP and then abandoned if the
>patch is not updated in 1 week. This will put this patches at the
>begining of the queue but using the Glance review dashboard should
>help keeing focus.
>
>Unless there are some critical things missing in the above or strong
>opiniones against this, I'll make this effective starting next Monday
>October 12th.

I'd like to provide some extra data here. This is our current status:

==
Total patches without activity in the last 2 months: 73
Total patches closing a bug: 30
Total patches with negative review by core reviewers: 62
Total patches with negative review by non-core reviewers: 75
Total patches without a core review in the last patchset: 13
Total patches with negative review from Jenkins: 50
==

It's not ideal but it's also not a lot. I'd like to recover as many
patches as possible from the above and I'm happy to do that manually
if necessary.

Cheers,
Flavio



It might be useful to schedule a review sprint to take a couple of days
to focus on reviews. Maybe the team can pick dates a couple of weeks in
advance so everyone can get permission to spend the full time on
reviews.


+1 This is something I've planned.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] Scheduler proposal

[Chris Friesen]

On 10/07/2015 07:23 PM, Ian Wells wrote:

On 7 October 2015 at 16:00, Chris Friesen mailto:chris.frie...@windriver.com>> wrote:

1) Some resources (RAM) only require tracking amounts.  Other resources
(CPUs, PCI devices) require tracking allocation of specific individual host
resources (for CPU pinning, PCI device allocation, etc.).  Presumably for
the latter we would have to actually do the allocation of resources at the
time of the scheduling operation in order to update the database with the
claimed resources in a race-free way.


The whole process is inherently racy (and this is inevitable, and correct),
which is why the scheduler works the way it does:

- scheduler guesses at a host based on (guaranteed - hello distributed systems!)
outdated information
- VM is scheduled to a host that looks like it might work, and host attempts to
run it
- VM run may fail (because the information was outdated or has become outdated),
in which case we retry the schedule


Why is it inevitable?

Theoretically if the DB knew about what resources were originally available and 
what resources have been consumed, then it should be able to allocate resources 
race-free (possibly with some retries involved if racing against other 
schedulers updating the DB, but that would be internal to the scheduler itself).


Or does that just not scale enough and we need to use inherently racy models?

Chris


__
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] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

[Johnston, Nate]

I can definitely help.

—N.

On Oct 7, 2015, at 8:11 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

Edgar Magana
__
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] 答复: [Congress] Tokyo sessions

[Rui Chen]

In my memory, there are 4 topics about OPNFV, congress gating, distributed
arch, Monasca.

Some details in IRC meeting log
http://eavesdrop.openstack.org/meetings/congressteammeeting/2015/congressteammeeting.2015-10-01-00.01.log.html

2015-10-08 9:48 GMT+08:00 zhangyali (D) :

> Hi Tim,
>
>
>
> Thanks for informing the meeting information. But does the meeting have
> some topics scheduled? I think it’s better to know what we are going to
> talk. Thanks so much!
>
>
>
> Yali
>
>
>
> *发件人:* Tim Hinrichs [mailto:t...@styra.com]
> *发送时间:* 2015年10月2日 2:52
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* [openstack-dev] [Congress] Tokyo sessions
>
>
>
> Hi all,
>
>
>
> We just got a tentative assignment for our meeting times in Tokyo.  Our 3
> meetings are scheduled back-to-back-to-back on Wed afternoon from
> 2:00-4:30p.  I don't think there's much chance of getting the meetings
> moved, but does anyone have a hard conflict?
>
>
>
> Here's our schedule for Wed:
>
>
>
> Wed 11:15-12:45 HOL
>
> Wed 2:00-2:40 Working meeting
>
> Wed 2:50-3:30 Working meeting
>
> Wed 3:40-4:20 Working meeting
>
>
>
> Tim
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> 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] Scheduler proposal

[Ed Leafe]

On Oct 7, 2015, at 6:00 PM, Chris Friesen  wrote:

> I've wondered for a while (ever since I looked at the scheduler code, really) 
> why we couldn't implement more of the scheduler as database transactions.
> 
> I haven't used Cassandra, so maybe you can clarify something about updates 
> across a distributed DB.  I just read up on lightweight transactions, and it 
> says that they're restricted to a single partition.  Is that an acceptable 
> limitation for this usage?

An implementation detail. A partition is defined by the partition key, not by 
any physical arrangement of nodes. The partition key would have to depend on 
the resource type, and whatever other columns would make such a query unique.

> Some points that might warrant further discussion:
> 
> 1) Some resources (RAM) only require tracking amounts.  Other resources 
> (CPUs, PCI devices) require tracking allocation of specific individual host 
> resources (for CPU pinning, PCI device allocation, etc.).  Presumably for the 
> latter we would have to actually do the allocation of resources at the time 
> of the scheduling operation in order to update the database with the claimed 
> resources in a race-free way.

Yes, that's correct. A lot of thought would have to be put into how to best 
represent these different types of resources, and that's something that I have 
ideas about, but would feel a whole lot better defining only after talking 
these concepts over with others who understand the underlying concepts better 
than I do.

> 2) Are you suggesting that all of nova switch to Cassandra, or just the 
> scheduler and resource tracking portions?  If the latter, how would we handle 
> things like pinned CPUs and PCI devices that are currently associated with 
> specific instances in the nova DB?

I am only thinking of the scheduler as a separate service. Perhaps Nova as a 
whole might benefit from switching to Cassandra for its database needs, but I 
haven't really thought about that at all.

> 3) The concept of the compute node updating the DB when things change is 
> really orthogonal to the new scheduling model.  The current scheduling model 
> would benefit from that as well.

Actually, it isn't that different. Compute nodes send updates to the scheduler 
when instances are created/deleted/resized/etc., so this isn't much of a 
stretch.

> 4) It seems to me that to avoid races we need to do one of the following.  
> Which are you proposing?
> a) Serialize the entire scheduling operation so that only one instance can 
> schedule at once.
> b) Make the evaluation of filters and claiming of resources a single atomic 
> DB transaction.
> c) Do a loop where we evaluate the filters, pick a destination, try to claim 
> the resources in the DB, and retry the whole thing if the resources have 
> already been claimed.

Probably a combination of b) and c). Filters would, for lack of a better term, 
add CSQL WHERE clauses to the query, which would return a set of acceptable 
hosts. Weighers would order these hosts in terms of desirability, and then the 
claim would be attempted. If the claim failed because the host had changed, the 
next acceptable host would be selected, etc. I don't imagine that "retrying the 
whole thing" would be an efficient option, unless there were no other 
acceptable hosts returned from the original filtering query.

Put another way: if we are in a racy situation, and two scheduler processes are 
trying to place a similar instance, both processes would most likely come up 
with the same set of hosts ordered in the same way. One of those processes 
would "win", and claim the first choice. The other would fail the transaction, 
and would then claim the second choice on the list. IMO, this is how you best 
deal with race conditions.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [nova] Intel PCI CI appears lost in the weeds

[yongli he]

Hi,  mriedem and all

Sorry for the CI problem.  we now back from holiday now, and find the 
problem and got solution.  CI will be back soon.


summary:
the LOG server connection lost, so the test result failed to uploading.

Yongli He



在 2015年10月08日 07:03, Matt Riedemann 写道:
Was seeing immediate posts on changes which I knew was bogus, and 
getting 404s on the logs:


http://52.27.155.124/232252/1

Anyone know what's going on?




__
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] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

[Jim Rollenhagen]

On Wed, Oct 07, 2015 at 12:41:55PM -0700, Devananda van der Veen wrote:
> Ramesh,
> 
> I thought about your points over night, and then looked at our in-tree
> driver code from stable/kilo and asked myself, "what if this driver was out
> of tree?" They'd all have broken -- for very similar reasons as what I
> encountered with my demo driver.
> 
> When we split the boot and deploy interfaces, we kept compatibility only at
> the boundary between ConductorManager and the Driver class. That's all we
> set out to do, because that's all we defined the interface to be. I can
> accept that, but I'd like us to think about whether the driver interface:
> a) is merely the interfaces defined in ironic/drivers/base.py, as we
> previously defined, or
> b) also includes one or more of the hardware-agnostic interface
> implementations (eg, PXEBoot, AgentDeploy, AgentRAID, inspector.Inspector)
> 
> As recent experience has taught me, these classes provide essential
> primitives for building new hardware drivers. If we want to support
> development of hardware drivers out of tree, but we don't want to include
> (b) in our definition of the API, then we are signalling that such drivers
> must be implemented entirely out of tree (iow, they're not allowed to
> borrow *any* functionality from ironic/drivers/modules/*).
> 
> And if we're signalling that, and someone goes and implements such a driver
> and then later wants to propose it upstream -- how will we feel about
> accepting a completely alternative implementation of, say, the pxe boot
> driver?

I agree; there's some hard things to think about here. I'd like to get a
definition of our driver API solidified and documented during Mitaka.
It's odd, because there are two pieces to (b) above; the names/methods
provided, and the actual behavior. I'm not sure that AgentDeploy is not
backwards compatible when it comes to names or methods, but we've
certainly changed the behavior. I've added this topic to our design
summit proposal list.

As for the original problem, I like ramesh's idea with the FakeBoot
driver. I think it will cause the least amount of breakage to
out-of-tree drivers, and still allow for an easy fix. We *do* need to be
very loud about this in release notes, ops mailing list, etc.

Deva, could you update the patch ASAP? I'd like to get it landed
tomorrow, so we can backport and get 4.2.1 out the door this week.

Thanks for digging into this! :)

// jim

__
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] 答复: [Congress] Tokyo sessions

[zhangyali (D)]

Hi Tim,

Thanks for informing the meeting information. But does the meeting have some 
topics scheduled? I think it’s better to know what we are going to talk. Thanks 
so much!

Yali

发件人: Tim Hinrichs [mailto:t...@styra.com]
发送时间: 2015年10月2日 2:52
收件人: OpenStack Development Mailing List (not for usage questions)
主题: [openstack-dev] [Congress] Tokyo sessions

Hi all,

We just got a tentative assignment for our meeting times in Tokyo.  Our 3 
meetings are scheduled back-to-back-to-back on Wed afternoon from 2:00-4:30p.  
I don't think there's much chance of getting the meetings moved, but does 
anyone have a hard conflict?

Here's our schedule for Wed:

Wed 11:15-12:45 HOL
Wed 2:00-2:40 Working meeting
Wed 2:50-3:30 Working meeting
Wed 3:40-4:20 Working meeting

Tim






__
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] Scheduler proposal

[Ian Wells]

On 7 October 2015 at 16:00, Chris Friesen 
wrote:

> 1) Some resources (RAM) only require tracking amounts.  Other resources
> (CPUs, PCI devices) require tracking allocation of specific individual host
> resources (for CPU pinning, PCI device allocation, etc.).  Presumably for
> the latter we would have to actually do the allocation of resources at the
> time of the scheduling operation in order to update the database with the
> claimed resources in a race-free way.
>

The whole process is inherently racy (and this is inevitable, and correct),
which is why the scheduler works the way it does:

- scheduler guesses at a host based on (guaranteed - hello distributed
systems!) outdated information
- VM is scheduled to a host that looks like it might work, and host
attempts to run it
- VM run may fail (because the information was outdated or has become
outdated), in which case we retry the schedule

In fact, with PCI devices the code has been written rather carefully to
make sure that they fit into this model.  There is central per-device
tracking (which, fwiw, I argued against back in the day) but that's not how
allocation works (or, considering how long it is since I looked, worked).

PCI devices are actually allocated from pools of equivalent devices, and
allocation works in the same manner as other scheduling: you work out from
the nova boot call what constraints a host must satisfy (in this case, in
number of PCI devices in specific pools), you check your best guess at
global host state against those constraints, and you pick one of the hosts
that meets the constraints to schedule on.

So: yes, there is a central registry of devices, which we try to keep up to
date - but this is for admins to refer to, it's not a necessity of
scheduling.  The scheduler input is the pool counts, which work largely the
same way as the available memory works as regards scheduling and updating.

No idea on CPUs, sorry, but again I'm not sure why the behaviour would be
any different: compare suspected host state against needs, schedule if it
fits, hope you got it right and tolerate if you didn't.

That being the case, it's worth noting that the database can be eventually
consistent and doesn't need to be transactional.  It's also worth
considering that the database can have multiple (mutually inconsistent)
copies.  There's no need to use a central datastore if you don't want to -
one theoretical example is to run multiple schedulers and let each
scheduler attempt to collate cloud state from unreliable messages from the
compute hosts.  This is not quite what happens today, because messages we
send over Rabbit are reliable and therefore costly.
-- 
Ian.
__
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] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,
stable/kilo is now frozen. I expect to do a release on Tuesday. If you need
to include something please let me know.

Thanks
chuck
__
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] [tc] naming N and O releases nowish

[Rochelle Grober]

> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: Wednesday, October 07, 2015 3:48 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] naming N and O releases nowish
> 
> On 10/07/2015 06:22 PM, Monty Taylor wrote:
> > On 10/07/2015 09:24 AM, Sean Dague wrote:
> >> On 10/07/2015 08:57 AM, Thierry Carrez wrote:
> >>> Sean Dague wrote:
>  We're starting to make plans for the next cycle. Long term plans
> are
>  getting made for details that would happen in one or two cycles.
> 
>  As we already have the locations for the N and O summits I think
> we
>  should do the naming polls now and have names we can use for this
>  planning instead of letters. It's pretty minor but it doesn't seem
> like
>  there is any real reason to wait and have everyone come up with
> working
>  names that turn out to be confusing later.
> >>>
> >>> That sounds fair. However the release naming process currently
> >>> states[1]:
> >>>
> >>> """
> >>> The process to chose the name for a release begins once the
> location of
> >>> the design summit of the release to be named is announced and no
> sooner
> >>> than the opening of development of the previous release.
> >>> """
> >>>
> >>> ...which if I read it correctly means we could pick N now, but not
> O. We
> >>> might want to change that (again) first.
> >>>
> >>> [1] http://governance.openstack.org/reference/release-naming.html
> >>
> >> Right, it seems like we should change it so that we can do naming as
> >> soon as the location is announced.
> >>
> >> For projects like Nova that are trying to plan things more than one
> >> cycle out, having those names to hang those features on is massively
> >> useful (as danpb also stated). Delaying for bureaucratic reasons
> just
> >> seems silly. :)
> >
> > So, for what it's worth, I remember discussing this when we discussed
> > the current process, and the change you are proposing was one of the
> > options put forward when we talked about it.
> >
> > The reason for not doing all of them as soon as we know them was to
> keep
> > a sense of ownership by the people who are actually working on the
> > thing. Barcelona is a long way away and we'll all likely have rage
> quit
> > by then, leaving the electorate for the name largely disjoint from
> the
> > people working on the release.
> >
> > Now, I hear you - and I'm not arguing that position. (In fact, I
> believe
> > my original thought was in line with what you said here) BUT - I
> mostly
> > want to point out that we have had this discussion, the discussion
> was
> > not too long ago, it covered this point, and I sort of feel like if
> we
> > have another discussion on naming process people might kill us with
> > pitchforks.
> 
> You are assuming that not having this conversation might shield you
> from
> the pitchforks.
 
I, myself favor war hammers (very useful tool for separating plaster from 
lathe), but if we all rage quit, the new guard can always change the name as a 
middle finger salute to the old guard.  Let's be daring!  Let's name O, too!

--Rocky

> Anita.
> 
> >
> > Monty
> >
> >
> >
> ___
> ___
> > 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] Scheduler proposal

[Fox, Kevin M]

I think if you went ahead and did the experiment, and had good results from it, 
the discussion would start to progress whether or not folks were fond of 
Cassandra or ...

Thanks,
Kevin

From: Ed Leafe [e...@leafe.com]
Sent: Wednesday, October 07, 2015 5:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Scheduler proposal

On Oct 7, 2015, at 2:28 PM, Zane Bitter  wrote:

> It seems to me (disclaimer: not a Nova dev) that which database to use is 
> completely irrelevant to your proposal,

Well, not entirely. The difference is that what Cassandra offers that separates 
it from other DBs is exactly the feature that we need. The solution to the 
scheduler isn't to simply "use a database".

> which is really about moving the scheduling from a distributed collection of 
> Python processes with ad-hoc (or sometimes completely missing) 
> synchronisation into the database to take advantage of its well-defined 
> semantics. But you've framed it in such a way as to guarantee that this never 
> gets discussed, because everyone will be too busy arguing about whether or 
> not Cassandra is better than Galera.

Understood - all one has to do is review the original thread from back in July 
to see this happening. But the reason that I framed it then as an experiment in 
which we would come up with measures of success we could all agree on up-front 
was so that if someone else thought that Product Foo would be even better, we 
could set up a similar test bed and try it out. IOW, instead of bikeshedding, 
if you want a different color, you build another shed and we can all have a 
look.


-- Ed Leafe






__
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] Core Reviewers groups restructure

[Dmitry Borodaenko]

On Wed, Oct 07, 2015 at 02:04:52PM -0700, Dmitry Borodaenko wrote:
> While we're waiting for openstack-infra team to finish the stackforge
> migration and review our ACL changes, I implemented the rest of the
> changes agreed in this thread:
> 
> - Fuel-core group removed everywhere.
> 
> - Per-project core groups populated with individual reviewers as quoted
>   below. Exceptions:
> 
>   - Dennis Dmitriev was approved as core in fuel-qa, fuel-devops, and
> fuel-ostf after this thread was started;

Correction: I meant fuel-qa and fuel-devops here, not fuel-ostf.

>   - fuel-upgrades already excludes fuel-core so I couldn't modify it,
> and the current list doesn't match Mike's email. It is up to current
> cores [0] to bring it up to date.
> 
> [0] https://review.openstack.org/#/admin/groups/1004,members
> 
> fuel-specs and fuel-*-release groups will have to wait until ACL update
> is merged (i.e. after October 17).
> 
> -- 
> Dmitry Borodaenko
> 
> On Thu, Oct 01, 2015 at 03:59:47PM -0700, Dmitry Borodaenko wrote:
> > This commit brings Fuel ACLs in sync with each other and in line with
> > the agreement on this thread:
> > https://review.openstack.org/230195
> > 
> > Please review carefully. Note that I intentionally didn't touch any of
> > the plugins ACLs, primarily to save time for us and the
> > openstack-infra team until after the stackforge->openstack namespace
> > migration.
> > 
> > On Mon, Sep 21, 2015 at 4:17 PM, Mike Scherbakov
> >  wrote:
> > > Thanks guys.
> > > So for fuel-octane then there are no actions needed.
> > >
> > > For fuel-agent-core group [1], looks like we are already good (it doesn't
> > > have fuel-core group nested). But it would need to include fuel-infra 
> > > group
> > > and remove Aleksandra Fedorova (she will be a part of fuel-infra group).
> > >
> > > python-fuel-client-core [2] is good as well (no nested fuel-core). 
> > > However,
> > > there is another group python-fuelclient-release [3], which has to be
> > > eliminated, and main python-fuelclient-core would just have fuel-infra 
> > > group
> > > included for maintenance purposes.
> > >
> > > [1] https://review.openstack.org/#/admin/groups/995,members
> > > [2] https://review.openstack.org/#/admin/groups/551,members
> > > [3] https://review.openstack.org/#/admin/groups/552,members
> > >
> > >
> > > On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh  
> > > wrote:
> > >>
> > >> FYI, we have a separate core group for stackforge/fuel-octane repository
> > >> [1].
> > >>
> > >> I'm supporting the move to modularization of Fuel with cleaner separation
> > >> of authority and better defined interfaces. Thus, I'm +1 to such a 
> > >> change as
> > >> a part of that move.
> > >>
> > >> [1] https://review.openstack.org/#/admin/groups/1020,members
> > >>
> > >> --
> > >> Best regards,
> > >> Oleg Gelbukh
> > >>
> > >> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov
> > >>  wrote:
> > >>>
> > >>> Hi all,
> > >>> as of my larger proposal on improvements to code review workflow [1], we
> > >>> need to have cores for repositories, not for the whole Fuel. It is the 
> > >>> path
> > >>> we are taking for a while, and new core reviewers added to specific 
> > >>> repos
> > >>> only. Now we need to complete this work.
> > >>>
> > >>> My proposal is:
> > >>>
> > >>> Get rid of one common fuel-core [2] group, members of which can merge
> > >>> code anywhere in Fuel. Some members of this group may cover a couple of
> > >>> repositories, but can't really be cores in all repos.
> > >>> Extend existing groups, such as fuel-library [3], with members from
> > >>> fuel-core who are keeping up with large number of reviews / merges. This
> > >>> data can be queried at Stackalytics.
> > >>> Establish a new group "fuel-infra", and ensure that it's included into
> > >>> any other core group. This is for maintenance purposes, it is expected 
> > >>> to be
> > >>> used only in exceptional cases. Fuel Infra team will have to decide 
> > >>> whom to
> > >>> include into this group.
> > >>> Ensure that fuel-plugin-* repos will not be affected by removal of
> > >>> fuel-core group.
> > >>>
> > >>> #2 needs specific details. Stackalytics can show active cores easily, we
> > >>> can look at people with *:
> > >>> http://stackalytics.com/report/contribution/fuel-web/180. This is for
> > >>> fuel-web, change the link for other repos accordingly. If people are 
> > >>> added
> > >>> specifically to the particular group, leaving as is (some of them are no
> > >>> longer active. But let's clean them up separately from this group
> > >>> restructure process).
> > >>>
> > >>> fuel-library-core [3] group will have following members: Bogdan D.,
> > >>> Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko.
> > >>> fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, Vitaly
> > >>> Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak
> > >>> fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li
> > >>> fuel-dev-tools-core [6]: Przemek Kaminski

Re: [openstack-dev] Scheduler proposal

[Ed Leafe]

On Oct 7, 2015, at 2:28 PM, Zane Bitter  wrote:

> It seems to me (disclaimer: not a Nova dev) that which database to use is 
> completely irrelevant to your proposal,

Well, not entirely. The difference is that what Cassandra offers that separates 
it from other DBs is exactly the feature that we need. The solution to the 
scheduler isn't to simply "use a database".

> which is really about moving the scheduling from a distributed collection of 
> Python processes with ad-hoc (or sometimes completely missing) 
> synchronisation into the database to take advantage of its well-defined 
> semantics. But you've framed it in such a way as to guarantee that this never 
> gets discussed, because everyone will be too busy arguing about whether or 
> not Cassandra is better than Galera.

Understood - all one has to do is review the original thread from back in July 
to see this happening. But the reason that I framed it then as an experiment in 
which we would come up with measures of success we could all agree on up-front 
was so that if someone else thought that Product Foo would be even better, we 
could set up a similar test bed and try it out. IOW, instead of bikeshedding, 
if you want a different color, you build another shed and we can all have a 
look.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

[Edgar Magana]

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

Edgar Magana
__
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] We should move strutils.mask_password back into oslo-incubator

[Matt Riedemann]

On 10/7/2015 6:00 PM, Robert Collins wrote:

On 8 October 2015 at 08:38, Matt Riedemann  wrote:

Here's why:

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

That's marked as fixing an OSSA which means we'll have to backport the fix
in nova but it depends on a change to strutils.mask_password in oslo.utils,
which required a release and a minimum version bump in global-requirements.

To backport the change in nova, we either have to:

1. Copy mask_password out of oslo.utils and add it to nova in the backport
or,

2. Backport the oslo.utils change to a stable branch, release it as a patch
release, bump minimum required version in stable g-r and then backport the
nova change and depend on the backported oslo.utils stable release - which
also makes it a dependent library version bump for any packagers/distros
that have already frozen libraries for their stable releases, which is kind
of not fun.

So I'm thinking this is one of those things that should ultimately live in
oslo-incubator so it can live in the respective projects. If mask_password
were in oslo-incubator, we'd have just fixed and backported it there and
then synced to nova on master and stable branches, no dependent library
version bumps required.

Plus I miss the good old days of reviewing oslo-incubator syncs...(joking of
course).


Whats wrong with 2?  I mean, other than the work needed *because* we
made branches of oslo.utils: something I hope we can stop doing in M
(I have a draft spec up about this...)

Libraries have security bugs too, and packagers/distros need to update
them as well as the API servers: this is one of the reasons we have
backpressure on libraries being admitted into our dependency chain.

-Rob




The work involved isn't the problem, I was more concerned about raising 
the minimum required version of a library on stable. But I guess it can 
happen and packagers/deployers/distros can update their packages on 
stable or patch them as needed (that's probably what we'd do internally 
since we have to legally clear each package we ship ourselves and 
version bumps are generally not fun for us on stable).


--

Thanks,

Matt Riedemann


__
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] [nova] Intel PCI CI appears lost in the weeds

[Matt Riedemann]

Was seeing immediate posts on changes which I knew was bogus, and 
getting 404s on the logs:


http://52.27.155.124/232252/1

Anyone know what's going on?

--

Thanks,

Matt Riedemann


__
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] Scheduler proposal

[Chris Friesen]

On 10/07/2015 11:36 AM, Ed Leafe wrote:


I've finally gotten around to finishing writing up that proposal [1], and I'd
like to hope that it would be the basis for future discussions about
addressing some of the underlying issues that exist in OpenStack for
historical reasons, and how we might rethink these choices today. I'd prefer
comments and discussion here on the dev list, so that all can see your ideas,
but I will be in Tokyo for the summit, and would also welcome some informal
discussion there, too.

-- Ed Leafe

 [1] http://blog.leafe.com/reimagining_scheduler/


I've wondered for a while (ever since I looked at the scheduler code, really) 
why we couldn't implement more of the scheduler as database transactions.


I haven't used Cassandra, so maybe you can clarify something about updates 
across a distributed DB.  I just read up on lightweight transactions, and it 
says that they're restricted to a single partition.  Is that an acceptable 
limitation for this usage?


Some points that might warrant further discussion:

1) Some resources (RAM) only require tracking amounts.  Other resources (CPUs, 
PCI devices) require tracking allocation of specific individual host resources 
(for CPU pinning, PCI device allocation, etc.).  Presumably for the latter we 
would have to actually do the allocation of resources at the time of the 
scheduling operation in order to update the database with the claimed resources 
in a race-free way.


2) Are you suggesting that all of nova switch to Cassandra, or just the 
scheduler and resource tracking portions?  If the latter, how would we handle 
things like pinned CPUs and PCI devices that are currently associated with 
specific instances in the nova DB?


3) The concept of the compute node updating the DB when things change is really 
orthogonal to the new scheduling model.  The current scheduling model would 
benefit from that as well.


4) It seems to me that to avoid races we need to do one of the following.  Which 
are you proposing?
a) Serialize the entire scheduling operation so that only one instance can 
schedule at once.
b) Make the evaluation of filters and claiming of resources a single atomic DB 
transaction.
c) Do a loop where we evaluate the filters, pick a destination, try to claim the 
resources in the DB, and retry the whole thing if the resources have already 
been claimed.


Chris

__
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] We should move strutils.mask_password back into oslo-incubator

[Robert Collins]

On 8 October 2015 at 08:38, Matt Riedemann  wrote:
> Here's why:
>
> https://review.openstack.org/#/c/220622/
>
> That's marked as fixing an OSSA which means we'll have to backport the fix
> in nova but it depends on a change to strutils.mask_password in oslo.utils,
> which required a release and a minimum version bump in global-requirements.
>
> To backport the change in nova, we either have to:
>
> 1. Copy mask_password out of oslo.utils and add it to nova in the backport
> or,
>
> 2. Backport the oslo.utils change to a stable branch, release it as a patch
> release, bump minimum required version in stable g-r and then backport the
> nova change and depend on the backported oslo.utils stable release - which
> also makes it a dependent library version bump for any packagers/distros
> that have already frozen libraries for their stable releases, which is kind
> of not fun.
>
> So I'm thinking this is one of those things that should ultimately live in
> oslo-incubator so it can live in the respective projects. If mask_password
> were in oslo-incubator, we'd have just fixed and backported it there and
> then synced to nova on master and stable branches, no dependent library
> version bumps required.
>
> Plus I miss the good old days of reviewing oslo-incubator syncs...(joking of
> course).

Whats wrong with 2?  I mean, other than the work needed *because* we
made branches of oslo.utils: something I hope we can stop doing in M
(I have a draft spec up about this...)

Libraries have security bugs too, and packagers/distros need to update
them as well as the API servers: this is one of the reasons we have
backpressure on libraries being admitted into our dependency chain.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [app-catalog] IRC Meeting Thursday October 8th at 17:00UTC

[Christopher Aedo]

Greetings! Our next OpenStack App Catalog meeting will take place this
Thursday October 8th at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher

__
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] [tc] naming N and O releases nowish

[Anita Kuno]

On 10/07/2015 06:22 PM, Monty Taylor wrote:
> On 10/07/2015 09:24 AM, Sean Dague wrote:
>> On 10/07/2015 08:57 AM, Thierry Carrez wrote:
>>> Sean Dague wrote:
 We're starting to make plans for the next cycle. Long term plans are
 getting made for details that would happen in one or two cycles.

 As we already have the locations for the N and O summits I think we
 should do the naming polls now and have names we can use for this
 planning instead of letters. It's pretty minor but it doesn't seem like
 there is any real reason to wait and have everyone come up with working
 names that turn out to be confusing later.
>>>
>>> That sounds fair. However the release naming process currently
>>> states[1]:
>>>
>>> """
>>> The process to chose the name for a release begins once the location of
>>> the design summit of the release to be named is announced and no sooner
>>> than the opening of development of the previous release.
>>> """
>>>
>>> ...which if I read it correctly means we could pick N now, but not O. We
>>> might want to change that (again) first.
>>>
>>> [1] http://governance.openstack.org/reference/release-naming.html
>>
>> Right, it seems like we should change it so that we can do naming as
>> soon as the location is announced.
>>
>> For projects like Nova that are trying to plan things more than one
>> cycle out, having those names to hang those features on is massively
>> useful (as danpb also stated). Delaying for bureaucratic reasons just
>> seems silly. :)
> 
> So, for what it's worth, I remember discussing this when we discussed
> the current process, and the change you are proposing was one of the
> options put forward when we talked about it.
> 
> The reason for not doing all of them as soon as we know them was to keep
> a sense of ownership by the people who are actually working on the
> thing. Barcelona is a long way away and we'll all likely have rage quit
> by then, leaving the electorate for the name largely disjoint from the
> people working on the release.
> 
> Now, I hear you - and I'm not arguing that position. (In fact, I believe
> my original thought was in line with what you said here) BUT - I mostly
> want to point out that we have had this discussion, the discussion was
> not too long ago, it covered this point, and I sort of feel like if we
> have another discussion on naming process people might kill us with
> pitchforks.

You are assuming that not having this conversation might shield you from
the pitchforks.

Anita.

> 
> Monty
> 
> 
> __
> 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] We should move strutils.mask_password back into oslo-incubator

[Joshua Harlow]

Isn't #2 the right approach?

Even if it might be more 'work' I personally would prefer #2 and do it 
right (and make it easier to do the right thing in the future via 
scripts, automation, other) vs. the other mentioned approaches.


If we were consuming, say a 3rd party library and that 3rd party library 
had/has a security issue, isn't the above the same thing that you would 
have to do?


My 2 cents.

Matt Riedemann wrote:

Here's why:

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

That's marked as fixing an OSSA which means we'll have to backport the
fix in nova but it depends on a change to strutils.mask_password in
oslo.utils, which required a release and a minimum version bump in
global-requirements.

To backport the change in nova, we either have to:

1. Copy mask_password out of oslo.utils and add it to nova in the
backport or,

2. Backport the oslo.utils change to a stable branch, release it as a
patch release, bump minimum required version in stable g-r and then
backport the nova change and depend on the backported oslo.utils stable
release - which also makes it a dependent library version bump for any
packagers/distros that have already frozen libraries for their stable
releases, which is kind of not fun.

So I'm thinking this is one of those things that should ultimately live
in oslo-incubator so it can live in the respective projects. If
mask_password were in oslo-incubator, we'd have just fixed and
backported it there and then synced to nova on master and stable
branches, no dependent library version bumps required.

Plus I miss the good old days of reviewing oslo-incubator
syncs...(joking of course).



__
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] [Neutron] [openstack-infra] stable changes to python-neutronclient unable to merge

[Armando M.]

On 6 October 2015 at 20:06, Armando M.  wrote:

> Hi folks,
>
> We are unable to merge stable changes to python-neutronclient (as shown in
> [1,2]) because of the missing master fixes [3,4]. We should be able to
> untangle Liberty with [5], but to unblock Kilo, I may need to squash [6]
> with a cherry pick of [3] and wait [5] to merge.
>
> Please bear with us until we get the situation sorted.
>
> Cheers,
> Armando
>
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/kilo,n,z
> [2]
> https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/liberty,n,z
> [3] https://review.openstack.org/#/c/231731/
> [4] https://review.openstack.org/#/c/231797/
> [5] https://review.openstack.org/#/c/231796/
> [6] https://review.openstack.org/#/c/231797/
>
>
An update: Liberty is unjammed, but Kilo is still in progress.
__
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] [tc] naming N and O releases nowish

[Monty Taylor]

On 10/07/2015 09:24 AM, Sean Dague wrote:

On 10/07/2015 08:57 AM, Thierry Carrez wrote:

Sean Dague wrote:

We're starting to make plans for the next cycle. Long term plans are
getting made for details that would happen in one or two cycles.

As we already have the locations for the N and O summits I think we
should do the naming polls now and have names we can use for this
planning instead of letters. It's pretty minor but it doesn't seem like
there is any real reason to wait and have everyone come up with working
names that turn out to be confusing later.


That sounds fair. However the release naming process currently states[1]:

"""
The process to chose the name for a release begins once the location of
the design summit of the release to be named is announced and no sooner
than the opening of development of the previous release.
"""

...which if I read it correctly means we could pick N now, but not O. We
might want to change that (again) first.

[1] http://governance.openstack.org/reference/release-naming.html


Right, it seems like we should change it so that we can do naming as
soon as the location is announced.

For projects like Nova that are trying to plan things more than one
cycle out, having those names to hang those features on is massively
useful (as danpb also stated). Delaying for bureaucratic reasons just
seems silly. :)


So, for what it's worth, I remember discussing this when we discussed 
the current process, and the change you are proposing was one of the 
options put forward when we talked about it.


The reason for not doing all of them as soon as we know them was to keep 
a sense of ownership by the people who are actually working on the 
thing. Barcelona is a long way away and we'll all likely have rage quit 
by then, leaving the electorate for the name largely disjoint from the 
people working on the release.


Now, I hear you - and I'm not arguing that position. (In fact, I believe 
my original thought was in line with what you said here) BUT - I mostly 
want to point out that we have had this discussion, the discussion was 
not too long ago, it covered this point, and I sort of feel like if we 
have another discussion on naming process people might kill us with 
pitchforks.


Monty


__
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] [nova] live migration in Mitaka

[Chris Friesen]

On 10/07/2015 03:14 AM, Daniel P. Berrange wrote:


For suspended instances, the scenario is really the same as with completely
offline instances. The only extra step is that you need to migrate the saved
image state file, as well as the disk images. This is trivial once you have
done the code for migrating disk images offline, since its "just one more file"
to care about.  Officially apps aren't supposed to know where libvirt keeps
the managed save files, but I think it is fine for Nova to peek behind the
scenes to get them. Alternatively I'd be happy to see an API added to libvirt
to allow the managed save files to be uploaded & downloaded via a libvirt
virStreamPtr object, in the same way we provide APIs to  upload & download
disk volumes. This would avoid the need to know explicitly about the file
location for the managed save image.


Assuming we were using libvirt with the storage pools API could we currently 
(with existing libvirt) migrate domains that have been suspended with 
virDomainSave()?  Or is the only current option to have nova move the file over 
using passwordless access?


I'm assuming we want to work towards using storage pools to get away from the 
need for passwordless access between hypervisors, so having libvirt support 
would be useful.


Chris


__
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] [Manila] CephFS native driver

[Shinobu Kinjo]

Yes, let's discuss this in Tokyo.

Shinobu

- Original Message -
From: "Clinton Knight" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, October 8, 2015 2:15:52 AM
Subject: Re: [openstack-dev] [Manila] CephFS native driver

Hi, John.  If you want to discuss this in Tokyo, I suggest you add it to
the etherpad:

https://etherpad.openstack.org/p/manila-mitaka-summit-topics


I look forward to meeting you at the Summit.  It¹d be great to see a demo
of your Ceph driver.

Clinton


On 10/7/15, 6:56 AM, "John Spray"  wrote:

>On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty 
>wrote:
>>>
>>> Currently, as you say, a share is accessible to anyone who knows the
>>> auth key (created a the time the share is created).
>>>
>>> For adding the allow/deny path, I'd simply create and remove new ceph
>>> keys for each entity being allowed/denied.
>>
>>
>> Ok, but how does that map to the existing Manila access types (IP, User,
>> Cert) ?
>
>None of the above :-)
>
>Compared with certs, the difference with Ceph is that ceph is issuing
>credentials, rather than authorizing existing credentials[1]. So
>rather than the tenant saying "Here's a certificate that Alice has
>generated and will use to access the filesystem, please authorize it",
>the tenant would say "Please authorize someone called Bob to access
>the share, and let me know the key he should use to prove he is Bob".
>
>As far as I can tell, we can't currently expose that in Manila: the
>missing piece is a way to tag that generated key onto a
>ShareInstanceAccessMapping, so that somebody with the right to read
>from the Manila API can go read Bob's key, and give it to Bob so that
>he can mount the filesystem.
>
>That's why the first-cut compromise is to create a single auth
>identity for accessing the share, and expose the key as part of the
>share's export location.  It's then the user application's job to
>share out that key to whatever hosts need to access it.  The lack of
>Manila-mediated 'allow' is annoying but not intrinsically insecure.
>The security problem with this approach is that we're not providing a
>way to revoke/rotate the key without destroying the share.
>
>So anyway.  This might be a good topic for a conversation at the
>summit (or catch me up on the list if it's already been discussed in
>depth) -- should drivers be allowed to publish generated
>authentication tokens as part of the API for allowing access to a
>share?
>
>John
>
>
>1. Aside: We *could* do a certificate-like model if it was assumed
>that the Manila API consumer knew how to go and talk to Ceph out of
>band to generate their auth identity.  That way, they could go and
>create their auth identity in Ceph, and then ask Manila to grant that
>identity access to the share.  However, it would be pointless, because
>in ceph, anyone who can create an identity can also set the
>capabilities of it (i.e. if they can talk directly to ceph, they don't
>need Manila's permission to access the share).
>
>__
>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] Scheduler proposal

[Clint Byrum]

Excerpts from Zane Bitter's message of 2015-10-07 12:28:36 -0700:
> On 07/10/15 13:36, Ed Leafe wrote:
> > Several months ago I proposed an experiment [0] to see if switching the 
> > data model for the Nova scheduler to use Cassandra as the backend would be 
> > a significant improvement as opposed to the current design using multiple 
> > copies of the same data (compute_node in MySQL DB, HostState in memory in 
> > the scheduler, ResourceTracker in memory in the compute node) and trying to 
> > keep them all in sync via passing messages.
> 
> It seems to me (disclaimer: not a Nova dev) that which database to use 
> is completely irrelevant to your proposal, which is really about moving 
> the scheduling from a distributed collection of Python processes with 
> ad-hoc (or sometimes completely missing) synchronisation into the 
> database to take advantage of its well-defined semantics. But you've 
> framed it in such a way as to guarantee that this never gets discussed, 
> because everyone will be too busy arguing about whether or not Cassandra 
> is better than Galera.
> 

Your point is valid Zane, that the idea is more about having a
synchronized view of the scheduling state, and not about Cassandra.

I think Cassandra makes the proposal more realistic and easier to think
aboutthough, as Cassandra is focused on problems of the scale that this
represents. Galera won't do this well at any kind of scale, without
the added complexity and inefficiency of cells. So whatever Galera's
capability for a single node to handle the write churn of a truly
synchronized scheduler is, would be the maximum capacity of one cell.

I like the concrete nature of this proposal, and suggest people review
it as a whole, and not try to reduce it to its components without an
extremely strong reason to do so.

__
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] Core Reviewers groups restructure

[Dmitry Borodaenko]

While we're waiting for openstack-infra team to finish the stackforge
migration and review our ACL changes, I implemented the rest of the
changes agreed in this thread:

- Fuel-core group removed everywhere.

- Per-project core groups populated with individual reviewers as quoted
  below. Exceptions:

  - Dennis Dmitriev was approved as core in fuel-qa, fuel-devops, and
fuel-ostf after this thread was started;

  - fuel-upgrades already excludes fuel-core so I couldn't modify it,
and the current list doesn't match Mike's email. It is up to current
cores [0] to bring it up to date.

[0] https://review.openstack.org/#/admin/groups/1004,members

fuel-specs and fuel-*-release groups will have to wait until ACL update
is merged (i.e. after October 17).

-- 
Dmitry Borodaenko

On Thu, Oct 01, 2015 at 03:59:47PM -0700, Dmitry Borodaenko wrote:
> This commit brings Fuel ACLs in sync with each other and in line with
> the agreement on this thread:
> https://review.openstack.org/230195
> 
> Please review carefully. Note that I intentionally didn't touch any of
> the plugins ACLs, primarily to save time for us and the
> openstack-infra team until after the stackforge->openstack namespace
> migration.
> 
> On Mon, Sep 21, 2015 at 4:17 PM, Mike Scherbakov
>  wrote:
> > Thanks guys.
> > So for fuel-octane then there are no actions needed.
> >
> > For fuel-agent-core group [1], looks like we are already good (it doesn't
> > have fuel-core group nested). But it would need to include fuel-infra group
> > and remove Aleksandra Fedorova (she will be a part of fuel-infra group).
> >
> > python-fuel-client-core [2] is good as well (no nested fuel-core). However,
> > there is another group python-fuelclient-release [3], which has to be
> > eliminated, and main python-fuelclient-core would just have fuel-infra group
> > included for maintenance purposes.
> >
> > [1] https://review.openstack.org/#/admin/groups/995,members
> > [2] https://review.openstack.org/#/admin/groups/551,members
> > [3] https://review.openstack.org/#/admin/groups/552,members
> >
> >
> > On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh  wrote:
> >>
> >> FYI, we have a separate core group for stackforge/fuel-octane repository
> >> [1].
> >>
> >> I'm supporting the move to modularization of Fuel with cleaner separation
> >> of authority and better defined interfaces. Thus, I'm +1 to such a change 
> >> as
> >> a part of that move.
> >>
> >> [1] https://review.openstack.org/#/admin/groups/1020,members
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov
> >>  wrote:
> >>>
> >>> Hi all,
> >>> as of my larger proposal on improvements to code review workflow [1], we
> >>> need to have cores for repositories, not for the whole Fuel. It is the 
> >>> path
> >>> we are taking for a while, and new core reviewers added to specific repos
> >>> only. Now we need to complete this work.
> >>>
> >>> My proposal is:
> >>>
> >>> Get rid of one common fuel-core [2] group, members of which can merge
> >>> code anywhere in Fuel. Some members of this group may cover a couple of
> >>> repositories, but can't really be cores in all repos.
> >>> Extend existing groups, such as fuel-library [3], with members from
> >>> fuel-core who are keeping up with large number of reviews / merges. This
> >>> data can be queried at Stackalytics.
> >>> Establish a new group "fuel-infra", and ensure that it's included into
> >>> any other core group. This is for maintenance purposes, it is expected to 
> >>> be
> >>> used only in exceptional cases. Fuel Infra team will have to decide whom 
> >>> to
> >>> include into this group.
> >>> Ensure that fuel-plugin-* repos will not be affected by removal of
> >>> fuel-core group.
> >>>
> >>> #2 needs specific details. Stackalytics can show active cores easily, we
> >>> can look at people with *:
> >>> http://stackalytics.com/report/contribution/fuel-web/180. This is for
> >>> fuel-web, change the link for other repos accordingly. If people are added
> >>> specifically to the particular group, leaving as is (some of them are no
> >>> longer active. But let's clean them up separately from this group
> >>> restructure process).
> >>>
> >>> fuel-library-core [3] group will have following members: Bogdan D.,
> >>> Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko.
> >>> fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, Vitaly
> >>> Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak
> >>> fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li
> >>> fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K.
> >>> fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky, Nastya
> >>> Urlapova
> >>> fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny
> >>> Konstantinov, Olga Gusarenko
> >>> fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry Pyzhov,
> >>> Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky
> >>> fuel-nailgun-agent-core [10]: Vladimir Sharshov, V

Re: [openstack-dev] [Cinder] Google Hangout recording of volume manger locks

[Dulko, Michal]

On Wed, 2015-10-07 at 11:01 -0700, Walter A. Boring IV wrote:
> Hello folks,
>I just wanted to post up the YouTube link for the video hangout that 
> the Cinder team just had.
> 
> We had a good discussion about the local file locks in the volume 
> manager and how it affects the interaction
> of Nova with Cinder in certain cases.  We are trying to iron out how to 
> proceed ahead with removing the
> volume manager locks in a way that doesn't break the world.  The hope of 
> this is to eventually allow Cinder
> to run active/active HA c-vol services.
> 
> The Youtube.com link for the recording is here on my personal account:
> https://www.youtube.com/watch?v=D_iXpNcWDv8
> 
> 
> We discussed several things in the meeting:
> * The etherpad that was used as a basis for discussion:
> https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
> * What to do with the current volume manager locks and how do we remove 
> them?
> * How do we move forward with checking 'ING' states for volume actions?
> * What is the process for moving forward with the compare/swap patches 
> that Gorka has in gerrit.
> 
> 
> Action Items:
> *  We agreed to take a deeper look into the main compare/swap changes 
> that Gorka has in gerrit and see if we can get those to land.
>* https://review.openstack.org/#/c/205834/
>* https://review.openstack.org/#/c/218012/
> * Gorka is to update the patches and add the references to the 
> specs/blueprints for reference.
> * Gorka is going to post up follow up patch sets to test the removal of 
> each lock and see if it is sufficient to remove each individual lock.
> 
> 
> Follow up items:
> * Does it make sense for the community to create an OpenStack Cinder 
> youtube account, where the PTL owns the account, and we run
> each of our google hangouts through that.  The advantage of this is to 
> allow the community to participate openly, as well as record each of
> our Cinder hangouts for folks that can't attend the live event.  We 
> could use this account for the meetups as well as the conference sessions,
> and have them all recorded and saved in one spot.

Unfortunately I wasn't able to attend and after watching the video I
feel like I'm on the same page, so for me it seems like a brilliant
idea! I think recordings are very beneficial in cross-timezone
community.
__
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] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

[Rich Megginson]

On 10/07/2015 03:54 PM, Matt Fischer wrote:


I thought the agreement was that default would be assumed so that we 
didn't break backwards compatibility?




puppet-heat had already started using domains, and had already written 
their code based on the implementation where an unqualified name was 
allowed if it was unique among all domains.  That code will need to 
change to specify the domain.  Any other code that was already using 
domains (which I'm assuming is hardly any, if at all) will also need to 
change.



On Oct 7, 2015 10:35 AM, "Rich Megginson" > wrote:


tl;dr You must specify a domain when using domain scoped resources.

If you are using domains with puppet-keystone, there is a proposed
patch that will break backwards compatibility.

https://review.openstack.org/#/c/226624/ Replace indirection calls

"Indirection calls are replaced with #fetch_project and
#fetch_user methods
using python-openstackclient (OSC).

Also removes the assumption that if a resource is unique within a
domain space
then the domain doesn't have to be specified."

It is the last part which is causing backwards compatibility to be
broken.  This patch requires that a domain scoped resource _must_
be qualified with the domain name if _not_ in the 'Default'
domain.  Previously, you did not have to qualify a resource name
with the domain if the name was unique in _all_ domains.  The
problem was this code relied heavily on puppet indirection, and
was complex and difficult to maintain.  We removed it in favor of
a very simple implementation: if the name is not qualified with a
domain, it must be in the 'Default' domain.

Here is an example from puppet-heat - the 'heat_admin' user has
been created in the 'heat_stack' domain previously.

ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
})

This means "assign the user 'heat_admin' in the unspecified domain
to have the domain scoped role 'admin' in the 'heat_stack'
domain". It is a domain scoped role, not a project scoped role,
because in "@::heat_stack" there is no project, only a domain.
Note that the domain for the 'heat_admin' user is unspecified. In
order to specify the domain you must use
'heat_admin::heat_stack@::heat_stack'. This is the recommended fix
- to fully qualify the user + domain.

The breakage manifests itself like this, from the logs::

2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack
user show --format shell heat_admin --domain Default'
2015-10-02 06:07:40.505 | Error:
/Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]:
Could not evaluate: No user heat_admin with domain  found

This is from the keystone_user_role code. Since the role user was
specified as 'heat_admin' with no domain, the keystone_user_role
code looks for 'heat_admin' in the 'Default' domain and can't find
it, and raises an error.

Right now, the only way to specify the domain is by adding
'::domain_name' to the user name, as
'heat_admin::heat_stack@::heat_stack'.  Sofer is working on a way
to add the domain name as a parameter of keystone_user_role -
https://review.openstack.org/226919 - so in the near future you
will be able to specify the resource like this:


ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
  'user_domain_name' => 'heat_stack',
})


__
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] [Neutron][Kuryr] Kuryr Open Tasks

[Antoni Segura Puimedon]

On Wed, Oct 7, 2015 at 9:40 PM, Egor Guz  wrote:

> Gal, thx I a lot. I have created the pool
> http://doodle.com/poll/udpdw77evdpnsaq6 where everyone can vote for time
> slot.
>

Thanks Egor


>
> —
> Egor
>
>
> From: Gal Sagie mailto:gal.sa...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Date: Tuesday, October 6, 2015 at 12:08
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>,
> Eran Gampel mailto:eran.gam...@huawei.com>>,
> Antoni Segura Puimedon mailto:t...@midokura.com>>,
> Irena Berezovsky mailto:ir...@midokura.com>>,
> Mohammad Banikazemi mailto:m...@us.ibm.com>>, Taku Fukushima
> mailto:tfukush...@midokura.com>>, Salvatore
> Orlando mailto:salv.orla...@gmail.com>>, sky fei <
> feisk...@gmail.com>, "
> digambarpati...@yahoo.co.in" <
> digambarpati...@yahoo.co.in>,
> Digambar Patil mailto:digambar...@gmail.com>>
> Subject: [openstack-dev] [Neutron][Kuryr] Kuryr Open Tasks
>
> Hello All,
>
> I have opened a Trello board to track all Kuryr assigned tasks and their
> assignee.
> In addition to all the non assigned tasks we have defined.
>
> You can visit and look at the board here [1].
> Please email back if i missed you or any task that you are working on, or
> a task
> that you think needs to be on that list.
>
> This is only a temporary solution until we get everything organised, we
> plan to track everything with launchpad bugs (and the assigned blueprints)
>
> If you see any task from this list which doesn't have an assignee and you
> feel
> you have the time and the desire to contribute, please contact me and i
> will provide
> guideness.
>
> Thanks
> Gal
>
> [1] https://trello.com/b/cbIAXrQ2/project-kuryr
>
__
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] We should move strutils.mask_password back into oslo-incubator

[Davanum Srinivas]

Matt,

My vote is for #1, as we should kill oslo-incubator in Mitaka.

Thanks,
Dims

On Wed, Oct 7, 2015 at 3:38 PM, Matt Riedemann 
wrote:

> Here's why:
>
> https://review.openstack.org/#/c/220622/
>
> That's marked as fixing an OSSA which means we'll have to backport the fix
> in nova but it depends on a change to strutils.mask_password in oslo.utils,
> which required a release and a minimum version bump in global-requirements.
>
> To backport the change in nova, we either have to:
>
> 1. Copy mask_password out of oslo.utils and add it to nova in the backport
> or,
>
> 2. Backport the oslo.utils change to a stable branch, release it as a
> patch release, bump minimum required version in stable g-r and then
> backport the nova change and depend on the backported oslo.utils stable
> release - which also makes it a dependent library version bump for any
> packagers/distros that have already frozen libraries for their stable
> releases, which is kind of not fun.
>
> So I'm thinking this is one of those things that should ultimately live in
> oslo-incubator so it can live in the respective projects. If mask_password
> were in oslo-incubator, we'd have just fixed and backported it there and
> then synced to nova on master and stable branches, no dependent library
> version bumps required.
>
> Plus I miss the good old days of reviewing oslo-incubator syncs...(joking
> of course).
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
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] [tc] naming N and O releases nowish

[Matthias Runge]

On Wed, Oct 07, 2015 at 03:02:47PM +0200, Christian Berendt wrote:
> Is this list correct?
> 
> M = Tokyo
> N = Atlanta
> O = Barcelona
> P = ?

IIRC N should be Austin instead of Atlanta.
-- 
Matthias Runge 

__
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] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

[Matt Fischer]

I thought the agreement was that default would be assumed so that we didn't
break backwards compatibility?
On Oct 7, 2015 10:35 AM, "Rich Megginson"  wrote:

> tl;dr You must specify a domain when using domain scoped resources.
>
> If you are using domains with puppet-keystone, there is a proposed patch
> that will break backwards compatibility.
>
> https://review.openstack.org/#/c/226624/ Replace indirection calls
>
> "Indirection calls are replaced with #fetch_project and #fetch_user methods
> using python-openstackclient (OSC).
>
> Also removes the assumption that if a resource is unique within a domain
> space
> then the domain doesn't have to be specified."
>
> It is the last part which is causing backwards compatibility to be
> broken.  This patch requires that a domain scoped resource _must_ be
> qualified with the domain name if _not_ in the 'Default' domain.
> Previously, you did not have to qualify a resource name with the domain if
> the name was unique in _all_ domains.  The problem was this code relied
> heavily on puppet indirection, and was complex and difficult to maintain.
> We removed it in favor of a very simple implementation: if the name is not
> qualified with a domain, it must be in the 'Default' domain.
>
> Here is an example from puppet-heat - the 'heat_admin' user has been
> created in the 'heat_stack' domain previously.
>
> ensure_resource('keystone_user_role',  'heat_admin@::heat_stack", {
>   'roles' => ['admin'],
> })
>
> This means "assign the user 'heat_admin' in the unspecified domain to have
> the domain scoped role 'admin' in the 'heat_stack' domain". It is a domain
> scoped role, not a project scoped role, because in "@::heat_stack" there is
> no project, only a domain. Note that the domain for the 'heat_admin' user
> is unspecified. In order to specify the domain you must use
> 'heat_admin::heat_stack@::heat_stack'. This is the recommended fix - to
> fully qualify the user + domain.
>
> The breakage manifests itself like this, from the logs::
>
> 2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack user
> show --format shell heat_admin --domain Default'
> 2015-10-02 06:07:40.505 | Error:
> /Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]:
> Could not evaluate: No user heat_admin with domain  found
>
> This is from the keystone_user_role code. Since the role user was
> specified as 'heat_admin' with no domain, the keystone_user_role code looks
> for 'heat_admin' in the 'Default' domain and can't find it, and raises an
> error.
>
> Right now, the only way to specify the domain is by adding '::domain_name'
> to the user name, as 'heat_admin::heat_stack@::heat_stack'.  Sofer is
> working on a way to add the domain name as a parameter of
> keystone_user_role - https://review.openstack.org/226919 - so in the near
> future you will be able to specify the resource like this:
>
>
> ensure_resource('keystone_user_role',  'heat_admin@::heat_stack", {
>   'roles' => ['admin'],
>   'user_domain_name' => 'heat_stack',
> })
>
>
> __
> 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] [Neutron][Kuryr] Kuryr Open Tasks

[Egor Guz]

Gal, thx I a lot. I have created the pool 
http://doodle.com/poll/udpdw77evdpnsaq6 where everyone can vote for time slot.

—
Egor


From: Gal Sagie mailto:gal.sa...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, October 6, 2015 at 12:08
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
Eran Gampel mailto:eran.gam...@huawei.com>>, Antoni 
Segura Puimedon mailto:t...@midokura.com>>, Irena Berezovsky 
mailto:ir...@midokura.com>>, Mohammad Banikazemi 
mailto:m...@us.ibm.com>>, Taku Fukushima 
mailto:tfukush...@midokura.com>>, Salvatore Orlando 
mailto:salv.orla...@gmail.com>>, sky fei 
mailto:feisk...@gmail.com>>, 
"digambarpati...@yahoo.co.in" 
mailto:digambarpati...@yahoo.co.in>>, Digambar 
Patil mailto:digambar...@gmail.com>>
Subject: [openstack-dev] [Neutron][Kuryr] Kuryr Open Tasks

Hello All,

I have opened a Trello board to track all Kuryr assigned tasks and their 
assignee.
In addition to all the non assigned tasks we have defined.

You can visit and look at the board here [1].
Please email back if i missed you or any task that you are working on, or a task
that you think needs to be on that list.

This is only a temporary solution until we get everything organised, we plan to 
track everything with launchpad bugs (and the assigned blueprints)

If you see any task from this list which doesn't have an assignee and you feel
you have the time and the desire to contribute, please contact me and i will 
provide
guideness.

Thanks
Gal

[1] https://trello.com/b/cbIAXrQ2/project-kuryr

__
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] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

[Devananda van der Veen]

Ramesh,

I thought about your points over night, and then looked at our in-tree
driver code from stable/kilo and asked myself, "what if this driver was out
of tree?" They'd all have broken -- for very similar reasons as what I
encountered with my demo driver.

When we split the boot and deploy interfaces, we kept compatibility only at
the boundary between ConductorManager and the Driver class. That's all we
set out to do, because that's all we defined the interface to be. I can
accept that, but I'd like us to think about whether the driver interface:
a) is merely the interfaces defined in ironic/drivers/base.py, as we
previously defined, or
b) also includes one or more of the hardware-agnostic interface
implementations (eg, PXEBoot, AgentDeploy, AgentRAID, inspector.Inspector)

As recent experience has taught me, these classes provide essential
primitives for building new hardware drivers. If we want to support
development of hardware drivers out of tree, but we don't want to include
(b) in our definition of the API, then we are signalling that such drivers
must be implemented entirely out of tree (iow, they're not allowed to
borrow *any* functionality from ironic/drivers/modules/*).

And if we're signalling that, and someone goes and implements such a driver
and then later wants to propose it upstream -- how will we feel about
accepting a completely alternative implementation of, say, the pxe boot
driver?

Curious what others think...
-deva


On Mon, Oct 5, 2015 at 11:35 PM, Ramakrishnan G <
rameshg87.openst...@gmail.com> wrote:

>
> Well it's nice to fix, but I really don't know if we should be fixing it.
> As discussed in one of the Ironic meetings before, we might need to define
> what is our driver API or SDK or DDK or whatever we choose to call it .
> Please see inline for my thoughts.
>
> On Tue, Oct 6, 2015 at 5:54 AM, Devananda van der Veen <
> devananda@gmail.com> wrote:
>
>> tldr; the boot / deploy interface split we did broke an out of tree
>> driver. I've proposed a patch. We should get a fix into stable/liberty too.
>>
>> Longer version...
>>
>> I was rebasing my AMTTool driver [0] on top of master because the in-tree
>> one still does not work for me, only to discover that my driver suddenly
>> failed to deploy. I have filed this bug
>>   https://bugs.launchpad.net/ironic/+bug/1502980
>> because we broke at least one out of tree driver (mine). I highly suspect
>> we've broken many other out of tree drivers that relied on either the
>> PXEDeploy or AgentDeploy interfaces that were present in Kilo release. Both
>> classes in Liberty are making explicit calls to "task.driver.boot" -- and
>> kilo-era driver classes did not define this interface.
>>
>
>
> I would like to think more about what really our driver API is ? We have a
> couple of well defined interfaces in ironic/drivers/base.py which people
> may follow, implement an out-of-tree driver, make it a stevedore entrypoint
> and get it working with Ironic.
>
> But
>
> 1) Do we promise them that in-tree implementations of these interfaces
> will always exist.  For example in boot/deploy work done in Liberty, we
> removed the class PxeDeploy [1].  It actually got broken down to PXEBoot
> and ISCSIDeploy.  In the first place, do we guarantee that they will exist
> for ever in the same place with the same name ? :)
>
> 2) Do we really promise the in-tree implementations of these interfaces
> will behave the same way ? For example, the broken stuff AgentDeploy which
> is an implementation of our DeployInterface.  Do we guarantee that this
> implementation will always keep doing what ever it was every time code is
> rebased ?
>
> [1]
> https://review.openstack.org/#/c/166513/19/ironic/drivers/modules/pxe.py
>
>
>
>>
>> I worked out a patch for the AgentDeploy driver and have proposed it here:
>>   https://review.openstack.org/#/c/231215/1
>>
>> I'd like to ask folks to review it quickly -- we should fix this ASAP and
>> backport it to stable/liberty before the next release, if possible. We
>> should also make a similar fix for the PXEDeploy class. If anyone gets to
>> this before I do, please reply here and let me know so we don't duplicate
>> effort.
>>
>
>
> This isn't going to be as same as above as there is no longer a PXEDeploy
> class any more.  We might need to create a new class PXEDeploy which
> probably inherits from ISCSIDeploy and has task.driver.boot worked around
> in the same way as the above patch.
>
>
>
>>
>> Also, Jim already spotted something in the review that is a bit
>> concerning. It seems like the IloVirtualMediaAgentVendorInterface class
>> expects the driver it is attached to *not* to have a boot interface and
>> *not* to call boot.clean_up_ramdisk. Conversely, other drivers may be
>> expecting AgentVendorInterface to call boot.clean_up_ramdisk -- since that
>> was its default behavior in Kilo. I'm not sure what the right way to fix
>> this is, but I lean towards updating the in-tree driver so we remain
>> backwards-

[openstack-dev] We should move strutils.mask_password back into oslo-incubator

[Matt Riedemann]

Here's why:

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

That's marked as fixing an OSSA which means we'll have to backport the 
fix in nova but it depends on a change to strutils.mask_password in 
oslo.utils, which required a release and a minimum version bump in 
global-requirements.


To backport the change in nova, we either have to:

1. Copy mask_password out of oslo.utils and add it to nova in the 
backport or,


2. Backport the oslo.utils change to a stable branch, release it as a 
patch release, bump minimum required version in stable g-r and then 
backport the nova change and depend on the backported oslo.utils stable 
release - which also makes it a dependent library version bump for any 
packagers/distros that have already frozen libraries for their stable 
releases, which is kind of not fun.


So I'm thinking this is one of those things that should ultimately live 
in oslo-incubator so it can live in the respective projects. If 
mask_password were in oslo-incubator, we'd have just fixed and 
backported it there and then synced to nova on master and stable 
branches, no dependent library version bumps required.


Plus I miss the good old days of reviewing oslo-incubator 
syncs...(joking of course).


--

Thanks,

Matt Riedemann


__
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] Scheduler proposal

[Zane Bitter]

On 07/10/15 13:36, Ed Leafe wrote:

Several months ago I proposed an experiment [0] to see if switching the data 
model for the Nova scheduler to use Cassandra as the backend would be a 
significant improvement as opposed to the current design using multiple copies 
of the same data (compute_node in MySQL DB, HostState in memory in the 
scheduler, ResourceTracker in memory in the compute node) and trying to keep 
them all in sync via passing messages.


It seems to me (disclaimer: not a Nova dev) that which database to use 
is completely irrelevant to your proposal, which is really about moving 
the scheduling from a distributed collection of Python processes with 
ad-hoc (or sometimes completely missing) synchronisation into the 
database to take advantage of its well-defined semantics. But you've 
framed it in such a way as to guarantee that this never gets discussed, 
because everyone will be too busy arguing about whether or not Cassandra 
is better than Galera.


cheers,
Zane.

__
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] [nova] It's time to update the Liberty release notes

[Steve Gordon]

- Original Message -
> From: "Matt Riedemann" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> We need to go through the changes which were tagged for release notes
> [1]. Generally this means anything with the UpgradeImpact tag but can
> also mean things with DocImpact.
> 
> Here are the commits in liberty that had the UpgradeImpact tag:
> 
> mriedem@ubuntu:~/git/nova$ git log --oneline -i --grep UpgradeImpact
> stable/kilo..stable/liberty
> 0b49934 CONF.allow_resize_to_same_host should check only once in controller
> 4a9e14a Update ComputeNode values with allocation ratios in the RT
> 4a18f7d api: use v2.1 only in api-paste.ini
> 11507ee api: deprecate the concept of extensions in v2.1
> 9c91781 Add missing rules in policy.json
> 1b8a2e0 Adding user_id handling to keypair index, show and create api calls
> 0283234 libvirt: Always default device names at boot
> 725c54e Remove db layer hard-code permission checks for
> quota_class_create/update
> 1dbb322 Remove db layer hard-code permission checks for
> quota_class_get_all_by_name
> 4d6a50a Remove db layer hard-code permission checks for floating_ip_dns
> 55e63f8 Allow non-admin to list all tenants based on policy
> 92807d6 Remove redundant policy check from security_group_default_rule
> 2a01a1b Remove hv_type translation shim for powervm
> dcd4be6 Remove db layer hard-code permission checks for quota_get_all_*
> 06e6056 Remove cell policy check
> d03b716 libvirt: deprecate libvirt version usage < 0.10.2
> 5309120 Update kilo version alias
> 
> So if you own on of those, please up the release notes.
> 
> Here are the DocImpact changes:
> 
> mriedem@ubuntu:~/git/nova$ git log --oneline -i --grep DocImpact
> stable/kilo..stable/liberty
> bc6f30d Give instance default hostname if hostname is empty
> 4ee4f9f RT: track evacuation migrations
> 9095b36 Expose keystoneclient's session and auth plugin loading parameters
> 4a9e14a Update ComputeNode values with allocation ratios in the RT
> 4a18f7d api: use v2.1 only in api-paste.ini
> 11507ee api: deprecate the concept of extensions in v2.1
> 45d1e3c Expose VIF net-id attribute in os-virtual-interfaces
> 9d353e5 libvirt: take account of disks in migration data size
> 17e5911 Add deprecated_for_removal parm for deprecated neutron_ops
> 95940cc Don't allow instance to overcommit against itself
> 9cd9e66 Add rootwrap daemon mode support
> c250aca Allow compute monitors in different namespaces
> 434ce2a Added processing /compute URL
> 2c0a306 Limit parallel live migrations in progress
> da33ab4 libvirt: set caps on maximum live migration time
> 07c7e5c libvirt: support management of downtime during migration
> 60d08e6 Add documentation for the nova-cells command.
> ae5a329 libvirt:Rsync remote FS driver was added
> 9a09674 libvirt: enable virtio-net multiqueue
> 8a7b1e8 :Add documentation for the nova-idmapshift command.
> bf91d9f Added missed '-' to the rest_api_version_history.rst
> 1b8a2e0 Adding user_id handling to keypair index, show and create api calls
> 622a845 Metadata: support proxying loadbalancers
> 2f7403b VMware: map one nova-compute to one VC cluster
> ace11d3 VMware: add serial port device
> ab35779 Handle SSL termination proxies for version list
> 6739df7 Include DiskFilter in the default list
> 5e5ef99 VMware: Add support for swap disk
> 49a572a Show 'locked' information in server details
> 4252420 VMware: add resource limits for disk
> f1f46a0 VMware: Resource limits for memory
> 7aec88c VMware: add support for cores per socket
> bc3b6cc libvirt: rename parallels driver to virtuozzo
> 95f1d47 Add console allowed origins setting
> d0ee3ab libvirt:Add a driver API to inject an NMI
> 50c8f93 Add MKS console support
> abf20cd Execute _poll_shelved_instances only if shelved_offload_time is > 0
> 973f312 Use stevedore for loading monitor extensions
> 9260ea1 Include project_id in instance metadata.
> d9c696a Make evacuate leave a record for the source compute host to process
> 6fe967b Cells: add instance cell registration utility to nova-manage
> 93a5a67 Removed extra '-' from rest_api_version_history.rst
> bad76e6 VMware: convert driver to use nova.objects.ImageMeta
> 56feb2b Add microversion to allow server search option ip6 for non-admin
> 55e63f8 Allow non-admin to list all tenants based on policy
> 92807d6 Remove redundant policy check from security_group_default_rule
> b06867c neutron: remove deprecated allow_duplicate_networks config option
> 5793d56 cells: remove deprecated mute_weight_value option
> 8237666 VMware: verify vCenter server certificate
> b9bae02 fix "down" nova-compute service spuriously marked as "up"
> 66e1427 Add AggregateTypeAffinityFilter multi values support
> f1a0d85 Cleanups for pci stats in preparation for RT using ComputeNode
> 27e7871 VMware: enforce minimum support VC version
> 438a48d Remove db layer hard-code permission checks for v2.1 cells
> ad8d50f Add policy to cover snapshotting of volume backed instances
> 5c521e7 libvirt: depr

Re: [openstack-dev] Scheduler proposal

[Joshua Harlow]

Just a question,

Why cassandra?

I'm curious what drew u to using that for an experiment?

/me not saying its a bad choice, just curious...

Ed Leafe wrote:

Several months ago I proposed an experiment [0] to see if switching the data 
model for the Nova scheduler to use Cassandra as the backend would be a 
significant improvement as opposed to the current design using multiple copies 
of the same data (compute_node in MySQL DB, HostState in memory in the 
scheduler, ResourceTracker in memory in the compute node) and trying to keep 
them all in sync via passing messages. It was discussed at the Nova mid-cycle, 
and while there was certainly not an immediate rejection, it was felt very 
strongly that there was too much work for us to focus on, and such an 
experiment, no matter how potentially beneficial, would prevent us from 
accomplishing the tasks we had undertaken for Liberty. And, as disappointed as 
I was, I had to agree. So I promised that I would write up my ideas on why I 
thought that such an experiment was worthwhile.

I've finally gotten around to finishing writing up that proposal [1], and I'd 
like to hope that it would be the basis for future discussions about addressing 
some of the underlying issues that exist in OpenStack for historical reasons, 
and how we might rethink these choices today. I'd prefer comments and 
discussion here on the dev list, so that all can see your ideas, but I will be 
in Tokyo for the summit, and would also welcome some informal discussion there, 
too.

-- Ed Leafe

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069593.html
[1] http://blog.leafe.com/reimagining_scheduler/

__
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-dev] [fuel] Last call: Team Structure policy document

[Dmitry Borodaenko]

All,

Looks like we have a consensus on the Team Structure policy [0], unless
there are objections in the next 24 hours, I propose to merge it
tomorrow. We can always update it with more clarifications and typo
fixes later, but for now we need this policy merged to start the
Component Leads elections.

[0] https://review.openstack.org/225376

-- 
Dmitry Borodaenko

__
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] [Neutron] Prepare for expiration bugs without activity

[Armando M.]

On 7 October 2015 at 07:50, Ihar Hrachyshka  wrote:

> > On 06 Oct 2015, at 19:26, ZZelle  wrote:
> >
> > Hi everyone,
> >
> >
> > As decided during last neutron meeting[1], we try to let Launchpad
> expire outdated bugs.
> >
> > The status of every bug without activity in last year has been set to
> Incomplete and their assignee/milestone unset in order to let Launchpad
> expire them in 60 days[2].
> >
> > It gives us a 60-days window to "revive" expirable bugs[3] which are
> (sadly :)) still valid (by changing their status).
> >
>
> I went thru the whole list of expirable bugs and moved some of them back
> to Confirmed where it seems to apply, plus added tags. I believe now we
> should not loose anything valuable.
>

Thanks Ihar, much appreciated. I'll have another pass too.

>
> Ihar
>
> __
> 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]

[David Chadwick]

On 07/10/2015 18:29, Adam Young wrote:
> On 10/07/2015 11:51 AM, Adam Young wrote:
>> Send me what you have, and I will post it as a Work in progress review
>> against Horizon.  That way at least it will be available for others to
>> look at and potentially adopt.
> 
> Review has been posted here
> https://review.openstack.org/232114
> 

thanks Adam

> 
> I made a best guess as far as where it it should be placed in the source
> tree.  I have not tested the code.
> 
> David and I have both signed the CLA. I am fairly certon Anton did not. 
> It would be easiest for OpenStack to accept this code if he did, as
> there would be no question about copyright or licensing.

Legally speaking it is not necessary, since any code produced by
students as part of their degree course does not belong to them.
However, it would be courteous of us to ask him, so I have done this.

> 
> David also provided me with a PDF version of Anton's dissertation. I do
> not know what the status of that document, but it would be a great
> resource to anyone that wants to take this code and get it integrated
> into Horizon.

This can be made publicly available after the exam board next month.
Until then I will give out personal copies for private study.

regards

David

> 
> This does not look like a radical stretch.  It would be a decent
> opportunity for anyone looking to get involved with OpenStack to step
> into something immediately.
> 
> 
> 
> 
>>
>>
>>
>> On 10/07/2015 11:37 AM, David Chadwick wrote:
>>> Hi Douglas
>>>
>>> we are happy for you (or someone else) to submit the code in 3 names:
>>> theirs, mine and Anton's. Then this third person can do all the work
>>> necessary to get it approved. In this way it is legitimate, since the
>>> third person will have contributed to the overall effort.
>>>
>>> I dont have any spare time yet for another month or so. After that I
>>> could submit it, but having never done it before for Horizon, there will
>>> be a big learning curve. And I might not have time to learn it
>>>
>>> regards
>>>
>>> David
>>>
>>> On 07/10/2015 16:05, Douglas Fish wrote:
 Hi David,
   This sounds like a great set of code, I'm sure we are going to
 realize
 we want it sooner or later! Unfortunately I can't consume code in this
 way (I can't propose code written by somebody else) and I can't spend
 significant time on it right now.
   Would you or Anton be willing to propose whatever code and
 documentation
 you have to Horizon? It doesn't have to be complete; it doesn't need to
 have grammar cleaned up or anything like that. You could mark it as a
 "Work in progress", and make it clear in the commit message that you
 aren't planning further work on this, so the patch is available for
 adoption. That way somebody else may be able to pick this up and
 work on
 it in the future, but Anton could get credit for the work he has done.

 Doug Fish

  - Original message -
  From: David Chadwick 
  To: OpenStack Development Mailing List
  
  Cc:
  Subject: [openstack-dev] [horizon][keystone]
  Date: Tue, Oct 6, 2015 2:13 PM
Dear All

  One of my students, Anton Brida, has developed an Attribute
 Mapping GUI
  for Horizon as part of his MSc project. Attribute mappings are an
  essential, though complex, part of federated Keystone.
 Currently they
  can only be created as JSON objects in the config file. The
 Horizon code
  allows them to be dynamically created via an easy to use GUI.

  Since Anton has now left the university for full time
 employment, he is
  not able to go through the process of submitting his code to
 the next
  release of Horizon. His design however was submitted to
 InVision and
  commented on by various people at the time of the development.

  I am now looking for someone who would like to take a copy of
 this code
  and go through the process of submitting this to the next
 release of
  Horizon. I have a copy of Anton's MSc dissertation as well which
  explains the work that he has done.

  All the attribute mapping features are supported in Anton's code
  (groups, users, direct mapping, multiple attribute values etc.)
  However the whitelist/blacklist feature is not, since this was
 not fully
  incorporated into Keystone when Anton was doing his
 implementation. (I
  am still not sure if it has been.)

  The code has a couple of known bugs:

  1. when a user tries to enter an email address into an
 attribute value
  (i.e. usern...@example.com) and saves the mapping rule into the
  database, after reloading the new list of mappings rules the
 interface
  does not work as intended. The particular

[openstack-dev] [Cinder] Google Hangout recording of volume manger locks

[Walter A. Boring IV]

Hello folks,
  I just wanted to post up the YouTube link for the video hangout that 
the Cinder team just had.


We had a good discussion about the local file locks in the volume 
manager and how it affects the interaction
of Nova with Cinder in certain cases.  We are trying to iron out how to 
proceed ahead with removing the
volume manager locks in a way that doesn't break the world.  The hope of 
this is to eventually allow Cinder

to run active/active HA c-vol services.

The Youtube.com link for the recording is here on my personal account:
https://www.youtube.com/watch?v=D_iXpNcWDv8


We discussed several things in the meeting:
* The etherpad that was used as a basis for discussion:
https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
* What to do with the current volume manager locks and how do we remove 
them?

* How do we move forward with checking 'ING' states for volume actions?
* What is the process for moving forward with the compare/swap patches 
that Gorka has in gerrit.



Action Items:
*  We agreed to take a deeper look into the main compare/swap changes 
that Gorka has in gerrit and see if we can get those to land.

  * https://review.openstack.org/#/c/205834/
  * https://review.openstack.org/#/c/218012/
* Gorka is to update the patches and add the references to the 
specs/blueprints for reference.
* Gorka is going to post up follow up patch sets to test the removal of 
each lock and see if it is sufficient to remove each individual lock.



Follow up items:
* Does it make sense for the community to create an OpenStack Cinder 
youtube account, where the PTL owns the account, and we run
each of our google hangouts through that.  The advantage of this is to 
allow the community to participate openly, as well as record each of
our Cinder hangouts for folks that can't attend the live event.  We 
could use this account for the meetups as well as the conference sessions,

and have them all recorded and saved in one spot.


Cheers,
Walt


__
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] Scheduler proposal

[Ed Leafe]

Several months ago I proposed an experiment [0] to see if switching the data 
model for the Nova scheduler to use Cassandra as the backend would be a 
significant improvement as opposed to the current design using multiple copies 
of the same data (compute_node in MySQL DB, HostState in memory in the 
scheduler, ResourceTracker in memory in the compute node) and trying to keep 
them all in sync via passing messages. It was discussed at the Nova mid-cycle, 
and while there was certainly not an immediate rejection, it was felt very 
strongly that there was too much work for us to focus on, and such an 
experiment, no matter how potentially beneficial, would prevent us from 
accomplishing the tasks we had undertaken for Liberty. And, as disappointed as 
I was, I had to agree. So I promised that I would write up my ideas on why I 
thought that such an experiment was worthwhile.

I've finally gotten around to finishing writing up that proposal [1], and I'd 
like to hope that it would be the basis for future discussions about addressing 
some of the underlying issues that exist in OpenStack for historical reasons, 
and how we might rethink these choices today. I'd prefer comments and 
discussion here on the dev list, so that all can see your ideas, but I will be 
in Tokyo for the summit, and would also welcome some informal discussion there, 
too.

-- Ed Leafe

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069593.html
[1] http://blog.leafe.com/reimagining_scheduler/


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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]

[Adam Young]

On 10/07/2015 11:51 AM, Adam Young wrote:
Send me what you have, and I will post it as a Work in progress review 
against Horizon.  That way at least it will be available for others to 
look at and potentially adopt.


Review has been posted here
https://review.openstack.org/232114


I made a best guess as far as where it it should be placed in the source 
tree.  I have not tested the code.


David and I have both signed the CLA. I am fairly certon Anton did not.  
It would be easiest for OpenStack to accept this code if he did, as 
there would be no question about copyright or licensing.


David also provided me with a PDF version of Anton's dissertation. I do 
not know what the status of that document, but it would be a great 
resource to anyone that wants to take this code and get it integrated 
into Horizon.


This does not look like a radical stretch.  It would be a decent 
opportunity for anyone looking to get involved with OpenStack to step 
into something immediately.









On 10/07/2015 11:37 AM, David Chadwick wrote:

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:

Hi David,
  This sounds like a great set of code, I'm sure we are going to 
realize

we want it sooner or later! Unfortunately I can't consume code in this
way (I can't propose code written by somebody else) and I can't spend
significant time on it right now.
  Would you or Anton be willing to propose whatever code and 
documentation

you have to Horizon? It doesn't have to be complete; it doesn't need to
have grammar cleaned up or anything like that. You could mark it as a
"Work in progress", and make it clear in the commit message that you
aren't planning further work on this, so the patch is available for
adoption. That way somebody else may be able to pick this up and 
work on

it in the future, but Anton could get credit for the work he has done.

Doug Fish

 - Original message -
 From: David Chadwick 
 To: OpenStack Development Mailing List
 
 Cc:
 Subject: [openstack-dev] [horizon][keystone]
 Date: Tue, Oct 6, 2015 2:13 PM
   Dear All

 One of my students, Anton Brida, has developed an Attribute 
Mapping GUI

 for Horizon as part of his MSc project. Attribute mappings are an
 essential, though complex, part of federated Keystone. 
Currently they
 can only be created as JSON objects in the config file. The 
Horizon code

 allows them to be dynamically created via an easy to use GUI.

 Since Anton has now left the university for full time 
employment, he is
 not able to go through the process of submitting his code to 
the next
 release of Horizon. His design however was submitted to 
InVision and

 commented on by various people at the time of the development.

 I am now looking for someone who would like to take a copy of 
this code
 and go through the process of submitting this to the next 
release of

 Horizon. I have a copy of Anton's MSc dissertation as well which
 explains the work that he has done.

 All the attribute mapping features are supported in Anton's code
 (groups, users, direct mapping, multiple attribute values etc.)
 However the whitelist/blacklist feature is not, since this was 
not fully
 incorporated into Keystone when Anton was doing his 
implementation. (I

 am still not sure if it has been.)

 The code has a couple of known bugs:

 1. when a user tries to enter an email address into an 
attribute value

 (i.e. usern...@example.com) and saves the mapping rule into the
 database, after reloading the new list of mappings rules the 
interface
 does not work as intended. The particular reason why this is 
happening
 is yet unknown. The only way to avoid such disruption is to 
delete the
 faulty mapping rule from the table. After removing the faulty 
rule the

 interface works as intended.

 2. Some of the descriptive text needs improvement due to incorrect
 grammar.

 There is also the following suggested enhancement which can be 
added

 later:

 1. After the mapping rules are created with the GUI, when they are
 displayed, they are still in JSON format. It would be nice to 
be able to

 display the rules in a table or similar.

 If you would like to take on the job of submitting this code to 
Horizon

 for review and incorporation, please contact me

 regards

 David

__

[openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

[Rich Megginson]

tl;dr You must specify a domain when using domain scoped resources.

If you are using domains with puppet-keystone, there is a proposed patch 
that will break backwards compatibility.


https://review.openstack.org/#/c/226624/ Replace indirection calls

"Indirection calls are replaced with #fetch_project and #fetch_user methods
using python-openstackclient (OSC).

Also removes the assumption that if a resource is unique within a domain 
space

then the domain doesn't have to be specified."

It is the last part which is causing backwards compatibility to be 
broken.  This patch requires that a domain scoped resource _must_ be 
qualified with the domain name if _not_ in the 'Default' domain.  
Previously, you did not have to qualify a resource name with the domain 
if the name was unique in _all_ domains.  The problem was this code 
relied heavily on puppet indirection, and was complex and difficult to 
maintain.  We removed it in favor of a very simple implementation: if 
the name is not qualified with a domain, it must be in the 'Default' domain.


Here is an example from puppet-heat - the 'heat_admin' user has been 
created in the 'heat_stack' domain previously.


ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
})

This means "assign the user 'heat_admin' in the unspecified domain to 
have the domain scoped role 'admin' in the 'heat_stack' domain". It is a 
domain scoped role, not a project scoped role, because in 
"@::heat_stack" there is no project, only a domain. Note that the domain 
for the 'heat_admin' user is unspecified. In order to specify the domain 
you must use 'heat_admin::heat_stack@::heat_stack'. This is the 
recommended fix - to fully qualify the user + domain.


The breakage manifests itself like this, from the logs::

2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack user 
show --format shell heat_admin --domain Default'
2015-10-02 06:07:40.505 | Error: 
/Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]: 
Could not evaluate: No user heat_admin with domain  found


This is from the keystone_user_role code. Since the role user was 
specified as 'heat_admin' with no domain, the keystone_user_role code 
looks for 'heat_admin' in the 'Default' domain and can't find it, and 
raises an error.


Right now, the only way to specify the domain is by adding 
'::domain_name' to the user name, as 
'heat_admin::heat_stack@::heat_stack'.  Sofer is working on a way to add 
the domain name as a parameter of keystone_user_role - 
https://review.openstack.org/226919 - so in the near future you will be 
able to specify the resource like this:



ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
  'user_domain_name' => 'heat_stack',
})

__
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] [Manila] CephFS native driver

[Knight, Clinton]

Hi, John.  If you want to discuss this in Tokyo, I suggest you add it to
the etherpad:

https://etherpad.openstack.org/p/manila-mitaka-summit-topics


I look forward to meeting you at the Summit.  It¹d be great to see a demo
of your Ceph driver.

Clinton


On 10/7/15, 6:56 AM, "John Spray"  wrote:

>On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty 
>wrote:
>>>
>>> Currently, as you say, a share is accessible to anyone who knows the
>>> auth key (created a the time the share is created).
>>>
>>> For adding the allow/deny path, I'd simply create and remove new ceph
>>> keys for each entity being allowed/denied.
>>
>>
>> Ok, but how does that map to the existing Manila access types (IP, User,
>> Cert) ?
>
>None of the above :-)
>
>Compared with certs, the difference with Ceph is that ceph is issuing
>credentials, rather than authorizing existing credentials[1]. So
>rather than the tenant saying "Here's a certificate that Alice has
>generated and will use to access the filesystem, please authorize it",
>the tenant would say "Please authorize someone called Bob to access
>the share, and let me know the key he should use to prove he is Bob".
>
>As far as I can tell, we can't currently expose that in Manila: the
>missing piece is a way to tag that generated key onto a
>ShareInstanceAccessMapping, so that somebody with the right to read
>from the Manila API can go read Bob's key, and give it to Bob so that
>he can mount the filesystem.
>
>That's why the first-cut compromise is to create a single auth
>identity for accessing the share, and expose the key as part of the
>share's export location.  It's then the user application's job to
>share out that key to whatever hosts need to access it.  The lack of
>Manila-mediated 'allow' is annoying but not intrinsically insecure.
>The security problem with this approach is that we're not providing a
>way to revoke/rotate the key without destroying the share.
>
>So anyway.  This might be a good topic for a conversation at the
>summit (or catch me up on the list if it's already been discussed in
>depth) -- should drivers be allowed to publish generated
>authentication tokens as part of the API for allowing access to a
>share?
>
>John
>
>
>1. Aside: We *could* do a certificate-like model if it was assumed
>that the Manila API consumer knew how to go and talk to Ceph out of
>band to generate their auth identity.  That way, they could go and
>create their auth identity in Ceph, and then ask Manila to grant that
>identity access to the share.  However, it would be pointless, because
>in ceph, anyone who can create an identity can also set the
>capabilities of it (i.e. if they can talk directly to ceph, they don't
>need Manila's permission to access the share).
>
>__
>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-dev] [kolla][release] Announcing Kolla Liberty RC1 available since 9/29

[Steven Dake (stdake)]

Hey folks,

My apologies for not sending out our release announcement for RC1 earlier.  I 
had thought I sent it, but don’t see it on the mailing list archive.


The Kolla community is pleased to announce the release of the Kolla Liberty rc1 
milestone.  This release fixes 87 bugs and implements 10 blueprints!


The Kolla Community developed the following notable features in Liberty rc1.


  *   Stable API for communicating with the Containers using JSON for 
configuration.
  *   RHEL and OSP container image building implemented.
  *   Logging using rsyslog to single log_data container
  *   Full OpenStack and Ceph integration and deployment across all services 
which have storage implementations using ceph (Cinder, Nova, Glance).
  *   Vastly improved implementation of Vagrant including libvirt integration.
  *   Murano Ansible and container implementation.
  *   Repository renamed to http://github.com/openstack/kolla.
  *   Ironic Ansible and container implementation in tech preview mode.

The following services are now stable and may be deployed multi-node via 
Ansible:

  *   Ceph implemented with storage for glance images, Nova ephermal storage, 
and cinder volumes and backups.
  *   Cinder only works with Ceph at this time.
  *   Murano works properly.
  *   Ironic ansible deployment which is selectable between either bare metal 
or virtualized flavors in Nova + Neutron (hence the tech preview).   Our long 
term goal to make this technologyfully implemented is to provide an 
implementation which allows baremetal and virtualized flavors in the same 
deployment.

We are in the home stretch of our release towards Liberty targeted for October 
15th.  Lets get a solid liberty-rc2 tagged and available on October 9th!


Regards,

- The Kolla Development Team

__
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] [kolla] Meeting cancelled due to lack of atendees

[Steven Dake (stdake)]

There were only 3 core reviewers available at the team meeting today and nobody 
outside the core review team, so the 10/7 meeting was cancelled.

I would like folks to make an effort to attend our IRC meeting on October 14th. 
 We will write our final release announcement for Liberty.  This process should 
take about  20 minutes and we can frontload it in the meeting.  This is crucial 
as the press/etc will use these release announcements to get a quick intro to 
Kolla.

A couple dates of notice:

October 9th (rc2)
October 15th (Liberty 1.0.0 tagged)

Between 9th and 15th, no backports will be done unless the bug is highly 
critical and not invasive as judged by the core reviewers.

If you have a patch for master which you think should be backported, please add 
the tag in lowercase

“backport: liberty”

My grep tools can validate the backports are completed.

Master is open for business or Mitaka.  If you have blueprints you would like 
to work on, use your kolla-drivers powers to bring them into the Mitaka-1 cycle.

Regards
-steve
__
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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Rich Megginson]

On 10/07/2015 09:08 AM, Sofer Athlan-Guyot wrote:

Rich Megginson  writes:


On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:

Rich Megginson  writes:


On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:

Gilles Dubreuil  writes:


On 30/09/15 03:43, Rich Megginson wrote:

On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:

On 15/09/15 19:55, Sofer Athlan-Guyot wrote:

Gilles Dubreuil  writes:


On 15/09/15 06:53, Rich Megginson wrote:

On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:

Hi,

Gilles Dubreuil  writes:


A. The 'composite namevar' approach:

keystone_tenant {'projectX::domainY': ... }
  B. The 'meaningless name' approach:

   keystone_tenant {'myproject': name='projectX',
domain=>'domainY',
...}

Notes:
  - Actually using both combined should work too with the domain
supposedly overriding the name part of the domain.
  - Please look at [1] this for some background between the two
approaches:

The question
-
Decide between the two approaches, the one we would like to
retain for
puppet-keystone.

Why it matters?
---
1. Domain names are mandatory in every user, group or project.
Besides
the backward compatibility period mentioned earlier, where no domain
means using the default one.
2. Long term impact
3. Both approaches are not completely equivalent which different
consequences on the future usage.

I can't see why they couldn't be equivalent, but I may be missing
something here.

I think we could support both.  I don't see it as an either/or
situation.


4. Being consistent
5. Therefore the community to decide

Pros/Cons
--
A.

I think it's the B: meaningless approach here.


   Pros
 - Easier names

That's subjective, creating unique and meaningful name don't look
easy
to me.

The point is that this allows choice - maybe the user already has some
naming scheme, or wants to use a more "natural" meaningful name -
rather
than being forced into a possibly "awkward" naming scheme with "::"

  keystone_user { 'heat domain admin user':
name => 'admin',
domain => 'HeatDomain',
...
  }

  keystone_user_role {'heat domain admin user@::HeatDomain':
roles => ['admin']
...
  }


   Cons
 - Titles have no meaning!

They have meaning to the user, not necessarily to Puppet.


 - Cases where 2 or more resources could exists

This seems to be the hardest part - I still cannot figure out how
to use
"compound" names with Puppet.


 - More difficult to debug

More difficult than it is already? :P


 - Titles mismatch when listing the resources (self.instances)

B.
   Pros
 - Unique titles guaranteed
 - No ambiguity between resource found and their title
   Cons
 - More complicated titles
My vote

I would love to have the approach A for easier name.
But I've seen the challenge of maintaining the providers behind the
curtains and the confusion it creates with name/titles and when
not sure
about the domain we're dealing with.
Also I believe that supporting self.instances consistently with
meaningful name is saner.
Therefore I vote B

+1 for B.

My view is that this should be the advertised way, but the other
method
(meaningless) should be there if the user need it.

So as far as I'm concerned the two idioms should co-exist.  This
would
mimic what is possible with all puppet resources.  For instance
you can:

   file { '/tmp/foo.bar': ensure => present }

and you can

   file { 'meaningless_id': name => '/tmp/foo.bar', ensure =>
present }

The two refer to the same resource.

Right.


I disagree, using the name for the title is not creating a composite
name. The latter requires adding at least another parameter to be part
of the title.

Also in the case of the file resource, a path/filename is a unique
name,
which is not the case of an Openstack user which might exist in several
domains.

I actually added the meaningful name case in:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074325.html


But that doesn't work very well because without adding the domain to
the
name, the following fails:

keystone_tenant {'project_1': domain => 'domain_A', ...}
keystone_tenant {'project_1': domain => 'domain_B', ...}

And adding the domain makes it a de-facto 'composite name'.

I agree that my example is not similar to what the keystone provider has
to do.  What I wanted to point out is that user in puppet should be used
to have this kind of *interface*, one where your put something
meaningful in the title and one where you put something meaningless.
The fact that the meaningful one is a compound one shouldn't matter to
the user.


There is a big blocker of making use of domain name as parameter.
The issue is the limitation of autorequire.

Because autorequire doesn't support any parameter other than the
resource type and expects the resource title (or a list of) [1].

So for instance, keystone_user requires t

[openstack-dev] Kolla meeting cancelled due to lack of atendees

[Steven Dake (stdake)]

There were only 3 core reviewers available at the team meeting today and nobody 
outside the core review team, so cancelled the meeting.

I would like folks to make an effort to attend our meeting on October 14th.  We 
will write our final release announcement for Liberty.  This process should 
take about  20 minutes and we can frontload it in the meeting.  This is crucial 
as the press/etc will use these release announcements to get a quick intro to 
Kolla.

A couple dates of notice:

October 9th (rc2)
October 15th (Liberty 1.0.0 tagged)

Between 9th and 15th, no backports will be done unless the bug is highly 
critical and not invasive as judged by the core reviewers.

If you have a patch for master which you think should be backported, please add 
the tag in lowercase

“backport: liberty”

My grep tools can validate the backports are completed.

Master is open for business or Mitaka.  If you have blueprints you would like 
to work on, use your kolla-drivers powers to bring them into the Mitaka-1 cycle.

Regards
-steve

__
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]

[David Chadwick]

Hi Adam

will do (by separate email, so that the list does not receive it)

thanks

David

On 07/10/2015 16:51, Adam Young wrote:
> Send me what you have, and I will post it as a Work in progress review
> against Horizon.  That way at least it will be available for others to
> look at and potentially adopt.
> 
> 
> 
> On 10/07/2015 11:37 AM, David Chadwick wrote:
>> Hi Douglas
>>
>> we are happy for you (or someone else) to submit the code in 3 names:
>> theirs, mine and Anton's. Then this third person can do all the work
>> necessary to get it approved. In this way it is legitimate, since the
>> third person will have contributed to the overall effort.
>>
>> I dont have any spare time yet for another month or so. After that I
>> could submit it, but having never done it before for Horizon, there will
>> be a big learning curve. And I might not have time to learn it
>>
>> regards
>>
>> David
>>
>> On 07/10/2015 16:05, Douglas Fish wrote:
>>> Hi David,
>>>   This sounds like a great set of code, I'm sure we are going to realize
>>> we want it sooner or later! Unfortunately I can't consume code in this
>>> way (I can't propose code written by somebody else) and I can't spend
>>> significant time on it right now.
>>>   Would you or Anton be willing to propose whatever code and
>>> documentation
>>> you have to Horizon? It doesn't have to be complete; it doesn't need to
>>> have grammar cleaned up or anything like that. You could mark it as a
>>> "Work in progress", and make it clear in the commit message that you
>>> aren't planning further work on this, so the patch is available for
>>> adoption. That way somebody else may be able to pick this up and work on
>>> it in the future, but Anton could get credit for the work he has done.
>>>
>>> Doug Fish
>>>
>>>  - Original message -
>>>  From: David Chadwick 
>>>  To: OpenStack Development Mailing List
>>>  
>>>  Cc:
>>>  Subject: [openstack-dev] [horizon][keystone]
>>>  Date: Tue, Oct 6, 2015 2:13 PM
>>>Dear All
>>>
>>>  One of my students, Anton Brida, has developed an Attribute
>>> Mapping GUI
>>>  for Horizon as part of his MSc project. Attribute mappings are an
>>>  essential, though complex, part of federated Keystone. Currently
>>> they
>>>  can only be created as JSON objects in the config file. The
>>> Horizon code
>>>  allows them to be dynamically created via an easy to use GUI.
>>>
>>>  Since Anton has now left the university for full time
>>> employment, he is
>>>  not able to go through the process of submitting his code to the
>>> next
>>>  release of Horizon. His design however was submitted to InVision
>>> and
>>>  commented on by various people at the time of the development.
>>>
>>>  I am now looking for someone who would like to take a copy of
>>> this code
>>>  and go through the process of submitting this to the next
>>> release of
>>>  Horizon. I have a copy of Anton's MSc dissertation as well which
>>>  explains the work that he has done.
>>>
>>>  All the attribute mapping features are supported in Anton's code
>>>  (groups, users, direct mapping, multiple attribute values etc.)
>>>  However the whitelist/blacklist feature is not, since this was
>>> not fully
>>>  incorporated into Keystone when Anton was doing his
>>> implementation. (I
>>>  am still not sure if it has been.)
>>>
>>>  The code has a couple of known bugs:
>>>
>>>  1. when a user tries to enter an email address into an attribute
>>> value
>>>  (i.e. usern...@example.com) and saves the mapping rule into the
>>>  database, after reloading the new list of mappings rules the
>>> interface
>>>  does not work as intended. The particular reason why this is
>>> happening
>>>  is yet unknown. The only way to avoid such disruption is to
>>> delete the
>>>  faulty mapping rule from the table. After removing the faulty
>>> rule the
>>>  interface works as intended.
>>>
>>>  2. Some of the descriptive text needs improvement due to incorrect
>>>  grammar.
>>>
>>>  There is also the following suggested enhancement which can be
>>> added
>>>  later:
>>>
>>>  1. After the mapping rules are created with the GUI, when they are
>>>  displayed, they are still in JSON format. It would be nice to be
>>> able to
>>>  display the rules in a table or similar.
>>>
>>>  If you would like to take on the job of submitting this code to
>>> Horizon
>>>  for review and incorporation, please contact me
>>>
>>>  regards
>>>
>>>  David
>>>
>>> 
>>> __
>>>
>>>  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] [neutron] New cycle started. What are you up to, folks?

[Henry Gessau]

Thanks Ihar. Here is what I plan to work on, or hope to help out with:

Continue working on alembic to support online migrations.

The alembic migrations seem to be a mysterious thing to many developers. I plan
to improve the devref documentation around this. The --autogenerate of
revisions, in particular, should work smoothly for developers and across the
various neutron stadium projects.

In Liberty each Neutron sub-project has a separate alembic environment and that
prevents sub-projects from having migration dependencies on other sub-projects.
So I will fix that.

Neutron's DB transaction issues at scale are a problem. I am not an expert in
this area, but would like to co-ordinate an effort with Mike Bayer and experts
from Neutron and other OpenStack projects to characterize the issues and plan
some solutions and/or best practices.

Neutron's IPv6 support is now quite extensive, but there are still some loose
ends like router HA support, and being able to use IPv6 for API/management. I
will help to co-ordinate the IPv6 updates in Mitaka. I will also sync up with
the state of IPv6 support in the *aaS and stadium repos and help out with IPv6
efforts there.

I think Salvatore's proposal [1] for API evolution is extremely important to
Neutron's future and I would like to see it happen this cycle. I will help out
where I can.

I want to help (mostly by reviewing and testing) the effort to make Neutron
support Python 3.

Always willing to help with, review, and improve Neutron's tests and testing
strategies.

[1] https://review.openstack.org/136760

-- 
Henry


On Thu, Oct 01, 2015, Ihar Hrachyshka  wrote:
> Hi all,
> 
> I talked recently with several contributors about what each of us plans for
> the next cycle, and found it’s quite useful to share thoughts with others,
> because you have immediate yay/nay feedback, and maybe find companions for
> next adventures, and what not. So I’ve decided to ask everyone what you see
> the team and you personally doing the next cycle, for fun or profit.
> 
> That’s like a PTL nomination letter, but open to everyone! :) No commitments,
> no deadlines, just list random ideas you have in mind or in your todo lists,
> and we’ll all appreciate the huge pile of awesomeness no one will ever have
> time to implement even if scheduled for Xixao release.
> 
> To start the fun, I will share my silly ideas in the next email.
> 
> Ihar


__
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] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

[Doug Hellmann]

Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400:
> 
> Using `message flavor` works for me, and having two words is just fine.

It might even be good to change "flavor" to "server flavor" (keeping
flavor as a backwards-compatible alias, of course).

Doug

> 
> I'm in the process of collecting all of the existing "object" works are
> putting them online, there's a lot of them. Hopefully this will reduce the
> collisions in the future.
> 
> Thanks,
> 
> Steve Martinelli
> OpenStack Keystone Core
> 
> 
> 
> From:Shifali Agrawal 
> To:openstack-dev@lists.openstack.org
> Date:2015/10/06 03:40 PM
> Subject:[openstack-dev] [Zaqar][cli][openstack-client] conflict in nova
> flavor and zaqar flavor
> 
> 
> 
> Greetings,
> 
> I am implementing cli commands for Zaqar flavors, the command should be
> like:
> 
> "openstack flavor "
> 
> But there is already same command present for Nova flavors. After
> discussing with Zaqar devs we thought to change all zaqar commands such
> that they include `message` word after openstack, thus above Zaqar flavor
> command will become:
> 
> "openstack message flavor "
> 
> Does openstack-client devs have something to say for this? Or they also
> feel its good to move with adding `message` word to all Zaqar cli
> commands?
> 
> Already existing Zaqar commands will work with get a deprecation
> message/warning and also I will implement them all to work with `message`
> word, and all new commands will be implement so that they work only with
> `message` word.

__
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] conflicting names in python-openstackclient: could we have some exception handling please?

[Sean Dague]

On 10/07/2015 10:50 AM, Dean Troyer wrote:
> On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown  > wrote:
> 
> Standardizing on "openstack   verb" would likely
> be the best solution for both the immediate problem and for the
> broader "naming stuff" issue.
> 
> 
> This is the approach that a number of plugins are taking.  I have
> STRONGLY recommended that the project name not be used, OSC never uses
> project names in a user-visible way.  Some plugins do it anyway.
>  
> 
> A flat namespace was a mostly-fine idea when all integrated projects
> were expected to put their CLI in-tree in openstackclient. There
> were reviews, and discussions about what noun belonged to whom.
> 
> 
> I wish there had been more of that.  You'd be surprised how little there
> actually has been...
>  
> 
> Noun conflict will only get worse: lots of projects will share words
> like stack, domain, user, container, address, and so on.
> 
> 
> This is one reason multiple-word object names are possible.  For
> example, we've just merged commands to support the object store
> 'account' functions and used 'object store account' for those commands
> because we felt that 'account' is too generic.
>  
> 
> A central reservation process for nouns won't really scale, but
> namespacing will because we *already* namespace projects.
> 
> 
> I believe it will scale far enough to encomapss the realistic
> possibilites of putting everything under the top-level 'openstack'
> command.  I think that is the assumption that we need to be addressing. 
> As you said, it worked when we started 4 years ago, but even then there
> were conflicts. We are discussing alternatives that include multiple
> top-level commands.  But we need to get input from actual users who are
> not OpenStack devs on this and do not have the pre-concieved notions of
> this-api and that-api to the extent that those of us in the project do. 
> This is just getting underway, and will be a summit topic.
> 
> Users should not have to know or care which API implements something.

For the CLI, definitely agree. Balkanizing back to a namespace per
project is the wrong direction.

> I am beginning to regret giving up the command name control as it is
> re-creating the situation we had with the original CLIs and the lack of
> consistency.
> 
> Also I want to add that the philosophy of OpenStackClient is not to
> simply accept everything that the API declares as the CLI and stop
> there, but to make the operations simple and meaningful for the users. 
> We have abstracted some API bits and flat out changed others to do this.  
> 
> dt
> 
> "The 'C' in OSC == 'consistent'."
> 
> -- 
> 
> Dean Troyer
> dtro...@gmail.com 
> 
> 
> __
> 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
> 


-- 
Sean Dague
http://dague.net

__
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]

[Adam Young]

Send me what you have, and I will post it as a Work in progress review 
against Horizon.  That way at least it will be available for others to 
look at and potentially adopt.




On 10/07/2015 11:37 AM, David Chadwick wrote:

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:

Hi David,
  
This sounds like a great set of code, I'm sure we are going to realize

we want it sooner or later! Unfortunately I can't consume code in this
way (I can't propose code written by somebody else) and I can't spend
significant time on it right now.
  
Would you or Anton be willing to propose whatever code and documentation

you have to Horizon? It doesn't have to be complete; it doesn't need to
have grammar cleaned up or anything like that. You could mark it as a
"Work in progress", and make it clear in the commit message that you
aren't planning further work on this, so the patch is available for
adoption. That way somebody else may be able to pick this up and work on
it in the future, but Anton could get credit for the work he has done.

Doug Fish
  
  


 - Original message -
 From: David Chadwick 
 To: OpenStack Development Mailing List
 
 Cc:
 Subject: [openstack-dev] [horizon][keystone]
 Date: Tue, Oct 6, 2015 2:13 PM
  
 Dear All


 One of my students, Anton Brida, has developed an Attribute Mapping GUI
 for Horizon as part of his MSc project. Attribute mappings are an
 essential, though complex, part of federated Keystone. Currently they
 can only be created as JSON objects in the config file. The Horizon code
 allows them to be dynamically created via an easy to use GUI.

 Since Anton has now left the university for full time employment, he is
 not able to go through the process of submitting his code to the next
 release of Horizon. His design however was submitted to InVision and
 commented on by various people at the time of the development.

 I am now looking for someone who would like to take a copy of this code
 and go through the process of submitting this to the next release of
 Horizon. I have a copy of Anton's MSc dissertation as well which
 explains the work that he has done.

 All the attribute mapping features are supported in Anton's code
 (groups, users, direct mapping, multiple attribute values etc.)
 However the whitelist/blacklist feature is not, since this was not fully
 incorporated into Keystone when Anton was doing his implementation. (I
 am still not sure if it has been.)

 The code has a couple of known bugs:

 1. when a user tries to enter an email address into an attribute value
 (i.e. usern...@example.com) and saves the mapping rule into the
 database, after reloading the new list of mappings rules the interface
 does not work as intended. The particular reason why this is happening
 is yet unknown. The only way to avoid such disruption is to delete the
 faulty mapping rule from the table. After removing the faulty rule the
 interface works as intended.

 2. Some of the descriptive text needs improvement due to incorrect
 grammar.

 There is also the following suggested enhancement which can be added
 later:

 1. After the mapping rules are created with the GUI, when they are
 displayed, they are still in JSON format. It would be nice to be able to
 display the rules in a table or similar.

 If you would like to take on the job of submitting this code to Horizon
 for review and incorporation, please contact me

 regards

 David

 __
 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][keystone]

[David Chadwick]

Hi Douglas

we are happy for you (or someone else) to submit the code in 3 names:
theirs, mine and Anton's. Then this third person can do all the work
necessary to get it approved. In this way it is legitimate, since the
third person will have contributed to the overall effort.

I dont have any spare time yet for another month or so. After that I
could submit it, but having never done it before for Horizon, there will
be a big learning curve. And I might not have time to learn it

regards

David

On 07/10/2015 16:05, Douglas Fish wrote:
> Hi David,
>  
> This sounds like a great set of code, I'm sure we are going to realize
> we want it sooner or later! Unfortunately I can't consume code in this
> way (I can't propose code written by somebody else) and I can't spend
> significant time on it right now.
>  
> Would you or Anton be willing to propose whatever code and documentation
> you have to Horizon? It doesn't have to be complete; it doesn't need to
> have grammar cleaned up or anything like that. You could mark it as a
> "Work in progress", and make it clear in the commit message that you
> aren't planning further work on this, so the patch is available for
> adoption. That way somebody else may be able to pick this up and work on
> it in the future, but Anton could get credit for the work he has done.
> 
> Doug Fish
>  
>  
> 
> - Original message -
> From: David Chadwick 
> To: OpenStack Development Mailing List
> 
> Cc:
> Subject: [openstack-dev] [horizon][keystone]
> Date: Tue, Oct 6, 2015 2:13 PM
>  
> Dear All
> 
> One of my students, Anton Brida, has developed an Attribute Mapping GUI
> for Horizon as part of his MSc project. Attribute mappings are an
> essential, though complex, part of federated Keystone. Currently they
> can only be created as JSON objects in the config file. The Horizon code
> allows them to be dynamically created via an easy to use GUI.
> 
> Since Anton has now left the university for full time employment, he is
> not able to go through the process of submitting his code to the next
> release of Horizon. His design however was submitted to InVision and
> commented on by various people at the time of the development.
> 
> I am now looking for someone who would like to take a copy of this code
> and go through the process of submitting this to the next release of
> Horizon. I have a copy of Anton's MSc dissertation as well which
> explains the work that he has done.
> 
> All the attribute mapping features are supported in Anton's code
> (groups, users, direct mapping, multiple attribute values etc.)
> However the whitelist/blacklist feature is not, since this was not fully
> incorporated into Keystone when Anton was doing his implementation. (I
> am still not sure if it has been.)
> 
> The code has a couple of known bugs:
> 
> 1. when a user tries to enter an email address into an attribute value
> (i.e. usern...@example.com) and saves the mapping rule into the
> database, after reloading the new list of mappings rules the interface
> does not work as intended. The particular reason why this is happening
> is yet unknown. The only way to avoid such disruption is to delete the
> faulty mapping rule from the table. After removing the faulty rule the
> interface works as intended.
> 
> 2. Some of the descriptive text needs improvement due to incorrect
> grammar.
> 
> There is also the following suggested enhancement which can be added
> later:
> 
> 1. After the mapping rules are created with the GUI, when they are
> displayed, they are still in JSON format. It would be nice to be able to
> display the rules in a table or similar.
> 
> If you would like to take on the job of submitting this code to Horizon
> for review and incorporation, please contact me
> 
> regards
> 
> David
> 
> __
> 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] conflicting names in python-openstackclient: could we have some exception handling please?

[Thomas Goirand]

On 10/07/2015 03:39 PM, Ryan Brown wrote:
> Sharing a flat namespace is a recipe for pain with a growing number of
> projects. Devs and users are unlikely to use every project, they
> probably won't notice conflicts naturally except in cases like horizon.

Well, users would typically install Horizon on a "controler" machine,
with everything installed there, and then specialized compute, network
or storage node. This is a very common practice. In such a case, if you
want to debug anything, you'd use python-openstackclient cli on the
controler machine, and probably at some point will want to type
"openstack help". So very likely, this *will* hit our users.

> To your (1) we could have a gate job that installs all the clients and
> fails on conflicts.

That's a very good idea.

Thomas


__
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] conflicting names in python-openstackclient: could we have some exception handling please?

[Thomas Goirand]

On 10/07/2015 03:57 PM, Hayes, Graham wrote:
> On 07/10/15 14:42, Ryan Brown wrote:
>> On 10/06/2015 05:15 PM, Thomas Goirand wrote:
>>> P.S: It wasn't the point of this message, but do we have a fix for
>>> designateclient? It'd be nice to have this fixed before Liberty is out.
> 
> Is there a bug filed for it? I haven't seen this before and it seems to
> be working for me locally :/
> 
> (I have openstackclient == 1.7.1 & designateclient == 1.5.0)
> 
> If we can find the issue we will try and get a fix out.

Here you are...
https://bugs.launchpad.net/python-designateclient/+bug/1503736

Cheers,

Thomas

P.S: That's a "normal" Debian Jessie machine with the latest Liberty
packages backported-built and available at (deb repo details there...):
http://liberty-jessie.pkgs.mirantis.com/


__
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]

[Douglas Fish]

Hi David,
 
This sounds like a great set of code, I'm sure we are going to realize we want it sooner or later! Unfortunately I can't consume code in this way (I can't propose code written by somebody else) and I can't spend significant time on it right now.
 
Would you or Anton be willing to propose whatever code and documentation you have to Horizon? It doesn't have to be complete; it doesn't need to have grammar cleaned up or anything like that. You could mark it as a "Work in progress", and make it clear in the commit message that you aren't planning further work on this, so the patch is available for adoption. That way somebody else may be able to pick this up and work on it in the future, but Anton could get credit for the work he has done.
Doug Fish
 
 
- Original message -From: David Chadwick To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon][keystone]Date: Tue, Oct 6, 2015 2:13 PM 
Dear AllOne of my students, Anton Brida, has developed an Attribute Mapping GUIfor Horizon as part of his MSc project. Attribute mappings are anessential, though complex, part of federated Keystone. Currently theycan only be created as JSON objects in the config file. The Horizon codeallows them to be dynamically created via an easy to use GUI.Since Anton has now left the university for full time employment, he isnot able to go through the process of submitting his code to the nextrelease of Horizon. His design however was submitted to InVision andcommented on by various people at the time of the development.I am now looking for someone who would like to take a copy of this codeand go through the process of submitting this to the next release ofHorizon. I have a copy of Anton's MSc dissertation as well whichexplains the work that he has done.All the attribute mapping features are supported in Anton's code(groups, users, direct mapping, multiple attribute values etc.)However the whitelist/blacklist feature is not, since this was not fullyincorporated into Keystone when Anton was doing his implementation. (Iam still not sure if it has been.)The code has a couple of known bugs:1. when a user tries to enter an email address into an attribute value(i.e. usern...@example.com) and saves the mapping rule into thedatabase, after reloading the new list of mappings rules the interfacedoes not work as intended. The particular reason why this is happeningis yet unknown. The only way to avoid such disruption is to delete thefaulty mapping rule from the table. After removing the faulty rule theinterface works as intended.2. Some of the descriptive text needs improvement due to incorrect grammar.There is also the following suggested enhancement which can be added later:1. After the mapping rules are created with the GUI, when they aredisplayed, they are still in JSON format. It would be nice to be able todisplay the rules in a table or similar.If you would like to take on the job of submitting this code to Horizonfor review and incorporation, please contact meregardsDavid__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [nova] nova-manage db archive_deleted_rows broken

[Matt Riedemann]

On 12/12/2014 7:54 PM, melanie witt wrote:

Hi everybody,

At some point, our db archiving functionality got broken because there was a 
change to stop ever deleting instance system metadata [1]. For those 
unfamiliar, the 'nova-manage db archive_deleted_rows' is the thing that moves 
all soft-deleted (deleted=nonzero) rows to the shadow tables. This is a 
periodic cleaning that operators can do to maintain performance (as things can 
get sluggish when deleted=nonzero rows accumulate).

The change was made because instance_type data still needed to be read even after 
instances had been deleted, because we allow admin to view deleted instances. I saw a bug 
[2] and two patches [3][4] which aimed to fix this by changing back to soft-deleting 
instance sysmeta when instances are deleted, and instead allow 
read_deleted="yes" for the things that need to read instance_type for deleted 
instances present in the db.

My question is, is this approach okay? If so, I'd like to see these patches 
revive so we can have our db archiving working again. :) I think there's likely 
something I'm missing about the approach, so I'm hoping people who know more 
about instance sysmeta than I do, can chime in on how/if we can fix this for db 
archiving. Thanks.

[1] https://bugs.launchpad.net/nova/+bug/1185190
[2] https://bugs.launchpad.net/nova/+bug/1226049
[3] https://review.openstack.org/#/c/110875/
[4] https://review.openstack.org/#/c/109201/

melanie (melwitt)






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



I'd like to bring this back up since even though [3] and [4] are merged, 
nova-manage db archive_deleted_rows still fails to delete rows from some 
tables because of foreign key constraint issues, detailed here:


https://bugs.launchpad.net/nova/+bug/1183523/comments/12

I'm wondering why we don't reverse sort the tables using the sqlalchemy 
metadata object before processing the tables for delete?  That's the 
same thing I did in the 267 migration since we needed to process the 
tree starting with the leafs and then eventually get back to the 
instances table (since most roads lead to the instances table).


Another thing that's really weird is how max_rows is used in this code. 
There is cumulative tracking of the max_rows value so if the value you 
pass in is too small, you might not actually be removing anything.


I figured max_rows meant up to max_rows from each table, not max_rows 
*total* across all tables. By my count, there are 52 tables in the nova 
db model. The way I read the code, if I pass in max_rows=10 and say it 
processes table A and archives 7 rows, then when it processes table B it 
will pass max_rows=(max_rows - rows_archived), which would be 3 for 
table B. If we archive 3 rows from table B, rows_archived >= max_rows 
and we quit. So to really make this work, you have to pass in something 
big for max_rows, like 1000, which seems completely random.


Does this seem odd to anyone else?  Given the relationships between 
tables, I'd think you'd want to try and delete max_rows for all tables, 
so archive 10 instances, 10 block_device_mapping, 10 pci_devices, etc.


I'm also bringing this up now because there is a thread in the operators 
list which pointed me to a set of scripts that operators at GoDaddy are 
using for archiving deleted rows:


http://lists.openstack.org/pipermail/openstack-operators/2015-October/008392.html

Presumably because the command in nova doesn't work. We should either 
make this thing work or just punt and delete it because no one cares.


--

Thanks,

Matt Riedemann


__
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] [Neutron] Prepare for expiration bugs without activity

[Ihar Hrachyshka]

> On 06 Oct 2015, at 19:26, ZZelle  wrote:
> 
> Hi everyone,
> 
> 
> As decided during last neutron meeting[1], we try to let Launchpad expire 
> outdated bugs.
> 
> The status of every bug without activity in last year has been set to 
> Incomplete and their assignee/milestone unset in order to let Launchpad 
> expire them in 60 days[2].
> 
> It gives us a 60-days window to "revive" expirable bugs[3] which are (sadly 
> :)) still valid (by changing their status).
> 

I went thru the whole list of expirable bugs and moved some of them back to 
Confirmed where it seems to apply, plus added tags. I believe now we should not 
loose anything valuable.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [neutron] New cycle started. What are you up to, folks?

[Edgar Magana]

Hello All,

Probably quite late answering this email but I want to add our contributions.

We will be testing Neutron at scale, so we will be contributing to bugs opened 
based on the outcome of our tests. We will be also testing concurrency, we are 
leveraging rally for this goal and also expecting some bugs that we can close.

On the Documentation, I want to incorporate the sections that we have missing 
and make the guide a very good networking resources for users/operators.

We don’t have any feature request right now, it is hard to catch up with the 
contributions so far but maybe a bit testing on the LBaaS area.

Looking forward to seeing you all in Tokyo,

Edgar





On 10/1/15, 6:45 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I talked recently with several contributors about what each of us plans for 
>the next cycle, and found it’s quite useful to share thoughts with others, 
>because you have immediate yay/nay feedback, and maybe find companions for 
>next adventures, and what not. So I’ve decided to ask everyone what you see 
>the team and you personally doing the next cycle, for fun or profit.
>
>That’s like a PTL nomination letter, but open to everyone! :) No commitments, 
>no deadlines, just list random ideas you have in mind or in your todo lists, 
>and we’ll all appreciate the huge pile of awesomeness no one will ever have 
>time to implement even if scheduled for Xixao release.
>
>To start the fun, I will share my silly ideas in the next email.
>
>Ihar
__
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] conflicting names in python-openstackclient: could we have some exception handling please?

[Dean Troyer]

On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown  wrote:

> Standardizing on "openstack   verb" would likely be the
> best solution for both the immediate problem and for the broader "naming
> stuff" issue.
>

This is the approach that a number of plugins are taking.  I have STRONGLY
recommended that the project name not be used, OSC never uses project names
in a user-visible way.  Some plugins do it anyway.


> A flat namespace was a mostly-fine idea when all integrated projects were
> expected to put their CLI in-tree in openstackclient. There were reviews,
> and discussions about what noun belonged to whom.
>

I wish there had been more of that.  You'd be surprised how little there
actually has been...


> Noun conflict will only get worse: lots of projects will share words like
> stack, domain, user, container, address, and so on.
>

This is one reason multiple-word object names are possible.  For example,
we've just merged commands to support the object store 'account' functions
and used 'object store account' for those commands because we felt that
'account' is too generic.


> A central reservation process for nouns won't really scale, but
> namespacing will because we *already* namespace projects.


I believe it will scale far enough to encomapss the realistic possibilites
of putting everything under the top-level 'openstack' command.  I think
that is the assumption that we need to be addressing.  As you said, it
worked when we started 4 years ago, but even then there were conflicts. We
are discussing alternatives that include multiple top-level commands.  But
we need to get input from actual users who are not OpenStack devs on this
and do not have the pre-concieved notions of this-api and that-api to the
extent that those of us in the project do.  This is just getting underway,
and will be a summit topic.

Users should not have to know or care which API implements something.

I am beginning to regret giving up the command name control as it is
re-creating the situation we had with the original CLIs and the lack of
consistency.

Also I want to add that the philosophy of OpenStackClient is not to simply
accept everything that the API declares as the CLI and stop there, but to
make the operations simple and meaningful for the users.  We have
abstracted some API bits and flat out changed others to do this.

dt

"The 'C' in OSC == 'consistent'."

-- 

Dean Troyer
dtro...@gmail.com
__
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] conflicting names in python-openstackclient: could we have some exception handling please?

[Dean Troyer]

On Tue, Oct 6, 2015 at 4:15 PM, Thomas Goirand  wrote:

> tl;dr: let's add a exception handling so that python-*client having
> conflicting command names isn't a problem anymore, and "openstack help"
> always work as much as it can.
>

This creates a first-one-wins scenario that requires *-client install order
to be deterministic.   Or we need a registry of which API owns which object
namens (nouns), which would actually solve our problem today without any
changes.


> Longer version:
>
> This is just a suggestion for contributors to python-openstackclient.
>
> I saw a few packages that had conflicts with the namespace of others
> within openstackclient. To the point that typing "openstack help" just
> fails. Here's an example:
>
> # openstack help
> [ ...]
>   project create  Create new project
>   project delete  Delete project(s)
>   project list   List projects
>   project setSet project properties
>   project show   Display project details
> Could not load EntryPoint.parse('ptr_record_list =
> designateclient.v2.cli.reverse:ListFloatingIPCommand')
> 'ArgumentParser' object has no attribute 'debug'
>
> This first happened to me with saharaclient. Lucky, upgrading to latest
> version fixed it. Then I had the problem with zaqarclient, which I fixed
> with a few patches to its setup.cfg. Then now designate, but this time,
> patching setup.cfg doesn't seem to cut it (ie: after changing the name
> of the command, "openstack help" just fails).
>

This is a problem with the implementation of the plugin, not with the
selection of command names.  Your experience with saharaclient and the fact
that editing setup.cfg did not help should confirm that.


> Which leads me to write this:
>
> Since we have a very large amount of projects, with each and everyone of
> them adding new commands to openstackclient, I would really nice if we
> could have some kind of checks to make sure that conflicts are either 1/
> not possible or 2/ handled gracefully.
>

The conflicting command names is due to the way setuptools handles entry
points by default (I'm not sure if this can even be changed easily).  It
turns out that having multiple classes registered to a common command name
is useful, I have a plugin that does this intentionally in order to modify
the behaviour of an existing command (changes server create to add --ram,
--disk and --cpu to auto-select a flavor).

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

[Kris G. Lindgren]

Please see inline.

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 10/7/15, 6:12 AM, "Tim Bell"  wrote:

>
>
>> -Original Message-
>> From: Daniel P. Berrange [mailto:berra...@redhat.com]
>> Sent: 07 October 2015 13:25
>> To: Tim Bell 
>> Cc: Sean Dague ; OpenStack Development Mailing List
>> (not for usage questions) ; openstack-
>> operat...@lists.openstack.org
>> Subject: Re: [Openstack-operators] [openstack-dev] [nova] Min libvirt for
>> Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1
>>
>> On Wed, Oct 07, 2015 at 11:13:12AM +, Tim Bell wrote:
>> >
>> > Although Red Hat is no longer supporting RHEL 6 after Icehouse, a
>> > number of users such as GoDaddy and CERN are using Software
>> > Collections to run the Python 2.7 code.
>>
>> Do you have any educated guess as to when you might switch to deploying
>> new OpenStack version exclusively on RHEL 7 ? I understand such a switch is
>> likely to take a while so you can test its performance and reliability and 
>> so on,
>> but I'm assuming you'll eventually switch ?
>>
>
>I think we'll be all 7 by spring next year (i.e. when we install Liberty). The 
>software collections work is not for the faint hearted and 7 brings lots of 
>good things with it for operations so we want to get there as soon as 
>possible. Thus, I think we'd be fine with a change in Mitaka (especially given 
>the points you mention below).

Like CERN, we don't currently plan on doing the software collections + venv 
trick past kilo.  We plan on having all of our HV's running cent 7+ before we 
move to liberty.  That said, Liberty should still technically work under CentOS 
6...

I am ok dropping support for RHEL/CentOS 6 in N.

>
>> > However, since this modification would only take place when Mitaka
>> > gets released, this would realistically give those sites a year to
>> > complete migration to RHEL/CentOS 7 assuming they are running from one
>> > of the community editions.
>> >
>> > What does the 1.1.1 version bring that is the motivation for raising
>> > the limit ?
>>
>> If we require 1.1.1 we could have unconditional support for
>>
>>  - Hot-unplug of PCI devices (needs 1.1.1)
>>  - Live snapshots (needs 1.0.0)
>>  - Live volume snapshotting (needs 1.1.1)
>>  - Disk sector discard support (needs 1.0.6)
>>  - Hyper-V clock tunables (needs 1.0.0 & 1.1.0)
>>
>> If you lack those versions, in case of hotunplug, and live volume snapshots
>> we just refuse the corresponding API call. With live snapshots we fallback 
>> to
>> non-live snapshots. For disk discard and hyperv clock we just run with
>> degraded functionality. The lack of hyperv clock tunables means Windows
>> guests will have unreliable time keeping and are likely to suffer random
>> BSOD, which I think is a particularly important issue.
>>
>> And of course we remove a bunch of conditional logic from Nova which
>> simplifies the code paths and removes code paths which rarely get testing
>> coverage.
>>
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ 
>> :|
>> |: http://libvirt.org  -o- http://virt-manager.org 
>> :|
>> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ 
>> :|
>> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc 
>> :|
__
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] [tc] naming N and O releases nowish

[Barrett, Carol L]

Is there any reason we can't change that process to align with the longer term 
planning that's happening around these things? 
Thanks
Carol
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Wednesday, October 07, 2015 5:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] naming N and O releases nowish

Sean Dague wrote:
> We're starting to make plans for the next cycle. Long term plans are 
> getting made for details that would happen in one or two cycles.
> 
> As we already have the locations for the N and O summits I think we 
> should do the naming polls now and have names we can use for this 
> planning instead of letters. It's pretty minor but it doesn't seem 
> like there is any real reason to wait and have everyone come up with 
> working names that turn out to be confusing later.

That sounds fair. However the release naming process currently states[1]:

"""
The process to chose the name for a release begins once the location of the 
design summit of the release to be named is announced and no sooner than the 
opening of development of the previous release.
"""

...which if I read it correctly means we could pick N now, but not O. We might 
want to change that (again) first.

[1] http://governance.openstack.org/reference/release-naming.html

--
Thierry Carrez (ttx)

__
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] [Glance] Process to clean up the review queue from non-active patches

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2015-10-07 16:50:16 +0900:
> On 06/10/15 23:36 +0900, Flavio Percoco wrote:
> >Greetings,
> >
> >Not so long ago, Erno started a thread[0] in this list to discuss the
> >abandon policies for patches that haven't been updated in Glance.
> >
> >I'd like to go forward and start following that policy with some
> >changes that you can find below:
> >
> >1) Lets do this on patches that haven't had any activity in the last 2
> >months. This adds one more month to Erno's proposal. The reason being
> >that during the lat cycle, there were some ups and downs in the review
> >flow that caused some patches to get stuck.
> >
> >2) Do this just on master, for all patches regardless they fix a
> >bug or implement a spec and for all patches regardless their review
> >status.
> >
> >3) The patch will be first marked as a WIP and then abandoned if the
> >patch is not updated in 1 week. This will put this patches at the
> >begining of the queue but using the Glance review dashboard should
> >help keeing focus.
> >
> >Unless there are some critical things missing in the above or strong
> >opiniones against this, I'll make this effective starting next Monday
> >October 12th.
> 
> I'd like to provide some extra data here. This is our current status:
> 
> ==
> Total patches without activity in the last 2 months: 73
> Total patches closing a bug: 30
> Total patches with negative review by core reviewers: 62
> Total patches with negative review by non-core reviewers: 75
> Total patches without a core review in the last patchset: 13
> Total patches with negative review from Jenkins: 50
> ==
> 
> It's not ideal but it's also not a lot. I'd like to recover as many
> patches as possible from the above and I'm happy to do that manually
> if necessary.
> 
> Cheers,
> Flavio
> 

It might be useful to schedule a review sprint to take a couple of days
to focus on reviews. Maybe the team can pick dates a couple of weeks in
advance so everyone can get permission to spend the full time on
reviews.

Doug

__
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] [nova] It's time to update the Liberty release notes

[Juvonen, Tomi (Nokia - FI/Espoo)]

This also had DocImpact, but flag was not there.

ff80032 Roman Dobosz   New nova API call to mark nova-compute down

br,
Tomi

-Original Message-
From: EXT Alexis Lee [mailto:lx...@hpe.com] 
Sent: Wednesday, October 07, 2015 4:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] It's time to update the Liberty release 
notes

Now with committer names.

Matt Riedemann said on Thu, Oct 01, 2015 at 01:27:38PM -0500:
> Here are the commits in liberty that had the UpgradeImpact tag:

% git log --format='%h %<(18,trunc)%cn %s' -i --grep UpgradeImpact \
remotes/origin/stable/kilo..remotes/origin/stable/liberty
0b49934 Zhenyu Zheng   CONF.allow_resize_to_same_host should check only 
once in controller
4a9e14a Sylvain Bauza  Update ComputeNode values with allocation ratios in 
the RT
4a18f7d John Garbutt   api: use v2.1 only in api-paste.ini
11507ee John Garbutt   api: deprecate the concept of extensions in v2.1
9c91781 Eli Qiao   Add missing rules in policy.json
1b8a2e0 Dan Smith  Adding user_id handling to keypair index, show and 
create api calls
0283234 Maxim Nestratovlibvirt: Always default device names at boot
725c54e He Jie Xu  Remove db layer hard-code permission checks for 
quota_class_create/update
1dbb322 He Jie Xu  Remove db layer hard-code permission checks for 
quota_class_get_all_by_name
4d6a50a ShaoHe FengRemove db layer hard-code permission checks for 
floating_ip_dns
55e63f8 Davanum Srinivas.. Allow non-admin to list all tenants based on policy
92807d6 jichenjc   Remove redundant policy check from 
security_group_default_rule
2a01a1b Matt Riedemann Remove hv_type translation shim for powervm
dcd4be6 He Jie Xu  Remove db layer hard-code permission checks for 
quota_get_all_*
06e6056 jichenjc   Remove cell policy check
d03b716 Matt Riedemann libvirt: deprecate libvirt version usage < 0.10.2
5309120 Dan Smith  Update kilo version alias

> Here are the DocImpact changes:

% git log --format='%h %<(18,trunc)%cn %s' -i --grep DocImpact \
remotes/origin/stable/kilo..remotes/origin/stable/liberty
bc6f30d He Jie Xu  Give instance default hostname if hostname is empty
4ee4f9f Nikola Dipanov RT: track evacuation migrations
9095b36 Davanum Srinivas.. Expose keystoneclient's session and auth plugin 
loading parameters
4a9e14a Sylvain Bauza  Update ComputeNode values with allocation ratios in 
the RT
4a18f7d John Garbutt   api: use v2.1 only in api-paste.ini
11507ee John Garbutt   api: deprecate the concept of extensions in v2.1
45d1e3c ghanshyam  Expose VIF net-id attribute in os-virtual-interfaces
9d353e5 Michael Still  libvirt: take account of disks in migration data size
17e5911 Michael Still  Add deprecated_for_removal parm for deprecated 
neutron_ops
95940cc Michael Still  Don't allow instance to overcommit against itself
9cd9e66 Davanum Srinivas   Add rootwrap daemon mode support
c250aca Jay Pipes  Allow compute monitors in different namespaces
434ce2a Marian Horban  Added processing /compute URL
2c0a306 Dan Smith  Limit parallel live migrations in progress
da33ab4 Daniel P. Berrange libvirt: set caps on maximum live migration time
07c7e5c Daniel P. Berrange libvirt: support management of downtime during 
migration
60d08e6 Chuck Carmack  Add documentation for the nova-cells command.
ae5a329 Marian Horban  libvirt:Rsync remote FS driver was added
9a09674 Vladik Romanovsky  libvirt: enable virtio-net multiqueue
8a7b1e8 Chuck Carmack  :Add documentation for the nova-idmapshift command.
bf91d9f Sergey Nikitin Added missed '-' to the rest_api_version_history.rst
1b8a2e0 Dan Smith  Adding user_id handling to keypair index, show and 
create api calls
622a845 Gary KottonMetadata: support proxying loadbalancers
2f7403b Radoslav Gerganov  VMware: map one nova-compute to one VC cluster
ace11d3 Radoslav Gerganov  VMware: add serial port device
ab35779 Radomir Dopieral.. Handle SSL termination proxies for version list
6739df7 Dan Smith  Include DiskFilter in the default list
5e5ef99 Thang Pham VMware: Add support for swap disk
49a572a Ghanshyam Mann Show 'locked' information in server details
4252420 Gary KottonVMware: add resource limits for disk
f1f46a0 Gary KottonVMware: Resource limits for memory
7aec88c Gary KottonVMware: add support for cores per socket
bc3b6cc Maxim Nestratovlibvirt: rename parallels driver to virtuozzo
95f1d47 Mike DormanAdd console allowed origins setting
d0ee3ab Shiina, Hironori   libvirt:Add a driver API to inject an NMI
50c8f93 Radoslav Gerganov  Add MKS console support
abf20cd abhishekkekane Execute _poll_shelved_instances only if 
shelved_offload_time is > 0
973f312 Jay Pipes  Use stevedore for loading monitor extensions
9260ea1 andrewbogott 

Re: [openstack-dev] [Openstack-operators][nova] Nova DB archiving script

[Matt Riedemann]

On 10/6/2015 11:49 AM, Mike Dorman wrote:

I posted a patch against one of the Nova DB archiving scripts in the
osops-tools-generic repo a few days ago to support additional tables:

https://review.openstack.org/#/c/229013/2

We’d like a few more folks to review to make sure it looks good.  Please
take a few minutes and take a look.  Thanks!



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



I've commented in the review but I'd like to see this actually addressed 
in the nova-manage db archive_deleted_rows command if possible, or at 
least tracking what is currently broken about that command so that we 
can at least attempt to investigate it.


I'm cross-posting this to the dev list for the nova team.

--

Thanks,

Matt Riedemann


__
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] conflicting names in python-openstackclient: could we have some exception handling please?

[Hayes, Graham]

On 07/10/15 14:42, Ryan Brown wrote:
> On 10/06/2015 05:15 PM, Thomas Goirand wrote:
>> Hi,
>>
>> tl;dr: let's add a exception handling so that python-*client having
>> conflicting command names isn't a problem anymore, and "openstack help"
>> always work as much as it can.
> 
> Standardizing on "openstack   verb" would likely be 
> the best solution for both the immediate problem and for the broader 
> "naming stuff" issue.
> 
> Sharing a flat namespace is a recipe for pain with a growing number of 
> projects. Devs and users are unlikely to use every project, they 
> probably won't notice conflicts naturally except in cases like horizon.
> 
> If we look over the fence at AWS, you'll note that their nice unified 
> CLI that stops the non-uniform `awk` bloodshed is namespaced.
> 
> - aws s3 ...
> - aws cloudformation ...
> - aws ec2 ...
> 
> A flat namespace was a mostly-fine idea when all integrated projects 
> were expected to put their CLI in-tree in openstackclient. There were 
> reviews, and discussions about what noun belonged to whom.
> 
> Noun conflict will only get worse: lots of projects will share words 
> like stack, domain, user, container, address, and so on.
> 
> Namespaces are one honking great idea -- let's do more of those!
> 
>> Longer version:
>>
>> This is just a suggestion for contributors to python-openstackclient.
>>
>> I saw a few packages that had conflicts with the namespace of others
>> within openstackclient. To the point that typing "openstack help" just
>> fails. Here's an example:
>>
>> # openstack help
>> [ ...]
>>project create  Create new project
>>project delete  Delete project(s)
>>project list   List projects
>>project setSet project properties
>>project show   Display project details
>> Could not load EntryPoint.parse('ptr_record_list =
>> designateclient.v2.cli.reverse:ListFloatingIPCommand')
>> 'ArgumentParser' object has no attribute 'debug'
>>
>> This first happened to me with saharaclient. Lucky, upgrading to latest
>> version fixed it. Then I had the problem with zaqarclient, which I fixed
>> with a few patches to its setup.cfg. Then now designate, but this time,
>> patching setup.cfg doesn't seem to cut it (ie: after changing the name
>> of the command, "openstack help" just fails).
>>
>> Note: I don't care which project is at fault, this isn't the point here.
>> The point is that command name conflicts aren't handled (see below)
>> which is the problem.
> 
> +1, this isn't a problem specific to any project, it's systemic with 
> flat namespacing.
> 
>> With Horizon being a large consumer of nearly all python-*client
>> packages, removing one of them also removes Horizon in my CI which is
>> not what I want to (or can) do to debug a tempest problem. End of the
>> story: since Liberty b3, I never could have "openstack help" to work
>> correctly in my CI... :(
> 
> O.O That's unfortunate.
> 
>> Which leads me to write this:
>>
>> Since we have a very large amount of projects, with each and everyone of
>> them adding new commands to openstackclient, I would really nice if we
>> could have some kind of checks to make sure that conflicts are either 1/
>> not possible or 2/ handled gracefully.
> 
> To your (1) we could have a gate job that installs all the clients and 
> fails on conflicts.
> 
> The downside of doing that without addressing the namespace problem is 
> that there will be inconsistent conventions everywhere. Zaqar will have 
> "openstack queue " but "openstack message flavor ..." which creates 
> the sort of confusion a unified client is supposed to avoid.
> 
> A central reservation process for nouns won't really scale, but 
> namespacing will because we *already* namespace projects.
> 
>> Your thoughts?
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> P.S: It wasn't the point of this message, but do we have a fix for
>> designateclient? It'd be nice to have this fixed before Liberty is out.

Is there a bug filed for it? I haven't seen this before and it seems to
be working for me locally :/

(I have openstackclient == 1.7.1 & designateclient == 1.5.0)

If we can find the issue we will try and get a fix out.



-- 
Graham Hayes
Software Engineer
DNS as a Service
Advanced Network Services
HP Helion Cloud - Platform Services

GPG Key: 7D28E972


graham.ha...@hpe.com
M +353 87 377 8315

P +353 1 525 1589
Dublin,
Ireland

HP

__
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] [nova] It's time to update the Liberty release notes

[Alexis Lee]

Now with committer names.

Matt Riedemann said on Thu, Oct 01, 2015 at 01:27:38PM -0500:
> Here are the commits in liberty that had the UpgradeImpact tag:

% git log --format='%h %<(18,trunc)%cn %s' -i --grep UpgradeImpact \
remotes/origin/stable/kilo..remotes/origin/stable/liberty
0b49934 Zhenyu Zheng   CONF.allow_resize_to_same_host should check only 
once in controller
4a9e14a Sylvain Bauza  Update ComputeNode values with allocation ratios in 
the RT
4a18f7d John Garbutt   api: use v2.1 only in api-paste.ini
11507ee John Garbutt   api: deprecate the concept of extensions in v2.1
9c91781 Eli Qiao   Add missing rules in policy.json
1b8a2e0 Dan Smith  Adding user_id handling to keypair index, show and 
create api calls
0283234 Maxim Nestratovlibvirt: Always default device names at boot
725c54e He Jie Xu  Remove db layer hard-code permission checks for 
quota_class_create/update
1dbb322 He Jie Xu  Remove db layer hard-code permission checks for 
quota_class_get_all_by_name
4d6a50a ShaoHe FengRemove db layer hard-code permission checks for 
floating_ip_dns
55e63f8 Davanum Srinivas.. Allow non-admin to list all tenants based on policy
92807d6 jichenjc   Remove redundant policy check from 
security_group_default_rule
2a01a1b Matt Riedemann Remove hv_type translation shim for powervm
dcd4be6 He Jie Xu  Remove db layer hard-code permission checks for 
quota_get_all_*
06e6056 jichenjc   Remove cell policy check
d03b716 Matt Riedemann libvirt: deprecate libvirt version usage < 0.10.2
5309120 Dan Smith  Update kilo version alias

> Here are the DocImpact changes:

% git log --format='%h %<(18,trunc)%cn %s' -i --grep DocImpact \
remotes/origin/stable/kilo..remotes/origin/stable/liberty
bc6f30d He Jie Xu  Give instance default hostname if hostname is empty
4ee4f9f Nikola Dipanov RT: track evacuation migrations
9095b36 Davanum Srinivas.. Expose keystoneclient's session and auth plugin 
loading parameters
4a9e14a Sylvain Bauza  Update ComputeNode values with allocation ratios in 
the RT
4a18f7d John Garbutt   api: use v2.1 only in api-paste.ini
11507ee John Garbutt   api: deprecate the concept of extensions in v2.1
45d1e3c ghanshyam  Expose VIF net-id attribute in os-virtual-interfaces
9d353e5 Michael Still  libvirt: take account of disks in migration data size
17e5911 Michael Still  Add deprecated_for_removal parm for deprecated 
neutron_ops
95940cc Michael Still  Don't allow instance to overcommit against itself
9cd9e66 Davanum Srinivas   Add rootwrap daemon mode support
c250aca Jay Pipes  Allow compute monitors in different namespaces
434ce2a Marian Horban  Added processing /compute URL
2c0a306 Dan Smith  Limit parallel live migrations in progress
da33ab4 Daniel P. Berrange libvirt: set caps on maximum live migration time
07c7e5c Daniel P. Berrange libvirt: support management of downtime during 
migration
60d08e6 Chuck Carmack  Add documentation for the nova-cells command.
ae5a329 Marian Horban  libvirt:Rsync remote FS driver was added
9a09674 Vladik Romanovsky  libvirt: enable virtio-net multiqueue
8a7b1e8 Chuck Carmack  :Add documentation for the nova-idmapshift command.
bf91d9f Sergey Nikitin Added missed '-' to the rest_api_version_history.rst
1b8a2e0 Dan Smith  Adding user_id handling to keypair index, show and 
create api calls
622a845 Gary KottonMetadata: support proxying loadbalancers
2f7403b Radoslav Gerganov  VMware: map one nova-compute to one VC cluster
ace11d3 Radoslav Gerganov  VMware: add serial port device
ab35779 Radomir Dopieral.. Handle SSL termination proxies for version list
6739df7 Dan Smith  Include DiskFilter in the default list
5e5ef99 Thang Pham VMware: Add support for swap disk
49a572a Ghanshyam Mann Show 'locked' information in server details
4252420 Gary KottonVMware: add resource limits for disk
f1f46a0 Gary KottonVMware: Resource limits for memory
7aec88c Gary KottonVMware: add support for cores per socket
bc3b6cc Maxim Nestratovlibvirt: rename parallels driver to virtuozzo
95f1d47 Mike DormanAdd console allowed origins setting
d0ee3ab Shiina, Hironori   libvirt:Add a driver API to inject an NMI
50c8f93 Radoslav Gerganov  Add MKS console support
abf20cd abhishekkekane Execute _poll_shelved_instances only if 
shelved_offload_time is > 0
973f312 Jay Pipes  Use stevedore for loading monitor extensions
9260ea1 andrewbogott   Include project_id in instance metadata.
d9c696a Dan Smith  Make evacuate leave a record for the source compute 
host to process
6fe967b Gary KottonCells: add instance cell registration utility to 
nova-manage
93a5a67 Sergey Nikitin Removed extra '-' from rest_api_version_history.rst
bad76e6 Gary KottonVMware: convert driver to use nova.objects.ImageMeta
56feb2b 

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

[Ryan Brown]

On 10/06/2015 05:15 PM, Thomas Goirand wrote:

Hi,

tl;dr: let's add a exception handling so that python-*client having
conflicting command names isn't a problem anymore, and "openstack help"
always work as much as it can.


Standardizing on "openstack   verb" would likely be 
the best solution for both the immediate problem and for the broader 
"naming stuff" issue.


Sharing a flat namespace is a recipe for pain with a growing number of 
projects. Devs and users are unlikely to use every project, they 
probably won't notice conflicts naturally except in cases like horizon.


If we look over the fence at AWS, you'll note that their nice unified 
CLI that stops the non-uniform `awk` bloodshed is namespaced.


- aws s3 ...
- aws cloudformation ...
- aws ec2 ...

A flat namespace was a mostly-fine idea when all integrated projects 
were expected to put their CLI in-tree in openstackclient. There were 
reviews, and discussions about what noun belonged to whom.


Noun conflict will only get worse: lots of projects will share words 
like stack, domain, user, container, address, and so on.


Namespaces are one honking great idea -- let's do more of those!


Longer version:

This is just a suggestion for contributors to python-openstackclient.

I saw a few packages that had conflicts with the namespace of others
within openstackclient. To the point that typing "openstack help" just
fails. Here's an example:

# openstack help
[ ...]
   project create  Create new project
   project delete  Delete project(s)
   project list   List projects
   project setSet project properties
   project show   Display project details
Could not load EntryPoint.parse('ptr_record_list =
designateclient.v2.cli.reverse:ListFloatingIPCommand')
'ArgumentParser' object has no attribute 'debug'

This first happened to me with saharaclient. Lucky, upgrading to latest
version fixed it. Then I had the problem with zaqarclient, which I fixed
with a few patches to its setup.cfg. Then now designate, but this time,
patching setup.cfg doesn't seem to cut it (ie: after changing the name
of the command, "openstack help" just fails).

Note: I don't care which project is at fault, this isn't the point here.
The point is that command name conflicts aren't handled (see below)
which is the problem.


+1, this isn't a problem specific to any project, it's systemic with 
flat namespacing.



With Horizon being a large consumer of nearly all python-*client
packages, removing one of them also removes Horizon in my CI which is
not what I want to (or can) do to debug a tempest problem. End of the
story: since Liberty b3, I never could have "openstack help" to work
correctly in my CI... :(


O.O That's unfortunate.


Which leads me to write this:

Since we have a very large amount of projects, with each and everyone of
them adding new commands to openstackclient, I would really nice if we
could have some kind of checks to make sure that conflicts are either 1/
not possible or 2/ handled gracefully.


To your (1) we could have a gate job that installs all the clients and 
fails on conflicts.


The downside of doing that without addressing the namespace problem is 
that there will be inconsistent conventions everywhere. Zaqar will have 
"openstack queue " but "openstack message flavor ..." which creates 
the sort of confusion a unified client is supposed to avoid.


A central reservation process for nouns won't really scale, but 
namespacing will because we *already* namespace projects.



Your thoughts?
Cheers,

Thomas Goirand (zigo)

P.S: It wasn't the point of this message, but do we have a fix for
designateclient? It'd be nice to have this fixed before Liberty is out.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
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] [neutron] New cycle started. What are you up to, folks?

[Assaf Muller]

On Wed, Oct 7, 2015 at 5:44 AM, Anna Kamyshnikova <
akamyshnik...@mirantis.com> wrote:

> I can' say that I have any great plans for this cycle, but I would like
> look into L3 HA (L3 HA + DVR) feature,
>

The agent side patch was merged yesterday, and the server side patch needs
reviews: https://review.openstack.org/#/c/143169/.
Your work in L3 HA land is greatly appreciated :)


> probably some bugfixes in this area and online data migration as logical
> continuation of online migration support that was done in Liberty.
>
> On Tue, Oct 6, 2015 at 8:34 PM, Ihar Hrachyshka 
> wrote:
>
>> > On 06 Oct 2015, at 19:10, Thomas Goirand  wrote:
>> >
>> > On 10/01/2015 03:45 PM, Ihar Hrachyshka wrote:
>> >> Hi all,
>> >>
>> >> I talked recently with several contributors about what each of us
>> plans for the next cycle, and found it’s quite useful to share thoughts
>> with others, because you have immediate yay/nay feedback, and maybe find
>> companions for next adventures, and what not. So I’ve decided to ask
>> everyone what you see the team and you personally doing the next cycle, for
>> fun or profit.
>> >>
>> >> That’s like a PTL nomination letter, but open to everyone! :) No
>> commitments, no deadlines, just list random ideas you have in mind or in
>> your todo lists, and we’ll all appreciate the huge pile of awesomeness no
>> one will ever have time to implement even if scheduled for Xixao release.
>> >>
>> >> To start the fun, I will share my silly ideas in the next email.
>> >>
>> >> Ihar
>> >
>> > Could we have oslo-config-generator flat neutron.conf as a release goal
>> > for Mitaka as well? The current configuration layout makes it difficult
>> > for distributions to catch-up with working by default config.
>>
>> Good idea. I think we had some patches for that. I will try to keep it on
>> my plate for M.
>>
>> Ihar
>>
>> __
>> 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
>>
>>
>
>
> --
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
>
> __
> 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] [tc] naming N and O releases nowish

[Sean Dague]

On 10/07/2015 08:57 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> We're starting to make plans for the next cycle. Long term plans are
>> getting made for details that would happen in one or two cycles.
>>
>> As we already have the locations for the N and O summits I think we
>> should do the naming polls now and have names we can use for this
>> planning instead of letters. It's pretty minor but it doesn't seem like
>> there is any real reason to wait and have everyone come up with working
>> names that turn out to be confusing later.
> 
> That sounds fair. However the release naming process currently states[1]:
> 
> """
> The process to chose the name for a release begins once the location of
> the design summit of the release to be named is announced and no sooner
> than the opening of development of the previous release.
> """
> 
> ...which if I read it correctly means we could pick N now, but not O. We
> might want to change that (again) first.
> 
> [1] http://governance.openstack.org/reference/release-naming.html

Right, it seems like we should change it so that we can do naming as
soon as the location is announced.

For projects like Nova that are trying to plan things more than one
cycle out, having those names to hang those features on is massively
useful (as danpb also stated). Delaying for bureaucratic reasons just
seems silly. :)

-Sean

-- 
Sean Dague
http://dague.net

__
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] [tc] naming N and O releases nowish

[Flavio Percoco]

On 07/10/15 15:02 +0200, Christian Berendt wrote:

On 10/07/2015 02:57 PM, Thierry Carrez wrote:

...which if I read it correctly means we could pick N now, but not O. We
might want to change that (again) first.


Is this list correct?

M = Tokyo
N = Atlanta


Austin, Texas.


O = Barcelona
P = ?

Christian.

--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
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


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [Glance] Process to clean up the review queue from non-active patches

[Flavio Percoco]

On 07/10/15 12:47 +, Bunting, Niall wrote:

From: Julien Danjou [jul...@danjou.info]
Sent: 07 October 2015 10:12

On Wed, Oct 07 2015, Flavio Percoco wrote:

> I'm not trying to solve the lack of reviews in Liberty by removing
> patches. What I'd like to do, though, is help to keep around patches
> that really matter.

I think that's where you are making a mistake. They are contributors,
like me or Victor, are knocking on the Glance doors for months now,
sending patches that resolve technical debt rather than adding new
debt^Wfeatures. Currently, these patches are not seen as important and
are often dismissed. So I'm pretty sure they are going to expire with
this new system.

Imagine that if you were merging patches from me, Victor, and people
like us, we would continue to send many of them, and mid-term, you'd get
some new blood on your core team.

What is proposed here is really focusing on making life easier for the
current core team which is in large majority inactive.

Don't read me wrong. I know you and Nikhil are both well-intentioned by
proposing that. I just think it's going to be worse, because it won't
improve much and you're going to push new contributors away.


If your patches are sitting there waiting for review once they get off
the top couple of pages they are likely to become buried, as they are
waiting for review. This is unlikely to benefit anyone.

How would an active user keep their patches it the active/up for review
state? By just posting bump comments?


No one should need to keep their reviews in the "active" queue as
there's not really an active queue. There are just tons of pages.

When a patch is marked as WIP because it hasn't been updated, the user
just needs to comment on it to keep it around. The WIP flag will be
removed then. The comment is needed because one cannot remove the WIP
flag of other users in gerrit.

If there are un-addressed comments, proposing a patch-set addressing
these comments would be the best/right way to remove the WIP flag.

Also, the WIP is not really mandatory. We could do away with it. I
think it'd be useful for users as it'd be clear that something is
happening in their patches when they load their personal dashboard.
Many folks ignore gerrit emails and they may miss the comment update,
which is what really worries me.


Any type of change Juilen is talking about could keep on being dismissed,
and this could end up in some sort of game to keep your patch above
the non-review line for it just to be ignored. This would definitely be
a bad thing, therefore I think any patches that are picked up as old,
should be reviewed before being marked as WIP. As this would mean if
the patch is moved out of WIP it would be less likely to get stuck in
some sort of loop as it has a review.

We also have to be careful about alienating contributors, we should make
sure they know why there work got marked WIP with a link to a wiki page
explaining the process. However if this forces a review, they may also
be happy that they eventually got a review on their patch.


The plan is not to just mark as WIP and be done with it. The plan is
to obviously provide enough information for users to know what the
next step is. I should've probably mentioned this in my original
email.



My thoughts,
Niall

Edit: As this did not send to the list originally.
Flavio points out that they aim to review patches that are unmarked wip,
I think that system could work as long as it avoids the problem of patches
potentially becoming stuck in a circle.

And It should be kept in mind that even old reviews could still be relevant,
and the best course of action may not to just mark them wip without thought.


Again, the plan is not to just go and blindly abandon. The above is
important and certainly being kept in mind.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Sofer Athlan-Guyot]

Rich Megginson  writes:

> On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:
>> Rich Megginson  writes:
>>
>>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:
 Gilles Dubreuil  writes:

> On 30/09/15 03:43, Rich Megginson wrote:
>> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
 Gilles Dubreuil  writes:

> On 15/09/15 06:53, Rich Megginson wrote:
>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>> Hi,
>>>
>>> Gilles Dubreuil  writes:
>>>
 A. The 'composite namevar' approach:

keystone_tenant {'projectX::domainY': ... }
  B. The 'meaningless name' approach:

   keystone_tenant {'myproject': name='projectX',
 domain=>'domainY',
 ...}

 Notes:
  - Actually using both combined should work too with the domain
 supposedly overriding the name part of the domain.
  - Please look at [1] this for some background between the two
 approaches:

 The question
 -
 Decide between the two approaches, the one we would like to
 retain for
 puppet-keystone.

 Why it matters?
 ---
 1. Domain names are mandatory in every user, group or project.
 Besides
 the backward compatibility period mentioned earlier, where no 
 domain
 means using the default one.
 2. Long term impact
 3. Both approaches are not completely equivalent which different
 consequences on the future usage.
>>> I can't see why they couldn't be equivalent, but I may be missing
>>> something here.
>> I think we could support both.  I don't see it as an either/or
>> situation.
>>
 4. Being consistent
 5. Therefore the community to decide

 Pros/Cons
 --
 A.
>>> I think it's the B: meaningless approach here.
>>>
   Pros
 - Easier names
>>> That's subjective, creating unique and meaningful name don't look
>>> easy
>>> to me.
>> The point is that this allows choice - maybe the user already has 
>> some
>> naming scheme, or wants to use a more "natural" meaningful name -
>> rather
>> than being forced into a possibly "awkward" naming scheme with "::"
>>
>>  keystone_user { 'heat domain admin user':
>>name => 'admin',
>>domain => 'HeatDomain',
>>...
>>  }
>>
>>  keystone_user_role {'heat domain admin user@::HeatDomain':
>>roles => ['admin']
>>...
>>  }
>>
   Cons
 - Titles have no meaning!
>> They have meaning to the user, not necessarily to Puppet.
>>
 - Cases where 2 or more resources could exists
>> This seems to be the hardest part - I still cannot figure out how
>> to use
>> "compound" names with Puppet.
>>
 - More difficult to debug
>> More difficult than it is already? :P
>>
 - Titles mismatch when listing the resources 
 (self.instances)

 B.
   Pros
 - Unique titles guaranteed
 - No ambiguity between resource found and their title
   Cons
 - More complicated titles
 My vote
 
 I would love to have the approach A for easier name.
 But I've seen the challenge of maintaining the providers behind the
 curtains and the confusion it creates with name/titles and when
 not sure
 about the domain we're dealing with.
 Also I believe that supporting self.instances consistently with
 meaningful name is saner.
 Therefore I vote B
>>> +1 for B.
>>>
>>> My view is that this should be the advertised way, but the other
>>> method
>>> (meaningless) should be there if the user need it.
>>>
>>> So as far as I'm concerned the two idioms should co-exist.  This
>>> would
>>> mimic what is possible with all puppet resources.  For instance
>>> you can:
>>>
>>>   file { '/tmp/foo.bar': ensure => present }
>>>
>>> and you can
>>>
>>>   file { 'meaningless_id': name => '/tmp/foo.bar', ensure =>
>>> present }
>

Re: [openstack-dev] [puppet] Running Debian packages on top of Trusty

[Thomas Goirand]

On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote:
> Hi,
> 
> On 2 Oct 2015, iberezovs...@mirantis.com wrote:
> 
>> Hello,
>>
>> thanks for bringing up this topic, that's what I wanted to discuss on
>> next puppet-openstack irc meeting.
>>
>> So, user case is following: users may want to install Debian packages
>> on Ubuntu host or vice versa,
>> the same problem can probably happen with CentOS, RHEL, Fedora; or
>> users may use non-official
>> package repositories with their own package (service) naming strategy
>> and so on.
>> Current situation in puppet modules is following that package and
>> service names are (let's say)
>> hardcoded in 'params' class (e.g. [0]). But in situation that I've
>> described it won't work.
>> Puppet will try to use Ubuntu names on Ubuntu host and it won't allow
>> to install and work with
>> Debian packages.
>>
>> I've researched puppet modules and found an interesting example which
>> can help to solve
>> this issue. It's implemented in puppetlabs mongodb module:
>> they have 'globals' class [1] that allows to override most part of
>> parameters from 'params' class [2].
>>
>> So, I've decided to rework this soltuion and use it in OpenStack
>> modules. As result I got draft patch
>> for ceilometer module [3]. By default we use parameters from 'params'
>> class, but every parameter
>> can be now overridden using 'globals' class.
>>
>> OpenStack Puppet team, what do you think about this solution?
> 
> Here is another track that you may follow.  For instance, to have access
> to the code variables there
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
> on an Ubuntu system you could just do this :
> 
> env FACTER_operatingsystem=Debian puppet agent -t 
> 
> You can override any facts on a system using the environment variable
> "FACTER_"
> 
> For instance on my system:
> 
>   $ facter -p 2>/dev/null | grep osfamily
>   osfamily => RedHat
> 
>   $ env FACTER_osfamily=Ubuntu facter -p 2>/dev/null | grep osfamily  
>   
>   osfamily => Ubuntu
> 
> Is this method wouldn't be enough for your purpose ?
>
> Check https://puppetlabs.com/blog/facter-part-1-facter-101 for more
> information.

I'm not sure, as I'm not a puppet specialist...

We don't want to overwrite the parameter about the distribution, because
some are really dependent of the distro. For example, the libvirt unix
group is libvirt in Debian, but libvirtd in Ubuntu. This difference has
to stay depending on the OS type, which we absolutely do not want to
overwrite. So we do want variables for the *OpenStack package type*
which is running on top of the operating system.

Will what you wrote above help in this regard?

Cheers,

Thomas Goirand (zigo)


__
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] [tc] naming N and O releases nowish

[Christian Berendt]

On 10/07/2015 02:57 PM, Thierry Carrez wrote:
> ...which if I read it correctly means we could pick N now, but not O. We
> might want to change that (again) first.

Is this list correct?

M = Tokyo
N = Atlanta
O = Barcelona
P = ?

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
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] [tc] naming N and O releases nowish

[Thierry Carrez]

Sean Dague wrote:
> We're starting to make plans for the next cycle. Long term plans are
> getting made for details that would happen in one or two cycles.
> 
> As we already have the locations for the N and O summits I think we
> should do the naming polls now and have names we can use for this
> planning instead of letters. It's pretty minor but it doesn't seem like
> there is any real reason to wait and have everyone come up with working
> names that turn out to be confusing later.

That sounds fair. However the release naming process currently states[1]:

"""
The process to chose the name for a release begins once the location of
the design summit of the release to be named is announced and no sooner
than the opening of development of the previous release.
"""

...which if I read it correctly means we could pick N now, but not O. We
might want to change that (again) first.

[1] http://governance.openstack.org/reference/release-naming.html

-- 
Thierry Carrez (ttx)

__
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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Sofer Athlan-Guyot]

Rich Megginson  writes:

> On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:
>> Rich Megginson  writes:
>>
>>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:
 Gilles Dubreuil  writes:

> On 30/09/15 03:43, Rich Megginson wrote:
>> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
 Gilles Dubreuil  writes:

> On 15/09/15 06:53, Rich Megginson wrote:
>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>> Hi,
>>>
>>> Gilles Dubreuil  writes:
>>>
 A. The 'composite namevar' approach:

keystone_tenant {'projectX::domainY': ... }
  B. The 'meaningless name' approach:

   keystone_tenant {'myproject': name='projectX',
 domain=>'domainY',
 ...}

 Notes:
  - Actually using both combined should work too with the domain
 supposedly overriding the name part of the domain.
  - Please look at [1] this for some background between the two
 approaches:

 The question
 -
 Decide between the two approaches, the one we would like to
 retain for
 puppet-keystone.

 Why it matters?
 ---
 1. Domain names are mandatory in every user, group or project.
 Besides
 the backward compatibility period mentioned earlier, where no 
 domain
 means using the default one.
 2. Long term impact
 3. Both approaches are not completely equivalent which different
 consequences on the future usage.
>>> I can't see why they couldn't be equivalent, but I may be missing
>>> something here.
>> I think we could support both.  I don't see it as an either/or
>> situation.
>>
 4. Being consistent
 5. Therefore the community to decide

 Pros/Cons
 --
 A.
>>> I think it's the B: meaningless approach here.
>>>
   Pros
 - Easier names
>>> That's subjective, creating unique and meaningful name don't look
>>> easy
>>> to me.
>> The point is that this allows choice - maybe the user already has 
>> some
>> naming scheme, or wants to use a more "natural" meaningful name -
>> rather
>> than being forced into a possibly "awkward" naming scheme with "::"
>>
>>  keystone_user { 'heat domain admin user':
>>name => 'admin',
>>domain => 'HeatDomain',
>>...
>>  }
>>
>>  keystone_user_role {'heat domain admin user@::HeatDomain':
>>roles => ['admin']
>>...
>>  }
>>
   Cons
 - Titles have no meaning!
>> They have meaning to the user, not necessarily to Puppet.
>>
 - Cases where 2 or more resources could exists
>> This seems to be the hardest part - I still cannot figure out how
>> to use
>> "compound" names with Puppet.
>>
 - More difficult to debug
>> More difficult than it is already? :P
>>
 - Titles mismatch when listing the resources 
 (self.instances)

 B.
   Pros
 - Unique titles guaranteed
 - No ambiguity between resource found and their title
   Cons
 - More complicated titles
 My vote
 
 I would love to have the approach A for easier name.
 But I've seen the challenge of maintaining the providers behind the
 curtains and the confusion it creates with name/titles and when
 not sure
 about the domain we're dealing with.
 Also I believe that supporting self.instances consistently with
 meaningful name is saner.
 Therefore I vote B
>>> +1 for B.
>>>
>>> My view is that this should be the advertised way, but the other
>>> method
>>> (meaningless) should be there if the user need it.
>>>
>>> So as far as I'm concerned the two idioms should co-exist.  This
>>> would
>>> mimic what is possible with all puppet resources.  For instance
>>> you can:
>>>
>>>   file { '/tmp/foo.bar': ensure => present }
>>>
>>> and you can
>>>
>>>   file { 'meaningless_id': name => '/tmp/foo.bar', ensure =>
>>> present }
>

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

[Bunting, Niall]

> From: Julien Danjou [jul...@danjou.info]
> Sent: 07 October 2015 10:12
> 
> On Wed, Oct 07 2015, Flavio Percoco wrote:
> 
> > I'm not trying to solve the lack of reviews in Liberty by removing
> > patches. What I'd like to do, though, is help to keep around patches
> > that really matter.
> 
> I think that's where you are making a mistake. They are contributors,
> like me or Victor, are knocking on the Glance doors for months now,
> sending patches that resolve technical debt rather than adding new
> debt^Wfeatures. Currently, these patches are not seen as important and
> are often dismissed. So I'm pretty sure they are going to expire with
> this new system.
> 
> Imagine that if you were merging patches from me, Victor, and people
> like us, we would continue to send many of them, and mid-term, you'd get
> some new blood on your core team.
> 
> What is proposed here is really focusing on making life easier for the
> current core team which is in large majority inactive.
> 
> Don't read me wrong. I know you and Nikhil are both well-intentioned by
> proposing that. I just think it's going to be worse, because it won't
> improve much and you're going to push new contributors away.

If your patches are sitting there waiting for review once they get off
the top couple of pages they are likely to become buried, as they are
waiting for review. This is unlikely to benefit anyone.

How would an active user keep their patches it the active/up for review
state? By just posting bump comments?

Any type of change Juilen is talking about could keep on being dismissed,
and this could end up in some sort of game to keep your patch above
the non-review line for it just to be ignored. This would definitely be
a bad thing, therefore I think any patches that are picked up as old,
should be reviewed before being marked as WIP. As this would mean if
the patch is moved out of WIP it would be less likely to get stuck in
some sort of loop as it has a review.

We also have to be careful about alienating contributors, we should make
sure they know why there work got marked WIP with a link to a wiki page
explaining the process. However if this forces a review, they may also
be happy that they eventually got a review on their patch.

My thoughts,
Niall

Edit: As this did not send to the list originally.
Flavio points out that they aim to review patches that are unmarked wip,
I think that system could work as long as it avoids the problem of patches
potentially becoming stuck in a circle.

And It should be kept in mind that even old reviews could still be relevant,
and the best course of action may not to just mark them wip without thought.
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Michał,

some comments in-line

>> - testrepository and related components are used in OpenStack Infra
>> environment for much more tasks than just running tests
> 
> If by "more tasks" you mean parallel testing, py.test also has a
> possibility to do that by pytest-xdist.

As Monthy mentioned, it’s not only about testing, it’s more about deeper 
integration with OpenStack Infra.


>> - py.test won’t be added to global-requirements so there always be a chance
>> of another dependency hell
> 
> As Igor Kalnitsky said, py.test doesn't have much requirements.
> https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
> It's only argparse, which already is in global requirements without
> any version pinned.

It’s not only about py.test, there is an up-to-date objective of sticking all 
requirements to global-requirements because we have big problems because of 
that every release.

> 
> Cheers,
> Michal
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [tc] naming N and O releases nowish

[Ed Leafe]

On Oct 7, 2015, at 6:47 AM, Sean Dague  wrote:

> We're starting to make plans for the next cycle. Long term plans are
> getting made for details that would happen in one or two cycles.
> 
> As we already have the locations for the N and O summits I think we
> should do the naming polls now and have names we can use for this
> planning instead of letters. It's pretty minor but it doesn't seem like
> there is any real reason to wait and have everyone come up with working
> names that turn out to be confusing later.

That makes sense, and it also has the advantage that it might give sufficient 
time to weed out undesirable names, such as what happened with the M naming 
process.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Michal Rostecki]

On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko  wrote:
> What I can extract now from this thread is that Fuel should switch to testr
> because of the following reasons:
>
> - Diversity of tools is a bad idea on a project scale

We already have diversity about frameworks (or lack of them) in
OpenStack. We have Pecan, Flask, wsgiref, Django.

> - testrepository and related components are used in OpenStack Infra
> environment for much more tasks than just running tests

If by "more tasks" you mean parallel testing, py.test also has a
possibility to do that by pytest-xdist.

> - py.test won’t be added to global-requirements so there always be a chance
> of another dependency hell

As Igor Kalnitsky said, py.test doesn't have much requirements.
https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
It's only argparse, which already is in global requirements without
any version pinned.

> - Sticking to global requirements is an idea which is in the scope of
> discussions around Fuel.
>
> Sounds like that’s the point when we should just file appropriate bugs and
> use testr in smaller components, e. g., Fuel Client, first and then try in
> in Nailgun.
>
>
> - romcheg
>

Cheers,
Michal

__
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] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

[Tim Bell]

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: 07 October 2015 13:25
> To: Tim Bell 
> Cc: Sean Dague ; OpenStack Development Mailing List
> (not for usage questions) ; openstack-
> operat...@lists.openstack.org
> Subject: Re: [Openstack-operators] [openstack-dev] [nova] Min libvirt for
> Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1
>
> On Wed, Oct 07, 2015 at 11:13:12AM +, Tim Bell wrote:
> >
> > Although Red Hat is no longer supporting RHEL 6 after Icehouse, a
> > number of users such as GoDaddy and CERN are using Software
> > Collections to run the Python 2.7 code.
>
> Do you have any educated guess as to when you might switch to deploying
> new OpenStack version exclusively on RHEL 7 ? I understand such a switch is
> likely to take a while so you can test its performance and reliability and 
> so on,
> but I'm assuming you'll eventually switch ?
>

I think we'll be all 7 by spring next year (i.e. when we install Liberty). The 
software collections work is not for the faint hearted and 7 brings lots of 
good things with it for operations so we want to get there as soon as 
possible. Thus, I think we'd be fine with a change in Mitaka (especially given 
the points you mention below).

> > However, since this modification would only take place when Mitaka
> > gets released, this would realistically give those sites a year to
> > complete migration to RHEL/CentOS 7 assuming they are running from one
> > of the community editions.
> >
> > What does the 1.1.1 version bring that is the motivation for raising
> > the limit ?
>
> If we require 1.1.1 we could have unconditional support for
>
>  - Hot-unplug of PCI devices (needs 1.1.1)
>  - Live snapshots (needs 1.0.0)
>  - Live volume snapshotting (needs 1.1.1)
>  - Disk sector discard support (needs 1.0.6)
>  - Hyper-V clock tunables (needs 1.0.0 & 1.1.0)
>
> If you lack those versions, in case of hotunplug, and live volume snapshots
> we just refuse the corresponding API call. With live snapshots we fallback 
> to
> non-live snapshots. For disk discard and hyperv clock we just run with
> degraded functionality. The lack of hyperv clock tunables means Windows
> guests will have unreliable time keeping and are likely to suffer random
> BSOD, which I think is a particularly important issue.
>
> And of course we remove a bunch of conditional logic from Nova which
> simplifies the code paths and removes code paths which rarely get testing
> coverage.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ 
> :|
> |: http://libvirt.org  -o- http://virt-manager.org 
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ 
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc 
> :|


smime.p7s
Description: S/MIME cryptographic signature
__
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] [tc] naming N and O releases nowish

[Daniel P. Berrange]

On Wed, Oct 07, 2015 at 07:47:31AM -0400, Sean Dague wrote:
> We're starting to make plans for the next cycle. Long term plans are
> getting made for details that would happen in one or two cycles.
> 
> As we already have the locations for the N and O summits I think we
> should do the naming polls now and have names we can use for this
> planning instead of letters. It's pretty minor but it doesn't seem like
> there is any real reason to wait and have everyone come up with working
> names that turn out to be confusing later.

Yep, it would be nice to have names decided further in advance than
we have done in the past. It saves having to refer to N, O
all the time, or having people invent their own temporary names like
Lemming and Muppet...

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [tc] naming N and O releases nowish

[Flavio Percoco]

On 07/10/15 07:47 -0400, Sean Dague wrote:

We're starting to make plans for the next cycle. Long term plans are
getting made for details that would happen in one or two cycles.

As we already have the locations for the N and O summits I think we
should do the naming polls now and have names we can use for this
planning instead of letters. It's pretty minor but it doesn't seem like
there is any real reason to wait and have everyone come up with working
names that turn out to be confusing later.


Unless there's a good reason for not doing this, I'm ok with the
above.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [nova] FYI: Updated Mitaka specs template

[Daniel P. Berrange]

FYI anyone who is pushing specs for review against Mitaka should be aware
that yesterday we merged a change to the spec template. Specifically we
have removed the "Project priority" section of the template, since it has
been a source of much confusion, cannot be filled out until after the
summit decides on priorities and priority specs are already tracked via
etherpad.

So if anyone has a spec up for review, simply delete the "Project priority"
section of your template when pushing your next update of it. It should
have already only contained the word "None" in any case :-)

Once priorities are decided we will track priority specs via this page:

  https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

Regards,
Daniel

[1] https://review.openstack.org/#/c/230916/
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [tc] naming N and O releases nowish

[Sean Dague]

We're starting to make plans for the next cycle. Long term plans are
getting made for details that would happen in one or two cycles.

As we already have the locations for the N and O summits I think we
should do the naming polls now and have names we can use for this
planning instead of letters. It's pretty minor but it doesn't seem like
there is any real reason to wait and have everyone come up with working
names that turn out to be confusing later.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

[Sean Dague]

On 10/07/2015 07:31 AM, Kai Qiang Wu wrote:
> Hi Sean,
> 
> 
> Do you mean all other projects, like Barbican (non-standard
> implementation with copy/paste ways) would break in devstack ?

Yes, that's what I mean. The copy/paste method will not work after that
point, which is why there is a heads up now to get things fixed.

-Sean

-- 
Sean Dague
http://dague.net

__
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] py.test vs testrepository

[Roman Prykhodchenko]

Yuri,

sticking to global requirements and interacting deeper with OpenStack Infra are 
up-to-date objectives for Fuel and those are pretty much technical question. 
However, software development is not only solving technical tasks, it also 
incorporates interaction between people and other teams so you cannot separate 
those thinks, even if it sounds too much like politics.

- romcheg

> 7 жовт. 2015 р. о 13:20 Yuriy Taraday  написав(ла):
> 
> On Wed, Oct 7, 2015 at 12:51 AM Monty Taylor  > wrote:
> On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote:
> > I've already wrote in the review that caused this thread that I do not want
> > to blindly follow rules for using one or another. We should always consider
> > technical requirements. And I do not see a reason to leave py.test (and
> > nobody
> > show me such reason) and replace it with something else.
> 
> Hi!
> 
> The reason is that testrepository is what OpenStack uses and as I
> understand it, Fuel wants to join the Big Tent.
> 
> It saddens me that once again choice of library is being forced upon a 
> project based on what other projects use, not on technical merit. py.test is 
> more than just a (way better) test runner, it allows to write tests with less 
> boilerplate and more power. While its features are not extensively used in 
> Fuel code, switching to testr would still require changing test logic which 
> is generally bad (that's why mox is still in use in OpenStack). Can we avoid 
> that?
> 
> The use of testr is documented in the Project Testing Interface:
> 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/project-testing-interface.rst#n78
>  
> 
> 
> There are many reasons for it, but in large part we are continually
> adding more and more tools to process subunit output across the board in
> the Gate. subunit2sql is an important one, as it will be feeding into
> expanded test result dashboards.
> 
> We also have zuul features in the pipeline to be able to watch the
> subunit streams in real time to respond more quickly to issues in test runs.
> 
> We also have standard job builders based around tox and testr. Having
> project divergence in this area is a non-starter when there are over 800
> repositories.
> 
> So it seems that all that's needed to keep py.test as an option is a plugin 
> for py.test that generates subunit stream like Robert said, is that right?
> 
> In short, while I understand that this seems like an area where a
> project can do whatever it wants to, it really isn't. If it's causing
> you excessive pain, I recommend connecting with Robert on ways to make
> improvements to testrepository. Those improvements will also have the
> effect of improving life for the rest of OpenStack, which is also a
> great reason why we all use the same tools rather than foster an
> environment of per-project snowflakes.
> 
> I wouldn't call py.test a snowflake. It's a very well-established testing 
> tool and OpenStack projects could benefit from using it if we integrate it 
> with testr well.
> __
> 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 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

[Daniel P. Berrange]

On Wed, Oct 07, 2015 at 07:17:09AM -0400, Sean Dague wrote:
> On 10/07/2015 07:02 AM, Daniel P. Berrange wrote:
> > On Wed, Oct 07, 2015 at 06:55:44AM -0400, Sean Dague wrote:
> >> Isn't RHEL 7.1 just an update stream on RHEL 7.0? It seems a little
> >> weird to keep the 1.1.1 support instead of just going up to 1.2.2.
> > 
> > Yes & no. There are in fact two different streams users can take
> > with RHEL. They can stick on a bugfix only stream, which would be
> > 7.0.1, 7.0.2, etc, or they can take the bugfix + features stream
> > which is 7.1, 7.2, etc. They can't stick on the bugfix only
> > stream forever though, so given that by time Nxx is released
> > 7.2 will also be available, we are probably justified in dropping
> > 7.0 support.
> > 
> > The next oldest distro libvirt would be Debian Wheezy-backports at 1.2.1.
> > If we are happy to force Debian users to Jessie, then next oldest after
> > that is Ubuntu 14.04 LTS with 1.2.2.
> 
> 1.2.1 seems reasonable, it's also probably worth asking the Debian folks
> if they can put 1.2.2 into the backport stream.
> 
> I think it might also be worth pre-declaring the O minimum as well so
> that instead of just following the distros we are signaling what we'd
> like in there. Because in the O time frame it feels like 1.2.8 would be
> a reasonable minimum, and that would give distros a year of warning to
> ensure they got things there.

FYI I extended the distro support wiki page with details of the min
libvirt we have required in each Nova release:

  
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Nova_release_min_version

We could just add a row for O release with an educated guess
as to a possible target, to give people an idea of where we're
likely to go.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

[Neil Jerram]

On 07/10/15 12:26, Sean Dague wrote:
> On 10/07/2015 07:17 AM, Neil Jerram wrote:
>> On 07/10/15 12:12, Sean Dague wrote:
>>> We've had devstack plugins for about 10 months. They provide a very "pro
>>> user" experience by letting you enable arbitrary plugins with:
>>>
>>> enable_plugin $name git://git.openstack.org/openstack/$project [$branch]
>>>
>>> They have reasonable documentation here
>>> http://docs.openstack.org/developer/devstack/plugins.html
>> enable_plugin is indeed great.
>>
>> A related question, if I may: has there been any discussion of
>> backporting enable_plugin support to e.g. DevStack's stable/juno
>> branch?  It would be cool to be able to use a DevStack plugin with
>> earlier OpenStack releases.
>>
>> Thanks,
>> Neil
> stable/juno is very close to eol (I think there are only a couple of
> months left), so I don't think that it's worth the backporting effort at
> this time. If someone else did it, I'd review the code, but I don't
> think it's a priority.
>
>   -Sean
>

OK, thanks for this answer.

Neil


__
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] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

[Kai Qiang Wu]

Hi Sean,


Do you mean all other projects, like Barbican (non-standard implementation
with copy/paste ways) would break in devstack ?




Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Sean Dague 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/10/2015 07:13 pm
Subject:[openstack-dev] [all] devstack extras.d support going away at
M1 - your jobs may break if you rely on it in your dsvm jobs



Before we had devstack plugins, we had a kind of janky extras.d
mechanism. A bunch of projects implemented some odd copy / paste
mechanism in test jobs to use that in unexpected / unsupported ways.

We've had devstack plugins for about 10 months. They provide a very "pro
user" experience by letting you enable arbitrary plugins with:

enable_plugin $name git://git.openstack.org/openstack/$project [$branch]

They have reasonable documentation here
http://docs.openstack.org/developer/devstack/plugins.html

We're now getting to the point where some projects like Magnum are
getting into trouble trying to build jobs with projects like Barbican,
because Magnum uses devstack plugins, and Barbican has some odd non
plugin copy paste method. Building composite test jobs are thus really
wonky.

This is a heads up that at Mitaka 1 milestone the extras.d support will
be removed. The copy / paste method was never supported, and now it will
explicitly break. Now would be a great time for teams to prioritize
getting to the real plugin architecture.

 -Sean

--
Sean Dague
http://dague.net

__
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] py.test vs testrepository

[Yuriy Taraday]

On Wed, Oct 7, 2015 at 3:14 AM Monty Taylor  wrote:

> On 10/06/2015 06:01 PM, Thomas Goirand wrote:
> > On 10/06/2015 01:14 PM, Yuriy Taraday wrote:
> >> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko  >> > wrote:
> >>
> >>  Atm I have the following pros. and cons. regarding testrepository:
> >>
> >>  pros.:
> >>
> >>  1. It’s ”standard" in OpenStack so using it gives Fuel more karma
> >>  and moves it more under big tent
> >>
> >>
> >> I don't think that big tent model aims at eliminating diversity of tools
> >> we use in our projects. A collection of web frameworks used in big tent
> >> is an example of that.
> >
> >  From the downstream distro point of view, I don't agree in general, and
> > with the web framework in particular. (though it's less a concern for
> > the testr vs pbr). We keep adding dependencies and duplicates, but never
> > remove them. For example, tablib and suds/sudsjurko need to be removed
> > because they are not maintainable, there's not much work to do so, but
> > nobody does the work...
>
> The Big Tent has absolutely no change in opinion about eliminating
> diversity of tools. OpenStack has ALWAYS striven to reduce diversity of
> tools. Big Tent applies OpenStack to more things that request to be part
> of OpenStack.
>
> Nothing has changed in the intent.
>
> Diversity of tools in a project this size is a bad idea. Always has
> been. Always will be.
>
> The amount of web frameworks in use is a bug.
>

I'm sorry, that was my mistake. I just can't remember any project that was
declined place under big tent (or integrated) because of a library in use.
__
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] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

[Daniel P. Berrange]

On Wed, Oct 07, 2015 at 11:13:12AM +, Tim Bell wrote:
> 
> Although Red Hat is no longer supporting RHEL 6 after Icehouse, a number of
> users such as GoDaddy and CERN are using Software Collections to run the
> Python 2.7 code.

Do you have any educated guess as to when you might switch to deploying
new OpenStack version exclusively on RHEL 7 ? I understand such a switch
is likely to take a while so you can test its performance and reliability
and so on, but I'm assuming you'll eventually switch ?

> However, since this modification would only take place when Mitaka gets
> released, this would realistically give those sites a year to complete
> migration to RHEL/CentOS 7 assuming they are running from one of the
> community editions.
> 
> What does the 1.1.1 version bring that is the motivation for raising the
> limit ?

If we require 1.1.1 we could have unconditional support for

 - Hot-unplug of PCI devices (needs 1.1.1)
 - Live snapshots (needs 1.0.0)
 - Live volume snapshotting (needs 1.1.1)
 - Disk sector discard support (needs 1.0.6)
 - Hyper-V clock tunables (needs 1.0.0 & 1.1.0)

If you lack those versions, in case of hotunplug, and live volume
snapshots we just refuse the corresponding API call. With live
snapshots we fallback to non-live snapshots. For disk discard and
hyperv clock we just run with degraded functionality. The lack of
hyperv clock tunables means Windows guests will have unreliable
time keeping and are likely to suffer random BSOD, which I think
is a particularly important issue.


And of course we remove a bunch of conditional logic from Nova
which simplifies the code paths and removes code paths which
rarely get testing coverage.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] py.test vs testrepository

[Thomas Goirand]

On 10/07/2015 02:06 AM, Monty Taylor wrote:
> The Big Tent has absolutely no change in opinion about eliminating
> diversity of tools. OpenStack has ALWAYS striven to reduce diversity of
> tools. Big Tent applies OpenStack to more things that request to be part
> of OpenStack.
> 
> Nothing has changed in the intent.
> 
> Diversity of tools in a project this size is a bad idea. Always has
> been. Always will be.
> 
> The amount of web frameworks in use is a bug.

Thanks a lot Monty. I am very happy that you have this opinion.

In such a case, could Zaqar get rid of Falcon? :)

Thomas


__
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