Re: [openstack-dev] [Neutron] default security group rules in neutron

[shihanzhang]

Hi, Lingxian
I think it indeed backport this feature to neutron, it will be very convenient 
for operators to use default security group!










At 2014-06-23 10:23:39, "Lingxian Kong"  wrote:
>Greetings
>
>We use neutron as network functionality implementation in nova, and as
>you know, there is a feature called 'os-security-group-default-rules'
>in nova extension[1], a hook mechanism to add customized rules when
>creating default security groups, which is a very useful feature to
>the administrators or operators (at least useful to us in our
>deployment). But I found this feature is valid only when using
>nova-network.
>
>So, for the functionality parity between nova-network and neutron and
>for our use case, I registered a blueprint[2] about default security
>group rules in Neutron days ago and related neutron spec[3], and I
>want it to be involved in Juno, so we can upgrade our deployment that
>time for this feature. I'm ready for the code implementation[3].
>
>But I still want to see what's the community's thought about including
>this feature in neutron, any of your feedback and comments are
>appreciated!
>
>[1] 
>https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group
>[2] 
>https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
>[3] https://review.openstack.org/98966
>[4] https://review.openstack.org/99320
>
>-- 
>Regards!
>---
>Lingxian Kong
>
>___
>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] default security group rules in neutron

[Miguel Angel Ajo Pelayo]

   I believe it's an important feature, because currently
the default security rules are hard-coded in neutron's code,
and that won't fit all organizations (not to say that the
default security rules won't scale well on our current
implementation).

   Best,
Miguel Ángel
  



- Mensaje original -
> Greetings
> 
> We use neutron as network functionality implementation in nova, and as
> you know, there is a feature called 'os-security-group-default-rules'
> in nova extension[1], a hook mechanism to add customized rules when
> creating default security groups, which is a very useful feature to
> the administrators or operators (at least useful to us in our
> deployment). But I found this feature is valid only when using
> nova-network.
> 
> So, for the functionality parity between nova-network and neutron and
> for our use case, I registered a blueprint[2] about default security
> group rules in Neutron days ago and related neutron spec[3], and I
> want it to be involved in Juno, so we can upgrade our deployment that
> time for this feature. I'm ready for the code implementation[3].
> 
> But I still want to see what's the community's thought about including
> this feature in neutron, any of your feedback and comments are
> appreciated!
> 
> [1]
> https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group
> [2]
> https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
> [3] https://review.openstack.org/98966
> [4] https://review.openstack.org/99320
> 
> --
> Regards!
> ---
> Lingxian Kong
> 
> ___
> 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] [Swift] Swift 2.0 release candidate

[Matthew Oliver]

Nice work swift devs!

Storage policies were a great idea and now they exist!

Awesome work!

Matt
On Jun 23, 2014 2:04 PM, "John Dickinson"  wrote:

> Through extensive work from the entirety of the Swift dev team over the
> past year, storage policies have landed in Swift. Last Friday, we merged
> commit 1feaf6e2 which brings storage polices into master.
>
> I especially would like to publicly thank Paul Luse (Intel), Clay Gerrard
> (SwiftStack), and Sam Merritt (SwiftStack) for providing such tremendous
> focus, dedication, awesome ideas, and leadership to getting this feature
> designed, written, and merged.
>
> For those that don't know, storage policies are a way to take the global
> footprint of your Swift cluster and choose what subset of hardware to store
> the data on and how to store it across that subset of hardware. For
> example, a single Swift cluster can now have data segmented by geographic
> region or performance tier. Additionally, each policy can have a different
> replication factor, which enables high replication for local access (e.g.
> one copy in every PoP) or low replication for some data (e.g. image
> thumbnails or transcoded video).
>
> Storage policies is the necessary building block to allow non-replicated
> storage (i.e. erasure codes) in Swift, a feature that we are continuing to
> develop.
>
> Full documentation, including design, usage, and upgrade notes, can be
> found at http://swift.openstack.org/overview_policies.html.
>
> With this commit landing, we have tagged Swift 2.0.0.rc1. We are now
> having a two week QA period to allow community members to play with it in
> their labs. At the end of the RC period, we'll formally release Swift 2.0.
> The current target for this is Thursday July 3 (although I realize that
> discovered issues and the US holiday may put this at risk).
>
> In addition to participating in the OpenStack integrated release cycle,
> Swift makes semantically-versioned releases throughout the year. Because of
> the scope of the storage policies changes and because you cannot safely
> downgrade your cluster after configuring a second policy (i.e. you'd lose
> access to that data if you go to a pre-storage-policies release), we have
> chosen to bump the major version number to 2.
>
> Note that deployers can still upgrade to this version with no client
> downtime and still safely downgrade until multiple policies are configured.
>
> The full CHANGELOG for the 2.0 release is at
> https://github.com/openstack/swift/blob/master/CHANGELOG.
>
> If you are using Swift, please read over the docs, download the tarball
> from http://tarballs.openstack.org/swift/swift-2.0.0.rc1.tar.gz, and let
> us know what you find.
>
> --John
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

