Re: [openstack-dev] [qa][FWaaS][Neutron]Firewall service disabled on gate

[Sumit Naiksatam]

Yair, The FWaaS tempest tests were not planned for H release. They are
planned for the current release (hence the blueprint) and some of us were
working towards them. This is also a standing discuss item this during the
the FWaaS sub team meetings.

Thanks,
~Sumit.


On Sun, Dec 29, 2013 at 2:41 PM, Salvatore Orlando wrote:

> I reckon the decision of keeping neutron's firewall API out of gate tests
> was reasonable for the Havana release.
> I might be argued the other 'experimental' service, VPN, is already
> enabled on the gate, but that did not happen before proving the feature was
> reliable enough to not cause gate breakage.
>
> If we can confidently say the same for the firewall extension now, I would
> agree on enabling it on gate tests as well.
>
> Salvatore
>
>
> On 29 December 2013 22:22, Yair Fried  wrote:
>
>> Hi,
>> I'm trying to push a firewall api test [1] and I see it cannot run on the
>> current gate.
>> I was FWaaS is disabled since it broke the gate.
>> Does anyone knows if this is still an issue?
>> If so - how do we overcome this?
>> I would like to do some work on this service (scenarios) and don't want
>> to waste time if this is something that cannot be done right now
>>
>> Thank you
>> Yair
>>
>> [1] https://review.openstack.org/64362
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Murano] Next meeting is scheduled on January 14

[Serg Melikyan]

Due to New Year holidays we postpone all our meetings till January 7, our
next meeting is scheduled on January 14. Happy New Year!

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thomas Goirand]

On 12/28/2013 11:21 PM, Day, Phil wrote:
> Hi Folks,
> 
>  
> 
> I know it may seem odd to be arguing for slowing down a part of the
> review process, but I’d like to float the idea that there should be a
> minimum review period for patches that change existing functionality in
> a way that isn’t backwards compatible.  
> 
>  
> 
> The specific change that got me thinking about this is
> https://review.openstack.org/#/c/63209/ which changes the default fs
> type from ext3 to ext4.I agree with the comments in the commit
> message that ext4 is a much better filesystem, and it probably does make
> sense to move to that as the new default at some point, however there
> are some old OS’s that may still be in use that don’t support ext4.  By
> making this change to the default without any significant notification
> period this change has the potential to brake existing images and
> snapshots.  It was already possible to use ext4 via existing
> configuration values, so there was no urgency to this change (and no
> urgency implied in the commit messages, which is neither a bug or
> blueprint).

IMO, switching to ext4 is a very bad idea, because ext4 doesn't support
online resize2fs, while ext3 does, so switching to ext4 is breaking
cloud-init!!!

Thomas


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

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

[Robert Collins]

On 30 December 2013 22:51, Thomas Goirand  wrote:

> IMO, switching to ext4 is a very bad idea, because ext4 doesn't support
> online resize2fs, while ext3 does, so switching to ext4 is breaking
> cloud-init!!!

It supports it just fine. (I just resized a 4TB volume to 10TB)...
online. But even if it didn't, the ephemeral volume is formatted by
the hypervisor, the one where resize is needed is the root device,
which is separate.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [All] tagged commit messages

[Flavio Percoco]

On 29/12/13 19:24 -0800, John Dickinson wrote:


On Dec 29, 2013, at 5:24 PM, Michael Still  wrote:


On Mon, Dec 30, 2013 at 11:51 AM, John Dickinson  wrote:

On Dec 29, 2013, at 2:05 PM, Michael Still  wrote:


[snip]


Perhaps step one is to work out what tags we think are useful and at
what time they should execute?


I think this is exactly what I don't want. I don't want a set of predefined 
tags.


[snip]

Super aggressive trimming, because I want to dig into this one bit some more...

I feel like anything that requires pro-active action from the target
audience will fail. For example, in nova we've gone through long
cycles with experimental features where we've asked deployers to turn
on new features in labs and report problems before we turn it on by
default. They of course don't.

So... I feel there is value in a curated list of tags, even if we
allow additional tags (a bit like launchpad). In fact, the idea of a
"DeployImpact" tag for example really works for me. I'm very tempted
to implement that one in notify_impact now.


Yup, I understand and agree with where you are coming from. Let's discuss 
DeployImpact as an example.

First, I like the idea of some set of curated tags (and you'll see why at the 
end of this email). Let's have a way that we can tag a commit as having a 
DeployImpact. Ok, what does that mean? In some manner of speaking, _every_ 
commit has a deployment impact. So maybe just things that affect upgrades? Is 
that changes? New features? Breaking changes only (sidebar: why would these 
sort of changes ever get merged anyway? moving on...)? My point is that a 
curated list of tags ends up being fairly generic to the point of not being too 
useful.

Ok, we figured out the above questions (ie when to use DeployImpact and when to 
not use it). Now I'm a deployer and packager (actually not hypothetical, since 
my employer is both for Swift), so what do I do? Do I have to sign up for some 
sort of thing? Does this mean a gerrit code review cycle to some -infra 
project? That would be a pretty high barrier for getting access to that info. 
Or maybe the change-merged action for a DeployImpact tag simply sends an email 
to a new DeployImpact mailing list or puts a new row in a DB somewhere that is 
shown on some page ever time I load it? In that case, I've still got to sign up 
for a new mailing list (and remember to not filter it and get everyone in my 
company who does deployments to check it) or remember to check a particular 
webpage before I do a deploy.

Maybe I'm thinking about this wrong way. Maybe the intended audience is the 
rest of the OpenStack dev community. In that case, sure, now I have a way to 
find DeployImpact commits. That's nice, but what does that get me? I already 
see all the patches in my email and on my gerrit dashboard. Being able to 
filter the commits is nice, but constraining that to an approved list of tags 
seems heavy-handed.

So while I like the idea of a curated list of tags, in general, I don't think they 
lessen the burden for the intended audience (the intended audience being people not 
in the dev/contributor community but rather those deploying and using the code). 
That's why a tool that can parse git commit messages seems simple and flexible enough 
to meet the needs of deployers (eg run `git log  | tagged-search 
deployimpact` before packaging) without requiring the overhead of managing a curated 
tag list via code repo changes (as DocImpact is today).

All that being said, I'll poke some holes in my own idea. The problem with my 
idea is letting deployers know what tags they should actually search for. In 
this case, there probably should be some curated list of high-level tags that 
should be used across all OpenStack projects. In other words, if I use 
deploy-change on my patch and you use DeploymentImpact, then what does a 
packager/deployer search for? There should be some set of tags with guidelines 
for their usage on the wiki. I'd propose starting with ConfigDefaultChanged, 
DependencyChanged, and NewFeature.




I like the idea of having custom tags. I'm a bit concerned about the
implications this might have with cross-project collaborations. I
mean, people contributing to more projects will have to be aware of
the many possible differences in this area.

That being said, I can think of some cases where we this could be
useful for other projects. However, I'd encourage to keep common tags
documented somewhere, perhaps this common tags shouldn't be part of
the `Tags:` 'field', which you already mentioned above.

Cheers,
FF

--
@flaper87
Flavio Percoco


pgpApEvIIWXr1.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Common SSH

[Flavio Percoco]

On 26/12/13 20:05 +0200, Sergey Skripnick wrote:


Hi all,

I'm surprised there is no common ssh library in oslo so I filed this
blueprint[0]. I would be happy to address any comments/suggestions.


[0] https://blueprints.launchpad.net/oslo/+spec/common-ssh-client



If you think the BP is ready to be reviewed - which I bet you do since
you already submitted a patch - please, set a target milestone and
series. That'll make it pop-up into the BPs review process.

Cheers,
FF

--
@flaper87
Flavio Percoco


pgp1AuikxNtkz.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Proposal for dd disk i/o performance blueprint of cinder.

[Flavio Percoco]

Hey,

Please, tag emails' subjects.

Thanks,
FF

On 26/12/13 16:56 +0900, cosmos cosmos wrote:
Hello. 


My name is Rucia for Samsung SDS.


I had in truouble in volume deleting.

I am developing for supporting big data storage such as hadoop in lvm.


it use as a full disk io for deleting of cinder lvm volume because of dd the
high disk I/O affects the other hadoop instance on same host.


If using dd for deleting the volume,  it takes too much time for deleting of
cinder lvm volume because of dd.

Cinder volume is 200GB for supporting hadoop master data.

When i delete cinder volume in using 'dd if=/dev/zero of $cinder-volume count=
100 bs=1M' it takes about 30 minutes.


So When I delete the volume, i added disk id scheduler, ionice.

Thanks.

https://blueprints.launchpad.net/cinder/+spec/
when-deleting-volume-dd-performance




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



--
@flaper87
Flavio Percoco


pgp_jkgxEzCa6.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

[Day, Phil]

Sent from Samsung Mobile



 Original message 
From: Pádraig Brady 
Date:
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "Day, Phil" 
Subject: Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to 
ext4



