[openstack-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

A bit delayed because of a bonkers conference this weekend, but here's
what went on last week in Horizon land.

During the team meeting[1] I reiterated that there's a priority list
of patches for review that has still been needing attention[2], and
that we'd start looking at pulling some of the angularjs interface
patches from our Ocata-2 list[3] over to that review list also.

We discussed the new README team badges, and discovered that the bug I
noticed has already been patched, so we just need to get the README
structure corrected.

We discussed the (old) pending patch for zaqar / websocket use in
panel updates, and agreed that it makes sense for us to implement such
support in newer angularjs interfaces rather than add functionality to
the legacy panels which will be deprecated.

Finally the tox migration is almost complete, with the patch mentioned
in the meeting[4] now merged. The only remaining task will be to
remove run_tests.sh completely in Queens. Current users of
run_tests.sh should stop doing so ASAP, and will already have noticed
that venv maintenance is slower due to it now pulling in
upper-constraints.


Catch you next week in #openstack-horizon

Richard


[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-30-20.00.html
[2] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open
[3] https://etherpad.openstack.org/p/horizon-ocata-priorities
[4] https://review.openstack.org/#/c/391506/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

[Michael Still]

+1, I'd value him on the team.

Michael

On Sat, Dec 3, 2016 at 2:22 AM, Matt Riedemann 
wrote:

> I'm proposing that we add Stephen Finucane to the nova-core team. Stephen
> has been involved with nova for at least around a year now, maybe longer,
> my ability to tell time in nova has gotten fuzzy over the years.
> Regardless, he's always been eager to contribute and over the last several
> months has done a lot of reviews, as can be seen here:
>
> https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com
>
> http://stackalytics.com/report/contribution/nova/180
>
> Stephen has been a main contributor and mover for the config option
> cleanup series that last few cycles, and he's a go-to person for a lot of
> the NFV/performance features in Nova like NUMA, CPU pinning, huge pages,
> etc.
>
> I think Stephen does quality reviews, leaves thoughtful comments, knows
> when to hold a +1 for a patch that needs work, and when to hold a -1 from a
> patch that just has some nits, and helps others in the project move their
> changes forward, which are all qualities I look for in a nova-core member.
>
> I'd like to see Stephen get a bit more vocal / visible, but we all handle
> that differently and I think it's something Stephen can grow into the more
> involved he is.
>
> So with all that said, I need a vote from the core team on this
> nomination. I honestly don't care to look up the rules too much on number
> of votes or timeline, I think it's pretty obvious once the replies roll in
> which way this goes.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

[Steven Dake (stdake)]

Thierry,

I personally prefer the meeting rooms as they are; however, we do need more of 
them.  I am often pinged in various other meetings in the common meeting 
channels and find the group communication that happens in this way preferable 
to joining each specific project channel.  Joining each specific project 
channel just to be pinged when desired during a project meeting introduces 
significant cognitive overhead for me.

I don’t know how others feel.

I’d be in favor of increasing the meeting rooms to enable the worldwide 
membership of OpenStack to better communicate as groups rather than silos and 
managing the meeting channels proactively.

Regards
-steve


-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 2, 2016 at 3:35 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [all] Creating a new IRC meeting room ?

Hi everyone,

There has been a bit of tension lately around creating IRC meetings.
I've been busy[1] cleaning up unused slots and defragmenting biweekly
ones to open up possibilities, but truth is, even with those changes
approved, there will still be a number of time slots that are full:

Tuesday 14utc -- only biweekly available
Tuesday 16utc -- full
Wednesday 15utc -- only biweekly available
Wednesday 16utc -- full
Thursday 14utc -- only biweekly available
Thursday 17utc -- only biweekly available

[1] https://review.openstack.org/#/q/topic:dec2016-cleanup

Historically, we maintained a limited number of meeting rooms in order
to encourage teams to spread around and limit conflicts. This worked for
a time, but those days I feel like team members don't have that much
flexibility in picking a time that works for everyone. If the miracle
slot that works for everyone is not available on the calendar, they tend
to move the meeting elsewhere (private IRC channel, Slack, Hangouts)
rather than change time to use a less-busy slot.

So I'm now wondering how much that artificial scarcity policy is hurting
us more than it helps us. I'm still convinced it's very valuable to have
a number of "meetings rooms" that you can lurk in and be available for
pings, without having to join hundreds of channels where meetings might
happen. But I'm not sure anymore that maintaining an artificial scarcity
is helpful in limiting conflicts, and I can definitely see that it
pushes some meetings away from the meeting channels, defeating their
main purpose.

TL;DR:
- is it time for us to add #openstack-meeting-5 ?
- should we more proactively add meeting channels in the future ?

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

[GHANSHYAM MANN]

Not Core but would like to vote +1 for him. Nice review always.

​Thanks
gmann

On Sat, Dec 3, 2016 at 12:22 AM, Matt Riedemann 
wrote:

> I'm proposing that we add Stephen Finucane to the nova-core team. Stephen
> has been involved with nova for at least around a year now, maybe longer,
> my ability to tell time in nova has gotten fuzzy over the years.
> Regardless, he's always been eager to contribute and over the last several
> months has done a lot of reviews, as can be seen here:
>
> https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com
>
> http://stackalytics.com/report/contribution/nova/180
>
> Stephen has been a main contributor and mover for the config option
> cleanup series that last few cycles, and he's a go-to person for a lot of
> the NFV/performance features in Nova like NUMA, CPU pinning, huge pages,
> etc.
>
> I think Stephen does quality reviews, leaves thoughtful comments, knows
> when to hold a +1 for a patch that needs work, and when to hold a -1 from a
> patch that just has some nits, and helps others in the project move their
> changes forward, which are all qualities I look for in a nova-core member.
>
> I'd like to see Stephen get a bit more vocal / visible, but we all handle
> that differently and I think it's something Stephen can grow into the more
> involved he is.
>
> So with all that said, I need a vote from the core team on this
> nomination. I honestly don't care to look up the rules too much on number
> of votes or timeline, I think it's pretty obvious once the replies roll in
> which way this goes.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [openstack-health] Avoid showing non-official projects failure ratios

[GHANSHYAM MANN]

On Sat, Dec 3, 2016 at 4:35 AM, Ken'ichi Ohmichi 
wrote:

> 2016-12-02 5:39 GMT-08:00 Masayuki Igawa :
> > Hi,
> >
> > On Fri, Dec 2, 2016 at 6:29 PM, Andreas Jaeger  wrote:
> >> On 12/02/2016 10:03 AM, Thierry Carrez wrote:
> >>> Ken'ichi Ohmichi wrote:
>  Hi QA-team,
> 
>  In the big-tent policy, we continue creating new projects.
>  On the other hand, some projects became non-active.
>  That seems natural thing.
> 
>  Now openstack-health[1] shows non-active project as 100% failure ratio
>  on "Project Status".
>  The project has became non-official since
> 
> ​​
> https://review.openstack.org/#/c/324412/
>  So I feel it is nice to have black-list or something to make it
>  disappear from the dashboard for concentrating on active projects'
>  failures.
> 
>  Any thoughts?
> >>>
> >>> Yes, I totally agree we should only list active official projects in
> >>> there, otherwise long-dead things like Cue will make the view look bad.
> >>> Looks like the system adds new ones but does not remove anything ? It
> >>> should probably take its list from [1].
> >>>
> >>> [1]
> >>> http://git.openstack.org/cgit/openstack/governance/tree/
> reference/projects.yaml
> >>
> >> Is cue completely dead? Should we then retire it completely following
> >> http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
> ?
> >>
> >> It still has jobs setup and I see people submitting typo fixes etc.
> >
> > I'm not sure the cue is dead or not. But I think we should fix the
> > failure of the job or remove the periodic jobs. Otherwise, the job
> > just waste the resource of the OpenStack infra..
>
> Yeah, that is a nice point.
> And this case means openstack-health notifies this wasting resource on
> the infra, that is good thing.
> The failing job is already removed since
> https://review.openstack.org/#/c/404375/
> So we will not see the failure on the dashboard soon, thanks for helping
> that.
>
>
​Completely agree on removal of non active one.

Failure status from o-h is nice input for removal the inactive projects
from OpenStack. So once it is removed from governance then we can remove
from o-h too.​
​For non-official one, we can just remove based on their failure frequency
etc. ​



> > But we should have the filter feature like a 'Project Type' of
> > stackalitics, probably. I think it's useful for openstack-health
> > users.
>
> ​+1. This will really help.
​


> Yeah, it might be useful. But it is fine to wait for seeing the above
> result.
> Maybe our motivation of the filter feature will become less after that ;)
>
> Thanks
> Ken Ohmichi
>
> ---
>
> >>
> >>
> >> Andreas
> >> --
> >>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >>HRB 21284 (AG Nürnberg)
> >> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >>
> >>
> >> 
> __
> >> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong  wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

thank you!
it's great to hear the project has more demands.

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, 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.
>>
>> >
>> > 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

[Steven Dake (stdake)]

Paul,

This is a good question probably best sent to the operators list.  I’m not sure 
also if operators know the difference in Kolla’s implementation.  I don’t 
believe Kolla’s documentation explains it particularly well.

I never wanted COPY_ALWAYS in the code base, but I tolerated it as COPY_ONCE 
was still the default and COPY_ALWAYS has a use case that developers want.  The 
default was changed from COPY_ONCE to COPY_ALWAYS, and I again tolerated that 
since operators can always change the default.  I am not tolerant of removal 
without a significant dialogue with operators.  This would take some work on 
the Kolla core team’s part to make sure operators really understood the two 
models and had a good comprehension of what they would be giving away 
permanently if COPY_ONCE were deprecated.

Putting myself into an operator’s shoes, I believe COPY_ONCE is how I would 
deploy Kolla if I understood the differences between COPY_ONCE and COPY_ALWAYS. 
 As a developer of the original two models in Kolla I do understand in great 
detail the differences.  Some/many developers that work on Kolla don’t 
understand the difference (this I know for fact).  I’m not sure the delta here 
has been made clear to the operator or developer community.  It requires an 
in-depth explanation.

Currently Kolla deployments are at 1%, testing at 4%, and interested at 11% 
[1].  Given these facts, it is not clear to me that enough operators have 
enough experience with Kolla to have this conversation at this time.

Regards
-steve

[1] https://www.openstack.org/analytics

-Original Message-
From: Paul Bourke 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, December 1, 2016 at 3:29 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

While I would be interested to know how many people actually do use 
COPY_ONCE, I think if I was in charge of a production deployment I would 
use COPY_ONCE.

On 01/12/16 02:27, Jeffrey Zhang wrote:
> Kolla has a config_strategy option during deployment. it supports
> COPY_ONCE and
> COPY_ALWAYS.  which means whether copy the configuration files defined in
> config.json again during starting containers.
>
> COPY_ALWAYS: copy all configuration files always during every start (
> default
>  value now )
> COPY_ONCE: copy only once for the first start, then it
>won't copy even the configuration is changed
>
> COPY_ALWAYS is more common for most users. change configuration, then
> restart
> containers and it works. but COPY_ONCE is not. after changing the
> configuration,
> should remove the container and start it again.
>
> for COPY_ONCE, the pro is keeping immutability of the container.  the con 
is
> making thing difficult. no matter for kolla code or end-user.
>
> I am curiosity does end-user really care about the immutability cause by
> configuration file? how many user really need such a feature?
>
> So I propose to remove COPY_ONCE.
>
> any idea is welcome ;)
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [acceleration]Team Biweekly Meeting 2016.11.23 agenda

