[openstack-dev] [all] PyCharm Licences

[Swapnil Kulkarni]

I have renewed the Pycharm licenses for community till Aug 13, 2019.
Everyone who is using it should have it updated automatically. Please
do not request again for renewal.

At the same time, I would request not to request multiple licenses
with multiple email addresses.

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] Pycharm license

[Swapnil Kulkarni]

On Mon 13 Aug, 2018, 15:41 Gary Kotton,  wrote:

> Hi,
>
> I understand that the community has an option to get licenses. Anyone have
> any information regarding this.
>
> Thanks
>
> Gary
> __
> 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


Hi Gary,

I can give you one. Please follow https://wiki.openstack.org/wiki/Pycharm

Best Regards,
Swapnil


>
__
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][vote] core nomination for caoyuan

[Swapnil Kulkarni]

On Mon, Mar 12, 2018 at 7:36 AM, Jeffrey Zhang  wrote:
> Kolla core reviewer team,
>
> It is my pleasure to nominate caoyuan for kolla core team.
>
> caoyuan's output is fantastic over the last cycle. And he is the most
> active non-core contributor on Kolla project for last 180 days[1]. He
> focuses on configuration optimize and improve the pre-checks feature.
>
> Consider this nomination a +1 vote from me.
>
> A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
> is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/180
> --
> 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
>

+1

__
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][kolla][rdo] Collaboration with Kolla for the RDO test days

[Swapnil Kulkarni]

Hi David,

Count me in.

~coolsvap

On Mon, Feb 5, 2018 at 9:01 PM, David Moreau Simard 
wrote:

> Hi everyone,
>
> We've started planning the deployment with the Kolla team, you can see
> the etherpad from the "operator" perspective here:
> https://etherpad.openstack.org/p/kolla-rdo-m3
>
> We'll advertise the test days and how users can participate soon.
>
> Thanks,
>
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Mon, Jan 29, 2018 at 8:29 AM, David Moreau Simard
>  wrote:
> > Hi !
> >
> > For those who might be unfamiliar with the RDO [1] community project:
> > we hang out in #rdo, we don't bite and we build vanilla OpenStack
> > packages.
> >
> > These packages are what allows you to leverage one of the deployment
> > projects such as TripleO, PackStack or Kolla to deploy on CentOS or
> > RHEL.
> > The RDO community collaborates with these deployment projects by
> > providing trunk and stable packages in order to let them develop and
> > test against the latest and the greatest of OpenStack.
> >
> > RDO test days typically happen around a week after an upstream
> > milestone has been reached [2].
> > The purpose is to get everyone together in #rdo: developers, users,
> > operators, maintainers -- and test not just RDO but OpenStack itself
> > as installed by the different deployment projects.
> >
> > We tried something new at our last test day [3] and it worked out great.
> > Instead of encouraging participants to install their own cloud for
> > testing things, we supplied a cloud of our own... a bit like a limited
> > duration TryStack [4].
> > This lets users without the operational knowledge, time or hardware to
> > install an OpenStack environment to see what's coming in the upcoming
> > release of OpenStack and get the feedback loop going ahead of the
> > release.
> >
> > We used Packstack for the last deployment and invited Packstack cores
> > to deploy, operate and troubleshoot the installation for the duration
> > of the test days.
> > The idea is to rotate between the different deployment projects to
> > give every interested project a chance to participate.
> >
> > Last week, we reached out to Kolla to see if they would be interested
> > in participating in our next RDO test days [5] around February 8th.
> > We supply the bare metal hardware and their core contributors get to
> > deploy and operate a cloud with real users and developers poking
> > around.
> > All around, this is a great opportunity to get feedback for RDO, Kolla
> > and OpenStack.
> >
> > We'll be advertising the event a bit more as the test days draw closer
> > but until then, I thought it was worthwhile to share some context for
> > this new thing we're doing.
> >
> > Let me know if you have any questions !
> >
> > Thanks,
> >
> > [1]: https://www.rdoproject.org/
> > [2]: https://www.rdoproject.org/testday/
> > [3]: https://dmsimard.com/2017/11/29/come-try-a-real-openstack-
> queens-deployment/
> > [4]: http://trystack.org/
> > [5]: http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.
> 2018-01-24-16.00.log.html
> >
> > David Moreau Simard
> > Senior Software Engineer | OpenStack RDO
> >
> > dmsimard = [irc, github, twitter]
>
> __
> 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] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Swapnil Kulkarni]

On Tue, Jan 30, 2018 at 4:18 PM, Thierry Carrez 
wrote:

> Masahito MUROI wrote:
> > Hi requirements team,
> >
> > This is a FFE request for adding python-blazarclient to
> > global-requirements.txt.  Blazar team had release problems for updating
> > the blazarclient to pypo.
> >
> > Luckily, the problems are fixed and the client is published at pypi this
> > morning.
> >
> > 1. https://review.openstack.org/#/c/539126/
>
> Looks like it only affects blazar-dashboard, so +1 from me
>
> --
> 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
>


Looks good to me as well. +1
__
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] [tc] Community Goals for Rocky -- privsep

[Swapnil Kulkarni]

On Thu, Jan 11, 2018 at 7:50 PM, Thierry Carrez  wrote:
> Emilien Macchi wrote:
>> [...]
>> Thierry mentioned privsep migration (done in Nova and Zun). (action,
>> ping mikal about it).
>
> It's not "done" in Nova: Mikal planned to migrate all of nova-compute
> (arguably the largest service using rootwrap) to privsep during Queens,
> but AFAICT it's still work in progress.
>
> Other projects like cinder and neutron are using it.
>
> If support in Nova is almost there, it would make a great Queens goal to
> get rid of the last rootwrap leftovers and deprecate it.
>
> Mikal: could you give us a quick update of where you are ?
> Anyone interested in championing that as a goal?
>
> --
> 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

I am interested in championing this as a goal for the next release.

-- 
Best Regards,
Swapnil
irc : coolsvap

__
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] Retirement of astara repos?

[Swapnil Kulkarni]

On Thu, Jan 11, 2018 at 3:50 AM, Sean McGinnis  wrote:
> While going through various repos looking at things to be cleaned up, I 
> noticed the last commit for openstack/astara
> was well over a year ago. Based on this and the little bit I have followed 
> with this project, it’s my understanding that
> there is no further work planned with Astara.
>
> Should these repos be retired at this point? Or is there a reason to keep 
> things around?
>
> Thanks,
>
> Sean McGinnis (smcginnis)
> __
> 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


Sean,

There have been a set of e-mails from Andreas in Dec for the inactive
projects [1] [2] [3] [4] with less or no responce. Just FYI.

[1] Astara: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125350.html
[2] Cerberor: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125351.html
[3] Evoque: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125352.html
[4] puppet-apps-site:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125360.html

~coolsvap

__
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] [hacking] [requirements] pep8 to pycodestyle

[Swapnil Kulkarni]

On Tue, Dec 12, 2017 at 4:37 AM, Ben Nemec <openst...@nemebean.com> wrote:
> It's probably worth noting here that this is to reflect an upstream rename
> from pep8 to pycodestyle, not an actual change in the library we use for
> style checking.  It's mentioned in the commit messages, but for anyone just
> scanning the mailing list it may not be obvious.
>
> I left a review on the hacking change.  I think the comments there about
> shadowing the flake8 module name are valid and we should undo/fix that
> before merging.  Otherwise I'm +2.
>
>
> On 12/04/2017 10:19 PM, Swapnil Kulkarni wrote:
>>
>> We have a change [1] out there which will remove pep8 and use
>> pycodestyle in global requirements. For this change to be merged we
>> need all dependent projects to use the same and check if they have any
>> conflicts. We are waiting for [2] for hacking and [3] for tackerclient
>> to be merged so that we can merge [1] into global requirements.
>>
>> Requesting the cores in the hacking and tacker group to have a look
>> into this and help us move further. Feel free to reply or drop by
>> #openstack-requirements if you have any questions. Thanks in advance.
>>
>> [1] https://review.openstack.org/#/c/514663/
>> [2] https://review.openstack.org/#/c/514934/
>> [3] https://review.openstack.org/#/c/517450/
>>
>


Thanks Ben for your review.

__
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] [rally]404 on docker rallyforge/rally

[Swapnil Kulkarni]

On Tue, Dec 5, 2017 at 5:35 AM,  <chen.haibi...@zte.com.cn> wrote:
> Hi, sorry for the inconvenience.
>
> docker team removed the rallyforge/rally repo. PTL has contacted them some
> days ago, but did not get the answer.
>
> Let us wait some days, if still not answer, we will create another repo
> (xrally/rally) for this.
>
>
> Best regards
>
> chen
>
>
>
>
>
> Original Mail
> Sender:  <matthieu.simo...@inria.fr>;
> To:  <openstack-dev@lists.openstack.org>;
> Date: 2017/12/04 23:18
> Subject: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
>
>
> - Mail original -
>> De: "Swapnil Kulkarni" <cools...@gmail.com>
>> À: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Envoyé: Lundi 4 Décembre 2017 12:57:36
>> Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally
>>
>> On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
>> <matthieu.simo...@inria.fr> wrote:
>> > Hi,
>> >
>> > Monday morning and it seems that docker images for rally aren't
>> > reachable
>> > anymore.
>> >
>> > https://hub.docker.com/r/rallyforge/rally/
>> >
>> > Did I miss something ? Is the doc up-to-date[1] ?
>> >
>> > [1]:
>> >
>> > http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
>> >
>> > Matt
>> >
>> >
>> > __
>> > 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
>>
>>
>> I think you need to refer to [1] for updated docs and [2] should be
>> able to help you with rally-docker information which might be useful
>> for you.
>
> Thanks Swapnil, but the namespace rallyforge[1] is now empty
> (or all images are private) on docker hub.
>
> I have no problem building images on my own, but I just wanted to make
> sure this is now the only way I can use the rally images.
>
> If so the doc will need to be updated to remove any reference to
> rallyforge/rally.
>
>
> [1] https://hub.docker.com/r/rallyforge/
>
> Best,
>
> Matthieu
>
>>
>> [1] https://docs.openstack.org/rally/latest/
>> [2]
>>
>> https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker
>>
>> __
>> 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
>

I was not sure about the defunct rally repo on docker hub. My bad. I
think yeah, till the time the new repo is operational building images
and using them would be a better idea.

__
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-dev] [tacker] [hacking] [requirements] pep8 to pycodestyle

[Swapnil Kulkarni]

We have a change [1] out there which will remove pep8 and use
pycodestyle in global requirements. For this change to be merged we
need all dependent projects to use the same and check if they have any
conflicts. We are waiting for [2] for hacking and [3] for tackerclient
to be merged so that we can merge [1] into global requirements.

Requesting the cores in the hacking and tacker group to have a look
into this and help us move further. Feel free to reply or drop by
#openstack-requirements if you have any questions. Thanks in advance.

[1] https://review.openstack.org/#/c/514663/
[2] https://review.openstack.org/#/c/514934/
[3] https://review.openstack.org/#/c/517450/
-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] [rally]404 on docker rallyforge/rally

[Swapnil Kulkarni]

On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin
 wrote:
> Hi,
>
> Monday morning and it seems that docker images for rally aren't reachable 
> anymore.
>
> https://hub.docker.com/r/rallyforge/rally/
>
> Did I miss something ? Is the doc up-to-date[1] ?
>
> [1]: 
> http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker
>
> Matt
>
> __
> 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


I think you need to refer to [1] for updated docs and [2] should be
able to help you with rally-docker information which might be useful
for you.

[1] https://docs.openstack.org/rally/latest/
[2] 
https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#rally-docker

__
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] [elections] Technical Committee Election Results

[Swapnil Kulkarni]

On Tue, Oct 24, 2017 at 1:01 PM, Swapnil Kulkarni <cools...@gmail.com> wrote:
> On Sat, Oct 21, 2017 at 5:29 AM, Kendall Nelson <kennelso...@gmail.com> wrote:
>> Hello Everyone :)
>>
>> Please join me in congratulating the 6 newly elected members of the
>> Technical Committee (TC)!
>>
>> Colleen Murphy (cmurphy)
>> Doug Hellmann (dhellmann)
>> Emilien Macchi (emilienm)
>> Jeremy Stanley (fungi)
>> Julia Kreger (TheJulia)
>> Paul Belanger (pabelanger)
>>
>> Full results:
>> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>>
>> Election process details and results are also available here:
>> https://governance.openstack.org/election/
>>
>> Thank you to all of the candidates, having a good group of candidates helps
>> engage the community in our democratic process.
>>
>> Thank you to all who voted and who encouraged others to vote. We need to
>> ensure your voice is heard.
>>
>> Thank you for another great round.
>>
>> -Kendall Nelson (diablo_rojo)
>>
>> [1] https://review.openstack.org/#/c/513881/
>>
>> __
>> 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
>>
>
>
> Congratulations ot a

Congratulations to all elected TC members.

~coolsvap

__
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] [elections] Technical Committee Election Results

[Swapnil Kulkarni]

On Sat, Oct 21, 2017 at 5:29 AM, Kendall Nelson  wrote:
> Hello Everyone :)
>
> Please join me in congratulating the 6 newly elected members of the
> Technical Committee (TC)!
>
> Colleen Murphy (cmurphy)
> Doug Hellmann (dhellmann)
> Emilien Macchi (emilienm)
> Jeremy Stanley (fungi)
> Julia Kreger (TheJulia)
> Paul Belanger (pabelanger)
>
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voice is heard.
>
> Thank you for another great round.
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://review.openstack.org/#/c/513881/
>
> __
> 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
>


Congratulations ot a

__
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] [tc][election] Question for the candidates

[Swapnil Kulkarni (coolsvap)]

On Fri, Oct 13, 2017 at 1:12 AM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
> I like a representative democracy.  It mostly means I get a say in which
> other people I have to trust to think deeply about issues which effect me
> and make decisions which I agree (more or less) are of benefit to the social
> groups in which I participate.  When I vote IRL I like to consider voting
> records.  Actions speak louder blah blah.
>
> To candidates:
>
> Would you please self select a change (or changes) from
> https://github.com/openstack/governance/ in the past ~12 mo or so where they
> thought the outcome or the discussion/process was particular good and
> explain why you think so?
>
> It'd be super helpful to me, thanks!
>
> -Clay
>
> __
> 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
>

I have few of them on my mind.

Setting up guidelines for managing releases of binary artifacts [1]
was very important in and key to the hearts of most OpenStack
operators and everyone who's looking at the next big leap with
containerized deployment.

Embracing new languages in OpenStack which are required as dependency
for certain projects [2] [3] is a very important decision and I would
really like to see it through. While there is a lot of work to be done
to get something fully operational in current infrastructure but as we
will have more contributors who feel the need, we have the background
work ready for it.

And of course setting up the vision and mission for TC [4] was one of
the important things done. There will still be updates to it, but the
current draft is a piece of work with a diverse community like ours.

[1] https://review.openstack.org/#/c/469265/
[2] https://review.openstack.org/#/c/451524/
[3] https://review.openstack.org/#/c/398875/
[4] https://review.openstack.org/#/c/453262/

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net

__
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] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni]

On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski <inc...@gmail.com> wrote:
> I haven't seen "malicious" meeting starters yet, let's hope that won't
> happen:) On the other hand, ad-hoc chair change can, and did, happen,
> so I agree with fungi - I don't think we need to put restrictions on
> that.
>
> On 11 October 2017 at 09:11, Jeremy Stanley <fu...@yuggoth.org> wrote:
>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
>> [...]
>>> The problem here is if we know who are most likely to chair the
>>> meeting e.g. [1] we can allow them to start the meeting.
>> [...]
>>
>> I'm pretty certain I wouldn't want to have to propose a patch to
>> update that every time I needed someone to chair a meeting in my
>> absence. This doesn't seem like a common enough issue to warrant the
>> added complexity and red tape of access controls on our meeting
>> automation.
>> --
>> Jeremy Stanley
>>
>> __
>> 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

Michal,

I just gave one instance of malicious meeting attempt [1] happened
today and it happened to be kolla meeting so I noticed its not correct
timing for the same. I would put it as permission-ed access rather
than restriction, because as much as we want to keep it open we need
to maintain the genuineness of meeting. I would not want to stumble
into a junk log file while I am reading it later looking for
something.


[1] 
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.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

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni]

Hi Jeremy, Amrith,

On Wed, Oct 11, 2017 at 7:50 PM, Amrith Kumar <amrith.ku...@gmail.com> wrote:
> I agree with Jeremy that we shouldn't attempt to implement technical
> solutions for non-technical problems. But to that end, I'd be curious
> to know what the problem was with this. In my experience it has been
> an asset to have the meeting start on time even if the regular chair
> is for some reason delayed.
>