> -  It causes inconsistent behaviour in the system, as any existing 
> "default" backing files will have ext3 in them, so a VM will now get either 
> ext3 or 3ext4 depending on whether the host they get created on already has a 
> backing file of the required size or not.   I don't think the existing design 
> ever considered the default FS changing - maybe we shouldn’t have files that 
> include "default" as the file system type if it can change over time, and the 
> name should always reflect the FS type.

 > I'm not sure this is a practical issue since ephemeral storage is built up 
 > from blank by each instance

Maybe it varies by hypervisor; my understanding is that at least in libvirt the 
ephemeral disks are cow layers on a shared common backing file that has the 
file system in it.  The naming convention includes the size and fs type or 
"default" and is only created once per size-fs combination.

So this is a real issue - I think that maybe the eventual change to ext4 need 
to be combined withoving away from "default"  in the file name.

Phil

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

[openstack-dev] [OpenStack][HEAT][Template][Dashboard] HEAT editing dashboard

[Jay Lau]

Hi,

I noticed that there is a bp
https://blueprints.launchpad.net/horizon/+spec/heat-template-managementwhich
want to improve the UI for HEAT template, does anyone working on this?

If not, does anyone who have some mock up dashboard for editing heat
template?

Thanks,

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

[openstack-dev] Bogus -1 scores from turbo hipster

[Michael Still]

Hi.

The purpose of this email to is apologise for some incorrect -1 review
scores which turbo hipster sent out today. I think its important when
a third party testing tool is new to not have flakey results as people
learn to trust the tool, so I want to explain what happened here.

Turbo hipster is a system which takes nova code reviews, and runs
database upgrades against them to ensure that we can still upgrade for
users in the wild. It uses real user datasets, and also times
migrations and warns when they are too slow for large deployments. It
started voting on gerrit in the last week.

Turbo hipster uses zuul to learn about reviews in gerrit that it
should test. We run our own zuul instance, which talks to the
openstack.org zuul instance. This then hands out work to our pool of
testing workers. Another thing zuul does is it handles maintaining a
git repository for the workers to clone from.

This is where things went wrong today. For reasons I can't currently
explain, the git repo on our zuul instance ended up in a bad state (it
had a patch merged to master which wasn't in fact merged upstream
yet). As this code is stock zuul from openstack-infra, I have a
concern this might be a bug that other zuul users will see as well.

I've corrected the problem for now, and kicked off a recheck of any
patch with a -1 review score from turbo hipster in the last 24 hours.
I'll talk to the zuul maintainers tomorrow about the git problem and
see what we can learn.

Thanks heaps for your patience.

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

[Pádraig Brady]

On 12/30/2013 12:39 AM, Pádraig Brady wrote:
> On 12/29/2013 08:12 AM, Day, Phil wrote:
>> Hi Folks,
>>
>> As highlighted in the thread “minimal review period for functional changes” 
>> I’d like to propose that change is https://review.openstack.org/#/c/63209/ 
>> is reverted because:
>>
>> -  It causes inconsistent behaviour in the system, as any existing 
>> "default" backing files will have ext3 in them, so a VM will now get either 
>> ext3 or 3ext4 depending on whether the host they get created on already has 
>> a backing file of the required size or not.   I don't think the existing 
>> design ever considered the default FS changing - maybe we shouldn’t have 
>> files that include "default" as the file system type if it can change over 
>> time, and the name should always reflect the FS type.
> 
> I'm not sure this is a practical issue since ephemeral storage is built up 
> from blank by each instance

Phil> Maybe it varies by hypervisor; my understanding is that at least in 
libvirt the ephemeral disks are cow layers on a shared common backing file that 
has the file system in it.
Phil> The naming convention includes the size and fs type or "default" and is 
only created once per size-fs combination.
Phil> So this is a real issue - I think that maybe the eventual change to ext4 
need to be combined withoving away from "default"  in the file name.

Right, what I meant by each instance building ephemeral up from blank each time,
is that each instance will go from either a blank ext3 or blank ext4 each time,
so if they support ext4 then there should be no practical issue. Now agreed 
there
is a consistency issue, which could have performance consistency issues for 
example,
so it's not ideal.

To be complete, for the libvirt case we don't even use these persistent backing 
files
for ephemeral disks if use_cow_images=False or with LVM backing.

To be most general and avoid this consistency issue, I suppose we could change 
the
name format for these cached CoW base images from ephemeral_10_default, 
ephemeral_20_linux etc.
to 'ephemeral_20_' + md5(mkfs_command)[:7]
That would impose a performance hit at first boot with this new logic,
and we'd have to double check that the cache cleaning logic would
handle removing unused older format images.
Alternatively we might just document this issue and put the onus on
users to clean these cached ephemeral disk on upgrade
(the commit is already tagged as DocImpact).

thanks,
Pádraig.

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

Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

[Tim Bell]

There is a big difference between DocImpact (i.e. needing some improvements to 
the doc) and putting the migration effort onto the users without automation to 
help... as I have said previously, while this (and others like it) may be a 
worthwhile change in isolation, making the upgrade process more difficult needs 
to be balanced with the technical benefits of the change. These questions need 
to be part of the review approval.

Tim

> -Original Message-
> From: Pádraig Brady [mailto:p...@draigbrady.com]
> Sent: 30 December 2013 14:00
> To: OpenStack Development Mailing List (not for usage questions); Day, Phil
> Subject: Re: [openstack-dev] [nova] - Revert change of default ephemeral fs 
> to ext4
> 
...

> To be most general and avoid this consistency issue, I suppose we could 
> change the name format for these cached CoW base images from
> ephemeral_10_default, ephemeral_20_linux etc.
> to 'ephemeral_20_' + md5(mkfs_command)[:7] That would impose a performance 
> hit at first boot with this new logic, and we'd have to
> double check that the cache cleaning logic would handle removing unused older 
> format images.
> Alternatively we might just document this issue and put the onus on users to 
> clean these cached ephemeral disk on upgrade (the commit
> is already tagged as DocImpact).
> 
> thanks,
> Pádraig.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Horizon] "import only module" message and #noqa

[Gabriel pettier]

Hi

Reading horizon's code and recent reviews, i'm under the impression that 
it's a common practice to use #noqa to bypass the "import only modules" 
qa message, i'm unconvinced of the advantages of this policy (i think 
the namespace is often cleaner when one import only the symbols needed 
from the modules), so i think this policy could be removed, by adding 
"H302" to the list of ignored errors in tox.ini.

This would allow removing a lot of #noqa comments, making for cleaner 
code.

If there are significant advantages to this policy, however, it should 
be made more consistently applied to fix all these imports.

Regards

-- 
Gabriel Pettier
Software Engineer at CloudWatt.com 
06 85 10 36 34

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

Re: [openstack-dev] [openstack][keystone] Is the user password too simple?

[Thomas Goirand]

On 12/30/2013 02:55 PM, li-zheming wrote:
> hi all:
>   when create user, you can set user password. You can set password
> as a simple word 'a'. the
> password is too simple but not limit. if someone want to steal your
> password, it is so easily(such as exhaustion).
> I consider that it must be limited when set password, like this:
>   1. inlcude uppper and lower letters
>   2. include nums
>   3. include particular symbol，such as  '_','&'
>   4. the length>8
> administor can set the password rule.

Hi,

If you want to check for password complexity, do it the correct way. I'm
used to *always* use a password generator that uses only lower case, and
removes chars that can be confused with one another, so that you don't
have l and 1, or O and 0 in my passwords. Yet, they are high entropy and
long. If you just force me to add upper+lower case and add symbols, then
you are just annoying me even with my very good passwords.

> I want to  provide a BP about  this issue. can you give me some advice
> or ideas??

Please use a password entropy function. Something like this:
https://pypi.python.org/pypi/cracklib

Thomas


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

Re: [openstack-dev] [Horizon] "import only module" message and #noqa

[Gabriel pettier]

So Tatiana pointed 
http://lists.openstack.org/pipermail/openstack-dev/2013-June/thread.html#9993 
to me, and from there i went on to read 
http://lists.openstack.org/pipermail/openstack-dev/2013-August/thread.html#13074
 
and i can see valid points for H302, even if it annoy me sometime, if 
it's better for reviews, i understand.

Sorry for the noise

On Mon, Dec 30, 2013 at 03:43:03PM +0100, Gabriel pettier wrote:
> Hi
> 
> Reading horizon's code and recent reviews, i'm under the impression that 
> it's a common practice to use #noqa to bypass the "import only modules" 
> qa message, i'm unconvinced of the advantages of this policy (i think 
> the namespace is often cleaner when one import only the symbols needed 
> from the modules), so i think this policy could be removed, by adding 
> "H302" to the list of ignored errors in tox.ini.
> 
> This would allow removing a lot of #noqa comments, making for cleaner 
> code.
> 
> If there are significant advantages to this policy, however, it should 
> be made more consistently applied to fix all these imports.
> 
> Regards
> 
> -- 
> Gabriel Pettier
> Software Engineer at CloudWatt.com 
> 06 85 10 36 34
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Gabriel Pettier
Software Engineer at CloudWatt.com 
06 85 10 36 34

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

Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages

[David Kranz]

On 12/29/2013 07:45 PM, Jeremy Stanley wrote:

On 2013-12-29 15:09:24 -0500 (-0500), David Kranz wrote:
[...]

Looking at the docs I see the warning that you can't put this
in the search field so I tried putting it directly in the url like
the other parameters but it was ignored. Is there indeed a way to
search for only patches that contain changes to files that match a
regexp?

As the documentation says, "Currently this operator is only
available on a watched project..."

https://review.openstack.org/Documentation/user-search.html#_search_operators

The implication being it's only implemented for filtering project
watches--the "Only if" field you see on the Watched Projects setting
page.

https://review.openstack.org/#/settings/projects

I get that but it seems like this is a single field per gerrit user. Is 
that not true? If true, it is not useful because the point is that we 
want to be able to filter reviews that contain changes to tests for a 
particular project. I need to make different kinds of requests, like 
with a bookmark for each one. Is it possible?


 -David

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

Re: [openstack-dev] [openstack][keystone] Is the user password too simple?

[Jeremy Stanley]

On 2013-12-30 23:15:06 +0800 (+0800), Thomas Goirand wrote:
> On 12/30/2013 02:55 PM, li-zheming wrote:
> [...]
> > I consider that it must be limited when set password, like this:
> >   1. inlcude uppper and lower letters
> >   2. include nums
> >   3. include particular symbol，such as  '_','&'
> >   4. the length>8
> > administor can set the password rule.
[...]
> If you just force me to add upper+lower case and add symbols, then
> you are just annoying me even with my very good passwords.
[...]

I think cracklib (or similar) integration as an optional rule, along
with those listed above, would be great... I'd even say docs should
recommend doing it "the right way" with an entropy checker rule
rather than those other arbitrary checks. However, support for them
is still useful because some operators very well may be hamstrung by
cargo-cult "best practices" requirements like that baked into their
corporate security policies (so they'll need to be able to support
such schemes no matter how backward it might seem).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [openstack][keystone] Is the user password too simple?

[Gabriel pettier]

On Mon, Dec 30, 2013 at 11:15:06PM +0800, Thomas Goirand wrote:
> On 12/30/2013 02:55 PM, li-zheming wrote:
> > hi all:
> >   when create user, you can set user password. You can set password
> > as a simple word 'a'. the
> > password is too simple but not limit. if someone want to steal your
> > password, it is so easily(such as exhaustion).
> > I consider that it must be limited when set password, like this:
> >   1. inlcude uppper and lower letters
> >   2. include nums
> >   3. include particular symbol，such as  '_','&'
> >   4. the length>8
> > administor can set the password rule.
> 
> Hi,
> 
> If you want to check for password complexity, do it the correct way. I'm
> used to *always* use a password generator that uses only lower case, and
> removes chars that can be confused with one another, so that you don't
> have l and 1, or O and 0 in my passwords. Yet, they are high entropy and
> long. If you just force me to add upper+lower case and add symbols, then
> you are just annoying me even with my very good passwords.
> 
> > I want to  provide a BP about  this issue. can you give me some advice
> > or ideas??
> 
> Please use a password entropy function. Something like this:
> https://pypi.python.org/pypi/cracklib
> 
> Thomas
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I agree with this, if there is a check, it should check general safety, 
rather than expect to fulfill all conditions, if i have a 50 letters
pass (and i do, using full sentences is quite convenient), don't force 
me to have numbers or symbols in it, it's already way harder to crack 
than an 8 chars word with a capital, a number, and a non-alphanumerical 
char.

--
Gabriel Pettier
Software Engineer at CloudWatt.com 
06 85 10 36 34

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

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Robert Myers]

+1


On Fri, Dec 27, 2013 at 4:48 PM, Michael Basnight wrote:

> Howdy,
>
> Im proposing Auston McReynolds (amcrn) to trove-core.
>
> Auston has been working with trove for a while now. He is a great
> reviewer. He is incredibly thorough, and has caught more than one critical
> error with reviews and helps connect large features that may overlap
> (config edits + multi datastores comes to mind). The code he submits is top
> notch, and we frequently ask for his opinion on architecture / feature /
> design.
>
> https://review.openstack.org/#/dashboard/8214
> https://review.openstack.org/#/q/owner:8214,n,z
> https://review.openstack.org/#/q/reviewer:8214,n,z
>
> Please respond with +1/-1, or any further comments.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Daniel Morris]

+1

From: Michael Basnight mailto:mbasni...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, December 27, 2013 4:48 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

Howdy,

Im proposing Auston McReynolds (amcrn) to trove-core.

Auston has been working with trove for a while now. He is a great reviewer. He 
is incredibly thorough, and has caught more than one critical error with 
reviews and helps connect large features that may overlap (config edits + multi 
datastores comes to mind). The code he submits is top notch, and we frequently 
ask for his opinion on architecture / feature / design.

https://review.openstack.org/#/dashboard/8214
https://review.openstack.org/#/q/owner:8214,n,z
https://review.openstack.org/#/q/reviewer:8214,n,z

Please respond with +1/-1, or any further comments.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages

[Jeremy Stanley]

On 2013-12-30 10:25:07 -0500 (-0500), David Kranz wrote:
> I get that but it seems like this is a single field per gerrit user.
> Is that not true? If true, it is not useful because the point is
> that we want to be able to filter reviews that contain changes to
> tests for a particular project. I need to make different kinds of
> requests, like with a bookmark for each one. Is it possible?

Right, the file filter parameter is really only effective for
determining what changes Gerrit E-mails you about, or which ones
should be incorporated into your list of watched changes. It's not
available for general search queries (I suspect this was a
compromise made for efficiency reasons since the queries could be
pretty intense the way file information is stored in the underlying
database).

Note, we're still running Gerrit 2.4 at the moment, so once we
transition to 2.8 or 2.9 the flexibility in the search interface may
increase significantly (I've heard it gives you the ability to
bookmark various searches as custom dashboard views, but not sure
what other search improvements may be added there).
-- 
Jeremy Stanley

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

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

[Thomas Goirand]

On 12/30/2013 06:02 PM, Robert Collins wrote:
> On 30 December 2013 22:51, Thomas Goirand  wrote:
> 
>> IMO, switching to ext4 is a very bad idea, because ext4 doesn't support
>> online resize2fs, while ext3 does, so switching to ext4 is breaking
>> cloud-init!!!
> 
> It supports it just fine. (I just resized a 4TB volume to 10TB)...
> online. But even if it didn't, the ephemeral volume is formatted by
> the hypervisor, the one where resize is needed is the root device,
> which is separate.
> 
> -Rob

Oh ok, thanks for correcting me. This must be a new feature of recent
kernels, and I needed to update myself then.

Someone told me that it only expand, not shrink, when doing online
resize. Can you confirm that? (probably the feature has been added also)

Cheers,

Thomas


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

Re: [openstack-dev] [OpenStack-Infra] [qa][FWaaS][Neutron]Firewall service disabled on gate

[Clark Boylan]

On Mon, Dec 30, 2013 at 12:17 AM, Sumit Naiksatam
 wrote:
> Yair, The FWaaS tempest tests were not planned for H release. They are
> planned for the current release (hence the blueprint) and some of us were
> working towards them. This is also a standing discuss item this during the
> the FWaaS sub team meetings.
>
> Thanks,
> ~Sumit.
>
>
> On Sun, Dec 29, 2013 at 2:41 PM, Salvatore Orlando 
> wrote:
>>
>> I reckon the decision of keeping neutron's firewall API out of gate tests
>> was reasonable for the Havana release.
>> I might be argued the other 'experimental' service, VPN, is already
>> enabled on the gate, but that did not happen before proving the feature was
>> reliable enough to not cause gate breakage.
>>
>> If we can confidently say the same for the firewall extension now, I would
>> agree on enabling it on gate tests as well.
>>
>> Salvatore
>>
>>
>> On 29 December 2013 22:22, Yair Fried  wrote:
>>>
>>> Hi,
>>> I'm trying to push a firewall api test [1] and I see it cannot run on the
>>> current gate.
>>> I was FWaaS is disabled since it broke the gate.
>>> Does anyone knows if this is still an issue?
>>> If so - how do we overcome this?
>>> I would like to do some work on this service (scenarios) and don't want
>>> to waste time if this is something that cannot be done right now
>>>
>>> Thank you
>>> Yair
>>>
>>> [1] https://review.openstack.org/64362
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>

There was a change [0] proposed to enable q-fwaas in devstack-gate,
but it also enabled the service on the Havana branch which is
problematic because as I understand it adding extra neutron services
to the Havana gate broke things [1] and fwaas isn't ready in Havana.
If we want to enable this service we should only do so on the master
branch (feel free to update that change I can restore it), or if I am
mistaken about the state of things in the Havana gate let me know and
we can restore that change as is.

[0] https://review.openstack.org/#/c/60149/
[1] https://review.openstack.org/#/c/48793/

Clark

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

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Sean Winn]

+1
On Dec 27, 2013 2:51 PM, "Michael Basnight"  wrote:

> Howdy,
>
> Im proposing Auston McReynolds (amcrn) to trove-core.
>
> Auston has been working with trove for a while now. He is a great
> reviewer. He is incredibly thorough, and has caught more than one critical
> error with reviews and helps connect large features that may overlap
> (config edits + multi datastores comes to mind). The code he submits is top
> notch, and we frequently ask for his opinion on architecture / feature /
> design.
>
> https://review.openstack.org/#/dashboard/8214
> https://review.openstack.org/#/q/owner:8214,n,z
> https://review.openstack.org/#/q/reviewer:8214,n,z
>
> Please respond with +1/-1, or any further comments.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Greg Hill]

+1

On Dec 27, 2013, at 4:48 PM, Michael Basnight 
mailto:mbasni...@gmail.com>> wrote:

Howdy,

Im proposing Auston McReynolds (amcrn) to trove-core.

Auston has been working with trove for a while now. He is a great reviewer. He 
is incredibly thorough, and has caught more than one critical error with 
reviews and helps connect large features that may overlap (config edits + multi 
datastores comes to mind). The code he submits is top notch, and we frequently 
ask for his opinion on architecture / feature / design.

https://review.openstack.org/#/dashboard/8214
https://review.openstack.org/#/q/owner:8214,n,z
https://review.openstack.org/#/q/reviewer:8214,n,z

Please respond with +1/-1, or any further comments.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Greg Hill]

I've begun working on the scheduled tasks feature that will allow automated 
backups (and other things) in trove.

Here's the blueprint:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks

I've heard some mention that mistral might be an option rather than building 
something into trove.  I did some research and it seems like it *might* be a 
good fit, but it also seems like a bit of overkill for something that could be 
built in to trove itself pretty easily.  There's also the security concern of 
having to give mistral access to the trove management API in order to allow it 
to fire off backups and other tasks on behalf of users, but maybe that's just 
my personal paranoia and it's really not much of a concern.

My current plan is to not use mistral, at least for the original 
implementation, because it's not yet ready and we have a fairly urgent need for 
the functionality.  We could make it an optional feature later for people who 
are running mistral and want to use it for this purpose.

I'd appreciate any and all feedback before I get too far along.

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

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

[Joshua Harlow]