[Harm Sluiman]

Team I promised to comment on NASCA and provide some thoughts and ppt on flows 
for cyborg

Sorry for the delay.

I added a few words to the NASCA etherpad,

I waited for cyborg git to drop ppt but no luck yet so I put it here on google 
drive. I hope you can reach it. follow it in show mode for a “rich” experience 
;-)
I captured some FPGA run time flows as background, and then some sequences of 
lifecycle management. I have shared this with a few of you before.
https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM 

I am creating etherpad to discuss
https://etherpad.openstack.org/p/cyborg-initial-flow-discussion 

I am also creating an etherpad to discuss the in POC we have talked about for 
February to help define the scope of Cyborg
https://etherpad.openstack.org/p/cyborg-initial-design-poc 



I would also like to intro/welcome a couple more people to the Cyborg topic

Chen, Fei  (aka Fei) from IBM research and the SuperVessel project among other 
things
Jack Ng and Li Liu, my colleagues from Huawei that will be participating in 
Cyborg and helping get our initial POC underway






Thanks for your time.
宋哲
Harm Sluiman






> On Nov 23, 2016, at 11:49 PM, Zhipeng Huang  wrote:
> 
> Hi team,
> 
> Thanks for the discussion and please find the minutes here 
> https://wiki.openstack.org/wiki/Cyborg/MeetingLogs 
> 
> 
> On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang  > wrote:
> Forward here again in case you have not registered to openstack-dev 
> mailinglist
> 
> -- Forwarded message --
> From: Zhipeng Huang >
> Date: Wed, Nov 23, 2016 at 8:34 PM
> Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> 
> 
> Hi Team,
> 
> Please find the meeting logistics and agendas at 
> https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting 
>  
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com 
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu 
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com 
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu 
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com 
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu 
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Ihar Hrachyshka]

Takashi Yamamoto  wrote:


On Tue, Nov 29, 2016 at 11:53 AM, Takashi Yamamoto
 wrote:

release team,

can we (networking-midonet) branch stable/newton from a past commit
with a RC tag, backport some changes [1], and then cut the first release
on the branch?


to answer myself, RC or beta-looking tag doesn't seem to be allowed for
release:independent projects. [1]


I wonder if we should revisit that requirement. What’s the rationale behind  
that?


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Weekly meeting time slot - doodle poll

[Trinath Somanchi]

Thanks a lot Sridhar.

/ Trinath

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Saturday, December 03, 2016 4:37 AM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Dharmendra Kushwaha ; 
 ; Tung Doan 
; Tung Doan ; 龚永生 

Subject: Re: [openstack-dev] [tacker] Weekly meeting time slot - doodle poll

Thanks for the all those who responded. There is an overwhelming response to go 
with an early UTC time. I'm picking the following slot,

Wednesdays 0530 UTC

I've pushed a request to switch to new this time effective Dec 14th [1]. We 
will continue with use the existing Tuesdays 1600UTC slot for one more week 
(Dec 6th).

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

On Tue, Nov 29, 2016 at 10:17 PM, Sridhar Ramaswamy 
> wrote:
Given the natural changes in the mix of our active members and the recent 
daylight savings time change, I'm opening a doodle poll to find the best slot 
for our weekly meeting with max coverage. Please respond to the doodle poll 
below,

http://doodle.com/poll/ee9p34kfhskd2ucc

Note, this is the same poll shared in today's weekly meeting, though I've added 
more timeslots to pick from. If you've already responded, please log back one 
more time and select all possible slots.

thanks,
Sridhar

__
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