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

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 Dja

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

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. in

[openstack-dev] [Mistral] Proposing to cancel community meetings today on Dec 30 and Jan 6

Hi, Due to NY celebrations and upcoming holidays I would suggest we cancel the next two Mistral community meetings: today on Dec 30 and on Jan 6. I tend to think they’re not going to be super productive. However, if someone still would like to have them please let us know. Thanks. Renat Akhme

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

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 t

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

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 prede

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

On Sun, Dec 29, 2013 at 7:51 PM, John Dickinson wrote: > > On Dec 29, 2013, at 2:05 PM, Michael Still wrote: > >> On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson wrote: >>> I've seen several disconnected messages about tags in commit messages. I've >>> seen >>> what is possible with the DocImpa

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

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

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

On Dec 29, 2013, at 2:05 PM, Michael Still wrote: > On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson wrote: >> I've seen several disconnected messages about tags in commit messages. I've >> seen >> what is possible with the DocImpact tag, and I'd like to have some more >> flexible tagging >> t

Re: [openstack-dev] [Ironic]Communication between Nova and Ironic

It makes a lot of sense. Thanks for your reply! B.R. Leslie Sent from my iPhone > On Dec 30, 2013, at 3:39 AM, "Oleg Gelbukh" wrote: > > Leslie, > > This discussion is very interesting indeed :) > > The current approach to auto-scale is that it is decided upon by Heat > service. Heat templa

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

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 cont

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

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

Re: [openstack-dev] [neutron] [third-party-testing] Tests against vendor controller

Hi Hemanth, I think that the only job that needs to be integrated with gate tests and vote is the one running tempest smoketests, which are plugin agnostic. For tests specific to a given controller, they can surely be integrated with upstream gerrit in order to vote on changes specific to the plug

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

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

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

On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson wrote: > I've seen several disconnected messages about tags in commit messages. I've > seen > what is possible with the DocImpact tag, and I'd like to have some more > flexible tagging > things too. I'd like to use tags for things like keeping trac

Re: [openstack-dev] [Neutron][LBaaS] Member status update mangled with pool stats API

Hi Vijay, Thanks for bringing this up. This is rather important API requirement to maintain actual member status. > One could argue that a periodic task could be started by the plugin driver instead of the agent, to collect the member > statuses. But since this is a requirement from many drivers,

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

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 was

[openstack-dev] [All] tagged commit messages

I've seen several disconnected messages about tags in commit messages. I've seen what is possible with the DocImpact tag, and I'd like to have some more flexible tagging things too. I'd like to use tags for things like keeping track of config defaults changing, specific ongoing feature work, and

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

On 12/24/2013 06:32 AM, Sean Dague wrote: On 12/24/2013 01:47 AM, Yair Fried wrote: Hi, Suggestion: Please consider tagging your Tempest commit messages the same way you do your mails in the mailing list Explanation: Since tempest is a single project testing multiple Openstack project we have

Re: [openstack-dev] [Ironic]Communication between Nova and Ironic

Leslie, This discussion is very interesting indeed :) The current approach to auto-scale is that it is decided upon by Heat service. Heat templates have special mechanisms to trigger auto-scaling of resources when certain conditions are met. In combination with Ironic, it has powerful potential f

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 n

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

On 12/28/2013 11:14 AM, Tim Bell wrote: I think there is a need for an incompatible change review process which includes more of the community than just those performing the code reviews. This kind of change can cause a lot of disruption for those of us running clouds so it is great to see tha

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

On 12/29/2013 03:53 PM, Clint Byrum wrote: > Excerpts from Andreas Jaeger's message of 2013-12-28 23:05:45 -0800: >> On 12/29/2013 07:50 AM, Robert Collins wrote: >>> One possible reason to want a different judgment call is that the >>> logic about impacted OS's was wrong - I claimed (correctly) th

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

Hi, Following all of the discussion I have done the following: 1. Update the wiki with all of the details - https://wiki.openstack.org/wiki/Nova_VM_Diagnostics 2. Renamed the BP. It is now called v3-diagnostics 3. Posted a patc

[openstack-dev] [Glance] Glance Mini Summit Details!

Hi folks, Late January, we will be having a mini summit focused on Glance and the Images Program. All OpenStack ATCs and associated technical product folks are welcome. Here are the details: Where: Hilton Washington Dulles Airport 13869 Park Center Road Herndon, Virginia 20171 (I do not yet know

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

Excerpts from Andreas Jaeger's message of 2013-12-28 23:05:45 -0800: > On 12/29/2013 07:50 AM, Robert Collins wrote: > > One possible reason to want a different judgment call is that the > > logic about impacted OS's was wrong - I claimed (correctly) that every > > OS has support for ext4, but negl

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

On 12/29/2013 03:06 AM, Day, Phil wrote: Basically, I'm not sure what problem you're trying to solve - lets tease that out, and then talk about how to solve it. "Backwards incompatible change landed" might be the problem - but since every reviewer knew it, having a longer review period is clearl

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

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 ex

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

> -Original Message- > From: Robert Collins [mailto:robe...@robertcollins.net] > Sent: 29 December 2013 06:50 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] minimum review period for functional > changes that break backwards compatib