Any reason to not use taskflow (https://wiki.openstack.org/wiki/TaskFlow) to 
help u here??

I think it could be easily adapted to do what u want, and would save u from 
having to recreate the same task execution logic that everyone seems to rebuild…

-Josh

From: Greg Hill mailto:greg.h...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, December 30, 2013 at 9:59 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [trove][mistral] scheduled tasks

I've begun working on the scheduled tasks feature that will allow automated 
backups (and other things) in trove.

Here's the blueprint:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks

I've heard some mention that mistral might be an option rather than building 
something into trove.  I did some research and it seems like it *might* be a 
good fit, but it also seems like a bit of overkill for something that could be 
built in to trove itself pretty easily.  There's also the security concern of 
having to give mistral access to the trove management API in order to allow it 
to fire off backups and other tasks on behalf of users, but maybe that's just 
my personal paranoia and it's really not much of a concern.

My current plan is to not use mistral, at least for the original 
implementation, because it's not yet ready and we have a fairly urgent need for 
the functionality.  We could make it an optional feature later for people who 
are running mistral and want to use it for this purpose.

I'd appreciate any and all feedback before I get too far along.

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

[openstack-dev] [Nova] Grizzly -> Havanna db migration bug/1245502 still biting me?

[Jonathan Proulx]

Hi All,

I'm mid upgrade between Grizzly and Havana and seem to still be having
issues with https://bugs.launchpad.net/nova/+bug/1245502

I grabbed the patched version of 185_rename_unique_constraints.py but
that migration still keeps failing with many issues trying to drop
nonexistant indexes and add preexisting indexes.

for example:
CRITICAL nova [-] (OperationalError) (1553, "Cannot drop index
'uniq_instance_type_id_x_project_id_x_deleted': needed in a foreign
key constraint") 'ALTER TABLE instance_type_projects DROP INDEX
uniq_instance_type_id_x_project_id_x_deleted' ()


I'm on Ubuntu 12.04 having originally installed Essex and
progressively upgraded using cloud archive packages since.

# nova-manage  db version
184

a dump of my nova database schema as it currently stands is at:
https://gist.github.com/jon-proulx/79a77e8b771f90847ae9

The bug is marked "fix released", but one of the last comments request
schemata from affected systems so not sure if replying to the bug is
appropriate or if this should be a new bug.

-Jon

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

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Craig Vyvial]

+1


On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill  wrote:

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

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

[Greg Hill]

I accidentally sent this reply to Josh directly.

Greg

On Dec 30, 2013, at 12:17 PM, Greg Hill 
mailto:greg.h...@rackspace.com>> wrote:

Taskflow seems like it would be a good fit for implementation or 
re-implementation of some of the tasks we hope to automate, but the first set 
of desired tasks are already built.  We're simply building the scheduling logic 
to automate them, so I don't see what taskflow would buy us there.

Greg

On Dec 30, 2013, at 12:14 PM, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>>
 wrote:

Any reason to not use taskflow (https://wiki.openstack.org/wiki/TaskFlow) to 
help u here??

I think it could be easily adapted to do what u want, and would save u from 
having to recreate the same task execution logic that everyone seems to rebuild…

-Josh

From: Greg Hill mailto:greg.h...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, December 30, 2013 at 9:59 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [trove][mistral] scheduled tasks

I've begun working on the scheduled tasks feature that will allow automated 
backups (and other things) in trove.

Here's the blueprint:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks

I've heard some mention that mistral might be an option rather than building 
something into trove.  I did some research and it seems like it *might* be a 
good fit, but it also seems like a bit of overkill for something that could be 
built in to trove itself pretty easily.  There's also the security concern of 
having to give mistral access to the trove management API in order to allow it 
to fire off backups and other tasks on behalf of users, but maybe that's just 
my personal paranoia and it's really not much of a concern.

My current plan is to not use mistral, at least for the original 
implementation, because it's not yet ready and we have a fairly urgent need for 
the functionality.  We could make it an optional feature later for people who 
are running mistral and want to use it for this purpose.

I'd appreciate any and all feedback before I get too far along.

Greg


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

Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

[Day, Phil]

Hi, so it seems we were saying the same thing - new vms get a shared "blank" 
(empty) file system,  not blank disc.  How big a problem it is that in many 
cases this will be the already created ext3 disk and not ext4 depends I guess 
on how important consistency is to you (to me its pretty important).  Either 
way the change as it stands wont give all new vms an ext4 fs as intended,  so 
its flawed in that regard.

Like you I was thinking that we may have to move away from "default" being in 
the file name to fix this.

I don't think the cache clean up code ever removes the ephemeral backing files 
though at the moment.

Phil

Sent from Samsung Mobile



 Original message 
From: Pádraig Brady 
Date:
To: "OpenStack Development Mailing List (not for usage questions)" 
,"Day, Phil" 
Subject: Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to 
ext4


On 12/30/2013 12:39 AM, Pádraig Brady wrote:
> On 12/29/2013 08:12 AM, Day, Phil wrote:
>> Hi Folks,
>>
>> As highlighted in the thread “minimal review period for functional changes” 
>> I’d like to propose that change is https://review.openstack.org/#/c/63209/ 
>> is reverted because:
>>
>> -  It causes inconsistent behaviour in the system, as any existing 
>> "default" backing files will have ext3 in them, so a VM will now get either 
>> ext3 or 3ext4 depending on whether the host they get created on already has 
>> a backing file of the required size or not.   I don't think the existing 
>> design ever considered the default FS changing - maybe we shouldn’t have 
>> files that include "default" as the file system type if it can change over 
>> time, and the name should always reflect the FS type.
>
> I'm not sure this is a practical issue since ephemeral storage is built up 
> from blank by each instance

Phil> Maybe it varies by hypervisor; my understanding is that at least in 
libvirt the ephemeral disks are cow layers on a shared common backing file that 
has the file system in it.
Phil> The naming convention includes the size and fs type or "default" and is 
only created once per size-fs combination.
Phil> So this is a real issue - I think that maybe the eventual change to ext4 
need to be combined withoving away from "default"  in the file name.

Right, what I meant by each instance building ephemeral up from blank each time,
is that each instance will go from either a blank ext3 or blank ext4 each time,
so if they support ext4 then there should be no practical issue. Now agreed 
there
is a consistency issue, which could have performance consistency issues for 
example,
so it's not ideal.

To be complete, for the libvirt case we don't even use these persistent backing 
files
for ephemeral disks if use_cow_images=False or with LVM backing.

To be most general and avoid this consistency issue, I suppose we could change 
the
name format for these cached CoW base images from ephemeral_10_default, 
ephemeral_20_linux etc.
to 'ephemeral_20_' + md5(mkfs_command)[:7]
That would impose a performance hit at first boot with this new logic,
and we'd have to double check that the cache cleaning logic would
handle removing unused older format images.
Alternatively we might just document this issue and put the onus on
users to clean these cached ephemeral disk on upgrade
(the commit is already tagged as DocImpact).

thanks,
Pádraig.

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

[openstack-dev] [all project] log files and logstash

[David Kranz]

In case any one other than me didn't know this, the log files that are 
indexed and searchable in logstash are not the same as the set of files 
that you see in the logs directory in jenkins, but only those that have 
an entry in 
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/logstash/jenkins-log-client.yaml. 
Here are the log files that are not mentioned in that yaml file in case 
any omissions are not intentional:


cinder:
screen-c-bak.txt

horizon:
screen-horizon.txt

neutron:
screen-q-lbaas.txt  (but there *is* an entry for screen-q-l3.txt)
screen-q-vpn.txt

ceilometer:
No log files are indexed by logstash

  -David

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

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

[Vipul Sabhaya]

+1

Sent from my iPhone

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

Re: [openstack-dev] [openstack][keystone] Is the user password too simple?

[Brant Knudson]

On Mon, Dec 30, 2013 at 12:55 AM, li-zheming  wrote:

> hi all:
>   when create user, you can set user password. You can set password as
> a simple word 'a'. the
> password is too simple but not limit. if someone want to steal your
> password, it is so easily(such as exhaustion).
> I consider that it must be limited when set password, like this:
>   1. inlcude uppper and lower letters
>   2. include nums
>   3. include particular symbol，such as  '_','&'
>   4. the length>8
> administor can set the password rule.
>
> I want to  provide a BP about  this issue. can you give me some advice or
> ideas??
> thanks!
>
> lizheming
>
>
I'd prefer it if we didn't reinvent this wheel ourselves. If customers need
to enforce password strength, expiration, history, user lockout, etc, then
they should store users in an LDAP directory that supports these things and
configure Keystone to use that.

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

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

[Day, Phil]

I wonder if at least part of the problem is that whilst we have prioritisation 
for bugs (via severity) and blueprints (via  approval and target release) that 
doesn't obviously carry through into gerrit.  If it was easier to see what 
we're high and low priory changes it might be easier to decide which need 
attention and which can / should wait for more input ?

At the moment or does feel that a changes chance of getting merged is somewhat 
random,  and we must be able to do better than that.

Of course we'd still need to work out how to prioritise changes which land add 
neither big or bp ( or maybe this is part of the argument for not having such 
changes)

Phil


Sent from  Mobile - spelling will be even worse than normal



 Original message 
From: Robert Collins 
Date:
To: "OpenStack Development Mailing List (not for usage questions)" 

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


On 29 December 2013 21:06, Day, Phil  wrote:

>> What is the minimum review period intended to accomplish? I mean:
>> everyone that reviewed this *knew* it changed a default, and that guest
>> OS's that did support ext3 but don't support ext4 would be broken.
>
> My point is that for some type of non-urgent change (i.e. those that change 
> existing behaviour) there needs to be a longer period to make sure that more 
> views and opinions can surface and be taken into account.   Maybe all the 
> reviewers in this case did realise the full impact of this change, but that's 
> still not the same thing as getting a wide range of input.   This is a change 
> which has some significant impact, and there was no prior discussion as far 
> as I know in the form of a BP or thread in the mailing list.   There was also 
> no real urgency in getting the change merged.

I disagree that 'longer period' implies 'more views and opinions'.
>From the nova open reviews stats:
3rd quartile wait time: 17 days, 7 hours, 14 minutes

25% of *all* open nova reviews have had no review at all in 17 days.

3rd quartile wait time: 23 days, 10 hours, 44 minutes

25% of all open nova reviews have had no -1 or -2 in 23 days.

I'm not debating the merits of more views and opinions - Sean has
pointed out already that automation is better than us having to guess
at when things will or won't work. But even if you accept that more
views and opinions will help, there are over 100 reviews up with *no*
such opinions added already.

Lets say that something like the patch that triggered this went up for
review, and that we established a one month mininum review period for
such patches. There's a 25% chance it would hit 3 weeks with no input
at all. The *effective* time then that a one month minimum period
would set for it would be a week.

Once the volume of reviews needed exceeds a single reviewers capacity,
by definition some reviewers will not see some patches *at all*. At
that point it doesn't matter how long a patch waits, it will never hit
the front of the line for some reviewers unless we have super strict -
and careful - ordering on who reviews what. Which we don't have, and
can't get trivially. But even if we do:

-> time is not a good proxy for attention, care, detail or pretty much
any other metric when operating a scaled out human process.

What would make a good proxy metric for 'more views and opinions'? I
think asking for more cores to +2 such changes would do it. E.g. ask
for 4 +2's for backward incompatible changes unless they've gone
through the a release cycle of being deprecated/warned.

>> Would  you like to have seen a different judgement call - e.g.
>> 'Because this is a backward breaking change, it has to go through one release
>> of deprecation warning, and *then* can be made' ?
>>
>
>  Yep, I think that would be appropriate in this case.   There is an impact 
> beyond just the GuestOS support that occurred to me since, but I don't want 
> to get this thread bogged down in this specific change so I'll start a new 
> thread for that.  My point is that where changes are proposed that affect the 
> behaviour of the system, and especially where they are not urgent (i.e not 
> high priority bug fixes) then we need to slow down the reviews and not assume 
> that all possible views / impacts will surface in a few days.

Again, I really disagree with 'need to slow down'. We need to achieve
something *different*.

> As I said, there seems to me to be something wrong with the priority around 
> changes when non urgent but behaviour changes go though in a few days but we 
> have bug fixes sitting with many +1's for over a month.

>> Another possible reason is that we should have a strict no-exceptions-by-
>> default approach to backwards incompatible changes, even when there are
>> config settings to override them. Whatever the nub is - lets surface that and
>> target it.
>>
>
> Yep - I think we should have a very clear policy around how and when we make 
> chang

Re: [openstack-dev] [Nova] Grizzly -> Havanna db migration bug/1245502 still biting me?

[Jonathan Proulx]

ah, because the patched version won't work if you've already run the
unpatched version, would be nice if that had been captured in the bug
but did dig it out of
http://lists.openstack.org/pipermail/openstack/2013-October/002481.html

On Mon, Dec 30, 2013 at 1:25 PM, Jonathan Proulx  wrote:
> Hi All,
>
> I'm mid upgrade between Grizzly and Havana and seem to still be having
> issues with https://bugs.launchpad.net/nova/+bug/1245502
>
> I grabbed the patched version of 185_rename_unique_constraints.py but
> that migration still keeps failing with many issues trying to drop
> nonexistant indexes and add preexisting indexes.
>
> for example:
> CRITICAL nova [-] (OperationalError) (1553, "Cannot drop index
> 'uniq_instance_type_id_x_project_id_x_deleted': needed in a foreign
> key constraint") 'ALTER TABLE instance_type_projects DROP INDEX
> uniq_instance_type_id_x_project_id_x_deleted' ()
>
>
> I'm on Ubuntu 12.04 having originally installed Essex and
> progressively upgraded using cloud archive packages since.
>
> # nova-manage  db version
> 184
>
> a dump of my nova database schema as it currently stands is at:
> https://gist.github.com/jon-proulx/79a77e8b771f90847ae9
>
> The bug is marked "fix released", but one of the last comments request
> schemata from affected systems so not sure if replying to the bug is
> appropriate or if this should be a new bug.
>
> -Jon

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

Re: [openstack-dev] django-bootstrap-form & django 1.4 / 1.5

[Sascha Peilicke]

Am 30.12.2013 08:31, schrieb Thomas Goirand:

Hi,

Currently, in the global-requirements.txt, we have:

Django>=1.4,<1.6
django-bootstrap-form

However, django-bootstrap-form fail in both Django 1.4 and Django 1.6.

What's the way forward? Would it be possible that someone makes a patch
for django-bootstrap-form, so that it could work with Django 1.4 & 1.5
(which would be the best way forward for me...)?


Isn't that project dead? I've been using crispy_forms with great 
success. It provides integration for both bootstrap 2 and 3 and works 
with Django-1.6. I could have a look into the issue...


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

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

[Clark Boylan]

On Mon, Dec 30, 2013 at 11:17 AM, Day, Phil  wrote:
> I wonder if at least part of the problem is that whilst we have 
> prioritisation for bugs (via severity) and blueprints (via  approval and 
> target release) that doesn't obviously carry through into gerrit.  If it was 
> easier to see what we're high and low priory changes it might be easier to 
> decide which need attention and which can / should wait for more input ?
>
> At the moment or does feel that a changes chance of getting merged is 
> somewhat random,  and we must be able to do better than that.
>
> Of course we'd still need to work out how to prioritise changes which land 
> add neither big or bp ( or maybe this is part of the argument for not having 
> such changes)
>
> Phil
>

ReviewDay tackles this problem. You can see the prioritized changes at
http://status.openstack.org/reviews/ and the source code for review
day is available at
https://git.openstack.org/cgit/openstack-infra/reviewday/tree/. It is
definitely not the only possible solution but it does try to rank
changes based on feedback, age, blueprint/bug priority and so on.

Clark

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

Re: [openstack-dev] [All] tagged commit messages

[Kevin L. Mitchell]

On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote:
> I like the idea of having custom tags. I'm a bit concerned about the
> implications this might have with cross-project collaborations. I
> mean, people contributing to more projects will have to be aware of
> the many possible differences in this area.
> 
> That being said, I can think of some cases where we this could be
> useful for other projects. However, I'd encourage to keep common tags
> documented somewhere, perhaps this common tags shouldn't be part of
> the `Tags:` 'field', which you already mentioned above.

If I may be allowed a tangent—should a mechanism external to the commit
message be allowed for attaching a tag to a review?  Consider the recent
ext3/ext4 change: a reviewer could browse that and say, "This should
have a DeploymentImpact tag."  With the tags as so far described in this
thread, that has to be something added by the submitter (or a new
version of the patch uploaded by a reviewer).  Can we create a mechanism
that would allow a reviewer to attach such a tag without having to
modify any part of the review?  Can the mechanism allow such an
attachment even if the review has already been merged?

Just something to think about :)
-- 
Kevin L. Mitchell 
Rackspace



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

Re: [openstack-dev] [Nova] Grizzly -> Havanna db migration bug/1245502 still biting me?

[Jonathan Proulx]

Should have tried that first I suppose, even after reverting (clean
schema at https://gist.github.com/jon-proulx/abb6af1ab7f3133671d2)
sync fails

# nova-manage db sync
Command failed, please check log for more info
2013-12-30 14:45:28.633 29427 CRITICAL nova [-] (OperationalError)
(1032, "Can't find record in 'task_log'") 'ALTER TABLE task_log DROP
INDEX uniq_task_name_x_host_x_period_beginning_x_period_ending' ()

On Mon, Dec 30, 2013 at 2:28 PM, Jonathan Proulx  wrote:
> ah, because the patched version won't work if you've already run the
> unpatched version, would be nice if that had been captured in the bug
> but did dig it out of
> http://lists.openstack.org/pipermail/openstack/2013-October/002481.html
>
> On Mon, Dec 30, 2013 at 1:25 PM, Jonathan Proulx  wrote:
>> Hi All,
>>
>> I'm mid upgrade between Grizzly and Havana and seem to still be having
>> issues with https://bugs.launchpad.net/nova/+bug/1245502
>>
>> I grabbed the patched version of 185_rename_unique_constraints.py but
>> that migration still keeps failing with many issues trying to drop
>> nonexistant indexes and add preexisting indexes.
>>
>> for example:
>> CRITICAL nova [-] (OperationalError) (1553, "Cannot drop index
>> 'uniq_instance_type_id_x_project_id_x_deleted': needed in a foreign
>> key constraint") 'ALTER TABLE instance_type_projects DROP INDEX
>> uniq_instance_type_id_x_project_id_x_deleted' ()
>>
>>
>> I'm on Ubuntu 12.04 having originally installed Essex and
>> progressively upgraded using cloud archive packages since.
>>
>> # nova-manage  db version
>> 184
>>
>> a dump of my nova database schema as it currently stands is at:
>> https://gist.github.com/jon-proulx/79a77e8b771f90847ae9
>>
>> The bug is marked "fix released", but one of the last comments request
>> schemata from affected systems so not sure if replying to the bug is
>> appropriate or if this should be a new bug.
>>
>> -Jon

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

Re: [openstack-dev] [OpenStack-Infra] [qa][FWaaS][Neutron]Firewall service disabled on gate

[Sumit Naiksatam]

I don't see too much benefit in turning on FWaaS in Havana, but we would
definitely want this to be considered for the master/Icehouse branch. The
FWaaS support leverages the Neutron L3 agent footprint, and my
understanding is that there were efforts underway to stabilize this L3
agent code. If required, we can wait until this stabilization effort around
the L3 agent is finished before we turn q-fwaas so as to avoid having an
additional variable to track at the gate. If this is not a concern, we can
turn on q-fwaas right away.

Thanks,
~Sumit.


On Mon, Dec 30, 2013 at 9:49 AM, Clark Boylan wrote:

> On Mon, Dec 30, 2013 at 12:17 AM, Sumit Naiksatam
>  wrote:
> > Yair, The FWaaS tempest tests were not planned for H release. They are
> > planned for the current release (hence the blueprint) and some of us were
> > working towards them. This is also a standing discuss item this during
> the
> > the FWaaS sub team meetings.
> >
> > Thanks,
> > ~Sumit.
> >
> >
> > On Sun, Dec 29, 2013 at 2:41 PM, Salvatore Orlando 
> > wrote:
> >>
> >> I reckon the decision of keeping neutron's firewall API out of gate
> tests
> >> was reasonable for the Havana release.
> >> I might be argued the other 'experimental' service, VPN, is already
> >> enabled on the gate, but that did not happen before proving the feature
> was
> >> reliable enough to not cause gate breakage.
> >>
> >> If we can confidently say the same for the firewall extension now, I
> would
> >> agree on enabling it on gate tests as well.
> >>
> >> Salvatore
> >>
> >>
> >> On 29 December 2013 22:22, Yair Fried  wrote:
> >>>
> >>> Hi,
> >>> I'm trying to push a firewall api test [1] and I see it cannot run on
> the
> >>> current gate.
> >>> I was FWaaS is disabled since it broke the gate.
> >>> Does anyone knows if this is still an issue?
> >>> If so - how do we overcome this?
> >>> I would like to do some work on this service (scenarios) and don't want
> >>> to waste time if this is something that cannot be done right now
> >>>
> >>> Thank you
> >>> Yair
> >>>
> >>> [1] https://review.openstack.org/64362
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > ___
> > OpenStack-Infra mailing list
> > openstack-in...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >
>
> There was a change [0] proposed to enable q-fwaas in devstack-gate,
> but it also enabled the service on the Havana branch which is
> problematic because as I understand it adding extra neutron services
> to the Havana gate broke things [1] and fwaas isn't ready in Havana.
> If we want to enable this service we should only do so on the master
> branch (feel free to update that change I can restore it), or if I am
> mistaken about the state of things in the Havana gate let me know and
> we can restore that change as is.
>
> [0] https://review.openstack.org/#/c/60149/
> [1] https://review.openstack.org/#/c/48793/
>
> Clark
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

[David Kranz]

On 12/27/2013 05:27 AM, Nadya Privalova wrote:

Hello guys!

I hope all of you are enjoying the holidays! But I'd like to raise a 
Tempest question. Again. I hope this email will not be lost after 
vacations :)
After the summit we decided to track all tests that are being created 
for Ceilometer in Tempest here: 
https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests. 
Besides, we've created an etherpad page with a test plan 
https://etherpad.openstack.org/p/ceilometer-test-plan.


But it turned out that it works very bad. Now we have at least 3 
change requests that have common functionality implemented. So we 
definitely need more reliable mechanism for tracking any changes.
That's why I suggest to create a separate blueprint for each 
functionality. E.g. "Ceilometer client for Tempest", "Notification 
testing" with several bps that depend on it ("Swift notifications", 
"Glance notifications", "Nova notifications") and so on. In future we 
may vary the detail level of blueprints but now we need very detailed 
ones because different people have started to work on e.g. notifications.

So there are the following action items:
1. Resolve all conflicts in changes that are on review now (see my 
comment to https://review.openstack.org/#/c/39237/ patch set 21 for 
more details)

2. Create set of blueprints from the testplan we have
3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)

I may take care of all the items above. I need only "ok" from PTLs and 
Cores.
Anyway, we've started working on 1st item, because it is urgent. The 
second one may be postponed due to holidays.


And one more important thing. Code review for Ceilometer tests in 
Tempest is too slow. Some of change requests are created almost a half 
a year ago! Ceilometer guys, please be informed. I think all of us are 
interested in good tests.


Thank you for attention,
Nadya


So the tempest patches for ceilometer are still not a coherent set. Can 
you please mark anything that is not ready for review as Work In 
Progress, or abandon until there is really something to review?


Also, having looked at a few of these, I am confused about the usage of 
"ceilometer", "metering", "telemetry". Is there an explanation for the 
context in which each of these terms is to be used?


 -David


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

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

[Brian Rosmaita]

Greg,

This might be useful: https://wiki.openstack.org/wiki/Qonos-scheduling-service

There's a link to the code repository at the bottom of the document.  It might 
be kind of overkill for what you want, though.

cheers,
brian


From: Greg Hill [greg.h...@rackspace.com]
Sent: Monday, December 30, 2013 12:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove][mistral] scheduled tasks