[Ian Wells]

On 21 June 2014 17:17, A, Keshava  wrote:

> Hi Thomas,
>
> This is interesting.
> I have some of the basic question about deployment model of using this
> BaGPipe BGP in virtual cloud network.
>
> 1. We want MPLS to start right from compute node as part Tennant traffic ?
> 2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
> Tenant = VRF ?
> Tenant span can be across multiple CN nodes,  then have BGP to
> Full mesh with in CN ?
> 3. How to have  E-VPN connectivity mapping at NN/CN nodes ?
> Is there an L2 VPN psuedowire thinking from CN nodes itself ?
> 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?ic
> Routing bp.
>
>
When you say things like 'tenant = VRF' (and, in fact, I presume you mean
'network = VRF', since networks and tenants are two different things) then
that's actually more to do with how you implement the networking overlay
layer in Neutron.  While interesting, and while it could potentially use a
BGP speaker and VRFs to do it, it's not the same use case as advertising
routes externally, or terminating an external MPLS VPN in Openstack.  I
could do either of those things independently of the other.  Terminating
VPNs requires an extension API and could potentially glue on to a current
plugin (much like VPNaaS).  Writing overlays is a new plugin entirely.

There's a use for BGP speakers in both arenas (and additionally within the
distributed virtual router, which is a third case) so perhaps we could
address who's using which speaker for precisely what?
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Swift] Swift 2.0 release candidate

[John Dickinson]

Through extensive work from the entirety of the Swift dev team over the past 
year, storage policies have landed in Swift. Last Friday, we merged commit 
1feaf6e2 which brings storage polices into master.

I especially would like to publicly thank Paul Luse (Intel), Clay Gerrard 
(SwiftStack), and Sam Merritt (SwiftStack) for providing such tremendous focus, 
dedication, awesome ideas, and leadership to getting this feature designed, 
written, and merged.

For those that don't know, storage policies are a way to take the global 
footprint of your Swift cluster and choose what subset of hardware to store the 
data on and how to store it across that subset of hardware. For example, a 
single Swift cluster can now have data segmented by geographic region or 
performance tier. Additionally, each policy can have a different replication 
factor, which enables high replication for local access (e.g. one copy in every 
PoP) or low replication for some data (e.g. image thumbnails or transcoded 
video).

Storage policies is the necessary building block to allow non-replicated 
storage (i.e. erasure codes) in Swift, a feature that we are continuing to 
develop.

Full documentation, including design, usage, and upgrade notes, can be found at 
http://swift.openstack.org/overview_policies.html.

With this commit landing, we have tagged Swift 2.0.0.rc1. We are now having a 
two week QA period to allow community members to play with it in their labs. At 
the end of the RC period, we'll formally release Swift 2.0. The current target 
for this is Thursday July 3 (although I realize that discovered issues and the 
US holiday may put this at risk).

In addition to participating in the OpenStack integrated release cycle, Swift 
makes semantically-versioned releases throughout the year. Because of the scope 
of the storage policies changes and because you cannot safely downgrade your 
cluster after configuring a second policy (i.e. you'd lose access to that data 
if you go to a pre-storage-policies release), we have chosen to bump the major 
version number to 2.

Note that deployers can still upgrade to this version with no client downtime 
and still safely downgrade until multiple policies are configured.