I agree this is a non-technical problem  and if someone else who can
start the meeting in the absence of the chair is always helpful. The
problem here is if we know who are most likely to chair the meeting
e.g. [1] we can allow them to start the meeting.


[1] 
https://github.com/openstack-infra/irc-meetings/blob/master/meetings/requirements-team.yaml#L10

> I've benefited from that in Trove, and on at least one occasion I've
> started the oslo meeting and the regular chair came in and took over a
> while later.
>
> The short log that coolsvap provided doesn't exhibit a problem, as
> best as I can tell; people without bouncers sometimes do lose their
> internet connection :(

This is all the log there is. I don't even know if the person who
started the meeting is contributor to kolla or openstack for that
matter. My only query is people who know about official meetings will
not do it, but can we restrict those who dont? Otherwise there is no
meaning to the official meetings if anyone can start them anytime.

>
> -amrith
>
>
>
> On Wed, Oct 11, 2017 at 9:55 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
>> On 2017-10-11 17:51:59 +0530 (+0530), Swapnil Kulkarni (coolsvap) wrote:
>>> I was attending the weekly requirements meeting when I noticed
>>> someone started the kolla meeting [1] on openstack-meeting-4
>>> channel. I thought we had the restrictions on the chairs, but
>>> apparently there's not. Can we think about having one such
>>> restriction?
>>
>> We don't implement technical solutions to social problems of this
>> nature. If you have an issue with the person who started the kolla
>> meeting in your absence, please take it up with them.
>> --
>> Jeremy Stanley
>>
>> __
>> 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-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Swapnil Kulkarni (coolsvap)]

I was attending the weekly requirements meeting when I noticed someone
started the kolla meeting [1] on openstack-meeting-4 channel. I thought we
had the restrictions on the chairs, but apparently there's not. Can we
think about having one such restriction?

[1]
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.html

Best Regards,
Swapnil
__
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-dev] [election][tc] TC Candidacy - Swapnil Kulkarni (coolsvap)

[Swapnil Kulkarni (coolsvap)]

OpenStackers,

I am Swapnil Kulkarni(coolsvap), I have been a ATC since Icehouse and I wish
take this opportunity to throw my hat for election to the OpenStack Technical
Committee this election cycle. I started contributing to OpenStack with
introduction at a community event and since then I have always utilized every
opportunity I had to contribute to OpenStack. I am a core reviewer at kolla
and requirements groups. I have also been active in activities to improve the
overall participation in OpenStack, through meetups, mentorship, outreach to
educational institions to name a few.

My focus of work during TC would be to make it easier for people to get
involved in, participate, and contribute to OpenStack, to build the community.
I have had a few hickups in the recent past for community engagement and
contribution activities but my current employment gives me the flexibilty
every ATC needs and I would like to take full advantage of it and increse
the level of contribution.

Please consider this my application and thank you for your consideration.

[1] https://www.openstack.org/community/members/profile/7314/swapnil-kulkarni
[2] http://stackalytics.com/report/users/coolsvap
[3] https://review.openstack.org/510402

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net

__
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-dev] [all] Pycharm professional for OpenStack developers

[Swapnil Kulkarni (coolsvap)]

Greetings,

As many of you are aware, OpenStack community developers get access to
PyCharm professional edition licence to contribute to OpenStack. I am
maintaining the licence allocation. We have limited number of licences
to allocate and it is essential that people who are contributing to
OpenStack should get it. To do this we have a filtering criteria for
revoking licences from non-active users.

If you wake one fine day and realise you do not have an active Pycharm
licence, it may be due to two reasons,
1) you are not contributing actively to OpenStack or
2) you are no longer using PyCharm for contributing to OpenStack.

In either case you are considered not active user of PyCharm and your
licence will be revoked.

I do not mind people reaching out to me personally to request the
licence but I do not actively track requests on mail. I request
everyone to please refer to [1] for requesting new licence.

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

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net

__
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][elections] PTL Voting is now open

[Swapnil Kulkarni]

On Thu, Aug 10, 2017 at 1:57 PM, Dmitry Tantsur  wrote:
> On 08/10/2017 02:01 AM, Kendall Nelson wrote:
>>
>> Hello Again!
>>
>> Elections are underway and will remain open for you to cast your vote
>> until Aug 16th, 2017 23:45 UTC.
>>
>> We are having elections for Ironic and Documentation.
>
>
> By the way, why do I receive a poll, given that I'm one of candidates? :)

Since you are also the contributor :) So I think you already got
yourself a vote :-D
>
>>
>> If you are a Foundation individual member and had a commit in one of the
>> program's projects[0] over the Ocata-Pike timeframe (September, 2016 23:59
>> UTC to August 3rd , 2017 23:59 UTC) then you are eligible to vote. You
>> should find your email with a link to the Condorcet page to cast your vote
>> in the inbox of your gerrit preferred email[1].
>>
>> What to do if you don't see the email and have a commit in at least one of
>> the programs having an election:
>>* check the trash or spam folders of your gerrit Preferred Email
>> address, in case it went into trash or spam
>
>
> A warning: the email got into gmail spam folder for me!
>
>>* wait a bit and check again, in case your email server is a bit slow
>>* find the sha of at least one commit from the program project repos[0]
>> and email the election officials. If we can confirm that you are entitled to
>> vote, we will add you to the voters list for the appropriate election.
>>
>> Our democratic process is important to the health of OpenStack, please
>> exercise your right to vote!
>
>
> ++ please do!
>
>>
>> Candidate statements/platforms can be found linked to Candidate names on
>> this page: http://governance.openstack.org/election/#pike-ptl-candidates
>>
>> Happy voting,
>>
>> -Kendall Nelson (diablo_rojo)
>>
>> [0] The list of the program projects eligible for electoral status:
>> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=aug-2017-elections
>>
>> [1] Sign into review.openstack.org :
>>  Go to Settings > Contact Information.
>>  Look at the email listed as your Preferred Email.
>>  That is where the ballot has been sent.
>>
>>
>>
>> __
>> 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] [all] New code contributors no longer forced to join the foundation

[Swapnil Kulkarni]

On Tue, Aug 8, 2017 at 4:58 AM, Jeremy Stanley  wrote:
> Due to improvements in the OpenStack Foundation member directory and
> our technical election tooling, it is no longer necessary to join
> the foundation as an individual member just to be able to submit
> changes through Gerrit for official repositories. You do, however,
> still eventually need to join if you want to be able to participate
> in technical elections (as a candidate or a voter).
>
> The Account Setup section[1] of the Developer's Guide has been
> updated to reflect the new simpler process, and a separate
> (optional) Eligibility to Vote in Elections section[2] has been
> added. This process change significantly simplifies the onboarding
> process for new code contributors by removing a very error-prone
> and, for many, eyebrow-raising hurdle.
>
> A little background: the Bylaws of the OpenStack Foundation Appendix
> 4 Technical Committee Member Policy[3] (section 3b) limits voter
> rolls for technical elections to Foundation Individual Members. It
> was never strictly required by policy to join the foundation if you
> only wanted to contribute code and had no interest in voting, which
> is not an entirely uncommon case for new contributors. Due to
> previous technical limitations in our systems we still forced new
> contributors to join, because that was the easiest way at the time
> to be relatively certain who was qualified to participate in
> technical elections. Now that we have a mechanism for verifying
> membership on demand when validating nominations and generating
> voter rolls, we have made the step of joining the foundation
> optional (though still very much recommended once you reach the
> point as a contributor where you want to participate in community
> governance processes).
>
> [1] https://docs.openstack.org/infra/manual/developers.html#account-setup
> [2] 
> https://docs.openstack.org/infra/manual/developers.html#eligibility-to-vote-in-elections
> [3] https://www.openstack.org/legal/technical-committee-member-policy/
> --
> Jeremy Stanley
>
> __
> 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
>

Great, excellent step to reduce barrier to entry. Kudos!

__
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] [requirements] PTL non-candidacy

[Swapnil Kulkarni]

On Wed, Aug 2, 2017 at 12:45 PM, Tony Breeds  wrote:
> Hi All,
> As the requirements team knows I will not be running for PTL of
> requirements management.  I'll still be an active core.
>
> It's been a blast being the PTL for the last 2 cycles but I need to
> focus on other parts of OpenStack for a while (like stable branch
> maintenance).  The requirements team will be in good hands with whomever
> is elected.
>
> Yours Tony.
>
> __
> 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
>

Thanks Tony.

Your role in setting up the requirements team and taking it where it
is currently is very important.

-- 
Best Regards,
Swapnil
irc : coolsvap

__
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][docs] recruiting for help with documentation tools

[Swapnil Kulkarni]

On Wed, Aug 2, 2017 at 2:25 PM, Bogdan Dobrelya  wrote:
> On 01.08.2017 21:35, Doug Hellmann wrote:
>> With the changes we've made to docs processes upstream, every team
>> is going to need to build up their knowledge of how the new
>> documentation tools and jobs work. The docs team will still help,
>> but things will obviously go more smoothly if folks know how the
>> tools work, now that the bulk of the content is in-tree with the
>> code.
>>
>> At the same time, the docs team could use help with developing and
>> maintaining those tools. We have a couple people working on them
>> now (me, Andreas, and Anne), but none of us is doing it full time.
>> I need to transition off of this work, so over the course of Queens
>> I will be trying to build up the skills of the existing team so
>> they do not need to rely on me so much. Also, Andreas and Anne have
>> said that they cannot commit to driving any work.
>>
>> Although the documentation team has some skills in this area, they
>> could use help, so I would like to find a few people to join the
>> team specifically to work on the tooling (although if you wanted
>> to write documentation, too, no one will object).
>>
>> Some of you have been helping informally (thank you!), but the
>> community shift is big enough that we need to account for the new
>> need a bit more formally. I think if we could find several people
>> who could give a small percentage of their time (10%?), we would
>> be well covered. There will not be work every week, but when there
>> is something to do it's likely to take a small extended period (1-2
>> days) to add a feature or resolve an issue. If we found 4-6 people,
>> I think we would be covered and have a sustainable group.
>>
>> The areas we need help are maintaining the doc build jobs, the
>> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
>> and the template build tool in the openstack-manuals git repo. These
>> are all minimally complete, but there is definitely feature work
>> and bug fixing to do. I can guarantee that, if you sign up to help,
>> you will have a chance to land changes that will be visible for all
>> OpenStack users. At the start of Queens, I will be doing some
>> one-on-one training with volunteers to ensure they understand the
>> system we have in place now and help them start on some of the
>> remaining feature work.
>>
>> If you are interested in helping, please let me know by following
>> up to this thread, and then join #openstack-docs on IRC.
>
> +1
>
>>
>> Doug
>>
>> __
>> 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
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> 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


+1

__
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][kolla-ansible] Proposing Surya (spsurya) for core

[Swapnil Kulkarni]

On Wed, Jun 14, 2017 at 9:16 PM, Michał Jastrzębski  wrote:
> Hello,
>
> With great pleasure I'm kicking off another core voting to
> kolla-ansible and kolla teams:) this one is about spsurya. Voting will
> be open for 2 weeks (till 28th Jun).
>
> Consider this mail my +1 vote, you know the drill:)
>
> Regards,
> Michal
>
> __
> 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


+1

__
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] [kolla-kubernetes] Dec 28 meeting canceled

[Swapnil Kulkarni]

On Wed, Dec 21, 2016 at 8:31 AM, Michał Jastrzębski  wrote:
> Hello,
>
> Let's cancel meeting at 28 Dec, but 21 Dec and 4 Jan are still on,
> probably more lightweight but try to be there please.
>
> Cheers,
> Michal
>
> __
> 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][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Dec 14, 2016 7:03 PM, "Steven Dake (stdake)" <std...@cisco.com> wrote:

Swapnil,

If you want to do that, please add it to the meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kolla

Regards
-steve


Done



-Original Message-----
From: Swapnil Kulkarni <cools...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Wednesday, December 14, 2016 at 3:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez <thie...@openstack.org>
wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake) <std...@cisco.com>
wrote:
>>
>>> The issue raised is they violate the 4 opens.
>>
>> Not necessarily. If you have regular planning meetings and
discussions in an open manner as prescribed, an occasional conference to
discuss a particular matter is not a "violation". What if someone in your
office is working on OpenStack too, and you meet in the hallway and discuss
something technical? Does that violate the 4 Opens?
>>
>> I think we have to balance realism with idealism.
>
> Like I said elsewhere, this is not about suppressing any type of
visual
> or more direct interaction... It is about making sure you are not
> excluding anyone from a project.
>
> In the precise case we are discussing here, there are complaints from
> contributors to a project that recent Hangouts meetings used in the
> Kolla team results in them being excluded (either technically by not
> being able to join them, or creating additional difficulties for
> non-native language speakers to follow or participate in them).
>
> I'm all for giving teams a bit of flexibility in how they organize,
but
> if the process chosen by some of the contributors is clearly excluding
> other contributors, falling back to a more inclusive medium (like IRC
> meetings) is the obvious solution. Jeffrey took the hard step of
raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.
>
> --
> 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



I do not believe anyone is willing to exclude contributors at any
stage. If such (mis)understanding is there, it needs to be discussed
why it is there and how to remediate it since it's not good for the
community and is diverting the focus.
Let's have 5-10 mins in today's weekly meeting where we get the facts
together behind the issue and try to bring it to a conclusion.

OR have a detailed discussion on #openstack-kolla


__
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][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez  wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  wrote:
>>
>>> The issue raised is they violate the 4 opens.
>>
>> Not necessarily. If you have regular planning meetings and discussions in an 
>> open manner as prescribed, an occasional conference to discuss a particular 
>> matter is not a "violation". What if someone in your office is working on 
>> OpenStack too, and you meet in the hallway and discuss something technical? 
>> Does that violate the 4 Opens?
>>
>> I think we have to balance realism with idealism.
>
> Like I said elsewhere, this is not about suppressing any type of visual
> or more direct interaction... It is about making sure you are not
> excluding anyone from a project.
>
> In the precise case we are discussing here, there are complaints from
> contributors to a project that recent Hangouts meetings used in the
> Kolla team results in them being excluded (either technically by not
> being able to join them, or creating additional difficulties for
> non-native language speakers to follow or participate in them).
>
> I'm all for giving teams a bit of flexibility in how they organize, but
> if the process chosen by some of the contributors is clearly excluding
> other contributors, falling back to a more inclusive medium (like IRC
> meetings) is the obvious solution. Jeffrey took the hard step of raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.
>
> --
> 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



I do not believe anyone is willing to exclude contributors at any
stage. If such (mis)understanding is there, it needs to be discussed
why it is there and how to remediate it since it's not good for the
community and is diverting the focus.
Let's have 5-10 mins in today's weekly meeting where we get the facts
together behind the issue and try to bring it to a conclusion.

OR have a detailed discussion on #openstack-kolla

__
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][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Tue, Dec 13, 2016 at 8:33 PM, Michał Jastrzębski <inc...@gmail.com> wrote:
> I really fail to see how add hoc meetings, if link will be posted openly on
> IRC, notes made public and invitation extended to everyone would violate 4
> opens. It's virtuality impossible in globally distributed project to have
> everyone interested around at all times. All decisions made will be
> reflected in gerrit when first code his it, etherpad or summary on IRC
> afterwards will allow those not present to get up to speed.
>
> I think we need to trust our fellow cores to have best interest of project
> in mind even when we are not around. Any issues can be dealt with later as
> well.
>
> Cheers,
> Michał
>

+1

> On Dec 13, 2016 5:12 AM, "Sean Dague" <s...@dague.net> wrote:
>
> On 12/13/2016 08:02 AM, Thierry Carrez wrote:
>> Ed Leafe wrote:
>>> On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang <zhang.lei@gmail.com>
>>> wrote:
>>>
>>>> Some contributors in kolla have had unscheduled video meetings. This has
>>>> resulted in complaints about inclusiveness. Some contributors can’t even
>>>> make
>>>> the meeting we have, and another scheduled video meeting might produce a
>>>> situation in which there is no any record of decisions made during the
>>>> video
>>>> meeting. At least with IRC meetings there is always a log.
>>>
>>> Occasionally a quick Google hangout is necessary in Nova in order to
>>> quickly settle an outstanding issue so we can continue to make progress.
>>> When that happens, the link is posted in the #openstack-nova channel, and
>>> anyone who is interested can join. So while it’s not logged like an IRC
>>> meeting, it’s no excluding anyone, and we can quickly remove roadblocks that
>>> are harder to do in IRC.
>>
>> Last time I checked, Google Hangouts were not accessible from China...
>> So it *is* excluding some contributors ?
>>
>> I think it's fine to use Hangouts or phone calls to quickly go through
>> an issue. But if those become routine and if contributors express that
>> those are making them feel (or be) excluded, then it is important to
>> reassess your usage of them before it starts threatening our "open
>> development" and "open community" pillars.
>>
>> And in all cases, regular team meetings (or decision-making meetings)
>> should happen on IRC in logged channels.
>
> There is definitely a reality that there are circumstances where
> collaboration happens, and happens quickly, in some setting where not
> everyone was around. Be it at a conference, randomly finding people in a
> coffee shop, on a google hangout, a telephone call, etc.
>
> I think the most important thing is to take the time to take whatever
> happened there and put it out in open memory afterwards. For instance, a
> write up to the mailing list with the notes of what about the issue, the
> discussion, the resolution. This isn't only helpful for the people not
> in the room, it's also really helpful even for those in the room 6 or 12
> months later to try to recall why a particular course of action was taken.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
coolsvap at gmail dot com
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
"It's better to SHARE"

__
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][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Dec 13, 2016 8:44 AM, "Michał Jastrzębski"  wrote:

I think video meetings Jeffrey is referring to are just that- quickly as
hoc way to resolve some technical dispute or implementation. We did that
few times to quickly work out kolla k8s issues. Hangouts are much more
efficient way of discussions like that.

My take on the issue is that we should use all tools available. Scheduling
of such meetings would defeat their purpose of resolving things *quickly*.
If something requires scheduling it should be done on our weekly meeting.

Video meetings are thing in Kolla k8s for one more reason- we want to move
fast and scheduling meeting with proper heads up for every technical
dispute (couple of these every week) would seriously impede our ability to
deliver. Ocata is our goal!

Tldr; ad hoc video meetings are good for quickly paced dev like in Kolla
k8s imho

Cheers
Michał

On Dec 12, 2016 12:36 PM, "Ed Leafe"  wrote:

On Dec 12, 2016, at 11:16 AM, Jeffrey Zhang  wrote:

> Some contributors in kolla have had unscheduled video meetings. This has
> resulted in complaints about inclusiveness. Some contributors can’t even
make
> the meeting we have, and another scheduled video meeting might produce a
> situation in which there is no any record of decisions made during the
video
> meeting. At least with IRC meetings there is always a log.

Occasionally a quick Google hangout is necessary in Nova in order to
quickly settle an outstanding issue so we can continue to make progress.
When that happens, the link is posted in the #openstack-nova channel, and
anyone who is interested can join. So while it’s not logged like an IRC
meeting, it’s no excluding anyone, and we can quickly remove roadblocks
that are harder to do in IRC.


-- Ed Leafe






__
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


I think there is a mutual understanding where we have informal/ ad-hoc/ on
the fly meetings to discuss important things, like after design sessions in
the corridor, during lunch/dinner, etc etc. Video calls or hangouts is just
digital extension of it.

Only recommendation I have is a digest either on etherpad or mailing list
where people who missed can get required details.

Swapnil
__
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] Vote to add zhubingbing to core team

[Swapnil Kulkarni]

On Tue, Nov 29, 2016 at 9:51 PM, Michał Jastrzębski  wrote:
> Hello team!
>
> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> core teams. He did great job reviewing code during last couple of
> months.
>
> Consider this proposal +1 from me, voting will be open for 1 week
> (until Dec 6) or if we get unanimous agreement (or veto) before.
>
> Regards,
> Michal
>
> __
> 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

+1

__
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][kolla-ansible][kolla-kubernetes] Kolla core election policy change - vote

[Swapnil Kulkarni]

On Wed, Nov 16, 2016 at 11:53 PM, Michał Jastrzębski  wrote:
> Hello,
>
> In light of recent events (kolla-kubernetes becoming thriving project,
> kolla-ansible being split) I feel we need to change of core reviewer
> election process.
>
> Currently Kolla was single core team. That is no longer the case, as
> right now we have 3 distinct core teams (kolla, kolla-ansible and
> kolla-kubernetes), although for now with big overlap in terms of
> people in them.
>
> For future-proofing, as we already have difference between teams, I
> propose following change to core election process:
>
>
> Core reviewer voting rights are reserved by core team in question.
> Which means if someone propose core reviewer to kolla-kubernetes, only
> kolla-kubernetes cores has a voting right (not kolla or kolla-ansible
> cores).
>
>
> Voting will be open until 30 Nov '16 end of day. Reviewers from all
> core teams in kolla has voting rights on this policy change.
>
> Regards
> Michal
>
> __
> 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


+1

__
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][kubernetes] kolla-kubernetes spec voting delay

[Swapnil Kulkarni]

On Wed, Nov 16, 2016 at 8:01 AM, Swapnil Kulkarni <cools...@gmail.com> wrote:
> On Wed, Nov 16, 2016 at 7:30 AM, Ryan Hallisey <rhall...@redhat.com> wrote:
>> Hey folks,
>>
>> There has been a lot of input in the spec and tons IRC discussion
>> over the last two days.  I'm glad the discussion is very active :).
>>
>> The goal of the spec is to capture the ideas and the discussion in
>> one readable doc so no one has to read the 1 lines of IRC
>> discussion that has occurred. Right now, the spec reflects about 95%
>> of the discussion so it isn't complete. Therefore, voting will be
>> delayed at least another day from the deadline I set (today).
>>
>> Thanks,
>> -Ryan
>>
>> https://review.openstack.org/#/c/392257/
>>
>> __
>> 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
>
>
> Thanks Ryan. I would appreciate if you could highlight some related
> information (e.g. reading material, tools) for new contributors to
> gain more insight into terminologies that one can refer to during or
> prior reading the spec and get better understanding.
>
> ~coolsvap



Jus to provide the background,  I saw on the IRC that there was some
confusion or need for more information was raised related to operator.

__
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][kubernetes] kolla-kubernetes spec voting delay

[Swapnil Kulkarni]

On Wed, Nov 16, 2016 at 7:30 AM, Ryan Hallisey  wrote:
> Hey folks,
>
> There has been a lot of input in the spec and tons IRC discussion
> over the last two days.  I'm glad the discussion is very active :).
>
> The goal of the spec is to capture the ideas and the discussion in
> one readable doc so no one has to read the 1 lines of IRC
> discussion that has occurred. Right now, the spec reflects about 95%
> of the discussion so it isn't complete. Therefore, voting will be
> delayed at least another day from the deadline I set (today).
>
> Thanks,
> -Ryan
>
> https://review.openstack.org/#/c/392257/
>
> __
> 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


Thanks Ryan. I would appreciate if you could highlight some related
information (e.g. reading material, tools) for new contributors to
gain more insight into terminologies that one can refer to during or
prior reading the spec and get better understanding.

~coolsvap

__
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][release] Version numbers for kolla-ansible repository.

[Swapnil Kulkarni]

On Tue, Nov 8, 2016 at 6:38 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> As we split out the repository per our unanimous vote several months ago, we
> have a choice to make (I think, assuming we are given latitude of  the
> release team who is in the cc list) as to which version to call
> kolla-ansible.
>
> My personal preference is to completely retag our newly split repo with all
> old tags from kolla git revisions up to version 3.0.z.  The main rationale I
> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think
> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could
> do that as well.
>
> The reason the repository needs to be retagged in either case is to generate
> release artifacts (tarballs, pypi, etc).
>
> Would also like feedback from the release team on what they think is a best
> practice here (we may be breaking new ground for the OpenStack release team,
> maybe not – is there prior art here?)
>
> For a diagram (mostly for the release team) of the repository split check
> out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>
> Thanks!
> -steve
>
>
> __
> 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
>


I would love to get inputs from release team, though one of the recent
repo split I remember is neutron and if I look at the history, old
tags from git revisions are preserved. I think we can follow the same
process for kolla and kolla-ansible split.



-coolsvap

__
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 removal of TrivialFix requirement

[Swapnil Kulkarni]

On Fri, Nov 4, 2016 at 10:01 PM, Jeremy Stanley  wrote:
> On 2016-11-04 15:42:17 + (+), Paul Bourke wrote:
>> We have no desire to do this, that's not what is being discussed
>> here. On the contrary we're looking to reduce the barrier to entry
>> for committers. Also the team is aware that cross project efforts
>> should not be nit picked.
>
> That's what it seemed like to me up to this point in the thread as
> well; I was specifically replying to Swapnil's suggestion that any
> important change to Kolla deliverables should have a bug filed or
> should continue to add a TrivialFix header in the commit message
> otherwise. (And yes, as Andreas pointed out the other thread on the
> related topic of mass changes for cross-project efforts does address
> the case specifically, but becomes less necessary if you end up
> agreeing to drop the TrivialFix requirement.)
> --
> Jeremy Stanley
>
> __
> 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


Jeremy,

I am sorry if I have miscommunicated earlier. I am referring to the
situation where people are using TrivialFix just to get the changes in
which is not good practice.

I agree with removing TrivialFix just that we need to be very careful
with changes that need tracking (e.g. bug/bp).

__
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 removal of TrivialFix requirement

[Swapnil Kulkarni]

On Fri, Nov 4, 2016 at 9:12 PM, Paul Bourke <paul.bou...@oracle.com> wrote:
> Hi Jeremy,
>
>> All I ask is that if the Kolla team wants to differentiate itself
>> from the review requirements of most OpenStack projects, please make
>
> We have no desire to do this, that's not what is being discussed here. On
> the contrary we're looking to reduce the barrier to entry for committers.
> Also the team is aware that cross project efforts should not be nit picked.
>
> -Paul
>
> On 04/11/16 15:25, Jeremy Stanley wrote:
>>
>> On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:
>>>
>>> I feel TrivialFix is consistently used by people just to avoid going
>>> to lanuchpad and filing a bug. It should only be used only if the "Fix
>>> is Trivial"
>>> This has been well documented in the contributing doc [1] and this
>>> should be referred to people when they do not have the bug/bp in the
>>> commit message.
>>>
>>> If the commits are important then there is no harm in creating a
>>> tracking bug for it.
>>
>> [...]
>>
>> All I ask is that if the Kolla team wants to differentiate itself
>> from the review requirements of most OpenStack projects, please make
>> sure you have active and attentive liaisons who can update
>> mass-proposed changes for base infrastructure or other similar
>> horizonal and cross-project efforts to meet your special reviewing
>> standards. I cannot personally keep on top of the nuances of every
>> review team and individually adjust such mass changes myself, so
>> rely on you to "fix" my patches for me in such situations.
>>
>>
>>
>> __
>> 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


Nit picking was needed since the policy was followed more to avoid
creating or using a tracker more often.

__
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 removal of TrivialFix requirement

[Swapnil Kulkarni]

On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke  wrote:
> Kolleagues,
>
> How do people feel above removing the requirement of having TrivialFix in
> commit messages where a bug/bp is not required?
>
> I'm seeing a lot of valid and important commits being held up because of
> this, in my opinion, unnecessary requirement. It also causes friction for
> new contributers to the project.
>
> Are there any major benefits we're getting from the use of this tag that I'm
> missing?
>
> Cheers,
> -Paul
>
> __
> 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

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
It would take 1/30(I am just making highest time for a build/deploy
gate) amount of time you need to verify the (important)fix on gate.

[1] docs.openstack.org/developer/kolla/CONTRIBUTING.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

Re: [openstack-dev] [kolla] Cross proejct initiative patches should merge free of tags/bugs/blueprints

[Swapnil Kulkarni]

On Sat, Oct 8, 2016 at 8:39 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
>
>
> Cross project initiative patches like this one:
>
> https://review.openstack.org/#/c/383226/1
>
>
>
> Should always be approved if they pass code review and the gate is green.
> There is no need for a bug id or trivial fix or blueprint.  Please do make
> sure to verify they are correct and don’t alter the codebase in a damaging
> way that the author may not have intended (or been aware of).  I don’t think
> this last scenario would happen often, but is possible.
>
>
>
> Sorting out the 60+ projects in the big tent’s various policies for patch
> acceptance is a lot of unnecessary work for the cross project initiative
> work (e.g. global requirements, translations, etc).  Lets make it easy on
> the great folks doing this work.
>
>
>
> Regards
>
> -steve
>
>
>
>
> __
> 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
>


+1

__
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] [tricircle]

[Swapnil Kulkarni (coolsvap)]

Glad to see you here sir :)

Best Regards,
Swapnil

On Fri, Sep 30, 2016 at 6:17 PM, Chandrakant Bagade
 wrote:
> Hello ,
>
>
>
> Myself Chandrakant Bagade , working at Persistent System Ltd.
>
> I was trying Tricircle with devstack and found it , a very helpful  idea to
> datacenter management.
>
>
>
> I can see feature like provisioning , image/vm/volume management therein.
>
> I was wondering if features like monitoring/inventory management is also
> available there or planned for coming released. I read the docs but couldn’t
> find the information.
>
>
>
> Can someone from Tricircle team , help me with my query. If these are
> available , then pointer/documents to those would be much appreciated.
>
>
>
> Thanks,
>
> Chandrakant
>
> DISCLAIMER == This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
> __
> 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] Deprecation Policies (related to Heka)

[Swapnil Kulkarni]

On Sep 29, 2016 9:30 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:
>
> notification = of course
> relase note with information and upgrade info = of course
> 1 full release of supporting both heka and alternative = not so much
>
> On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap)
> <m...@coolsvap.net> wrote:
> > On Sep 29, 2016 3:06 PM, "Christian Berendt"
> > <bere...@betacloud-solutions.de> wrote:
> >>
> >> > On 29 Sep 2016, at 06:26, Steven Dake (stdake) <std...@cisco.com>
wrote:
> >> >
> >> > If you have a different parsing of the deprecation policy, feel free
to
> >> > chime in.
> >>
> >> Heka is only used as an internal component of Kolla and is not
provided as
> >> a service for the operators. It should be sufficient to replace Heka by
> >> something else without deprecating it.
> >>
> >> Christian.
> >>
> >>
__
> >> 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
> >>
> >
> > Kolla is an operator tool and there are multiple tools only internal to
> > deployment. This does not mean we can deprecate tools without operator
being
> > notified about it.
> >
> >
> >
__
> > 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

Doesn't the notification in release note be a depreciation notification for
something not available from subsequent release? If no why not?
__
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] Deprecation Policies (related to Heka)

[Swapnil Kulkarni (coolsvap)]

On Sep 29, 2016 3:06 PM, "Christian Berendt" 
wrote:
>
> > On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
> >
> > If you have a different parsing of the deprecation policy, feel free to
chime in.
>
> Heka is only used as an internal component of Kolla and is not provided
as a service for the operators. It should be sufficient to replace Heka by
something else without deprecating it.
>
> Christian.
>
> __
> 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
>

Kolla is an operator tool and there are multiple tools only internal to
deployment. This does not mean we can deprecate tools without operator
being notified about it.
__
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] Ocata summit session poll

[Swapnil Kulkarni]

On Wed, Sep 21, 2016 at 11:16 PM, Steven Dake (stdake)  wrote:
> One note in this poll.  Repo-split has already reached a consensus decision 
> via ml vote, and the activity around that will happen prior to summit, so it 
> is probably worth ignoring entirely.
>
> Regards
> -steve
>
>
> On 9/21/16, 10:14 AM, "Michał Jastrzębski"  wrote:
>
> Hello,
>
> Now, when we have full list of sessions, let's prioritize them
> accordingly to our preferences. Based on this we'll allocate our
> summit space.
>
> 
> http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_8368e1e74f8a0049=91bbcf4baeff0a2f
>
> __
> 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


I agree. We already devoted a couple of sessions (or more) in Austin
design summit and couple of polls on ML thread.

__
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] [vote][kolla] deprecation for debian distro support

[Swapnil Kulkarni]

On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke  wrote:
> -1 for deprecating Debian.
>
> As I mentioned in https://review.openstack.org/#/c/369183/, Debian support
> was added incrementally by Benedikt Trefzer as recently as June. So it's
> reasonable to believe there is at least one active user of Debian.
>
> I would like to try get some input from him on whether he's still using it
> and would be interested in helping maintain by adding gates etc.
>
> On 19/09/16 18:44, Jeffrey Zhang wrote:
>>
>> Kolla core reviewer team,
>>
>> Kolla supports multiple Linux distros now, including
>>
>> * Ubuntu
>> * CentOS
>> * RHEL
>> * Fedora
>> * Debian
>> * OracleLinux
>>
>> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
>> robust gate to ensure the quality.
>>
>> For Debian, Kolla hasn't any test for it and nobody reports any bug
>> about it( i.e. nobody use Debian as base distro image). We (kolla
>> team) also do not have enough resources to support so many Linux
>> distros. I prefer to deprecate Debian support now.
>>
>> Please vote:
>>
>> 1. Kolla needs support Debian( if so, we need some guys to set up the
>> gate and fix all the issues ASAP in O cycle)
>> 2. Kolla should deprecate Debian support
>>
>> Voting is open for 7 days until September 27st, 2016.
>>
>
> __
> 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


+1 for #2

I agree with reasoning from Paul, though Debian support was being
added incrementally by Benedikt Trefzer but it has been stopped in
middle and all patches in the queue were abandoned [1]

[1] https://review.openstack.org/#/q/topic:bp/build-debian,n,z

__
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] [vote][kolla] Splitting out Ansible into a separate deliverable

[Swapnil Kulkarni]

On Thu, Sep 15, 2016 at 11:42 AM, Steven Dake (stdake)  wrote:
> Core Reviewers:
>
>
>
> The facts:
>
> We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be
> closed out as dupes, fixed, wontfix, or the like.
>
> The core reviewer team has had various discussions around splitting the
> repository at various times but has not come to a concrete conclusion via a
> vote.
>
> Once RC1 is tagged, the stable/newton branch will be created automatically.
>
> All rc2 bug fixes will require bug IDs and backports to stable/newton to
> enable the ability to manage the release of rc2 and 3.0.0.
>
> There is an expectation for core reviewers to do the work of backporting to
> stable/newton – only our backports team typically does this work – however
> during release we really need everyone’s participation.
>
>
>
> My understanding of general consensus beliefs:
>
> We believe splitting out the Ansible implementation into a separate
> repository will produce a better outcome for both Kolla-Ansible and
> Kolla-Kubernetes
>
> We have been unable to achieve consensus on the right timing for a repo
> split in the past but generally believe the timing is right at some point
> between rc1 and Summit or shortly thereafter, if we are to do the repo split
> during Newton or very early Ocata.)
>
>
>
> This vote is a multiple choice (one choice please) vote.  Feel free to
> discuss before making a decision.
>
>
>
> Please vote:
>
> a)   Do not split the repository between rc1 and Summit or shortly
> thereafter at all, keeping the Ansible implementation intact in Ocata
>
> b)   Split the repository shortly after tagging RC1 – creating of a
> kolla-ansible deliverable for Ocata.
>
> c)   Split the repository shortly after tagging 3.0.0 – creating a
> kolla-ansible deliverable for Ocata.
>
>
>
> Voting is open for 7 days until September 21st, 2016. Please do not abstain
> on this critical vote.  Remember, no veto vote is available in roll-call
> votes.  If a majority can’t be reached on any one choice, but there is a
> majority around B & C, (which are the same idea, but different timing) a
> second vote will be triggered around when to split the repository.  The
> implication there is if you vote for b or c, your voting for a repository
> split.  If you vote for A you are voting for no repository split.  I hate to
> overload voting in this way.  It is only an optimization to speed things up
> as execution may need to happen now, or can be pushed out a month, or may
> not be needed at this time.
>
>
>
> Regards
>
> -steve
>
>
> __
> 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
>


my vote is for option C.

__
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][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Swapnil Kulkarni]

On Mon, Sep 12, 2016 at 10:34 PM, Steven Dake (stdake)  wrote:
> To the OpenStack Community,
>
>
>
> Consider this email my self non-nomination for PTL of Kolla for
>
> the coming Ocata release.  I let the team know in our IRC team meeting
>
> several months ago I was passing the on baton at the conclusion of Newton,
>
> but I thought the broader OpenStack community would appreciate the
> information.
>
>
>
> I am super proud of what our tiny struggling community produced starting
>
> 3 years ago with only 3 people to the strongly emergent system that is Kolla
>
> with over 467 total contributors [1] since inception and closing in on 5,000
>
> commits today.
>
>
>
> In my opinion, the Kolla community is well on its way to conquering the last
>
> great challenge OpenStack faces: Making operational deployment management
> (ODM)
>
> of OpenStack cloud platforms straight-forward, easy, and most importantly
>
> cost effective for the long term management of OpenStack.
>
>
>
> The original objective the Kolla community set out to accomplish, deploying
>
> OpenStack in containers at 100 node scale has been achieved as proven by
> this
>
> review [2].  In these 12 scenarios, we were able to deploy with 3
>
> controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
>
> storage and run rally as well as tempest against the deployment.
>
>
>
> Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.
>
>
>
> I have developed a strong leadership pipeline and expect several candidates
>
> to self-nominate.  I wish all of them the best in the future PTL elections.
>
>
>
> Finally, I would like to thank all of the folks that have supported Kolla’s
>
> objectives.  If I listed the folks individually this email would be far too
>
> long, but you know who you are J Thank you for placing trust in my
> judgement.
>
>
>
> It has been a pleasure to serve as your leader.
>
>
>
> Regards
>
> -steak
>
>
>
> [1] http://stackalytics.com/report/contribution/kolla-group/2000
>
> [2] https://review.openstack.org/#/c/352101/
>
>
>
>
> __
> 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
>

Thank you, Steve, for your role in working with the team for creating
a perfect track to roll.

__
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] [FFE] two xstatic packages to be bumped in upper-constraints, please

[Swapnil Kulkarni (coolsvap)]

On Tue, Sep 13, 2016 at 6:09 AM, Richard Jones  wrote:
> Hi folks,
>
> We have two patches to upper-constraints up that we'd like to see merged for
> Newton. The package updates in question only changed meta-data, but they did
> so in a way that fixes issues for downstream, and it makes sense to keep
> upper-constraints in line with what they'll be packaging.
>
> The reviews are:
>
> update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
> https://review.openstack.org/#/c/368970/
>
> update constraint for XStatic-smart-table to new release 1.4.13.2
> https://review.openstack.org/#/c/366194/
>
>
> Thanks,
>
> Richard
>
>
> __
> 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
>


+1

__
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] proposing adding Tony Breeds to "Release Managers" team

[Swapnil Kulkarni]

On Tue, Sep 6, 2016 at 9:06 PM, Doug Hellmann  wrote:
> Team,
>
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
>
> Please respond below with +1 or -1.
>
> Thanks,
> Doug
>
> __
> 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



+1

__
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] [requirements][FFE] block graphviz 0.5.0

[Swapnil Kulkarni (coolsvap)]

On Fri, Sep 9, 2016 at 3:46 PM, Dirk Müller  wrote:
> Hi Tony,
>
> 2016-09-09 9:42 GMT+02:00 Tony Breeds :
>
>> Has some impact on  octavia (doc-requirements) and rpm-packaging (internal
>> global-requirements.txt)
>
> Yeah, rpm-packaging shouldn't be a blocker on this, since we're just
> trying to keep a snapshot of g-r that we have tested against (this
> isn't fully functional yet).
>
> so +2, workflow+1.
>
> Greetings,
> Dirk
>
> __
> 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


Thank you all for your responses and getting it merged.

__
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] [requirements][FFE] block graphviz 0.5.0

[Swapnil Kulkarni]

On Fri, Sep 9, 2016 at 12:07 PM, Shake Chen <shake.c...@gmail.com> wrote:
> seem the link is error.
>
> https://review.openstack.org/#/c/367740/
>
>
>
> On Fri, Sep 9, 2016 at 2:28 PM, Swapnil Kulkarni (coolsvap)
> <m...@coolsvap.net> wrote:
>>
>> Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]
>>
>> We need to unblock the gates by blocking graphviz===0.5.0.
>>
>> [1] https://review.openstack.org/#/c/367416/
>>
>> --
>> Best Regards,
>> Swapnil Kulkarni
>> irc : coolsvap
>>
>> __
>> 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
>
>
>
>
> --
> Shake Chen
>
>
> __
> 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
>


This is the change [1]  where py34 gate is failing. The requirements
update will be triggered with requirements bot once FFE is granted and
related change is merged.

__
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-dev] [requirements][FFE] block graphviz 0.5.0

[Swapnil Kulkarni (coolsvap)]

Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]

We need to unblock the gates by blocking graphviz===0.5.0.

[1] https://review.openstack.org/#/c/367416/

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Swapnil Kulkarni]

On Thu, Sep 8, 2016 at 8:29 AM, Steven Dake (stdake)  wrote:
> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate Christian Berendt for the Kolla core team.
>
>
>
> Christian’s output over the last cycle has been fantastic – cracking the top
> 10 reviewer list for the full cycle.  His 30 day stats [1] place him in
> solid 7th position, and considering the size of the core review team we
> have, this is a great accomplishment.  Christian also has solid 60 day
> review stats [2] place him in solid 7th position.  But more importantly his
> reviews are of high quality.  He has great IRC participation as well as
> having implemented all kinds of bug fixes all over the code base.  He
> clearly understands Kolla by the quality of his reviews.
>
>
>
> Consider this nomination a +1 vote from me.
>
>
>
> A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote
> indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until
> September 15th, or a unanimous response is reached or a veto vote occurs.
> If a unanimous response is reached or a veto occurs, voting will close
> early.
>
>
>
> Regards,
>
> -steve
>
>
>
> [1] http://stackalytics.com/report/contribution/kolla/30
>
> [2] http://stackalytics.com/report/contribution/kolla/60
>
>
>
>
> __
> 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
>

+1

__
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-dev] [PyCharm] Renewal of Licence

[Swapnil Kulkarni (coolsvap)]

The annual renewal process of pycharm licences has been completed. As
part of this, the licences ar now renewed till Sep 4, 2017.

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] Seeking Mobile Beta Testers

[Swapnil Kulkarni]

Count me in for Android beta testing.

On Sep 2, 2016 11:31 PM, "Jimmy McArthur"  wrote:
>
> We're looking for a handful of community members to test our updated
OpenStack Summit mobile Apps. If you're interested, shoot me a note, along
with iOS/Android preference, and we'll get you set up.
>
> Thank you,
> Jimmy McArthur
>
>
> __
> 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] which footer format we need

[Swapnil Kulkarni]

On Fri, Sep 2, 2016 at 8:32 AM, Jeffrey Zhang  wrote:
> We introduced customization solution.
>
> Now, we support two format of footer.
>
> 1. the legacy way: {{ include_footer }}
> 2. the new way: {% block footer %}{% endblock %}
>
> there two conflict about this now[0][1].
>
> I think the option 2 is better. We can get more consistent solution.
>
> [0] https://review.openstack.org/#/c/357746
> [1] https://review.openstack.org/#/c/361253
>
> --
> 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
>


I tend towards #2, patchset [0] is corresponding to a discussion on
#openstack-kolla and if we keep #2, we need to keep #1 in all
dockerfiles with a deprecation warning for next cycle.

Also what if user specifies both the footer blocks? We need to confirm
we ignore  #1 if #2 is chosen.

__
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-dev] [kolla] Feature freeze until we tag rc1

[Swapnil Kulkarni]

Hello all,

With the end of last development milestone newton-3, we will be having
a procedural -2 on all features change requests to block merge until
rc1 is tagged on September 15th.

As a result of this, all changes related to blueprints not tagged for
rc1 will have -2. The -2 here does not indicate the work is not
valued. So please continue working on the features as we will actively
review work once we move into next development milestones for ocata.

Feel free to work on any bugs targetted to rc1 or otherwise. For any
queries reply to this thread or jump to #openstack-kolla

TIA

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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-dev] [kolla][documentation] Docimpact bugs

[Swapnil Kulkarni (coolsvap)]

Hello,

We have around 13 doc bugs [1] created for features which required
documentation. Most of the bugs are not attended after the feature got
merged. I have moved all the bugs to o-1. If you think any of this can
be completed within rc1 timeframe, feel free to move it back to the
current milestone or submit a change.


[1] https://bugs.launchpad.net/kolla/+bugs?field.tag=doc

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] [TripleO] New bug tagging policy

[Swapnil Kulkarni]

On Thu, Aug 25, 2016 at 4:00 PM, Julie Pichon  wrote:
> Hi folks,
>
> The bug tagging proposal has merged, behold the new policy:
>
> http://specs.openstack.org/openstack/tripleo-specs/specs/policy/bug-tagging.html
>
> TL;DR The TripleO Launchpad tracker encompasses a lot of sub-projects,
> let's use a consistent list of Launchpad tags where they make sense in
> order to help understand which area(s) are affected. The tags get
> autocompleted by Launchpad (or will be soon).
>
>
> There is one remaining action to create the missing tags: I don't have
> bug wrangling permissions on the TripleO project so, if someone with
> the appropriate permissions could update the list [1] to match the
> policy I would appreciate it. Should I be deemed trustworthy enough
> I'm just as happy to do it myself and help out with the occasional
> bout of triaging as well.
>
> Thanks,
>
> Julie
>
> [1] https://bugs.launchpad.net/tripleo/+manage-official-tags
>
> __
> 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

Done!

__
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][vote] Core nomination for Dave Walker (Daviey on irc)

[Swapnil Kulkarni]

On Aug 24, 2016 2:15 AM, "Steven Dake (stdake)"  wrote:
>
> Kolla core reviewers,
>
> I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day
review stats [1] place him in the middle of the pack for reviewers and his
60 day stats[2] are about equivalent.  Dave participates heavily in IRC and
has done some good technical work including the Watcher playbook and
container.  He also worked on Sensu, but since we are unclear if we are
choosing Sensu or Tig, that work is on hold.  He will also be helping us
sort out how to execute with PBR going into the future on our stable and
master branches.  Dave has proven to me his reviews are well thought out
and he understands the Kolla Architecture.  Dave is part time like many
Kolla core reviewers and is independent of any particular affiliation.
>
> Consider this nomination as a +1 from me.
>
> As a reminder, a +1 vote indicates you approve of the candidate, an
abstain vote indicates you don't care or don't know for certain, and a –1
vote indicates a veto.  If a veto occurs or a unanimous response is reached
prior to our 7 day voting window which concludes on August 30th, voting
will be closed early.
>
> [1] http://stackalytics.com/report/contribution/kolla/30
> [2] http://stackalytics.com/report/contribution/kolla/60
>
> __
> 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
>

+1
__
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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Swapnil Kulkarni]

Thanks sdake.

+1 :)

On Aug 19, 2016 10:35 PM, "Steven Dake (stdake)"  wrote:
>
> Coolsvap mentioned he wasn't receiving his emails at his home email
> server, so he will respond from a different mail service.  Just bringing
> this up again so he can see the thread.
>
> Regards
> -steve
>
> On 8/19/16, 7:09 AM, "Kwasniewska, Alicja" 
> wrote:
>
> >+1 :)
> >
> >-Original Message-
> >From: Ryan Hallisey [mailto:rhall...@redhat.com]
> >Sent: Friday, August 19, 2016 2:50 PM
> >To: OpenStack Development Mailing List (not for usage questions)
> >
> >Subject: Re: [openstack-dev] [vote][kolla] Core nomination proposal for
> >Eduardo Gonzalez Gutierrez (egonzales90 on irc)
> >
> >+1
> >
> >-Ryan
> >
> >- Original Message -
> >From: "Steven Dake (stdake)" 
> >To: "OpenStack Development Mailing List (not for usage questions)"
> >
> >Sent: Thursday, August 18, 2016 7:09:35 PM
> >Subject: [openstack-dev] [vote][kolla] Core nomination proposal for
> >Eduardo Gonzalez Gutierrez (egonzales90 on irc)
> >
> >Kolla Core Review Team:
> >
> >I am nominating Eduardo for the core reviewer team. His reviews are
> >fantastic, as I'm sure most of you have seen after looking over the
> >review queue. His 30 day stats place him at #3 by review count [1] and 60
> >day stats [2] at #4 by review count. He is also first to review a
> >significant amount of the time ­ which is impressive for someone new to
> >Kolla. He participates in IRC and he has done some nice code contribution
> >as well [3] including the big chunk of work on enabling Senlin in Kolla,
> >the dockerfile customizations work, as well as a few documentation fixes.
> >Eduardo is not affiliated with any particular company. As a result he is
> >not full time on Kolla like many of our other core reviewers. The fact
> >that he is part time and still doing fantastically well at reviewing is a
> >great sign of things to come :)
> >
> >Consider this nomination as my +1 vote.
> >
> >Voting is open for 7 days until August 24th. Joining the core review team
> >requires a majority of the core review team to approve within a 1 week
> >period with no veto (-1) votes. If a veto or unanimous decision is
> >reached prior to August 24th, voting will close early.
> >
> >Regards
> >-steve
> >
> >[1] http://stackalytics.com/report/contribution/kolla/30
> >[2] http://stackalytics.com/report/contribution/kolla/60
> >[3]
> >
https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2
> >540gmail.com%253E%22
> >
>
>__
> >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
__
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] [tc] persistently single-vendor projects

[Swapnil Kulkarni (coolsvap)]

On Mon, Aug 1, 2016 at 1:09 PM, Thierry Carrez  wrote:
> Steven Dake (stdake) wrote:
>> On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:
>>> [...]
>>> To be clear, I'm suggesting that projects with team:single-vendor be
>>> given enough time to lose that tag. That does not require them to grow
>>> diverse enough to get team:diverse-affiliation.
>>
>> That makes sense and doesn't send the wrong message.  I wasn't trying to
>> suggest that either; was just pointing out Kevin's numbers are more in
>> line with diverse-affiliation than single vendor.  My personal thoughts
>> are single vendor projects are ok in OpenStack if they are undertaking
>> community-building activities to increase their diversity of contributors.
>
> Basically my position on this is: OpenStack is about providing open
> collaboration spaces so that multiple organizations and individuals can
> collaborate (on a level playing ground) to solve a set of issues. It's
> difficult to have a requirement of a project having a diversity of
> affiliation before it can join, because of the chicken-and-egg issue
> between visibility and affiliation-diversity. So we totally accept
> single-vendor projects as official OpenStack projects.
>
> But if a project is persistently single-vendor after some time and
> nobody seems interested to join it, the technical value of that project
> being "in" OpenStack rather than a separate project in the OpenStack
> ecosystem of projects is limited. It's limited for OpenStack (why
> provide resources to support a project that is obviously only beneficial
> to one organization ?), and it's limited to the organization itself (why
> go through the OpenStack-specific open processes when you could shortcut
> it with internal tools and meetings ? why accept the oversight of the
> Technical Committee ?).

+1 to track this.

>
> So the idea is to find a way for projects who realize that they won't
> attract a significant share of external contributions to move to an
> externally-governed project. I'm not sure we can use a strict deadline
> -- some projects might still be single-vendor after a year but without
> structurally resisting contributions. But being able to trigger a review
> after some time, to assess if we have reasons to think it will improve
> in the future (or not), sounds like a good idea.
>
> --
> 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


The idea of externally-governed projects is very good since there are
and will be projects which want the status of being part of
"OpenStack" community but cannot have diverse-affiliation due to
inherent nature of development/testing/ci or whatsoever requirements.
If it remains or is known to remain a single vendor project in its
future, it does not need to be dependent on any of the community
resources, be it contributors/infrastructure.

__
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] [ptl][requirements] nomination period started

[Swapnil Kulkarni (coolsvap)]

On Wed, Jul 27, 2016 at 7:11 PM, Matthew Thode
 wrote:
> We've started a period of self nomination in preparation for the
> requirements project fully moving into project (as it's still under Doug
> Hellmann).
>
> We are gathering the self nominations here before we vote next week.
> https://etherpad.openstack.org/p/requirements-ptl-newton
>
> Nominees should also send an email to the openstack-dev list.
>
> --
> -- Matthew Thode (prometheanfire)
>
>
> __
> 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
>

I would like to nominate for the PTL of newly formed requirements team.

I joined release engineering discussion during Austin Summit as an
enthusiast to see and volunteer for contribution. From the bootstrap
meeting of the requirement group [1] I have contributed with both code
and reviews[2]. I constantly review the requirements queue and always
help people to accelerate the merge of failing/required libraries. I
would like to do better management of requirements project. I have
started with the formulating team meeting agenda on wiki.

I wish to work on the requirements in the same intent going forward.

Thank you,
coolsvap

[1] 
http://eavesdrop.openstack.org/meetings/requirements/2016/requirements.2016-05-18-12.00.html
[2] http://stackalytics.com/report/contribution/requirements/75

__
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-dev] [kolla] Binary containers with pip install?

[Swapnil Kulkarni (coolsvap)]

Dear Kollagues,

There has been a detailed conversation between me and Prithiv related
to [1] and allowing pip install in binary containers.

Till now we have simply skipped the binary containers till we have
official packages in respective distro repositories. I strongly feel
we should be following that.

If someone wishes to have a functionality without a package in the
base distro, there is always an option to build source containers and
use it with Kolla.

Thoughs welcome?

[1] https://review.openstack.org/#/c/344930/

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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-dev] [requirements] Project Mascot

[Swapnil Kulkarni (coolsvap)]

Hello,

We had a discussion about project mascot for requirements team today
at the team meeting. Some of the options mentioned are added to [1].
If you have any option, please add to the list.
Also do not forget to provide preference. We will finalize the mascot
on Monday July 25.

[1] https://etherpad.openstack.org/p/requirements-team-mascot

--
Best Regards,
Swapnil

__
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] [PyCharm] [all] Revoking pycharm licences for non-active users

[Swapnil Kulkarni (coolsvap)]

On Tue, May 17, 2016 at 4:22 PM, Swapnil Kulkarni <m...@coolsvap.net> wrote:
> Hello All,
>
> As part of the JetBrains Community support OpenStack (active)
> developers get access to community edition of PyCharm tool. From the
> management perspective I am facing issue to allocate licences to new
> requests. With some review, I have found more than 70 licences which
> are allocated and never used.
>
> I am revoking the PyCharm licences for this list of users. If you are
> among the users and you still think you need PyCharm licence, feel
> free to request a licence.
>
> Note: This exercise will be done every month for users who are not
> actively using PyCharm for 3 months or more.
>
> Best Regards,
> Swapnil

In order to make it easier for active contributors to obtain PyCharm
licence, I have created [1] to submit the information.

[1] 
https://docs.google.com/forms/d/1dQnWgvs9Aanf0Jx2OyZhVewDi2q8r5c905BdWBdXwvA/viewform

__
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][vote] Applying for stable-follows tag

[Swapnil Kulkarni (coolsvap)]

On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
> Hi Steve,
>
> +1 to applying. I'll volunteer for the backport team also.
>
> -Paul
>
>
> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>>
>> Hey Koalians,
>>
>> I'd like us to consider applying  for the stable follows policy tag.
>>   Full details are here:
>>
>>
>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>>
>> Because of the magic work we did to make liberty functional, it is
>> possible that we may not be able to apply for this tag until Liberty
>> falls into EOL.  Still I personally believe intent matters most, and our
>> intent has always been for these to be stable low-rate-of-change
>> no-feature-backport branches.  There are some exceptions I think we
>> would fit under for the Liberty case, so I think it is worth a shot.
>>
>> I'd need 2-4 people to commit to joining the stable backport team for
>> Kolla reviews specifically.  These folks would be the only folks that
>> could ACK patches in the stable branch maintenance queue.  Anyone could
>> continue to submit backport patches as they desire.
>>
>> I'll leave voting open for 1 week or until there I a majority (6 core
>> reviewers) or until there is a unanimous vote.  If there is not, then we
>> won't apply.  The deadline for this vote is July 25th.
>>
>> Thanks!
>> -steve
>>
>>
>>
>>
>> __
>> 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

+1 to apply for stable follows policy.
I would like to volunteer for the backport team.

__
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] our mascot - input needed

[Swapnil Kulkarni (coolsvap)]

On Fri, Jul 15, 2016 at 1:38 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> The OpenStack foundation is putting together mascots for every project with
> a proper artist doing the work.  The cool thing about this is we a) get
> stickers b) have consistent look and feel among mascots in OpenStack.
>
> The downside is we have to make a decision.  The foundation wants 3-5
> choices.
>
> The mascot must be an animal and it can't involve glue or other inc007
> inspired ideas :)
>
> Obviously Koala bear is probably everyone's first choice since we have sort
> of been using that as a mascot since day one.  Anyone else have anything
> else for me to provide the foundation with a choices 2-5?
>
> Please respond quickly, the foundation needs the information shortly.  I'd
> like to offer up two alternatives just in case.
>
> Regards
> -steve
>
>
>
> __
> 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
>

Koala bear

__
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][nova][infra] Voting gates

[Swapnil Kulkarni (coolsvap)]

On Thu, Jul 14, 2016 at 7:51 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> At the midcycle, we had a session on gating.
>
> Out of that session came the decision to make the build gates voting as soon
> as the mirroring is finished for ubuntu first (because that is closer for us
> to get mirroring sorted out) followed by CentOS/Oracle Linux.  I am taking
> this work on (mirroring specifically) and expect it to finish in the next
> 1-2 weeks (ubuntu only).  After that I will sort out the centos mirroring.
> I'm not sure who got the mirroring work kicked off in infrastructure – I
> think it was Jessie Pretorious – if the credit is wrong apologies, but
> whoever it was, - huge thanks from me personally :)
>
> We are not making the deploy gates voting at this time, although the plan is
> to do so once we stablize the last of the gate issues.  I think we are just
> down to one issue now, and that is that ubuntu source fails with an error
> about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova
> community has any bones to throw us on how to fix this, it would be
> appreciated.  I'd cut and paste the log, but for some reason C isn't
> working in my email client at present.
>
> If folks know of other consistent deploy gate failures, can you please
> respond on this thread with either a bug link or a link to a log of the
> failure in question.
>
> The review where it fails is 339776.
>
> Regards
> -steve
>
> __
> 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
>


+1 I think its good idea to finally move towards voting build jobs.

__
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] New specs process - a dicussion

[Swapnil Kulkarni (coolsvap)]

On Jul 12, 2016 8:04 PM, "Michał Jastrzębski"  wrote:
>
> Hey guys,
>
> Since our project matured, we decided that we should have a discussion
> regarding our spec process.
>
> https://etherpad.openstack.org/p/kolla-N-midcycle-specs
>
> Currently we do specs for most critical things, and they require majority
vote.
>
> We want to introduce another way, to enable non-nuclear specs.
> To summarize our discussion so far:
>
> 1. Specs will require only 2 * +2 by default
> 2. Specs sit at minimum 2 weeks in gerrit before first +2 arrives, so
> other people will have time to look at it
> 3. Any core can require a rollcall vote - then it becomes rollcall vote
> 4. If nobody calls for rollcall vote, after 2 weeks spec can be merged
> with normal 2 * +2
>
> Thoughts?
> Michal
>
> __
> 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

+1 I agree.
__
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][vote] Apply for release:managed tag

[Swapnil Kulkarni (coolsvap)]

On Fri, Jul 1, 2016 at 6:26 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> I'd like the release management team to take on releases of Kolla.  This
> means applying for the release:managed[1] tag.  Please vote +1 if you wish
> to proceed, or –1 if you don’t wish to proceed.  The most complex part of
> this change will be that when feature freeze happens, we must actually
> freeze all feature development.  We as a team haven't been super good at
> this in the past, but I am confident we could hold to that set of rules if
> the core team is in agreement on this vote.
>
> I will leave voting open or 1 week until July 8th.  If a majority is reached
> prior to that date, I will close voting early and submit governance changes.
>
> Note the release team would have  to accept our application, so even though
> we may decide to vote to be release:managed, it is ultimately up to the
> discretion of the release management team whether we meet the criteria and
> if they have the bandwidth to work with our release liason.
>
> [1]
> https://github.com/openstack/governance/blob/master/reference/tags/release_managed.rst
>
>
> __
> 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
>

+1 to apply for release:managed tag.

Swapnil

__
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] [TripleO] TripleO deep dive hour?

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 29, 2016 at 4:57 PM, Swapnil Kulkarni (coolsvap)
<m...@coolsvap.net> wrote:
> On Wed, Jun 29, 2016 at 3:30 AM, James Slagle <james.sla...@gmail.com> wrote:
>> We've got some new contributors around TripleO recently, and I'd like
>> to offer up a "TripleO deep dive hour".
>>
>> The idea is to spend 1 hour a week in a high bandwidth environment
>> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
>> topic. The topic could be anything TripleO related, such as general
>> onboarding, CI, networking, new features, etc.
>>
>> I'm by no means an expert on all those things, but I'd like to
>> facilitate the conversation and I'm happy to lead the first few
>> "dives" and share what I know. If it proves to be a popular format,
>> hopefully I can convince some other folks to lead discussions on
>> various topics.
>>
>> I think it'd be appropriate to record these sessions so that what is
>> discussed is available to all. However, I don't intend these to be a
>> presentation format, and instead more of a q discussion. If I don't
>> get any ideas for topics though, I may choose to prepare something to
>> present :).
>>
>> Our current meeting time of day at 1400 UTC seems to suit a lot of
>> folks, so how about 1400 UTC on Thursdays? If folks think this is
>> something that would be valuable and want to do it, we could start
>> next Thursday, July 7th.
>>
>>
>> --
>> -- James Slagle
>> --
>>
>> __
>> 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
>
> +1

I have done some bootstrapping in the ehterpad [1]. Hoping to see some
action there :)

[1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics

__
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] [TripleO] TripleO deep dive hour?

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 29, 2016 at 3:30 AM, James Slagle  wrote:
> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
>
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
>
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.
>
> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).
>
> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.
>
>
> --
> -- James Slagle
> --
>
> __
> 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

+1

__
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] [requirements][packaging] Normalizing requirements file

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 22, 2016 at 10:15 AM, Haïkel  wrote:
> Hi,
>
> as a packager, I spend a lot of time to scrutinize the requirements
> repo, and I find it easier to read if specifiers are ordered.
> So in a quick glance, you can check which is the min version required
> and max one without trying to search them among other specifiers.
> I scripted a basic linter to do that (which also normalize comments to
> PEP8 standards)
>
> Initial review is here:
> https://review.openstack.org/#/c/332623/
>
> script is available here;
> https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1
>
> Your thoughts?
>
> Regards,
> H.
>
> __
> 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

Haikel,

This looks good and the global-requirements.txt now looks much cleaner.

Can you add the linter to the tools directory in requirements. We can
use it in our gates.

Swapnil

__
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] [requirements][all] VOTE to expand the Requirements Team

[Swapnil Kulkarni (coolsvap)]

Thank you all.

On Mon, Jun 20, 2016 at 6:39 PM, Davanum Srinivas <dava...@gmail.com> wrote:
> Thanks for the VOTE everyone.
>
> Matthew, Dirk, Swapnil, Tony, Thomas,
> With this VOTE the training wheels come off :) Please be cautious with
> your new super powers!

Dims, yes of course :)

>
> And thanks a Ton to Thierry as well.
>
> Thanks,
> Dims
>
> On Fri, Jun 17, 2016 at 3:59 PM, Robert Collins
> <robe...@robertcollins.net> wrote:
>> Sure. +1
>>
>> On 17 June 2016 at 02:44, Davanum Srinivas <dava...@gmail.com> wrote:
>>> Folks,
>>>
>>> At Austin the Release Management team reached a consensus to spin off
>>> with some new volunteers to take care of the requirements process and
>>> repository [1]. The following folks showed up and worked with me on
>>> getting familiar with the issues/problems/tasks (see [1] and [2]) and
>>> help with the day to day work.
>>>
>>> Matthew Thode (prometheanfire)
>>> Dirk Mueller (dirk)
>>> Swapnil Kulkarni (coolsvap)
>>> Tony Breeds (tonyb)
>>> Thomas Bechtold (tbechtold)
>>>
>>> So, please cast your VOTE to grant them +2/core rights on the
>>> requirements repository and keep up the good work w.r.t speeding up
>>> reviews, making sure new requirements don't break etc.
>>>
>>> Also, please note that Thierry has been happy enough with our work to
>>> step down from core responsibilities :) Many thanks Thierry for
>>> helping with this effort and guidance. I'll make all the add/remove to
>>> the requirements-core team when this VOTE passes.
>>>
>>> Thanks,
>>> Dims
>>>
>>> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
>>> [2] https://etherpad.openstack.org/p/requirements-tasks
>>> [3] https://etherpad.openstack.org/p/requirements-cruft
>>>
>>> --
>>> Davanum Srinivas :: https://twitter.com/dims
>>>
>>> __
>>> 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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



-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap
me at coolsvap dot net
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
"It's better to SHARE"

__
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] stepping down from core

[Swapnil Kulkarni (coolsvap)]

On Tue, Jun 7, 2016 at 1:06 AM, Jeff Peeler  wrote:
> Hi all,
>
> This is my official announcement to leave core on Kolla /
> Kolla-Kubernetes. I've enjoyed working with all of you and hopefully
> we'll cross paths again!
>
> Jeff
>
> __
> 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


All the best Jeff for the next big thing you are going to do :)

__
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] Request for changing the meeting time to 1600 UTC for all meetings

[Swapnil Kulkarni (coolsvap)]

On Fri, Jun 10, 2016 at 6:44 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Swapnil,
>
> Thanks for triggering this community vote.  It was sorely overdue :).  I
> counted 8 votes before I voted (I am all for moving everything to 1600UTC)
> which is a majority of the CR team.  Note in the future I think we may
> need to consider having split meetings again, if our community makeup
> changes.

Steve, yes I understand.

>
> I have submitted a review to make the change official:
> https://review.openstack.org/#/c/327845/1
>
>
> Regards
> -steve
>
>
> On 6/8/16, 5:54 AM, "Swapnil Kulkarni (coolsvap)" <m...@coolsvap.net> wrote:
>
>>Dear Kollagues,
>>
>>Some time ago we discussed the requirement of alternating meeting
>>times for Kolla weekly meeting due to major contributors from
>>kolla-mesos were not able to attend weekly meeting at UTC 1600 and we
>>implemented alternate US/APAC meeting times.
>>
>>With kolla-mesos not active anymore and looking at the current active
>>contributors, I wish to reinstate the UTC 1600 time for all Kolla
>>Weekly meetings.
>>
>>Please let me know your views.
>>
>>--
>>Best Regards,
>>Swapnil Kulkarni
>>irc : coolsvap
>>
>>__
>>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


Thank you all for your vote!

__
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-dev] [kolla] Request for changing the meeting time to 1600 UTC for all meetings

[Swapnil Kulkarni (coolsvap)]

Dear Kollagues,

Some time ago we discussed the requirement of alternating meeting
times for Kolla weekly meeting due to major contributors from
kolla-mesos were not able to attend weekly meeting at UTC 1600 and we
implemented alternate US/APAC meeting times.

With kolla-mesos not active anymore and looking at the current active
contributors, I wish to reinstate the UTC 1600 time for all Kolla
Weekly meetings.

Please let me know your views.

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] prototype of a DSL for generating Dockerfiles

[Swapnil Kulkarni (coolsvap)]

On Fri, May 27, 2016 at 8:35 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> While Swapnil has been busy churning the dockerfile.j2 files to all match
> the same style, and we also had summit where we declared we would solve the
> plugin problem, I have decided to begin work on a DSL prototype.
>
> Here are the problems I want to solve in order of importance by this work:
>
> Build CentOS, Ubuntu, Oracle Linux, Debian, Fedora containers
> Provide a programmatic way to manage Dockerfile construction rather then a
> manual (with vi or emacs or the like) mechanism
> Allow complete overrides of every facet of Dockerfile construction, most
> especially repositories per container (rather than in the base container) to
> permit the use case of dependencies from one version with dependencies in
> another version of a different service
> Get out of the business of maintaining 100+ dockerfiles but instead maintain
> one master file which defines the data that needs to be used to construct
> Dockerfiles
> Permit different types of optimizations or Dockerfile building by changing
> around the parser implementation – to allow layering of each operation, or
> alternatively to merge layers as we do today
>
> I don't believe we can proceed with both binary and source plugins given our
> current implementation of Dockerfiles in any sane way.
>
> I further don't believe it is possible to customize repositories & installed
> files per container, which I receive increasing requests for offline.
>
> To that end, I've created a very very rough prototype which builds the base
> container as well as a mariadb container.  The mariadb container builds and
> I suspect would work.
>
> An example of the DSL usage is here:
> https://review.openstack.org/#/c/321468/4/dockerdsl/dsl.yml
>
> A very poorly written parser is here:
> https://review.openstack.org/#/c/321468/4/dockerdsl/load.py
>
> I played around with INI as a format, to take advantage of oslo.config and
> kolla-build.conf, but that didn't work out.  YML is the way to go.
>
> I'd appreciate reviews on the YML implementation especially.
>
> How I see this work progressing is as follows:
>
> A yml file describing all docker containers for all distros is placed in
> kolla/docker
> The build tool adds an option —use-yml which uses the YML file
> A parser (such as load.py above) is integrated into build.py to lay down he
> Dockerfiles
> Wait 4-6 weeks for people to find bugs and complain
> Make the —use-yml the default for 4-6 weeks
> Once we feel confident in the yml implementation, remove all Dockerfile.j2
> files
> Remove —use-yml option
> Remove all jinja2-isms from build.py
>
> This is similar to the work that took place to convert from raw Dockerfiles
> to Dockerfile.j2 files.  We are just reusing that pattern.  Hopefully this
> will be the last major refactor of the dockerfiles unless someone has some
> significant complaints about the approach.
>
> Regards
> -steve
>
>
> __
> 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
>

The DSL template to generate the Dockerfile seems way better than the
jinja templates in terms of extension which is currently a major
bottleneck in the plugin implementation. I am +2+W on this plan of
action to test it for next 4-6 weeks and see thereon.

Swapnil

__
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] Cross project spec liason

[Swapnil Kulkarni (coolsvap)]

On Thu, May 26, 2016 at 8:28 AM, Steven Dake (stdake)  wrote:
> Fellow core reviewers,
>
> I have a lot of liasing to do as a PTL and would like to offload some of
> it so I can get some actual sleep :)  Are there any takers on Mike's
> requirement for a cross-project liason for Kolla?  The job involves
> reviewing all specs in the cross project spec repository and understanding
> their technical impact on Kolla.  It is important in this role to take
> care of ensuring Kolla's objectives are met by the specs and raise any red
> flags to the PTL and provide an update to the core team during our weekly
> team meeting.  This responsibility comes with +2/-2 voting rights on all
> cross project specifications.
>
> The individual must be a core reviewer.
>
> Regards,
> -steve
>
> On 5/17/16, 6:41 AM, "Mike Perez"  wrote:
>
>>Hi PTL's,
>>
>>Please make sure your cross-project spec liaisons are up-to-date [1].
>>This role
>>defaults to the PTL if no liaison is selected. See list of
>>reponsibilities [2].
>>
>>As agreed by the TC, the cross-project spec liaison team will have voting
>>rights on the openstack/openstack-spec repo [3]. Next week I will be
>>adding
>>people from the cross-project spec liaison list to the gerrit group with
>>the
>>appropriate ACLs.
>>
>>
>>[1] -
>>https://wiki.openstack.org/wiki/CrossProjectLiaisons#Cross-Project_Spec_Li
>>aisons
>>[2] -
>>http://docs.openstack.org/project-team-guide/cross-project.html#cross-proj
>>ect-specification-liaisons
>>[3] -
>>http://governance.openstack.org/resolutions/20160414-grant-cross-project-s
>>pec-team-voting.html
>>
>>--
>>Mike Perez
>>
>>__
>>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


Steve,

I would like to take the responsibility to be cross-project liaison for Kolla.

Swapnil

__
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] [ceilometer] [telemetry] ceilometer-specs submodule path is invalid

[Swapnil Kulkarni]

On Thu, May 19, 2016 at 12:47 PM, Gerard Braad  wrote:
> Hi All,
>
>
> Doing:
>
>   $ git clone https://github.com/openstack/openstack.git
>   $ git submodule init
>   $ git submodule update
>
> fails on:
>
> Cloning into 'ceilometer-specs'...
> fatal: remote error: Git repository not found
> fatal: clone of
> 'https://review.openstack.org/openstack/ceilometer-specs.git' into
> submodule path 'ceilometer-specs' failed
>
> Hope this can be resolved (not sure where to report this).
>
> regards,
>
>
> Gerard
>
> --
> Gerard Braad
>F/OSS & IT Consultant
>http://gbraad.nl
>
> __
> 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


Hi Gerard,

You could've done one or all of the below things,

First of all, you should have included [ceilometer] or [telemetry]  in
subject. (which i have done in the reply) so its targetted intended
receipients.
Second you can open a bug at [1] or
lastly, you could have joined  #openstack-telemetry and reported the issue.

1&2 are preferable to track in case you could not find someone at IRC.

[1] https://bugs.launchpad.net/ceilometer/+filebug

__
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] Proposing Mauricio Lima for core reviewer

[Swapnil Kulkarni]

On Wed, May 18, 2016 at 12:30 AM, Steven Dake (stdake)  wrote:
> Hello core reviewers,
>
> I am proposing Mauricio (mlima on irc) for the core review team.  He has
> done a fantastic job reviewing appearing in the middle of the pack for 90
> days [1] and appearing as #2 in 45 days [2].  His IRC participation is also
> fantastic and does a good job on technical work including implementing
> Manila from zero experience :) as well as code cleanup all over the code
> base and documentation.  Consider my proposal a +1 vote.
>
> I will leave voting open for 1 week until May 24th.  Please vote +1
> (approve), or –2 (veto), or abstain.  I will close voting early if there is
> a veto vote, or a unanimous vote is reached.
>
> Thanks,
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/90
> [2] http://stackalytics.com/report/contribution/kolla/45
>
> __
> 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
>

+1

__
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-dev] [PyCharm] [all] Revoking pycharm licences for non-active users

[Swapnil Kulkarni]

Hello All,

As part of the JetBrains Community support OpenStack (active)
developers get access to community edition of PyCharm tool. From the
management perspective I am facing issue to allocate licences to new
requests. With some review, I have found more than 70 licences which
are allocated and never used.

I am revoking the PyCharm licences for this list of users. If you are
among the users and you still think you need PyCharm licence, feel
free to request a licence.

Note: This exercise will be done every month for users who are not
actively using PyCharm for 3 months or more.

Best Regards,
Swapnil

__
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] [bifrost] bifrost container poc update

[Swapnil Kulkarni]

On Sat, May 14, 2016 at 2:44 AM, Mooney, Sean K  wrote:
> Hi this is an  update on where I am with my poc of creating a bifost
> container for kolla.
>
> As of  Wednesday evening I have reached my v0 poc goal
>
>
>
> That goal was to demonstrate it was easy bifrost in a container with little
> to know changes.
>
> This is further broken down as follows.
>
> -Create poc patch to split bifrost ironic install role into install,
> bootstrap and start phases
>
> -Use kolla build.py to build a container with all bifrost/ironic
> dependences installed by running
> bifrost install phase as part of the docker build
>
> -Spawn an instance of the resulting container then bootstrap and
> start ironic by running bifrost install playbook  with only the bootstrap
> and run phases enabled
>
> -Enroll a physical node using the enroll-dynamic playbook
>
> -Deploy the default OS image to the physical node using the
> deploy-dynamic playbook
>
>
>
> The attached file assume basic knowledge of how to build images with kola
> and documents how the command I
>
> Ran to preform this poc.
>
>
>
> Limitations of v0:
>
>
>
> -Only tested with centos source build
>
> -Fat container. Uses systemd as an init system in the container.
> (yes this works fine)
>
> -Requires privileged (required for networking and  mounting loopback
> devices)
>
> -Requires net=host (as an infrastructure container on the undercloud
> this shold be ok)
>
> -Requires /sys/fs/cgroups to be bind mounted for systemd
>
> -Requires /dev to be bind mounted  to allow building of Baremetal
> image
>
> -No integration with kola deploy playbooks or script to automate
> deployment (fix in v1)
>
> -No support for external config (fix in v1)
>
> -I wrote it in 12-18 hours so no comments or docs except the
> attachment
>
> -Ironic service done restart automatically on restarting container.(
> rerun install playbook with skip_boostrap=true and skip_install=true to fix)
>
>
>
> Next steps:
>
>
>
> Define scope of v1
>
> -Should I open a blueprint/spec/bug in kolla and or bifrost?
>
> -Kolla spec to cover container and ansible integration
> (https://github.com/SeanMooney/kolla/commit/bbbfc573dcd8e20ad912dedeecc0b3994832925f)
>
> o   Support builds of bifrost container both source and binary with all 4
> base OS
>
> o   Support baremetal image customization via external config. (os,packages)
> and bring your own model to supply your own image.
>
> o   Integrate with kolla deploy playbooks.
>
> o   Add bifrost.rst to kolla docs
>
> o   Thin containers or supervisord as a v2
>
> -Bifrost spec to cover ironic install  decomposition
> (https://github.com/SeanMooney/bifrost/commit/e223f4fe73871b76ce87999470a1efc43862671e)
>
> o   Split install ironic playbook into 3 phases (install,bootstarp,start)
>
> §  possible solutions. Skip_* as in poc, separate roles or tags
>
> o   Replace use of sed for fixing hostname as it fails in a container
> (https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml#L117-L123)
>
> o   Introduce install_dib  to control if disk image build is installed of
> checking if the image should be built.
>
> -Testing: kolla ci job? Test in bifrost ci?
>
>
>
> So this is the point I pause for feedback:
>
> Does this sound like a reasonable next step?
>
> Am I going in the wrong direction with this?
>
> If I create spec or when I submit the code for review would anyone in
> particular like me to add them as reviewers?
>
>
>
> Regards
>
> Seán
>
>
>
>
> __
> 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
>


Sean, This is an excellent start. Please create a blueprint.

__
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] [requirements] Bootstrapping new team for Requirements.

[Swapnil Kulkarni]

DIms,

I would like to see how I can get involved. Looking forward to the meeting.

Best Regards,
Swapnil Kulkarni
irc : coolsvap


On Sat, May 7, 2016 at 8:32 PM, Davanum Srinivas <dava...@gmail.com> wrote:
> Dirk, Haïkel, Igor, Alan, Tony, Ghe,
>
> Please see brain dump here - 
> https://etherpad.openstack.org/p/requirements-tasks
>
> Looking at time overlap, it seems that most of you are in one time
> range and Tony and I are outliers
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506=43=240=195=166=83=281=141)
>
> So one choice for time is 7:00 AM or 8:00 AM my time which will be
> 9:00/10:00 PM for Tony. Are there other options that anyone sees?
> Please let me know which days work as well.
>
> dhellmann, sdague, markmcclain, ttx, lifeless,
> Since you are on the current requirements-core gerrit group, Can you
> please review the etherpad and add your thoughts/ideas/pointers to
> transfer knowledge to the new folks?
>
> To be clear, we are not yet adding new folks to the gerrit group, At
> the moment, i am just getting everyone familiar and productive with
> what we do now and see who is still around doing stuff in a couple of
> months :)
>
> Anyone else want to help, Jump in please!
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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][kubernetes] One repo vs two

[Swapnil Kulkarni]

On May 3, 2016 1:53 AM, "Davanum Srinivas" <dava...@gmail.com> wrote:
>
> Sorry for top-post...
>
> There's a third option : Using Feature branch for Kubernetes with a
> custom gerrit group
>
> * Feature branch can be sync'ed from Master periodically
> * Feature branch can have it's own separate gerrit group.
> * We can opt to merge from feature branch to master if necessary.
> * We can have minimum changes in the feature branch (only that is
> needed for k8s work). Everything else should hit master first and then
> sync'ed to the branch.
> * We should have a deadline for the feature branch when we think
> appropriate (Say Newton-2 Milestone?)
> * We can define jobs that run only on feature branch
> * I'll assume that folks get promoted as they earn karma from just the
> feature group to the main group.
> * At some point (Newton-2) we take a go/no-go on k8s feature for the
> Newton release, if we say no-go, then the feature branch remains for
> on-going work while the master branch can be made release-ready.
>
> Worst case scenario, we nuke the feature branch as an experiment
> Best case scenario, we can choose either to make the feature branch
> into master OR figure out how to split the contents into another repo.
> We don't have to decide right now.
>
> Thanks,
> Dims
>

like this option which keeps you kinda detached to the kolla repo and
achieve the required bootstrapping, gating, reviewing code separately and
analyze overlap.

> On Mon, May 2, 2016 at 3:38 PM, Steven Dake (stdake) <std...@cisco.com>
wrote:
> > Yup but that didn't happen with kolla-mesos and I didn't catch it until
2
> > weeks after it was locked in stone.  At that point I asked for the ABI
to
> > be unified to which I got a "shrug" and no action.
> >
> > If it has been in one repo, everyone would have seen the multiple ABIs
and
> > rejected the patch in the first place.
> >
> > FWIW I am totally open to extending the ABI however is necessary to make
> > Kolla containers be the reference that other projects use for their
> > container deployment technology tooling.  In this case the ABI was
> > extended without consultation and without repair after the problem was
> > noticed.
> >
> > Regards
> > -steve
> >
> > On 5/2/16, 12:04 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
> >
> >>+1 to one set of containers for all. If kolla-k8s needs tweaks to the
> >>abi, the request should go to the kolla core team (involving everyone)
> >>and discuss why they are needed/reasonable. This should be done
> >>regardless of if there are 1or 2 repo's in the end.
> >>
> >>Thanks,
> >>Kevin
> >>
> >>From: Steven Dake (stdake) [std...@cisco.com]
> >>Sent: Monday, May 02, 2016 11:14 AM
> >>To: OpenStack Development Mailing List (not for usage questions)
> >>Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two
> >>
> >>I personally would like to see one set of defaults files for the default
> >>config and merging thereof. (the stuff in roles/*/defaults).
> >>
> >>There would be overlap there.
> >>
> >>A lot of the overlap involves things like reno, sphinx, documentation,
> >>gating, etc.
> >>
> >>During kolla-emsos, separate containers (IIRC) were made, separate start
> >>extension scripts were made, and to my dismay a completely different ABI
> >>was implemented.
> >>
> >>We need one ABI to the containers and that should be laid out in the
spec
> >>if it isn't already.
> >>
> >>Regards
> >>-steve
> >>
> >>
> >>On 5/2/16, 10:31 AM, "Ryan Hallisey" <rhall...@redhat.com> wrote:
> >>
> >>>Most of the code is not an overlap. We will preserve the ABI while
> >>>customizing the ansible config generation (if we do end up using it).
We
> >>>can use some of what's in kolla as a starting point.
> >>>
> >>>I'd say the code overlap is a bootstrapping point for the project.
> >>>
> >>>-Ryan
> >>>
> >>>- Original Message -
> >>>From: "Kevin M Fox" <kevin@pnnl.gov>
> >>>To: "OpenStack Development Mailing List (not for usage questions)"
> >>><openstack-dev@lists.openstack.org>
> >>>Sent: Monday, May 2, 2016 12:56:22 PM
> >>>Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two
> >>>
> >>>One thing we didn't ta

Re: [openstack-dev] [kolla][kubernetes] One repo vs two

[Swapnil Kulkarni]

On Mon, May 2, 2016 at 9:54 AM, Britt Houser (bhouser)
<bhou...@cisco.com> wrote:
> Although it seems I'm in the minority, I am in favor of unified repo.
>
> From: "Steven Dake (stdake)" <std...@cisco.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Sunday, May 1, 2016 at 5:03 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [kolla][kubernetes] One repo vs two
>
> Ryan had rightly pointed out that when we made the original proposal 9am
> morning we had asked folks if they wanted to participate in a separate
> repository.
>
> I don't think a separate repository is the correct approach based upon one
> off private conversations with folks at summit.  Many people from that list
> approached me and indicated they would like to see the work integrated in
> one repository as outlined in my vote proposal email.  The reasons I heard
> were:
>
> Better integration of the community
> Better integration of the code base
> Doesn't present an us vs them mentality that one could argue happened during
> kolla-mesos
> A second repository makes k8s a second class citizen deployment architecture
> without a voice in the full deployment methodology
> Two gating methods versus one
> No going back to a unified repository while preserving git history
>
> I favor of the separate repositories I heard
>
> It presents a unified workspace for kubernetes alone
> Packaging without ansible is simpler as the ansible directory need not be
> deleted
>
> There were other complaints but not many pros.  Unfortunately I failed to
> communicate these complaints to the core team prior to the vote, so now is
> the time for fixing that.
>
> I'll leave it open to the new folks that want to do the work if they want to
> work on an offshoot repository and open us up to the possible problems
> above.
>
> If you are on this list:
>
> Ryan Hallisey
> Britt Houser
>
> mark casey
>
> Steven Dake (delta-alpha-kilo-echo)
>
> Michael Schmidt
>
> Marian Schwarz
>
> Andrew Battye
>
> Kevin Fox (kfox)
>
> Sidharth Surana (ssurana)
>
>  Michal Rostecki (mrostecki)
>
>   Swapnil Kulkarni (coolsvap)
>
>   MD NADEEM (mail2nadeem92)
>
>   Vikram Hosakote (vhosakot)
>
>   Jeff Peeler (jpeeler)
>
>   Martin Andre (mandre)
>
>   Ian Main (Slower)
>
> Hui Kang (huikang)
>
> Serguei Bezverkhi (sbezverk)
>
> Alex Polvi (polvi)
>
> Rob Mason
>
> Alicja Kwasniewska
>
> sean mooney (sean-k-mooney)
>
> Keith Byrne (kbyrne)
>
> Zdenek Janda (xdeu)
>
> Brandon Jozsa (v1k0d3n)
>
> Rajath Agasthya (rajathagasthya)
> Jinay Vora
> Hui Kang
> Davanum Srinivas
>
>
>
> Please speak up if you are in favor of a separate repository or a unified
> repository.
>
> The core reviewers will still take responsibility for determining if we
> proceed on the action of implementing kubernetes in general.
>
> Thank you
> -steve
>
> __
> 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
>


I am in the favor of having two separate repos and evaluating the
merge/split option later.
Though in the longer run, I would recommend having a single repo with
multiple stable deployment tools(maybe too early to comment views but
yeah)

Swapnil

__
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][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Swapnil Kulkarni]

On Mon, May 2, 2016 at 10:08 AM, Vikram Hosakote (vhosakot)
<vhosa...@cisco.com> wrote:
> A separate repo will land us in the same spot as we had with kolla-mesos
> originally.  We had all kinds of variance in the implementation.
>
> I’m in favor of a single repo.
>
> +1 for the single repo.
>

I agree with you Vikram, but we should consider the bootstrapping
requirements for new deployment technologies and learn from our
failures with kolla-mesos.

At the same time, it will help us evaluate the deployment technologies
going ahead without distrupting the kolla repo which we can treat as a
repo with stable images & associated deployment tools.

> Regards,
> Vikram Hosakote
> IRC: vhosakot
>
> From: Vikram Hosakote <vhosa...@cisco.com>
> Date: Sunday, May 1, 2016 at 11:36 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
> kolla-kubernetes repository management proposal up for vote
>
> Please add me too to the list!
>
> Regards,
> Vikram Hosakote
> IRC: vhosakot
>
> From: Michał Jastrzębski <inc...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Saturday, April 30, 2016 at 9:58 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
> kolla-kubernetes repository management proposal up for vote
>
> Add me too please Steven.
>
> On 30 April 2016 at 09:50, Steven Dake (stdake) <std...@cisco.com> wrote:
>
> Fellow core reviewers,
>
> We had a fantastic turnout at our fishbowl kubernetes as an underlay for
> Kolla session.  The etherpad documents the folks interested and discussion
> at summit[1].
>
> This proposal is mostly based upon a combination of several discussions at
> open design meetings coupled with the kubernetes underlay discussion.
>
> The proposal (and what we are voting on) is as follows:
>
> Folks in the following list will be added to a kolla-k8s-core group.
>
>   This kolla-k8s-core group will be responsible for code reviews and code
> submissions to the kolla repository for the /kubernetes top level directory.
> Individuals in kolla-k8s-core that consistently approve (+2) or disapprove
> with a (-2) votes to TLD directories other then kubernetes will be handled
> on a case by case basis with several "training warnings" followed by removal
> of the kolla-k8s-core group.  The kolla-k8s-core group will be added as a
> subgroup of the kolla-core reviewer team, which means they in effect have
> all of the ACL access as the existing kolla repository.  I think it is
> better in this case to trust these individuals to the right thing and only
> approve changes for the kubernetes directory until proposed for the
> kolla-core reviewer group where they can gate changes to any part of the
> repository.
>
> Britt Houser
>
> mark casey
>
> Steven Dake (delta-alpha-kilo-echo)
>
> Michael Schmidt
>
> Marian Schwarz
>
> Andrew Battye
>
> Kevin Fox (kfox)
>
> Sidharth Surana (ssurana)
>
>   Michal Rostecki (mrostecki)
>
>Swapnil Kulkarni (coolsvap)
>
>MD NADEEM (mail2nadeem92)
>
>Vikram Hosakote (vhosakot)
>
>Jeff Peeler (jpeeler)
>
>Martin Andre (mandre)
>
>Ian Main (Slower)
>
> Hui Kang (huikang)
>
> Serguei Bezverkhi (sbezverk)
>
> Alex Polvi (polvi)
>
> Rob Mason
>
> Alicja Kwasniewska
>
> sean mooney (sean-k-mooney)
>
> Keith Byrne (kbyrne)
>
> Zdenek Janda (xdeu)
>
> Brandon Jozsa (v1k0d3n)
>
> Rajath Agasthya (rajathagasthya)
>
>
> If you already are in the kolla-core review team, you won't be added to the
> kolla-k8s-core team as you will already have the necessary ACLs to do the
> job.  If you feel you would like to join this initial bootstrapping process,
> please add your name to the etherpad in [1].
>
> After 8 weeks (July 15h), folks that have not been actively reviewing or
> committing code will be removed from the kolla-k8s-core group.  We will use
> the governance repository metrics for team size [2] which is either 30
> reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months
> (in this case 2 commits) to the repository.  Folks that don't meet the
> qualifications are still welcome to commit to the repository and contribute
> code or documentation but will lose approval rights on patches.
>
> The kubernetes codebase will be maintained in the
> http

Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Swapnil Kulkarni]

On Sat, Apr 30, 2016 at 8:20 PM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Fellow core reviewers,
>
> We had a fantastic turnout at our fishbowl kubernetes as an underlay for
> Kolla session.  The etherpad documents the folks interested and discussion
> at summit[1].
>
> This proposal is mostly based upon a combination of several discussions at
> open design meetings coupled with the kubernetes underlay discussion.
>
> The proposal (and what we are voting on) is as follows:
>
> Folks in the following list will be added to a kolla-k8s-core group.
>
>  This kolla-k8s-core group will be responsible for code reviews and code
> submissions to the kolla repository for the /kubernetes top level directory.
> Individuals in kolla-k8s-core that consistently approve (+2) or disapprove
> with a (-2) votes to TLD directories other then kubernetes will be handled
> on a case by case basis with several "training warnings" followed by removal
> of the kolla-k8s-core group.  The kolla-k8s-core group will be added as a
> subgroup of the kolla-core reviewer team, which means they in effect have
> all of the ACL access as the existing kolla repository.  I think it is
> better in this case to trust these individuals to the right thing and only
> approve changes for the kubernetes directory until proposed for the
> kolla-core reviewer group where they can gate changes to any part of the
> repository.
>
> Britt Houser
>
> mark casey
>
> Steven Dake (delta-alpha-kilo-echo)
>
> Michael Schmidt
>
> Marian Schwarz
>
> Andrew Battye
>
> Kevin Fox (kfox)
>
> Sidharth Surana (ssurana)
>
>  Michal Rostecki (mrostecki)
>
>   Swapnil Kulkarni (coolsvap)
>
>   MD NADEEM (mail2nadeem92)
>
>   Vikram Hosakote (vhosakot)
>
>   Jeff Peeler (jpeeler)
>
>   Martin Andre (mandre)
>
>   Ian Main (Slower)
>
> Hui Kang (huikang)
>
> Serguei Bezverkhi (sbezverk)
>
> Alex Polvi (polvi)
>
> Rob Mason
>
> Alicja Kwasniewska
>
> sean mooney (sean-k-mooney)
>
> Keith Byrne (kbyrne)
>
> Zdenek Janda (xdeu)
>
> Brandon Jozsa (v1k0d3n)
>
> Rajath Agasthya (rajathagasthya)
>
>
> If you already are in the kolla-core review team, you won't be added to the
> kolla-k8s-core team as you will already have the necessary ACLs to do the
> job.  If you feel you would like to join this initial bootstrapping process,
> please add your name to the etherpad in [1].
>
> After 8 weeks (July 15h), folks that have not been actively reviewing or
> committing code will be removed from the kolla-k8s-core group.  We will use
> the governance repository metrics for team size [2] which is either 30
> reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months
> (in this case 2 commits) to the repository.  Folks that don't meet the
> qualifications are still welcome to commit to the repository and contribute
> code or documentation but will lose approval rights on patches.
>
> The kubernetes codebase will be maintained in the
> https://github.com/openstack/kolla repository under the kubernees top level
> directory.  Contributors that become active in the kolla repository itself
> will be proposed over time to the kolla-core group.  Only core-kolla members
> will be permitted to participate in policy decisions and voting thereof, so
> there is some minimal extra responsibility involved in joining the
> kolla-core ACL team for those folks wanting to move into the kolla core team
> over time.  The goal will be to over time entirely remove the kolla-k8s-core
> team and make one core reviewer team in the kolla-core ACL.
>
> Members in the kolla-k8s-core group will have the ability to +2 or –2 any
> change to the main kolla repository via ACLs, however, I propose we trust
> these folks to only +2/-2 changes related to the kubernetes directory in the
> kolla repository and remove folks that consistently break this agreement.
> Initial errors as folks learn the system will be tolerated and commits
> reverted as makes sense.
>
> I feel we made a couple errors with the creation of Kolla-mesos that I feel
> needs correction.  Our first error the kolla-mesos-core team made a lack of
> a diversely affiliated team membership developing the code base.  The above
> list has significant diversity.  The second error is that the repository was
> split in the first place.  This resulted in a separate ABI to the containers
> being implemented which was a sore spot for me personally.  We did our best
> to build both sides of the bridge here, but this time I'd like the bridge
> between these two interests and set of individuals to be fully built before
> beginning.  As such, I'd ask the existing kolla-core team to trus

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

[Swapnil Kulkarni]

On Sat, Apr 23, 2016 at 5:38 AM, Steven Dake (stdake)  wrote:
> Fellow Core Reviewers,
>
> Since many of the engineers working on the kolla-mesos repository are moving
> on to other things[1], possibly including implementing Kubernetes as an
> underlay for OpenStack containers, I propose we move the kolla-mesos
> repository into the attic[2].  This will allow folks to focus on Ryan's
> effort[3] to use Kubernetes as an underlay for Kolla containers for folks
> that want a software based underlay rather than bare metal.  I understand
> Mirantis's position that Kubernetes may have some perceived "more mojo" and
> If we are to work on an underlay, it might as well be a fresh effort based
> upon the experience of the past two failures to develop a software underlay
> for OpenStack services.  We can come back to mesos once kubernetes is
> implemented with a fresh perspective on the problem.
>
> Please vote +1 to attic the repo, or –1 not to attic the repo.  I'll leave
> the voting open until everyone has voted, or for 1 week until April 29th,
> 2016.
>
> Regards
> -steve
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/093143.html
> [2] https://github.com/openstack-attic
> [3] https://review.openstack.org/#/c/304182/
>
> __
> 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
>


I am +1 on this.

__
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][vote] Just make Mitaka deploy Liberty within the Liberty branch

[Swapnil Kulkarni]

On Wed, Mar 30, 2016 at 9:03 AM, Michał Jastrzębski  wrote:
> I think that it goes without saying that I'm +1
>
> On 29 March 2016 at 22:27, Steven Dake (stdake)  wrote:
>> Dear cores,
>>
>> inc0 has been investigating our backport options for 1.1.0 and they look
>> bleak.  At this time we would have to backport heka because of changes in
>> Docker 1.10.z which are incompatible with the syslog dev file.  We had
>> originally spoken about just taking Mitaka and placing it in Liberty,
>> validating the defaults directory of Ansible, fixing the repo pointers,
>> fixing the source pointers, and modifying containers as necessary to make
>> that happen.
>>
>> I know this is vastly different then what we have discussed in the past
>> related to Liberty management, but beyond giving up entirely on Liberty
>> which is unacceptable to me, it seems like our only option.
>>
>> The good news is we will be able to leverage all of the testing we have done
>> with liberty and all of the testing we have done developing Mitaka, and have
>> a smooth stable backport experience for Mitaka and Liberty.
>>
>> Consider this proposal a +1 vote for me.  Our core team has 11 members,
>> which means we need 6 +1 votes in order for this new plan to pass.  Note I
>> see no other options, so abstaining or voting –1 is in essence recommending
>> abandonment of the Liberty branch.
>>
>> I'll leave voting open for 7 days until Tuesday April 5th unless there is a
>> majority before then.  If  there is a majority prior to the voting deadline,
>> I'll close voting early but leave discussion open for those that wish to
>> have it.
>>
>> We won't be having this happen again, as our Mitaka architecture is stable
>> and strong minus a few straggling bugs remaining.
>>
>> Regards
>> -steve
>>
>>
>> __
>> 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

+1

__
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][vote] Nominating Vikram Hosakot for Core Reviewer

[Swapnil Kulkarni]

On Tue, Mar 29, 2016 at 9:37 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> Consider this proposal a +1 in favor of Vikram joining the core reviewer
> team.  His reviews are outstanding.  If he doesn’t have anything useful to
> add to a review, he doesn't pile on the review with more –1s which are
> slightly disheartening to people.  Vikram has started a trend amongst the
> core reviewers of actually diagnosing gate failures in peoples patches as
> opposed to saying gate failed please fix.  He does this diagnosis in nearly
> every review I see, and if he is stumped  he says so.  His 30 days review
> stats place him in pole position and his 90 day review stats place him in
> second position.  Of critical notice is that Vikram is ever-present on IRC
> which in my professional experience is the #1 indicator of how well a core
> reviewer will perform long term.   Besides IRC and review requirements, we
> also have code requirements for core reviewers.  Vikram has implemented only
> 10 patches so far, butI feel he could amp this up if he had feature work to
> do.  At the moment we are in a holding pattern on master development because
> we need to fix Mitaka bugs.  That said Vikram is actively working on
> diagnosing root causes of people's bugs in the IRC channel pretty much 12-18
> hours a day so we can ship Mitaka in a working bug-free state.
>
> Our core team consists of 11 people.  Vikram requires at minimum 6 +1 votes,
> with no veto –2 votes within a 7 day voting window to end on April 7th.  If
> there is a veto vote prior to April 7th I will close voting.  If there is a
> unanimous vote prior to April 7th, I will make appropriate changes in
> gerrit.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla-group/30
> [2] http://stackalytics.com/report/contribution/kolla-group/90
>
> __
> 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
>

Big +1.

__
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] [vote] Managing bug backports to Mitaka branch

[Swapnil Kulkarni]

On Thu, Mar 24, 2016 at 12:10 AM, Steven Dake (stdake)  wrote:
> We had an emergency voting session on this proposal on IRC in our team
> meeting today and it passed as documented in the meeting minutes[1].  I was
> asked to have a typical vote and discussion on irc by one of the
> participants of the vote, so please feel free to discuss and vote again.  I
> will leave discussion and voting open until March 30th.  If the voting is
> unanimous prior to that time, I will close voting.  The original vote will
> stand unless there is a majority that oppose this process in this formal
> vote.  (formal votes > informal irc meeting votes).
>
> Thanks,
> -steve
>
> [1]
> http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-03-23-16.30.log.html
>
> look for timestamp 16:51:05
>
> From: Steven Dake 
> Reply-To: OpenStack Development Mailing List
> 
> Date: Tuesday, March 22, 2016 at 10:12 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [kolla] Managing bug backports to Mitaka branch
>
> Thierry (ttx in the irc log at [1]) proposed the standard way projects
> typically handle backports of newton fixes that should be fixed in an rc,
> while also maintaining the information in our rc2/rc3 trackers.
>
> Here is an example bug with the process applied:
> https://bugs.launchpad.net/kolla/+bug/1540234
>
> To apply this process, the following happens:
>
> Any individual may propose a newton bug for backport potential by specifying
> the tag 'rc-backport-potential" in the Newton 1 milestone.
> Core reviewers review the rc-backport-potential bugs.
>
> CR's review [3] on a daily basis for new rc backport candidates.
> If the core reviewer thinks the bug should be backported to stable/mitaka,
> (or belongs in the rc), they use the Target to series button, select mitaka,
> save.
>  copy the state of the bug, but set thte Mitaka milestone target to
> "mitaka-rc2".
> Finally they remove the rc-backport-potential tag from the bug, so it isn't
> re-reviwed.
>
> The purpose of this proposal is to do the following:
>
> Allow the core reviewer team to keep track of bugs needing attention for the
> release candidates in [2] by looking at [3].
> Allow master development to proceed un-impeded.
> Not single thread on any individual for backporting.
>
> I'd like further discussion on this proposal at our Wednesday meeting, so
> I've blocked off a 20 minute timebox for this topic.  I'd like wide
> agreement from the core reviewers to follow this best practice, or
> alternately lets come up with a plan b :)
>
> If your a core reviewer and won't be able to make our next meeting, please
> respond on this thread with your  thoughts.  Lets also not apply the process
> until the conclusion of the discussion at Wednesday's meeting.
>
>
> __
> 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
>

I was not able to attend the meeting yesterday. I am +1 on this.

__
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-dev] [Kolla] DocImpact in reviews

[Swapnil Kulkarni]

Hello,

I was triaging some of the bugs reported to Kolla and I found a couple
of bugs [1] [2] created due to incorrect usage of DocImpact[1] tag in
reviews. The DocImapct tag should only be used in case if you have
done some change which requires following two,

1) Update in some existing documentation
2) Add some new documentation

which are not addressed in the current changeset where you are adding
the DocImapct.


[1] https://wiki.openstack.org/wiki/Documentation/DocImpact
[2] https://bugs.launchpad.net/kolla/+bug/1553291
[3] https://bugs.launchpad.net/kolla/+bug/1553405

Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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][vote] Proposing Alicja Kwasniewska for core reviewer

[Swapnil Kulkarni]

On Fri, Mar 4, 2016 at 10:25 PM, Steven Dake (stdake)  wrote:
> Core Reviewers,
>
> Alicja has been instrumental in our work around jinja2 docker file creation,
> removing our symlink madness.  She has also been instrumental in actually
> getting Diagnostics implemented in a sanitary fashion.  She has also done a
> bunch of other work that folks in the community already know about that I
> won't repeat here.
>
> I had always hoped she would start reviewing so we could invite her to the
> core review team, and over the last several months she has reviewed quite a
> bit!  Her 90 day stats[1] place her at #9 with a solid ratio of 72%.  Her 30
> day stats[2] are even better and place her at #6 with an improving ratio of
> 67%.  She also just doesn't rubber stamp reviews or jump in reviews at the
> end; she sticks with them from beginning to end and finds real problems, not
> trivial things.  Finally Alicja is full time on Kolla as funded by her
> employer so she will be around for the long haul and always available.
>
> Please consider my proposal to be a +1 vote.
>
> To be approved for the core reviewer team, Alicja requires a majority vote
> of 6 total votes with no veto within the one week period beginning now and
> ending Friday March 11th.  If your on the fence, you can always abstain.  If
> the vote is unanimous before the voting ends, I will make appropriate
> changes to gerrit's acls.  If their is a veto vote, voting will close prior
> to March 11th.
>
> Regards,
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla-group/90
> [2] http://stackalytics.com/report/contribution/kolla-group/30
>
> __
> 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
>

+1

__
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][security] Obtaining the vulnerability:managed tag

[Swapnil Kulkarni]

On Tue, Mar 1, 2016 at 10:25 PM, Steven Dake (stdake)  wrote:
> Core reviewers,
>
> Please review this document:
> https://github.com/openstack/governance/blob/master/reference/tags/vulnerability_managed.rst
>
> It describes how vulnerability management is handled at a high level for
> Kolla.  When we are ready, I want the kolla delivery repos vulnerabilities
> to be managed by the VMT team.  By doing this, we standardize with other
> OpenStack processes for handling security vulnerabilities.
>
> The first step is to form a kolla-coresec team, and create a separate
> kolla-coresec tracker.  I have already created the tracker for kolla-coresec
> and the kolla-coresec team in launchpad:
>
> https://launchpad.net/~kolla-coresec
>
> https://launchpad.net/kolla-coresec
>
> I have a history of security expertise, and the PTL needs to be on the team
> as an escalation point as described in the VMT tagging document above.  I
> also need 2-3 more volunteers to join the team.  You can read the
> requirements of the job duties in the vulnerability:managed tag.
>
> If your interested in joining the VMT team, please respond on this thread.
> If there are more then 4 individuals interested in joining this team, I will
> form the team from the most active members based upon liberty + mitaka
> commits, reviews, and PDE spent.
>
> Regards
> -steve
>
>
> __
> 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
>

I am interested in security. I would .like to be a part of it.

~coolsvap

__
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] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc

[Swapnil Kulkarni]

On Tue, Jan 19, 2016 at 1:56 PM, Steven Dake (stdake) 
wrote:

> Hi folks,
>
> I would like to propose Lei Zhang for our core reviewer team.  Count this
> proposal as a +1 vote from me.  Lei has done a fantastic job in his reviews
> over the last 6 weeks and has managed to produce some really nice
> implementation work along the way.  He participates in IRC regularly, and
> has a commitment from his management team at his employer to work full time
> 100% committed to Kolla for the foreseeable future (although things can
> always change in the future :)
>
> Please vote +1 if you approve of Lei for core reviewer, or –1 if wish to
> veto his nomination.  Remember just one –1 vote is a complete veto, so if
> your on the fence, another option is to abstain from voting.
>
> I would like to change from our 3 votes required, as our core team has
> grown, to requiring a simple majority of core reviewers with no veto
> votes.  As we have 9 core reviewers, this means Lei requires 4 more  +1
> votes with no veto vote in the voting window to join the core reviewer team.
>
> I will leave the voting open for 1 week as is the case with our other core
> reviewer nominations until January 26th.  If the vote is unanimous or there
> is a veto vote before January 26th I will close voting.  I'll make
> appropriate changes to gerrit permissions if Lei is voted into the core
> reviewer team.
>
> Thank you for your time in evaluating Lei for the core review team.
>
> Regards
> -steve
>
>
> __
> 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
>
>
+1 :)
__
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] Is latest PyCharm license still available?

[Swapnil Kulkarni]

The PyCharm licences are available for OpenStack developers, please send me
your lauchpad-id off-list, I will help you with the updated link. Thanks

Best Regards,
Swapnil Kulkarni
irc : coolsvap


On Tue, Nov 17, 2015 at 10:06 PM, OpenStack Mailing List Archive <
cor...@gmail.com> wrote:

> Link: https://openstack.nimeyo.com/65517/?show=65517#q65517
> From: vanderwl <vande...@us.ibm.com>
>
> I tried the link above, but got: "Invitation code is not valid." from the
> jetbrains website.
>
> Has something in getting the license steps changed again?
>
> __
> 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] Integrating kollacli as python-kollaclient

[Swapnil Kulkarni]

On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake) 
wrote:

> Hello Folks,
>
>
> Oracle has developed a CLI tool for managing OpenStack Kolla clusters.
> Several months ago at our midcycle, the topic was brought up an I suggested
> to go ahead and get started on the work.  We clearly didn't spend enough
> time discussing how it should be integrated into the code base or developed
> or even what its features should be, and that is my error.
>
>
> What ended up happening is sort of a code dump, which is not ideal, but I
> can only work so many 20 hour days ;)  I didn't believe our community had
> the bandwidth to deal with integrating a CLI directly into the tree while
> we were focused on our major objective of implementing Ansible deployment
> of OpenStack in Docker containers.  Possibly the wrong call, but it is what
> it is and it is my error, not Oracles.
>
>
> I think user experience will of the one of the major milestones for Kolla
in Mitaka, e.g. user facing documentation, operator integration etc. a CLI
would be helpful in that.

> The code can be cloned from:
>
> git clone git://oss.oracle.com/git/openstack-kollacli.git
>
>
> The code as is is very high quality but will likely need to go through
> alot of refactoring to ReST-ify it.  There are two major authors of the
> code, Borne Mace and Steve Noyes.
>
>
> I'd like a majority vote from the core team as to whether we should add
> this repository to our list of governed repositories in the OpenStack Kolla
> governance repository here:
>
>
>
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>
>
> Consider this email a +1 vote from me.
>

+1 from me


> A completely separate email thread and decision will be made by the
> community about core team membership changes to handle maintenance of the
> code.  Assuming this code is voted into Kolla's governance, I plan to
> propose Borne as a core reviewer, which will be open to core team vote as a
> separate act with our 3 +1 votes no vetos within 1 week period.  We will
> address that assuming a majority vote of the code merge wins.  Steve can
> follow the normal processes for joining the core team if he wishes
> (reviewing patches) - clearly his code contributions are there.  Borne
> already does some reviews, and although he isn't a top reviewer, he does
> have some contribution in this area making it into the top 10 for the
> Liberty cycle.
>
>
>

> Kolla CLI Features:
>
>- dynamic ansible inventory manipulation via the host, group and
>service commands
>- ssh key push via the host setup command
>- ssh key validation via the host check command
>- ansible deployment via the deploy command
>- property viewing and modification with the property list, set and
>clear commands
>- cleanup of docker containers on a single, multiple or all hosts via
>the host destroy command
>- debug data collection via the dump command
>- configuration of openstack passwords via the password command
>- Lines of python = 2700
>- Lines of  test case code =  1800
>- ~ 200 commits
>
>
>
> __
> 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] proposing Michal Jastrzebski (inc0) for core reviewer

[Swapnil Kulkarni]

On Wed, Sep 30, 2015 at 3:50 AM, Steven Dake (stdake) 
wrote:

> Hi folks,
>
> I am proposing Michal for core reviewer.  Consider my proposal as a +1
> vote.  Michal has done a fantastic job with rsyslog, has done a nice job
> overall contributing to the project for the last cycle, and has really
> improved his review quality and participation over the last several months.
>
> Our process requires 3 +1 votes, with no veto (-1) votes.  If your
> uncertain, it is best to abstain :)  I will leave the voting open for 1
> week until Tuesday October 6th or until there is a unanimous decision or a
>  veto.
>

+1 :)

>
> Regards
> -steve
>
> __
> 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] new yaml format for all.yml, need feedback

[Swapnil Kulkarni]

On Wed, Sep 30, 2015 at 11:24 PM, Jeff Peeler  wrote:

> The patch I just submitted[1] modifies the syntax of all.yml to use
> dictionaries, which changes how variables are referenced. The key
> point being in globals.yml, the overriding of a variable will change
> from simply specifying the variable to using the dictionary value:
>
> old:
> api_interface: 'eth0'
>
> new:
> network:
> api_interface: 'eth0'
>
> This looks good.


> Preliminary feedback on IRC sounded positive, so I'll go ahead and
> work on finishing the review immediately assuming that we'll go
> forward. Please ping me if you hate this change so that I can stop the
> work.
>
> [1] https://review.openstack.org/#/c/229535/
>
> __
> 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] Followup to review in gerrit relating to RHOS + RDO types

[Swapnil Kulkarni]

On Mon, Sep 14, 2015 at 5:14 PM, Sam Yaple  wrote:

>
> On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke 
> wrote:
>
>>
>>
>> On 13/09/15 18:34, Steven Dake (stdake) wrote:
>>
>>> Response inline.
>>>
>>> From: Sam Yaple >
>>> Reply-To: "s...@yaple.net" > s...@yaple.net>>
>>> Date: Sunday, September 13, 2015 at 1:35 AM
>>> To: Steven Dake >
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>> openstack-dev@lists.openstack.org>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to RHOS + RDO
>>> types
>>>
>>> On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake) >> > wrote:
>>> Response inline.
>>>
>>> From: Sam Yaple >
>>> Reply-To: "s...@yaple.net" > s...@yaple.net>>
>>> Date: Saturday, September 12, 2015 at 11:34 PM
>>> To: Steven Dake >
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>> openstack-dev@lists.openstack.org>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to RHOS + RDO
>>> types
>>>
>>>
>>>
>>> Sam Yaple
>>>
>>> On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake) >> > wrote:
>>>
>>>
>>> From: Sam Yaple >
>>> Reply-To: "s...@yaple.net" > s...@yaple.net>>
>>> Date: Saturday, September 12, 2015 at 11:01 PM
>>> To: Steven Dake >
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>> openstack-dev@lists.openstack.org>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to RHOS + RDO
>>> types
>>>
>>>
>>> On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake) >> > wrote:
>>> Hey folks,
>>>
>>> Sam had asked a reasonable set of questions regarding a patchset:
>>> https://review.openstack.org/#/c/222893/
>>>
>>> The purpose of the patchset is to enable both RDO and RHOS as binary
>>> choices on RHEL platforms.  I suspect over time, from-source deployments
>>> have the potential to become the norm, but the business logistics of such a
>>> change are going to take some significant time to sort out.
>>>
>>> Red Hat has two distros of OpenStack neither of which are from source.
>>> One is free called RDO and the other is paid called RHOS.  In order to
>>> obtain support for RHEL VMs running in an OpenStack cloud, you must be
>>> running on RHOS RPM binaries.  You must also be running on RHEL.  It
>>> remains to be seen whether Red Hat will actively support Kolla deployments
>>> with a RHEL+RHOS set of packaging in containers, but my hunch says they
>>> will.  It is in Kolla’s best interest to implement this model and not make
>>> it hard on Operators since many of them do indeed want Red Hat’s support
>>> structure for their OpenStack deployments.
>>>
>>> Now to Sam’s questions:
>>> "Where does 'binary' fit in if we have 'rdo' and 'rhos'? How many more
>>> do we add? What's our policy on adding a new type?”
>>>
>>> I’m not immediately clear on how binary fits in.  We could make binary
>>> synonymous with the community supported version (RDO) while still
>>> implementing the binary RHOS version.  Note Kolla does not “support” any
>>> distribution or deployment of OpenStack – Operators will have to look to
>>> their vendors for support.
>>>
>>> If everything between centos+rdo and rhel+rhos is mostly the same then I
>>> would think it would make more sense to just use the base ('rhel' in this
>>> case) to branch of any differences in the templates. This would also allow
>>> for the least amount of change and most generic implementation of this
>>> vendor specific packaging. This would also match what we do with
>>> oraclelinux, we do not have a special type for that and any specifics would
>>> be handled by an if statement around 'oraclelinux' and not some special
>>> type.
>>>
>>> I think what you are proposing is RHEL + RHOS and CENTOS + RDO.  RDO
>>> also runs on RHEL.  I want to enable Red Hat customers to make a choice to
>>> have a supported  operating system but not a supported Cloud environment.
>>> The answer here is RHEL + RDO.  This leads to full support down the road if
>>> the Operator chooses to pay Red Hat for it by an easy transition to RHOS.
>>>
>>> I am against including vendor specific things like RHOS in Kolla
>>> outright like you are purposing. Suppose another vendor comes along with a
>>> new base and new packages. They are willing to maintain it, but its
>>> something that no one but their customers with their licensing can use.