I've begun working on the scheduled tasks feature that will allow automated 
backups (and other things) in trove.

Here's the blueprint:
https://wiki.openstack.org/wiki/Trove/scheduled-tasks

I've heard some mention that mistral might be an option rather than building 
something into trove.  I did some research and it seems like it *might* be a 
good fit, but it also seems like a bit of overkill for something that could be 
built in to trove itself pretty easily.  There's also the security concern of 
having to give mistral access to the trove management API in order to allow it 
to fire off backups and other tasks on behalf of users, but maybe that's just 
my personal paranoia and it's really not much of a concern.

My current plan is to not use mistral, at least for the original 
implementation, because it's not yet ready and we have a fairly urgent need for 
the functionality.  We could make it an optional feature later for people who 
are running mistral and want to use it for this purpose.

I'd appreciate any and all feedback before I get too far along.

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

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

[Collins, Sean]

OK - if nobody has any objections, we'll start the new meetings up at
1500 UTC - that appears to be the time that everyone is OK with?

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

Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?

[Collins, Sean]

Spoke too soon – I think 1500 UTC on Thursdays is already taken, we'd have to 
change days.

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

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

[Georgy Okrokvertskhov]

Hi,

I would suggest to talk with Mistral team about scheduling. As I know right
now thay are writing a PoC code which will have scheduling functionality.
Mistral in contrary to Qonos does not require worker process. In Mistral
you can create a task with scheduler and API call back so that Mistral can
call some API endpoint with some specific parameters in predefined time. I
suspect that it covers your use case.