The full CHANGELOG for the 2.0 release is at 
https://github.com/openstack/swift/blob/master/CHANGELOG.

If you are using Swift, please read over the docs, download the tarball from 
http://tarballs.openstack.org/swift/swift-2.0.0.rc1.tar.gz, and let us know 
what you find.

--John






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] default security group rules in neutron

[Lingxian Kong]

Greetings

We use neutron as network functionality implementation in nova, and as
you know, there is a feature called 'os-security-group-default-rules'
in nova extension[1], a hook mechanism to add customized rules when
creating default security groups, which is a very useful feature to
the administrators or operators (at least useful to us in our
deployment). But I found this feature is valid only when using
nova-network.

So, for the functionality parity between nova-network and neutron and
for our use case, I registered a blueprint[2] about default security
group rules in Neutron days ago and related neutron spec[3], and I
want it to be involved in Juno, so we can upgrade our deployment that
time for this feature. I'm ready for the code implementation[3].

But I still want to see what's the community's thought about including
this feature in neutron, any of your feedback and comments are
appreciated!

[1] 
https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group
[2] 
https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
[3] https://review.openstack.org/98966
[4] https://review.openstack.org/99320

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [hacking] rules for removal

[Christopher Yeoh]

On Mon, Jun 23, 2014 at 4:43 AM, Jay Pipes  wrote:

> On 06/22/2014 09:41 AM, Amrith Kumar wrote:
>
>> In addition to making changes to the hacking rules, why don't we mandate
>> also
>> that perceived problems in the commit message shall not be an acceptable
>> reason to -1 a change.
>>
>> Would this improve the situation?
>>
>
> I actually *do* think a very poor commit message for a substantial patch
> deserves a -1. The git commit message is our history for the patch, and it
> is important in its own right. Now, nits like a single misspelled word or
> the commit summary being 60 characters instead of 50 are not what I'm
> talking about, of course.
>
> I'm speaking only about when a commit message blatantly disregards the
> best practices of commit message writing [1] and doesn't offer anything of
> value to the reviewer.
>
>
+1.

Minor typos and grammatical errors I don't  care about (but will put in
suggested fixes if the patch needs to be updated anyway). However, commit
messages are very important for future debugging. One or two line vague
commit messages can make life a lot harder for others in the future when
writing a short description is not what I'd consider an excessive burden.
And there should be no assumption that the person reading the commit
message will have easy access to the bug database.

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

Re: [openstack-dev] [Oslo] Translating log and exception messages in Oslo libraries

[Jay Bryant]

+1 To translating oslo logs.  There is quite a bit of logging that comes
out of the libraries.   It should be logged for consistency using delayed
translation.

Jay
On Jun 20, 2014 8:22 AM, "Doug Hellmann" 
wrote:

> On Fri, Jun 20, 2014 at 8:40 AM, Mark McLoughlin 
> wrote:
> > Hi
> >
> > I'm not sure we've ever discussed this before, but I had previously
> > figured that we shouldn't translate log and exception messages in
> > oslo.messaging.
> >
> > My thinking is:
> >
> >   - it seems like an odd thing for a library to do, I don't know of
> > examples of other libraries doing this .. but I haven't gone
> > looking
> >
> >   - it involves a dependency on oslo.i18n
> >
> >   - more than just marking strings for translation and using
> > gettextutils, you also need to set up the infrastructure for pushing
> > the .pot files to transifex, pulling the .po files from .transifex
> > and installing the .mo files at install time
> >
> > I don't feel terribly strongly about this except that unless someone is
> > willing to see this through and do the transifex and install-time work,
> > we shouldn't be doing the use-oslo.i18n and mark-strings-for-translation
> > work.
>
> I had thought we would do all of the oslo libraries, since so many of
> the log messages actually come from library code. I think Andreas has
> already set up most of the infrastructure needed to make the
> translation jobs work.
>
> We haven't done a great job of communicating the plan on log
> translations, and I'm currently looking for someone from the i18n team
> to step forward to be the point of contact on that work.
>
> Doug
>
> >
> > Mark.
> >
> >
> > ___
> > 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] [hacking] rules for removal

[Jay Bryant]

I agree Duncan.

I think the commit message is one of the most important parts of a
commit.   If the message is not useful, the code shouldn't go in.

Jay Bryant
On Jun 22, 2014 1:51 PM, "Duncan Thomas"  wrote:

> On 22 June 2014 14:41, Amrith Kumar  wrote:
> > In addition to making changes to the hacking rules, why don't we mandate
> also
> > that perceived problems in the commit message shall not be an acceptable
> > reason to -1 a change.
>
> -1.
>
> There are some /really/ bad commit messages out there, and some of us
> try to use the commit messages to usefully sort through the changes
> (i.e. I often -1 in cinder a change only affects one driver and that
> isn't clear from the summary).
>
> If the perceived problem is grammatical, I'm a bit more on board with
> it not a reason to rev a patch, but core reviewers can +2/A over the
> top of a -1 anyway...
>
> > Would this improve the situation?
>
> Writing better commit messages in the first place would improve the
> situation?
>
> ___
> 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] Periodic Security Checks

[Grant Murphy]

Adding openstack-security to the thread. In case folks on OSSG don't monitor 
this list. 

- Original Message -
> From: "Alexandr Naumchev" 
> To: openstack-dev@lists.openstack.org
> Cc: "Amey Ghadigaonkar" , "Vasiliy Artemev" 
> , "David Yuan"
> 
> Sent: Sunday, June 22, 2014 4:33:35 AM
> Subject: [openstack-dev] Periodic Security Checks
> 
> Hello!
> We have blueprints here:
> 
> https://blueprints.launchpad.net/horizon/+spec/periodic-security-checks
> 
> and here:
> 
> https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/
> 
> And we already have some code. Is it necessary to approve the blueprint
> before contributing the code? In any case, could someone review the
> aforementioned blueprints?
> Thanks!
> 
> ___
> 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-Infra] [infra] Nominations for jenkins-job-builder core

[Jeremy Stanley]

On 2014-06-20 14:01:01 -0700 (-0700), James E. Blair wrote:
> The Jenkins Job Builder project [...] core reviewers [...] I would
> like to add Darragh Bailey [...] and Marc Abramowitz
[...]

I'm very much in favor of both Darragh and Marc as additions to the
openstack-infra/jenkins-job-builder project core reviewer team.
Their knowledge of the project internals and support of its existing
core reviewers has been invaluable.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Octavia] PTL and core team members

[Stephen Balukoff]

Hi Brandon,

Yep, that sounds like a good way to approach this. And FWIW, this week I'm
planning on moving several of the designs I've presented to the group into
blueprints / gerrit specs for the project and otherwise start working on a
roadmap to actually get the thing built.

In the mean time, there's still a ton that needs to be done on the Neutron
LBaaS side of things to make sure we get feature improvements and cleaner
Neutron API interfaces in before the Juno freeze. So I don't think there's
a reason anyone should be idle working on these two projects, eh.

Stephen


On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan  wrote:

> I'm thinking we are going to need more than 2 on the core team at first
> but it is hard to tell exactly how many people will be contributing code
> at first.  I know we've got a lot of interested parties and the
> possibility that some 10+ people are actively contributing.  Of course,
> these things can only be predicted and will be unknown until it is
> actually known.
>
> Also, we really need to have a good plan of action.  Once we get a
> consensus on the design we should start breaking the implementation up
> into umbrella blueprint specs (or epic blueprint specs) with each one
> detailing the bigger picture and breaking up the bigger picture into
> smaller tasks/stories that can be accomplished.  Then people can start
> choosing which they would like to implement.  Sounds good in theory, but
> actually executing it will be the tough part.
>
> Thanks,
> Brandon
>
> On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote:
> > On 20/06/14 07:29 +0100, Mark McLoughlin wrote:
> > >On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:
> > >> Dolph,
> > >>
> > >>
> > >> I appreciate the suggestion. In the mean time how does the review
> > >> process work without core developers to approve gerrit submissions?
> > >
> > >If you're just getting started, have a small number (possibly just 1 to
> > >begin with) of developers collaborate closely, with the minimum possible
> > >process and then use that list of developers as your core review team
> > >when you gradually start adopting some process. Aim to get from zero to
> > >bootstrapped with that core team in a small number of weeks at most.
> > >
> > >Minimum possible process could mean a git repo anywhere that those
> > >initial developers have direct push access to. You could use stackforge
> > >from the beginning and the developers just approve their own changes,
> > >but that's a bit annoying.
> >
> > +1 this is how we did it in Marconi (except for the repo with push
> > access). At the beginning, we kept a core team of 2 developers despite
> > there being at least 4 ppl working on the project. This allowed the
> > team to have better discussions on what got in the repo and what not.
> >
> > One benefit of using stackforge is that you get a great CI system to
> > test your project with but the development will slow down for sure. We
> > started on stackforge right away, then had a 2 days hackathon on a
> > github fork which was not a good idea because we had to submit al
> > those patches for review after the hackathon. :(
> >
> > Flavio
> >
> > ___
> > 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
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

[Jay Pipes]

On 06/22/2014 09:41 AM, Amrith Kumar wrote:

In addition to making changes to the hacking rules, why don't we mandate also
that perceived problems in the commit message shall not be an acceptable
reason to -1 a change.

Would this improve the situation?


I actually *do* think a very poor commit message for a substantial patch 
deserves a -1. The git commit message is our history for the patch, and 
it is important in its own right. Now, nits like a single misspelled 
word or the commit summary being 60 characters instead of 50 are not 
what I'm talking about, of course.


I'm speaking only about when a commit message blatantly disregards the 
best practices of commit message writing [1] and doesn't offer anything 
of value to the reviewer.


Best,
-jay

[1] https://wiki.openstack.org/wiki/GitCommitMessages

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

Re: [openstack-dev] [hacking] rules for removal

[Jay Pipes]

On 06/20/2014 02:07 PM, Sean Dague wrote:

After seeing a bunch of code changes to enforce new hacking rules, I'd
like to propose dropping some of the rules we have. The overall patch
series is here -
https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z

H402 - 1 line doc strings should end in punctuation. The real statement
is this should be a summary sentence. A sentence is not just a set of
words that end in a period. Squirel fast bob. It's something deeper.
This rule thus isn't really semantically useful, especially when you are
talking about at 69 character maximum (79 - 4 space indent - 6 quote
characters).


++ This was always a silly rule, IMO

Sorry, forgot to add a period. There. Better.


H803 - First line of a commit message must *not* end in a period. This
was mostly a response to an unreasonable core reviewer that was -1ing
people for not having periods. I think any core reviewer that -1s for
this either way should be thrown off the island, or at least made fun
of, a lot. Again, the clarity of a commit message is not made or lost by
the lack or existence of a period at the end of the first line.


+10

Sorry, I meant +10. Period.


H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty,
our tree. This biggest issue here is it's built in a world where there
was only 1 viable python version, 2.7. Python's stdlib is actually
pretty dynamic and grows over time. As we embrace more python 3, and as
distros start to make python3 be front and center, what does this even
mean? The current enforcement can't pass on both python2 and python3 at
the same time in many cases because of that.


+0 on this one... I find it useful to group the libs together in this 
way, as it makes it relatively easy to identify quickly at a glance the 
third party libs that are in use in the module.



We have to remember we're all humans, and it's ok to have grey space.
Like in 305, you *should* group the libraries if you can, but stuff like
that should be labeled as 'nit' in the review, and only ask the author
to respin it if there are other more serious issues to be handled.


Ya, no real disagreement on that.


Let's optimize a little more for fun, and stop throwing -1s for silly
things. :)


++

I would also love to get rid of H404, otherwise known as the dumb rule 
that says if you have a multiline docstring, that there must be a 
summary line, then a blank line, then a detailed description. It makes 
things like this illegal, which, IMHO, is stupid:


def do_something(self, thing):
"""We do something with the supplied thing, so that something else
is also done with this other thing. Make sure the other thing is
of type something.
"""
pass

Likewise, I'd love to be able to have a newline start the docstring, 
like so:


def do_something(self, thing):
"""
We do something with the supplied thing, so that something else
is also done with this other thing. Make sure the other thing is
of type something.
"""
pass

But there's a rule that prevents that as well...

To be clear, I don't think all hacking rules are silly. To the contrary, 
there are many that are reasonable and useful. However, I'd prefer to 
focus on things that make the code more readable, not less readable, and 
rules that enforce Pythonic idioms, not some random hacker's idea of 
good style.


Best,
-jay

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

Re: [openstack-dev] [hacking] rules for removal

[Duncan Thomas]

On 22 June 2014 14:41, Amrith Kumar  wrote:
> In addition to making changes to the hacking rules, why don't we mandate also
> that perceived problems in the commit message shall not be an acceptable
> reason to -1 a change.

-1.

There are some /really/ bad commit messages out there, and some of us
try to use the commit messages to usefully sort through the changes
(i.e. I often -1 in cinder a change only affects one driver and that
isn't clear from the summary).

If the perceived problem is grammatical, I'm a bit more on board with
it not a reason to rev a patch, but core reviewers can +2/A over the
top of a -1 anyway...

> Would this improve the situation?

Writing better commit messages in the first place would improve the situation?

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

Re: [openstack-dev] [Octavia] PTL and core team members

[Brandon Logan]

I'm thinking we are going to need more than 2 on the core team at first
but it is hard to tell exactly how many people will be contributing code
at first.  I know we've got a lot of interested parties and the
possibility that some 10+ people are actively contributing.  Of course,
these things can only be predicted and will be unknown until it is
actually known.

Also, we really need to have a good plan of action.  Once we get a
consensus on the design we should start breaking the implementation up
into umbrella blueprint specs (or epic blueprint specs) with each one
detailing the bigger picture and breaking up the bigger picture into
smaller tasks/stories that can be accomplished.  Then people can start
choosing which they would like to implement.  Sounds good in theory, but
actually executing it will be the tough part.

Thanks,
Brandon

On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote:
> On 20/06/14 07:29 +0100, Mark McLoughlin wrote:
> >On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:
> >> Dolph,
> >>
> >>
> >> I appreciate the suggestion. In the mean time how does the review
> >> process work without core developers to approve gerrit submissions?
> >
> >If you're just getting started, have a small number (possibly just 1 to
> >begin with) of developers collaborate closely, with the minimum possible
> >process and then use that list of developers as your core review team
> >when you gradually start adopting some process. Aim to get from zero to
> >bootstrapped with that core team in a small number of weeks at most.
> >
> >Minimum possible process could mean a git repo anywhere that those
> >initial developers have direct push access to. You could use stackforge
> >from the beginning and the developers just approve their own changes,
> >but that's a bit annoying.
> 
> +1 this is how we did it in Marconi (except for the repo with push
> access). At the beginning, we kept a core team of 2 developers despite
> there being at least 4 ppl working on the project. This allowed the
> team to have better discussions on what got in the repo and what not.
> 
> One benefit of using stackforge is that you get a great CI system to
> test your project with but the development will slow down for sure. We
> started on stackforge right away, then had a 2 days hackathon on a
> github fork which was not a good idea because we had to submit al
> those patches for review after the hackathon. :(
> 
> Flavio
> 
> ___
> 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] [hacking] rules for removal

[Amrith Kumar]

In addition to making changes to the hacking rules, why don't we mandate also 
that perceived problems in the commit message shall not be an acceptable 
reason to -1 a change.

Would this improve the situation?

-amrith

--

Amrith Kumar, CTO Tesora (www.tesora.com)

Twitter: @amrithkumar
IRC: amrith @freenode

| -Original Message-
| From: Sean Dague [mailto:s...@dague.net]
| Sent: Friday, June 20, 2014 2:08 PM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: [openstack-dev] [hacking] rules for removal
|
| After seeing a bunch of code changes to enforce new hacking rules, I'd
| like to propose dropping some of the rules we have. The overall patch
| series is here -
| https://review.openstack.org/#/q/status:open+project:openstack-
| dev/hacking+branch:master+topic:be_less_silly,n,z
|
| H402 - 1 line doc strings should end in punctuation. The real statement is
| this should be a summary sentence. A sentence is not just a set of words
| that end in a period. Squirel fast bob. It's something deeper.
| This rule thus isn't really semantically useful, especially when you are
| talking about at 69 character maximum (79 - 4 space indent - 6 quote
| characters).
|
| H803 - First line of a commit message must *not* end in a period. This was
| mostly a response to an unreasonable core reviewer that was -1ing people
| for not having periods. I think any core reviewer that -1s for this either
| way should be thrown off the island, or at least made fun of, a lot.
| Again, the clarity of a commit message is not made or lost by the lack or
| existence of a period at the end of the first line.
|
| H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty,
| our tree. This biggest issue here is it's built in a world where there was
| only 1 viable python version, 2.7. Python's stdlib is actually pretty
| dynamic and grows over time. As we embrace more python 3, and as distros
| start to make python3 be front and center, what does this even mean? The
| current enforcement can't pass on both python2 and python3 at the same
| time in many cases because of that.
|
| We have to remember we're all humans, and it's ok to have grey space.
| Like in 305, you *should* group the libraries if you can, but stuff like
| that should be labeled as 'nit' in the review, and only ask the author to
| respin it if there are other more serious issues to be handled.
|
| Let's optimize a little more for fun, and stop throwing -1s for silly
| things. :)
|
|   -Sean
|
| --
| Sean Dague
| http://dague.net



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches

[Sean Dague]

On 06/21/2014 05:41 PM, Doug Hellmann wrote:
> 
> 
> 
> On Sat, Jun 21, 2014 at 2:27 PM, Morgan Fainberg
> mailto:morgan.fainb...@gmail.com>> wrote:
> 
> The issue with the login page simply refreshing was due to a change
> in Keystone that updated the type of Token issued by default from
> PKI to PKIZ (compressed PKI/ASN1). The update to the django auth
> module was intended to correct that specific issue with Keystone and
> Horizon (Juno).
> 
> The bug fix (not sure if another review is to blame with the
> django_openstack_auth module tha t is currently happening) that
> addressed your specific issue is:
> https://bugs.launchpad.net/horizon/+bug/1331406
> 
> I have proposed a fix for Keystone that would revert the PKIZ
> default: https://review.openstack.org/#/c/101714/
> 
> Depending on the fixes upcoming for the django_openstack_auth
> module, it may make sense to temporarily revert the PKIZ provider
> default until we can solve the issues with the django auth module
> and horizon when PKIZ is enabled. If this review is not needed based
> on how the horizon issues are corrected, it will be abandoned.
> 
> I think this is also showing some gaps in our testing, notably that
> the django_openstack_auth module isn't being exercised on the
> integration tests. I'll aim to hit up Horizon team and work with
> them and the QA folks to make sure we cover this gap in the future.
> 
> 
> ​We may also want to consider adding it to the list of libraries we have
> in the cross-project unit test matrix
> (https://review.openstack.org/#/c/95885/).

This is actually just the same issue we've got with the python clients.
The changes were moving through to actually do the right thing here
(https://review.openstack.org/#/c/79881/) however, that's got to be
backported to stable devstack branches as well.

Also we need https://review.openstack.org/101749

I just approved https://review.openstack.org/#/c/101734/ (havana pin)

Once that passes and merges, if someone rechecks the icehouse pin
(Approved, but it won't pass tests until the havana version lands)
https://review.openstack.org/#/c/101727/, it should pass and let patches
flow again.

Next week we need a proper unwind with the horizon team to get
django_openstack_auth working with stable/* again, get the testing
working again.

I'm mostly away from computers today, however 101727 should be in a
state where all it needs is a recheck bug 1331406 in about an hour or
two, which anyone can do.

-Sean

> 
> Doug
> 
>  
> 
> 
> 
> --Morgan
> 
> On Saturday, June 21, 2014, Mike Spreitzer  > wrote:
> 
> Since Friday I have been getting this misbehavior: enter
> username and password, hit login, and it shows you the login
> page again.
> 
> 
> Sean Dague --- [openstack-dev] horizon failing on icehouse 100%,
> currently blocking all patches ---
> 
> 
> From: "Sean Dague" 
> To"openstack-dev" 
> Date: Sat, Jun 21, 2014 12:54
> Subject   [openstack-dev] horizon failing on icehouse 100%,
> currently blocking all patches
> 
> 
> 
> 
> Horizon in icehouse is now 100% failing
> 
>  [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: /
> [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call
> last):
> [Sat Jun 21 16:17:35 2014] [error]   File
> "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py",
> line 112, in get_response
> [Sat Jun 21 16:17:35 2014] [error] response =
> wrapped_callback(request, *callback_args, **callback_kwargs)
> [Sat Jun 21 16:17:35 2014] [error]   File
> 
> "/usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py",
> line
> 36, in inner_func
> [Sat Jun 21 16:17:35 2014] [error] response = func(*args,
> **kwargs)
> [Sat Jun 21 16:17:35 2014] [error]   File
> 
> "/opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py",
> line 35, in splash
> [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request)
> [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module'
> object has
> no attribute 'Login'
> 
> This suspiciously times with django_openstack_auth 1.1.6 being
> released.
> 
> http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9
> 
> Because this breaks smoke tests on icehouse, it means that any
> project
> with upgrade testing fails.
> 
> 

Re: [openstack-dev] [Octavia] PTL and core team members

[Flavio Percoco]

On 20/06/14 07:29 +0100, Mark McLoughlin wrote:

On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:

Dolph,


I appreciate the suggestion. In the mean time how does the review
process work without core developers to approve gerrit submissions?


If you're just getting started, have a small number (possibly just 1 to
begin with) of developers collaborate closely, with the minimum possible
process and then use that list of developers as your core review team
when you gradually start adopting some process. Aim to get from zero to
bootstrapped with that core team in a small number of weeks at most.

Minimum possible process could mean a git repo anywhere that those
initial developers have direct push access to. You could use stackforge
from the beginning and the developers just approve their own changes,
but that's a bit annoying.


+1 this is how we did it in Marconi (except for the repo with push
access). At the beginning, we kept a core team of 2 developers despite
there being at least 4 ppl working on the project. This allowed the
team to have better discussions on what got in the repo and what not.

One benefit of using stackforge is that you get a great CI system to
test your project with but the development will slow down for sure. We
started on stackforge right away, then had a 2 days hackathon on a
github fork which was not a good idea because we had to submit al
those patches for review after the hackathon. :(

Flavio

--
@flaper87
Flavio Percoco


pgp3yPPKqEift.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] [hacking] rules for removal

[Mark McLoughlin]

On Sat, 2014-06-21 at 07:36 -0700, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2014-06-21 05:08:01 -0700:

> > Pedantic reviewers that are reviewing for this kind of thing only should
> > be scorned. I realistically like the idea markmc came up with -
> > https://twitter.com/markmc_/status/480073387600269312
> >
> 
> I also agree it is really fun to think about shaming those annoying
> actions. It is also not fun _at all_ to be publicly shamed. In fact I'd
> say it is at least an order of magnitude less fun. There is an old saying,
> "praise in public, punish in private." It is one reason the -1 comments I
> give always include praise for whatever is right for new contributors. Not
> everyone is a grizzled veteran.
> 
> It is far more interesting to me to solve the grouping problem in a
> way that works for us long term (python 2 and 3) than it is to develop
> a culture that builds any of its core activities on negative emotional
> feedback.
> 
> That's not to say we can't say "hey you're doing it wrong." I mean to say
> that direct feedback like that belongs in private IRC messages or email,
> not in public "everyone can see that" reviews. Give people a chance to
> save face. Meanwhile, the less we have to have one on one negative
> feedback, the easier the job of reviewers is.
> 
> The last thing we want to do is have more reasons for people to NOT do
> reviews.

You're right that something like I suggested could easily lead to more
negative energy in the project, not less.

What I had in mind was that we could laugh at ourselves about this.
Assuming that the reviewers called out would be fully on-board and
willing to laugh along at being the most pedantic nerd of the week.

Yeah, that's probably wishful thinking. Maybe it could be anonymous.
Maybe instead it could be a weekly mailing list discussion so that we
could all discuss as a community whether that kind of feedback on a
review is appropriate.

The main point is that this is something worth addressing as a wider
community rather than in individual reviews with a limited audience. And
that doing it with a bit of humor might help take the sting out of it.

Mark.


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