Re: [OpenStack-Infra] JJB V2.0 planning

[Darragh Bailey]

Think you forgot to Reply-All ;-)

Only spotted that now, while I was waiting for others to chime in and see
different points of view.

On 22 November 2016 at 07:25, Wayne Warren  wrote:

>
>
> On Tue, Nov 15, 2016 at 8:04 AM, Darragh Bailey 
> wrote:
>
>>
>> So on that patch:
>> https://review.openstack.org/358019 Support explicit API and simple
>> config creation
>>
>> Does it make sense? I'd like to hear other people's opinion on whether it
>> makes sense to have an explicit API as well as a from_config(cfg) method
>> when someone would create the config object and then pass it around, or is
>> it more of a YAGNI?
>>
>
> I think that if you don't have an explicit use case for it that you intend
> to use personally it's probably a YAGNI.
>
> Personally, I prefer to pass configuration values around with and access
> them through an instance of a single configuration class that
>
> * can be more easily instantiated with reasonable default settings
> * we can reason about and write tests for configuration
> * discourages proliferation of scattered configuration value munging
> throughout the code base which is one problem that JJBConfig was intended
> to address
>
> Also, should all classes be instantiable without a JJBConfig? Why? If not,
> why not? I'm curious why the focus on the Builder object for this behavior,
> but I'm also interested in the principles at work here so I can change my
> way of thinking if it's flawed; sorry if I've missed an explanation in the
> past.
>

Previous experience with libcurl, which also uses this idea of
configuration all in one object and then passed around, resulted in me
experiencing that fun behaviour of needing to refer back to the config
object in order to determine how to control the behaviour of the other
API's I was calling. It was exceedingly frustrating, though that might be
just due to poor API documentation on the curl project's behalf.

I'm not sure it'll discourage "proliferation of scattered configuration",
but rather have methods that reach into the config object to get
behavioural controlling settings that are not then clearly reflected in the
arguments into the method/class.

End up needing to define config options used internally as part of
classes/methods docstrings in order to help convey how to use the API.

Btw, the builder was just the easiest to look at first, I didn't see any
point in going through the rest of the objects and making changes to have
an expressive constructor which used params that controlled the current
objects behaviour, if it was clear this doesn't make sense as an approach.

Of course for the plugin settings, these will have to be passed through as
a single config object to the dispatch methods, so perhaps unless we plan
to look at that as well, maybe there is no need to worry about the other
classes having separate params for each setting controlling instantiated
objects behaviour.



> Since it impacts the API that will be published, seems like it would be a
>> good idea to get this ironed out before releasing?
>>
>
> I'd prefer to choose one approach for instantiating objects now based on
> its technical merits, make sure it's not incompatible with whatever
> alternative we are considering, and save alternatives as additive features
> that can be implemented sometime in the future when a need becomes apparent.
>

Agreed, it's probably only because there is no overloading of constructors
available in most dynamic languages that it's needing a closer look because
I'm not sure it's possible to add support for creation without a config
object without another breaking API change. I think the only solution would
be simple subclasses with different __init__ methods.

Hence I'm willing to look at this pretty closely.


> --
>> Darragh Bailey
>> "Nothing is foolproof to a sufficiently talented fool"
>>
>
>

Suggested to Thanh, that it might be worth cutting a beta release (maybe
tomorrow) and advertise it to allow people to start installing from pypi by
using '--pre'.

-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [infra]please help to add initial member to networking-zte-core andnetworking-zte-release group

[Joshua Hesketh]

I did this and replied to the os-dev list.

On Mon, Nov 21, 2016 at 7:30 PM, flyflyzhen08 
wrote:

> Hi Infra team:
>
> Please add the following member to networking-zte-core
> and networking-zte-release group.
>
> kyle liu: liu.hui58 at zte.com.cn
>
> Thanks!
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Fw: [Openstack-Infra]please help to add initial member to networking-zte-core and networking-zte-release group

[Joshua Hesketh]

Hi Kyle,

I've added you to those groups.

Cheers,
Josh

On Tue, Nov 29, 2016 at 12:30 PM, flyflyzhen08 
wrote:

> Is anyone able to handle this?
>
> Thanks.
>
> ---Original---
> *From:* "flyflyzhen08 "
> *Date:* 2016/11/21 16:30:03
> *To:* "openstack-infra";
> *Subject:* [infra]please help to add initial member to 
> networking-zte-coreandnetworking-zte-release
> group
>
> Hi Infra team:
>
> Please add the following member to networking-zte-core
> and networking-zte-release group.
>
> kyle liu: liu.hui58 at zte.com.cn
>
> Thanks!
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Group membership request

[Joshua Hesketh]

Hey Christopher,

No problems, I've added you to that group.

Cheers,
Josh

On Thu, Dec 1, 2016 at 11:24 AM, Christopher Aedo  wrote:

> Dear infra, could someone please add me to this group:
> https://review.openstack.org/#/admin/groups/1651,members
>
> This was created as a result of this patch I submitted:
> https://review.openstack.org/398533
>
> Thanks very much!
>
> -Christopher
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M.  wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

thank you.

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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