Security concerns can be addressed and it will be great if you submit
specific BP to Mistral with all security requirements and scheduling
features required by Trove.

Thanks
Georgy


On Mon, Dec 30, 2013 at 12:26 PM, Brian Rosmaita <
brian.rosma...@rackspace.com> wrote:

>  Greg,
>
> This might be useful:
> https://wiki.openstack.org/wiki/Qonos-scheduling-service
>
> There's a link to the code repository at the bottom of the document.  It
> might be kind of overkill for what you want, though.
>
> cheers,
> brian
>
>  --
> *From:* Greg Hill [greg.h...@rackspace.com]
> *Sent:* Monday, December 30, 2013 12:59 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [trove][mistral] scheduled tasks
>
>  I've begun working on the scheduled tasks feature that will allow
> automated backups (and other things) in trove.
>
>  Here's the blueprint:
> https://wiki.openstack.org/wiki/Trove/scheduled-tasks
>
>  I've heard some mention that mistral might be an option rather than
> building something into trove.  I did some research and it seems like it
> *might* be a good fit, but it also seems like a bit of overkill for
> something that could be built in to trove itself pretty easily.  There's
> also the security concern of having to give mistral access to the trove
> management API in order to allow it to fire off backups and other tasks on
> behalf of users, but maybe that's just my personal paranoia and it's really
> not much of a concern.
>
>  My current plan is to not use mistral, at least for the original
> implementation, because it's not yet ready and we have a fairly urgent need
> for the functionality.  We could make it an optional feature later for
> people who are running mistral and want to use it for this purpose.
>
>  I'd appreciate any and all feedback before I get too far along.
>
>  Greg
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 12/29/2013 07:58 PM, Day, Phil wrote:

Hi Sean,

I'm not convinced the comparison to my clean shut down change is valid here.  
For sure that proved that beyond a certain point (in that case months) there is 
no additional value in extending the review period, and no amount of review 
will catch all problems,  but that's not the same as saying that there is no 
value in a minimum period.


The reason I brought up graceful shutdown was that I actually think that 
review went the opposite direction, and got worse over time.


Borrowing from another part of Robert's thread - 
https://review.openstack.org/#/q/status:open+-Verified-1+-CodeReview%2B2+-CodeReview%2B1+-CodeReview-1+-CodeReview-2+(project:openstack/nova+OR+project:openstack/python-novaclient)+branch:master,n,z


Minimum review time only works if all patches eventually see review, 
which they don't.



In this particular case if the review has been open for say three weeks then 
imo the issue would have been caught, as I spotted it as soon as I saw the 
merge.  As it wasn't and urgent bug fix I don't see a major gain from not 
waiting even if there wasn't a problem.


So... then why didn't you spot it on the submit? And would you have 
found the review on your own if it hadn't been for the merge commit email?


It was urgent from a tripleo perspective, enough so that they were 
carrying an out of tree patch for it until it merged. Remember, we're 
trying to get tripleo, eventually, gating. And 45 mins deploy times was 
a big fix to move that ball forward. That's why I prioritized that.


So while it was a low priority change for your environment, don't assume 
that it wasn't really needed as part of CI.



I'm all for continually improving the gate tests, but in this case they would 
need to be testing against a system that had been running before the change, to 
test specifically that new vms got the new fs, so there would have needed to be 
a matching test added to grenade as part of the same commit.

Not quite sure where the number of open changes comes in either, just because 
there are a lot of proposed changes doesn't to me mean we need to rush the non 
urgent ones, it mwans we maybe need better prioritisation.  There are plenty of 
long lived buf fixes siting with many +1s


Again, you keep assuming this was non urgent, and your assumptions that 
no one should have been looking at it were because of that. However this 
was effectively communicated by Robert a high priority issue on trippleo 
CD testing, enough so that they were going to run a nova fork until it 
merged, so it was treated as such.


So please step back from the assumption that this was a non urgent 
change, because the tone in IRC was anything but. So it was treated as 
something that needed to move fast. The fact that it was a super small 
change, saw no negative reviews, no negative email comments, means I'm 
not sure we would have done any better. The point was, with no negative 
feedback it didn't really occur to anyone that it was a backwards 
compatibility problem. I was *actually* looking for someone to say 
something about why it would be a problem, and there was nothing. So I 
assumed we had exhausted the set of issues.


So you are really making 2 assumptions here that aren't valid:
 * it was known to be a backwards compatibility problem - because it 
wasn't, and no one provided feedback over the course of 4 days to 
indicate that it was (there were some alternative implementation ideas, 
but no one said "hold on, this could break X")
 * it wasn't urgent - and like I said the tone really was towards this 
being an important need for trippleo


Which is why I don't think saying 3 week minimum review time is helpful, 
because if any of the reviewers had thought it was backwards 
incompatible, they would have -1ed it. Humans only get so much of that 
right.


So we need to handle this defensively and beef up the automated systems. 
Does that require more people adding in defensive tests to those 
scenarios? definitely. The fact that right now basically Dean and I are 
the only ones that understand our upgrade testing (with a few others 
bootstrapping) is way too few people touching that problem.


If seemless upgrade is the most important thing to people, we need more 
people in the trenches on the tooling that helps us verify that.


-Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

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

Re: [openstack-dev] [All] tagged commit messages

[Angus Salkeld]

On 30/12/13 13:44 -0600, Kevin L. Mitchell wrote:


On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote:

I like the idea of having custom tags. I'm a bit concerned about the
implications this might have with cross-project collaborations. I
mean, people contributing to more projects will have to be aware of
the many possible differences in this area.

That being said, I can think of some cases where we this could be
useful for other projects. However, I'd encourage to keep common tags
documented somewhere, perhaps this common tags shouldn't be part of
the `Tags:` 'field', which you already mentioned above.


If I may be allowed a tangent—should a mechanism external to the commit
message be allowed for attaching a tag to a review?  Consider the recent
ext3/ext4 change: a reviewer could browse that and say, "This should
have a DeploymentImpact tag."  With the tags as so far described in this
thread, that has to be something added by the submitter (or a new
version of the patch uploaded by a reviewer).  Can we create a mechanism
that would allow a reviewer to attach such a tag without having to
modify any part of the review?  Can the mechanism allow such an
attachment even if the review has already been merged?


https://www.kernel.org/pub/software/scm/git/docs/git-notes.html



Just something to think about :)
--
Kevin L. Mitchell 
Rackspace



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


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

Re: [openstack-dev] [Neutron] Availability of external testing logs

[Collins, Sean]

On Mon, Dec 23, 2013 at 02:13:59PM -0500, Sean Dague wrote:
> On 12/23/2013 12:10 PM, Collins, Sean wrote:
> I also think we need to have these systems prove themselves on
> reliability before they post votes back. A mis configured CI system can
> easily -1 the entire patch stream, and many of us use -Verified-1 as a
> filter criteria on reviews, which effectively makes that a DOS attack.

I also just found out that it starts the countdown clock for a patch to
be abandoned. An unpleasant surprise.

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

Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4

[Clint Byrum]

Excerpts from Day, Phil's message of 2013-12-30 11:05:17 -0800:
> Hi, so it seems we were saying the same thing - new vms get a shared "blank" 
> (empty) file system,  not blank disc.  How big a problem it is that in many 
> cases this will be the already created ext3 disk and not ext4 depends I guess 
> on how important consistency is to you (to me its pretty important).  Either 
> way the change as it stands wont give all new vms an ext4 fs as intended,  so 
> its flawed in that regard.
> 
> Like you I was thinking that we may have to move away from "default" being in 
> the file name to fix this.
> 

Indeed, "default"'s meaning is mutable and thus it is flawed as a
cache key.

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

Re: [openstack-dev] [All] tagged commit messages

[John Dickinson]

On Dec 30, 2013, at 4:49 PM, Angus Salkeld  wrote:

> On 30/12/13 13:44 -0600, Kevin L. Mitchell wrote:
>> 
>> On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote:
>>> I like the idea of having custom tags. I'm a bit concerned about the
>>> implications this might have with cross-project collaborations. I
>>> mean, people contributing to more projects will have to be aware of
>>> the many possible differences in this area.
>>> 
>>> That being said, I can think of some cases where we this could be
>>> useful for other projects. However, I'd encourage to keep common tags
>>> documented somewhere, perhaps this common tags shouldn't be part of
>>> the `Tags:` 'field', which you already mentioned above.
>> 
>> If I may be allowed a tangent—should a mechanism external to the commit
>> message be allowed for attaching a tag to a review?  Consider the recent
>> ext3/ext4 change: a reviewer could browse that and say, "This should
>> have a DeploymentImpact tag."  With the tags as so far described in this
>> thread, that has to be something added by the submitter (or a new
>> version of the patch uploaded by a reviewer).  Can we create a mechanism
>> that would allow a reviewer to attach such a tag without having to
>> modify any part of the review?  Can the mechanism allow such an
>> attachment even if the review has already been merged?
> 
> https://www.kernel.org/pub/software/scm/git/docs/git-notes.html

So yeah, that's pretty nice. Thanks.

> 
>> 
>> Just something to think about :)
>> -- 
>> Kevin L. Mitchell 
>> Rackspace
>> 
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][3rd Party Testing]Remove voting until your testing structure works.

[Anita Kuno]

Please.

When your third party testing structure votes on patches and your
testing structure is not stable, it will vote with a -1 on patches.

This results in three consequences:
1. The patch it votes on starts a countdown for abandonment, this is
frustrating for developers.
2. Reviewers who use -Verified-1 as a filter criteria will not review a
patch with a -1 in the verification column in the Gerrit dashboard. This
prevents developers from progressing in their work, and this also
prevents reviewers from reviewing patches that need to be assessed.
3. Third party testing that does not provide publicly accessible logs
leave developers with no way to diagnose the issue, which makes it very
difficult for a developer to fix, leaving the patch in a state of limbo.

You can post messages to the patches, including a stable working url to
the logs for your tests, as you continue to work on your third party tests.

You are also welcome to post a success of failure message, just please
refrain from allowing your testing infrastructure to vote on patches
until your testing infrastructure is working, reliably, and has logs
that developers can use to fix problems.

The list of third party testing accounts are found here.[0]

Right now there are three plugins that need to remove voting until they
are stable.

Please be active in #openstack-neutron, #openstack-qa, and the mailing
list so that if there is an issue with your testing structure, people
can come and talk to you.

Thank you,
Anita.

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

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

Re: [openstack-dev] [Neutron] Availability of external testing logs

[Joe Gordon]

On Mon, Dec 23, 2013 at 11:13 AM, Sean Dague  wrote:

> On 12/23/2013 12:10 PM, Collins, Sean wrote:
> > On Sun, Dec 22, 2013 at 12:30:50PM +0100, Salvatore Orlando wrote:
> >> I would suggest that external jobs should not vote until logs are
> publicly
> >> accessible, otherwise contributors would have no reason to understand
> where
> >> the negative vote came from.
> >
> > +1
> >
> > I've had Tail-F NCS Jenkins -1 some things that the OpenStack
> > Jenkins has +1'd, and other times where I've seen it +1 things that
> > OpenStack Jenkins -1'd.
>
> Agreed.
>
> I also think we need to have these systems prove themselves on
> reliability before they post votes back. A mis configured CI system can
> easily -1 the entire patch stream, and many of us use -Verified-1 as a
> filter criteria on reviews, which effectively makes that a DOS attack.
>
> Detailed public results need to come first. After those look reliable,
> voting can be allowed.
>
>

FYI, we are trying to record the requirements at
http://ci.openstack.org/third_party.html/, patch:
https://review.openstack.org/#/c/63478/


> -Sean
>
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> http://dague.net
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages

[David Kranz]

On Dec 30, 2013, at 11:32 AM, Jeremy Stanley  wrote:

> On 2013-12-30 10:25:07 -0500 (-0500), David Kranz wrote:
>> I get that but it seems like this is a single field per gerrit user.
>> Is that not true? If true, it is not useful because the point is
>> that we want to be able to filter reviews that contain changes to
>> tests for a particular project. I need to make different kinds of
>> requests, like with a bookmark for each one. Is it possible?
> 
> Right, the file filter parameter is really only effective for
> determining what changes Gerrit E-mails you about, or which ones
> should be incorporated into your list of watched changes. It's not
> available for general search queries (I suspect this was a
> compromise made for efficiency reasons since the queries could be
> pretty intense the way file information is stored in the underlying
> database).
> 
> Note, we're still running Gerrit 2.4 at the moment, so once we
> transition to 2.8 or 2.9 the flexibility in the search interface may
> increase significantly (I've heard it gives you the ability to
> bookmark various searches as custom dashboard views, but not sure
> what other search improvements may be added there).
> -- 
> Jeremy Stanley
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Looks like 2.8 came out recently and fixes this. It is mentioned near the top 
of http://ostrovsky.org/gerrit-code-review-2-8-released/. 

Is there a planned time to upgrade?

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

Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages

[Jeremy Stanley]

On 2013-12-30 22:46:24 -0500 (-0500), David Kranz wrote:
> Looks like 2.8 came out recently and fixes this. It is mentioned
> near the top of http://ostrovsky.org/gerrit-code-review-2-8-released/.

Awesome!

> Is there a planned time to upgrade?

It's a priority, but the upgrade process is still being tested and
kinks worked out for our data. The transition also depends on
additional patches/plugins at the moment, and the new version brings
changes in features which will are likely to be somewhat disruptive
(so we want to find ways to minimize that). I don't believe there's
a strict timeline or schedule for it at this point, but it is
definitely being worked on.
-- 
Jeremy Stanley

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

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

[Renat Akhmerov]

Greg,

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

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

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

Thanks.

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

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

[Renat Akhmerov]

Sorry for being a little bit verbose :) …

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

Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

[Nadya Privalova]

Hello all,

Thank you for your suggestions about tracking bps. I'll create a
spreadsheet.

David,

1. https://review.openstack.org/#/c/55276/ is ready for review
2. We decided to move base.py to a separate change request:
https://review.openstack.org/#/c/64304/ to make it merged ASAP. But now I
see that reviewers want to see an example of usage. We didn't wanted to add
any examples there. There are several changes that are abandoned now but
will be restored soon with dependency on 64304 (
https://review.openstack.org/#/c/43481/,
https://review.openstack.org/#/c/46745/). What do you think is it OK to
keep 64304 as a separate one?
3. https://review.openstack.org/#/c/39237/ is In Progress because it should
be depended on 2.
4. Not sure why https://review.openstack.org/#/c/64299/ is a separate one.
It is a part of 1 now. I think it should be abandoned.

And about "ceilometer", "metering", "telemetry". Originally 'metering' was
used, but official was changed to 'telemetry'. I'm not the person who
resolved such questions but I guess that 'telemetry' is the final solution.
Anyway, I will discuss it with Julien.

Thanks,
Nadya


On Mon, Dec 30, 2013 at 11:53 PM, David Kranz  wrote:

>  On 12/27/2013 05:27 AM, Nadya Privalova wrote:
>
>   Hello guys!
>
>  I hope all of you are enjoying the holidays! But I'd like to raise a
> Tempest question. Again. I hope this email will not be lost after vacations
> :)
>  After the summit we decided to track all tests that are being created for
> Ceilometer in Tempest here:
> https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests.
> Besides, we've created an etherpad page with a test plan
> https://etherpad.openstack.org/p/ceilometer-test-plan.
>
>  But it turned out that it works very bad. Now we have at least 3 change
> requests that have common functionality implemented. So we definitely need
> more reliable mechanism for tracking any changes.
> That's why I suggest to create a separate blueprint for each
> functionality. E.g. "Ceilometer client for Tempest", "Notification testing"
> with several bps that depend on it ("Swift notifications", "Glance
> notifications", "Nova notifications") and so on. In future we may vary the
> detail level of blueprints but now we need very detailed ones because
> different people have started to work on e.g. notifications.
>  So there are the following action items:
>  1. Resolve all conflicts in changes that are on review now (see my
> comment to https://review.openstack.org/#/c/39237/ patch set 21 for more
> details)
>  2. Create set of blueprints from the testplan we have
>  3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)
>
>  I may take care of all the items above. I need only "ok" from PTLs and
> Cores.
>  Anyway, we've started working on 1st item, because it is urgent. The
> second one may be postponed due to holidays.
>
>  And one more important thing. Code review for Ceilometer tests in Tempest
> is too slow. Some of change requests are created almost a half a year ago!
> Ceilometer guys, please be informed. I think all of us are interested in
> good tests.
>
>  Thank you for attention,
>  Nadya
>
>
>  So the tempest patches for ceilometer are still not a coherent set. Can
> you please mark anything that is not ready for review as Work In Progress,
> or abandon until there is really something to review?
>
> Also, having looked at a few of these, I am confused about the usage of
> "ceilometer", "metering", "telemetry". Is there an explanation for the
> context in which each of these terms is to be used?
>
>  -David
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev