Re: [openstack-dev] [openstack-infra] How to take over a project?

[Sangho Shin]

Hello, Ian 

I am trying to add a new stable branch in the networking-onos, following the 
page you suggested.

Create stable/* Branch¶ 

For OpenStack projects this should be performed by the OpenStack Release 
Management Team at the Release Branch Point. If you are managing branches for 
your project you may have permission to do this yourself.

Go to https://review.openstack.org/  and sign in
Select ‘Admin’, ‘Projects’, then the project
Select ‘Branches’
Enter stable/ in the ‘Branch Name’ field, and HEAD as the ‘Initial 
Revision’, then press ‘Create Branch’. Alternatively, you may run git branch 
stable/  && git push gerrit stable/

However, after I login, I cannot see the ‘Admin’ and also I cannot create a new 
branch. Do I need an additional authority for it?
BTW, I am a member of networking-onos-core team, as you know.

Thank you,

Sangho


 

> On 18 Apr 2018, at 9:00 AM, Sangho Shin  wrote:
> 
> Ian and Gary,
> 
> Thank you so much for your answer.
> I will try what you suggested.
> 
> Thank you,
> 
> Sangho
> 
>> On 17 Apr 2018, at 7:47 PM, Gary Kotton > > wrote:
>> 
>> Hi,
>> You either need one of the ono core team or the neutron release team to add 
>> you. FYI - https://review.openstack.org/#/admin/groups/1001,members 
>> 
>> Thanks
>> Gary
>>  
>> From: Sangho Shin > >
>> Reply-To: OpenStack List > >
>> Date: Tuesday, April 17, 2018 at 5:01 AM
>> To: OpenStack List > >
>> Subject: [openstack-dev] [openstack-infra] How to take over a project?
>>  
>> Dear OpenStack Infra team,  <>
>>  
>> I would like to know how to take over an OpenStack project.
>> I am a committer of the networking-onos project 
>> (https://github.com/openstack/networking-onos 
>> ),
>>  and I would like to take over the project. 
>> The current maintainer (cc’d) has already agreed with that.
>>  
>> Please let me know the process to take over (or change the maintainer of) 
>> the project.
>>  
>> BTW, it looks like even the current maintainer cannot create a new branch of 
>> the codes. How can we get the authority to create a new branch?
>>  
>> Thank you,
>>  
>> Sangho
>> __
>> 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] [openstack-infra] How to take over a project?

[Sangho Shin]

Frank,

Thank  you for your support. I will make it work as quickly as possible and add 
many features like odl.
I will let you know if I need your help.

Sangho


> On 18 Apr 2018, at 9:29 AM, Frank Wang  wrote:
> 
> Hi Sangho,
> 
> I'm excited to see the networking-onos project moving forward again. that's 
> very cool, please let me know if there are some features need to be done.
> Hope you can get rid of this problem quickly
> 
> Thanks,
> Frank.
> 
> At 2018-04-18 08:00:58, "Sangho Shin"  wrote:
> Ian and Gary,
> 
> Thank you so much for your answer.
> I will try what you suggested.
> 
> Thank you,
> 
> Sangho
> 
>> On 17 Apr 2018, at 7:47 PM, Gary Kotton > > wrote:
>> 
>> Hi,
>> You either need one of the ono core team or the neutron release team to add 
>> you. FYI - https://review.openstack.org/#/admin/groups/1001,members 
>> 
>> Thanks
>> Gary
>>  
>> From: Sangho Shin > >
>> Reply-To: OpenStack List > >
>> Date: Tuesday, April 17, 2018 at 5:01 AM
>> To: OpenStack List > >
>> Subject: [openstack-dev] [openstack-infra] How to take over a project?
>>  
>> Dear OpenStack Infra team,  <>
>>  
>> I would like to know how to take over an OpenStack project.
>> I am a committer of the networking-onos project 
>> (https://github.com/openstack/networking-onos 
>> ),
>>  and I would like to take over the project. 
>> The current maintainer (cc’d) has already agreed with that.
>>  
>> Please let me know the process to take over (or change the maintainer of) 
>> the project.
>>  
>> BTW, it looks like even the current maintainer cannot create a new branch of 
>> the codes. How can we get the authority to create a new branch?
>>  
>> Thank you,
>>  
>> Sangho
>> __
>> 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][vote]Retire kolla-kubernetes project

[Chan Chason]

+1

在 2018年4月18日，上午9:51，Jeffrey Zhang 
> 写道：

Since many of the contributors in the kolla-kubernetes project are moved to 
other things. And there is no active contributor for months.  On the other 
hand, there is another comparable project, openstack-helm, in the community.  
For less confusion and disruptive community resource, I propose to retire the 
kolla-kubernetes project.

More discussion about this you can check the mail[0] and patch[1]

please vote +1 to retire the repo, or -1 not to retire the repo. The vote will 
be open until everyone has voted, or for 1 week until April 25th, 2018.

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
[1] https://review.openstack.org/552531

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

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

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

[楊睿豪]

+1

從我的 iPhone 傳送

> Richard Wellum  於 2018年4月18日 上午10:10 寫道：
> 
> +1
> 
>> On Tue, Apr 17, 2018 at 9:52 PM Jeffrey Zhang  
>> wrote:
>> Since many of the contributors in the kolla-kubernetes project are moved to 
>> other things. And there is no active contributor for months.  On the other 
>> hand, there is another comparable project, openstack-helm, in the community. 
>>  For less confusion and disruptive community resource, I propose to retire 
>> the kolla-kubernetes project.
>> 
>> More discussion about this you can check the mail[0] and patch[1]
>> 
>> please vote +1 to retire the repo, or -1 not to retire the repo. The vote 
>> will be open until everyone has voted, or for 1 week until April 25th, 2018.
>> 
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
>> [1] https://review.openstack.org/552531
>> 
>> -- 
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

[Jeffrey Zhang]

Recently, one of networking-odl package breaks kolla's gate[0]. The direct
issue is ceilometer is added in networking-odl's requirements.txt file[1]

Then when install network-odl with upper-contraints.txt file, it will raise
error like

$ pip install -c
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
./networking-odl
...
collecting networking-bgpvpn>=8.0.0 (from networking-odl==12.0.1.dev54)
  Downloading
http://pypi.doubanio.com/packages/5a/e5/995be0d53d472f739a7a0bb6c9d9fecbc4936148651aaf56d39f3b65b1f1/networking_bgpvpn-8.0.0-py2-none-any.whl
(172kB)
100% || 174kB 12.0MB/s
Collecting ceilometer (from networking-odl==12.0.1.dev54)
  Could not find a version that satisfies the requirement ceilometer (from
networking-odl==12.0.1.dev54) (from versions: )
No matching distribution found for ceilometer (from
networking-odl==12.0.1.dev54)


But if you just install the networking-odl's requirements.txt file, it works


$ pip install -c
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
-r ./networking-odl/requirements.txt
...
Obtaining ceilometer from git+
https://git.openstack.org/openstack/ceilometer@master#egg=ceilometer (from
-r networking-odl/requirements.txt (line 21))
  Cloning https://git.openstack.org/openstack/ceilometer (to revision
master) to /home/jeffrey/.dotfiles/virtualenvs/test/src/ceilometer
...


Is this expected? and how could we fix this?


[0] https://bugs.launchpad.net/kolla/+bug/1764621
[1]
https://github.com/openstack/networking-odl/blob/master/requirements.txt#L21

-
​​
-
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

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

[Richard Wellum]

+1

On Tue, Apr 17, 2018 at 9:52 PM Jeffrey Zhang 
wrote:

> Since many of the contributors in the kolla-kubernetes project are moved
> to other things. And there is no active contributor for months.  On the
> other hand, there is another comparable project, openstack-helm, in the
> community.  For less confusion and disruptive community resource, I propose
> to retire the kolla-kubernetes project.
>
> More discussion about this you can check the mail[0] and patch[1]
>
> please vote +1 to retire the repo, or -1 not to retire the repo. The vote
> will be open until everyone has voted, or for 1 week until April 25th, 2018.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
> [1] https://review.openstack.org/552531
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] The Weekly Owl - 17th Edition

[Wesley Hayutin]

On Tue, Apr 17, 2018 at 9:44 PM Emilien Macchi  wrote:

> Note: this is the seventeeth edition of a weekly update of what happens in
> TripleO.
> The goal is to provide a short reading (less than 5 minutes) to learn
> where we are and what we're doing.
> Any contributions and feedback are welcome.
> Link to the previous version:
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129255.html
>
> +-+
> | General announcements |
> +-+
>
> +--> Rocky milestone 1 will be released this week (probably tomorrow)!
> +--> (reminder) if you're looking at reproducing a CI job, checkout:
> https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html
>
> +--+
> | Continuous Integration |
> +--+
>
> +--> Ruck is quiquell and Rover is panda. Please let them know any new CI
> issue.
> +--> Master promotion is 1 day, Queens is 2 days, Pike is 4 days and Ocata
> is 5 days.
> +--> Efforts around libvirt based multinode reproducer, see
> https://trello.com/c/JEGLSVh6/323-reproduce-ci-jobs-with-libvirt
> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
> https://goo.gl/D4WuBP
>

So, just to add some context.  We would like to be able to setup libvirt
guests in the same way nodepool nodes are setup to allow the ci team and
others to reexecute upstream ci jobs on libvirt using the exact workflow
that upstream jobs take.

A reminder the current reproduce scripts are documented here [1].  We plan
on updating the current doc with our libvirt work when it is ready.
 Thanks all

[1] http://tripleo.org/contributor/reproduce-ci.html


>
>
> +-+
> | Upgrades |
> +-+
>
> +--> Progress on FFU CLI in tripleoclient, need reviews.
> +--> Work for containerized undercloud upgrades has been merged. Testing
> will make progress after rocky-m1 (with new tags).
> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
>
> +---+
> | Containers |
> +---+
>
> +--> Still working on UX problems
> +--> Still working on container workflow, good progress last week where
> container prepare isn't needed. Now working on container updates.
> +--> Investigating how to bootstrap Docker + Registry before deploying
> containers
> +--> Progress on routed networks support
> +--> More: https://etherpad.openstack.org/p/tripleo-containers-sq
> uad-status
>
> +--+
> | config-download |
> +--+
>
> +--> Moving to config-download by default is coming very soon (once Ceph
> patches land).
> +--> Ceph was migrated and all patches are going to merge this week.
> +--> octavia/skydive migration is wip.
> +--> Improving deploy-steps-tasks.j2 to improve playbook readability and
> memory consumption
> +--> UI work is work in progress.
> +--> More: https://etherpad.openstack.org/p/tripleo-config-downlo
> ad-squad-status
>
> +--+
> | Integration |
> +--+
>
> +--> No updates.
> +--> More: https://etherpad.openstack.org/p/tripleo-integration-s
> quad-status
>
> +-+
> | UI/CLI |
> +-+
>
> +--> Efforts on config-download integration
> +--> Added type to ansible-playbook messages (feedback needed)
> +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status
>
> +---+
> | Validations |
> +---+
>
> +--> No updates.
> +--> More: https://etherpad.openstack.org/p/tripleo-validations-s
> quad-status
>
> +---+
> | Networking |
> +---+
>
> +--> No updates this week.
> +--> More: https://etherpad.openstack.org/p/tripleo-networking-sq
> uad-status
>
> +--+
> | Workflows |
> +--+
>
> +--> Need reviews, see etherpad.
> +--> Working on workflows v2
> +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status
>
> +---+
> | Security |
> +---+
>
> +--> Tomorrow's meeting is about Storyboard migration and Secret
> management.
> +--> More: https://etherpad.openstack.org/p/tripleo-security-squad
>
> ++
> | Owl fact  |
> ++
>
> Did you know owls were watching you while working on TripleO?
> Check this out:
> https://www.reddit.com/r/pics/comments/8cz8v0/owls_born_outside_of_office_window_wont_stop/
> (Thanks Wes for the link)
>
>
> Thanks all for reading and stay tuned!
> --
> Your fellow reporter, Emilien Macchi
> __
> 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

[openstack-dev] [kolla][vote]Retire kolla-kubernetes project

[Jeffrey Zhang]

Since many of the contributors in the kolla-kubernetes project are moved to
other things. And there is no active contributor for months.  On the other
hand, there is another comparable project, openstack-helm, in the
community.  For less confusion and disruptive community resource, I propose
to retire the kolla-kubernetes project.

More discussion about this you can check the mail[0] and patch[1]

please vote +1 to retire the repo, or -1 not to retire the repo. The vote
will be open until everyone has voted, or for 1 week until April 25th, 2018.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
[1] https://review.openstack.org/552531

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

Re: [openstack-dev] [stable][trove] keep trove-stable-maint members up-to-date

[赵超]

Matt,

Thanks for the explanation. Currently we don't have much participation in
the Trove project(so much less resources for the stable branches), from
time to time some people would ask or submit patches to the stable
branches, I think it would be sufficient to ask the stable-maint-core team
for help after the trove team have agreed on accepting them.

Thanks for approving the stable branch patches of trove and python-trove,
we also have some in the trove-dashboard.

Some check and gate jobs of python-troveclient and trove-dashboard in the
stable branches do work properly, so some patches couldn't get merged, I'll
try to find ways to fix them.


On Wed, Apr 18, 2018 at 12:18 AM, Matt Riedemann 
wrote:

> On 4/16/2018 3:04 AM, 赵超 wrote:
>
>>
>> There are some patches to stable branches to the different trove repos,
>> and they are always progressing slowly ,because none of the current trove
>> team core members are in the trove-stable-maint. I tried to contact with
>> the previous PTLs about expanding the 'trove-stable-maint' group and keep
>> the group up-to-date, however got no response yet.
>>
>> I noticed that 'stable-maint-core' is always included in the individual
>> project -stable-maint group, could the core stable team help to update the
>> 'trove-stable-maint' group (adding me to it could be sufficient by now)?
>>
>
> I've gone through the stable branch proposed changes for
> python-troveclient and trove.
>
> The reason the core team from a project isn't automatically core on the
> stable branches for that project is because the review criteria and what's
> appropriate for stable branches is different from changes on the master
> branch. The details are in the stable branch guide [1]. Until it becomes
> clear that there are people that are reviewing stable branch patches and
> understand the rules, they don't get added to the core team for stable.
>
> Until then, you can make review requests for stable patches in the ML like
> you have here, or in the #openstack-stable freenode IRC channel.
>
> I think over time once the stable-maint-core team can identify some people
> that have done a good job of doing early reviews and +1 (and -1
> inappropriate changes) then they can be added to the stable branch core
> team for the project.
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>
> --
>
> Thanks,
>
> 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
>



-- 
To be free as in freedom.
__
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] [tripleo] The Weekly Owl - 17th Edition

[Emilien Macchi]

Note: this is the seventeeth edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129255.html

+-+
| General announcements |
+-+

+--> Rocky milestone 1 will be released this week (probably tomorrow)!
+--> (reminder) if you're looking at reproducing a CI job, checkout:
https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html

+--+
| Continuous Integration |
+--+

+--> Ruck is quiquell and Rover is panda. Please let them know any new CI
issue.
+--> Master promotion is 1 day, Queens is 2 days, Pike is 4 days and Ocata
is 5 days.
+--> Efforts around libvirt based multinode reproducer, see
https://trello.com/c/JEGLSVh6/323-reproduce-ci-jobs-with-libvirt
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> Progress on FFU CLI in tripleoclient, need reviews.
+--> Work for containerized undercloud upgrades has been merged. Testing
will make progress after rocky-m1 (with new tags).
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Still working on UX problems
+--> Still working on container workflow, good progress last week where
container prepare isn't needed. Now working on container updates.
+--> Investigating how to bootstrap Docker + Registry before deploying
containers
+--> Progress on routed networks support
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> Moving to config-download by default is coming very soon (once Ceph
patches land).
+--> Ceph was migrated and all patches are going to merge this week.
+--> octavia/skydive migration is wip.
+--> Improving deploy-steps-tasks.j2 to improve playbook readability and
memory consumption
+--> UI work is work in progress.
+--> More: https://etherpad.openstack.org/p/tripleo-config-downlo
ad-squad-status

+--+
| Integration |
+--+

+--> No updates.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Efforts on config-download integration
+--> Added type to ansible-playbook messages (feedback needed)
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> No updates.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> Need reviews, see etherpad.
+--> Working on workflows v2
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> Tomorrow's meeting is about Storyboard migration and Secret management.
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact  |
++

Did you know owls were watching you while working on TripleO?
Check this out:
https://www.reddit.com/r/pics/comments/8cz8v0/owls_born_outside_of_office_window_wont_stop/
(Thanks Wes for the link)


Thanks all for reading and stay tuned!
--
Your fellow reporter, Emilien Macchi
__
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] [openstack-infra] How to take over a project?

[Frank Wang]

Hi Sangho,

I'm excited to see the networking-onos project moving forward again. that's 
very cool, please let me know if there are some features need to be done.
Hope you can get rid of this problem quickly

Thanks,
Frank.



At 2018-04-18 08:00:58, "Sangho Shin"  wrote:
Ian and Gary,


Thank you so much for your answer.
I will try what you suggested.


Thank you,


Sangho


On 17 Apr 2018, at 7:47 PM, Gary Kotton  wrote:


Hi,
You either need one of the ono core team or the neutron release team to add 
you. FYI - https://review.openstack.org/#/admin/groups/1001,members
Thanks
Gary
 
From: Sangho Shin 
Reply-To: OpenStack List 
Date: Tuesday, April 17, 2018 at 5:01 AM
To: OpenStack List 
Subject: [openstack-dev] [openstack-infra] How to take over a project?
 
Dear OpenStack Infra team, 
 
I would like to know how to take over an OpenStack project.
I am a committer of the networking-onos project 
(https://github.com/openstack/networking-onos), and I would like to take over 
the project. 
The current maintainer (cc’d) has already agreed with that.
 
Please let me know the process to take over (or change the maintainer of) the 
project.
 
BTW, it looks like even the current maintainer cannot create a new branch of 
the codes. How can we get the authority to create a new branch?
 
Thank you,
 
Sangho
__
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] [openstack-infra] How to take over a project?

[Sangho Shin]

Ian and Gary,

Thank you so much for your answer.
I will try what you suggested.

Thank you,

Sangho

> On 17 Apr 2018, at 7:47 PM, Gary Kotton  wrote:
> 
> Hi,
> You either need one of the ono core team or the neutron release team to add 
> you. FYI - https://review.openstack.org/#/admin/groups/1001,members 
> 
> Thanks
> Gary
>  
> From: Sangho Shin 
> Reply-To: OpenStack List 
> Date: Tuesday, April 17, 2018 at 5:01 AM
> To: OpenStack List 
> Subject: [openstack-dev] [openstack-infra] How to take over a project?
>  
> Dear OpenStack Infra team,  <>
>  
> I would like to know how to take over an OpenStack project.
> I am a committer of the networking-onos project 
> (https://github.com/openstack/networking-onos 
> ),
>  and I would like to take over the project. 
> The current maintainer (cc’d) has already agreed with that.
>  
> Please let me know the process to take over (or change the maintainer of) the 
> project.
>  
> BTW, it looks like even the current maintainer cannot create a new branch of 
> the codes. How can we get the authority to create a new branch?
>  
> Thank you,
>  
> Sangho
> __
> 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] [All] [Election] End TC Nominations & Begin Campaigning Period

[Kendall Nelson]

 Hello All,

The TC Nomination period is now over. The official candidate list is
available on the election website[0].

Now begins the campaigning period where candidates and
electorate may debate their statements.

Polling will start 2018-04-23T23:45.

Thank you,

[0] http://governance.openstack.org/election/#rocky-tc-candidates
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[melanie witt]

On Tue, 17 Apr 2018 06:40:35 -0700, Dan Smith wrote:

I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = True in tempest.conf before we add the
z/VM driver blueprint back into a runway in the future.


Agreed. I also want to see the CI reporting cleaned up so that it's
readable and consistent. Yesterday I pointed out some issues with the
fact that the actual config files being used are not the ones being
uploaded. There are also duplicate (but not actually identical) logs
from all services being uploaded, including things like a full compute
log from starting with the libvirt driver.


Yes, we definitely need to see all of these issues fixed.


I'm also pretty troubled by the total lack of support for the metadata
service. I know it's technically optional on our matrix, but it's a
pretty important feature for a lot of scenarios, and it's also a
dependency for other features that we'd like to have wider support for
(like attached device metadata).

Going back to the spec, I see very little detail on some of the things
raised here, and very (very) little review back when it was first
approved. I'd also like to see more detail be added to the spec about
all of these things, especially around required special changes like
this extra AE agent.


Agreed, can someone from the z/VM team please propose an update to the 
driver spec to document these details?


Thanks,
-melanie











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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[melanie witt]

On Tue, 17 Apr 2018 16:58:22 +0800, Chen Ch Ji wrote:
For the question on AE documentation, it's open source in [1] and the 
documentation for how to build and use is [2]
once our code is upstream, there are a set of documentation change which 
will cover this image build process by

adding some links to there [3]


Thanks, that is good info.

You are right, we need image to have our Active Engine, I think 
different arch and platform might have their unique
requirements and our solution our Active Engine is very like to 
cloud-init so no harm to add it from user's perspective
I think later we can upload image to some place so anyone is able to 
consume it as test image if they like

because different arch's image (e.g x86 and s390x) can't be shared anyway.

For the config drive format you mentioned, actually, as previous 
explanation and discussion witho Michael and Dan,
We found the iso9660 can be used (previously we made a bad assumption) 
and we already changed the patch in [4],
so it's exactly same to other virt drivers you mentioned , we don't need 
special format and iso9660 works perfect for our driver


That's good news, I'm glad that got resolved.

It make sense to me we are temply moved out from runway, I suppose we 
can adjust the CI to enable the run_ssh = true
with config drive functionalities very soon and we will apply for review 
after that with the test result requested in our CI log.


Okay, sounds good. Since you expect to be up and running with 
[validation]run_validation = True soon, I'm going to move the z/VM 
driver blueprint back to the front of the queue and put the next 
blueprint in line into the runway.


Then, when the next blueprint end date arrives (currently 2018-04-30), 
if the z/VM CI is ready with cleaned up, human readable log files and is 
running with run_ssh = True with the test_server_basic_ops test to 
verify config drive operation, we will add the z/VM driver blueprint 
back to a runway for dedicated review.


Let us know when the z/VM CI is ready, in case other runway reviews are 
completed early. If other runway reviews complete early, a runway space 
might be available earlier than 2018-04-30.


Thanks,
-melanie


Thanks

[1] 
https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure
[2] 
http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/add-zvm-driver-rocky
[4] 
https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.pyline 104






__
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] [keystone] rocky-1 retrospective

[Lance Bragstad]

Hi all,

As discussed in the keystone meeting today [0], we'll be holding our
retrospective for rocky-1 next Tuesday, April 24th immediately after the
keystone meeting at 1600 UTC. We're going to coordinate tools and
what-not prior to the retrospective in the #openstack-keystone channel.

See you next week,

Lance

[0]
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-04-17-16.00.log.html#l-137




signature.asc
Description: OpenPGP digital signature
__
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] [stable][trove] keep trove-stable-maint members up-to-date

[Matt Riedemann]

On 4/16/2018 3:04 AM, 赵超 wrote:


There are some patches to stable branches to the different trove repos, 
and they are always progressing slowly ,because none of the current 
trove team core members are in the trove-stable-maint. I tried to 
contact with the previous PTLs about expanding the 'trove-stable-maint' 
group and keep the group up-to-date, however got no response yet.


I noticed that 'stable-maint-core' is always included in the individual 
project -stable-maint group, could the core stable team help to update 
the 'trove-stable-maint' group (adding me to it could be sufficient by 
now)?


I've gone through the stable branch proposed changes for 
python-troveclient and trove.


The reason the core team from a project isn't automatically core on the 
stable branches for that project is because the review criteria and 
what's appropriate for stable branches is different from changes on the 
master branch. The details are in the stable branch guide [1]. Until it 
becomes clear that there are people that are reviewing stable branch 
patches and understand the rules, they don't get added to the core team 
for stable.


Until then, you can make review requests for stable patches in the ML 
like you have here, or in the #openstack-stable freenode IRC channel.


I think over time once the stable-maint-core team can identify some 
people that have done a good job of doing early reviews and +1 (and -1 
inappropriate changes) then they can be added to the stable branch core 
team for the project.


[1] https://docs.openstack.org/project-team-guide/stable-branches.html

--

Thanks,

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

[openstack-dev] [neutron] Sum up about "Enable mutable configuration" goal in Neutron

[Slawomir Kaplonski]

Hi,

I was working to implement goal [1] in Neutron and it’s now done with [2].
I also checked with code search if other related to neutron projects will need 
any changes.
I looked with [3] for projects which might need such changes. According to this 
list it looks that projects which may require 
some changes are:

openstack/neutron-lbaas
openstack/networking-cisco
openstack/networking-dpm
openstack/networking-infoblox
openstack/networking-l2gw
openstack/networking-lagopus
openstack/neutron-dynamic-routing
openstack/networking-avaya
openstack/networking-6wind

Based on mail [4] I updated also neutron-dynamic-routing project [5] and 
proposed a patch for neutron-lbaas [6] but it will probably not be merged as 
neutron-lbaas is deprecated.

If You are maintainer of one of other projects from list above (or other 
related to neutron) please take care of this goal on Your side.

[1] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
[2] https://review.openstack.org/#/c/554259/
[3] 
http://codesearch.openstack.org/?q=service.launch=nope==networking-6wind,networking-ale-omniswitch,networking-arista,networking-avaya,networking-bagpipe,networking-baremetal,networking-bgpvpn,networking-bigswitch,networking-brocade,networking-calico,networking-cisco,networking-cumulus,networking-dpm,networking-edge-vpn,networking-extreme,networking-fortinet,networking-fujitsu,networking-generic-switch,networking-generic-switch-tempest-plugin,networking-gluon,networking-h3c,networking-hpe,networking-huawei,networking-hyperv,networking-icc,networking-infoblox,networking-l2gw,networking-l2gw-tempest-plugin,networking-lagopus,networking-lenovo,networking-midonet,networking-mlnx,networking-nec,networking-odl,networking-onos,networking-opencontrail,networking-ovn,networking-ovs-dpdk,networking-peregrine,networking-plumgrid,networking-powervm,networking-sfc,networking-spp,networking-vpp,networking-vsphere,networking-zte,networking-zvm,neutron-classifier,neutron-dynamic-routing,neutron-fwaas,neutron-fwaas-dashboard,neutron-lbaas,neutron-lbaas-dashboard,neutron-lib,neutron-specs,neutron-tempest-plugin,neutron-vpnaas,neutron-vpnaas-dashboard
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129137.html
[5] https://review.openstack.org/#/c/559309/
[6] https://review.openstack.org/#/c/559412/

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


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

Re: [openstack-dev] [nova][xenapi] does get_all_bw_counters driver call nova-network only?

[Bob Ball]

As far as I remember this isn't a nova-network only feature; but I may be 
missing something.
I believe the bandwidth counters may be being used at Rackspace.

Bob

-Original Message-
From: Balázs Gibizer [mailto:balazs.gibi...@ericsson.com] 
Sent: 16 April 2018 13:37
To: OpenStack-dev 
Subject: [openstack-dev] [nova][xenapi] does get_all_bw_counters driver call 
nova-network only?

Hi,

The get_all_bw_counters() virt driver [1] is only supported by xenapi today. 
However Matt raised the question [2] if this is a nova-network only feature. As 
in that case we can simply remove it.

Cheers,
gibi

[1]
https://github.com/openstack/nova/blob/68afe71e26e60a3e4ad30083cc244c57540d4da9/nova/virt/xenapi/driver.py#L383
[2]
https://review.openstack.org/#/c/403660/78/nova/compute/manager.py@6855




__
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] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting tomorrow (April 18th) is canceled, as many Vitrage developers 
will be on vacation.

See you next week,
Ifat

__
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] How to handle python3 only projects

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-17 13:40:05 +0100:
> On 17/04/18 07:10, Adrian Turjak wrote:
> > Hello devs,
> > 
> > The python27 clock of doom ticks closer to zero
> > (https://pythonclock.org/) and officially dropping python27 support is
> > going to have to happen eventually, that though is a bigger topic.
> > 
> > Before we get there outright what we should think about is what place
> > python3 only projects have in OpenStack alongside ones that support both.
> > 
> > Given that python27's life is nearing the end, we should probably
> > support a project either transitioning to only python3 or new projects
> > that are only python3. Not to mention the potential inclusion of python3
> > only libraries in global-requirements.
> > 
> > Potentially we should even encourage python3 only projects, and
> > encourage deployers and distro providers to focus on python3 only (do
> > we?). Python3 only projects are now a reality, python3 only libraries
> > are now a reality, and most of OpenStack already supports python3. Major
> > libraries are dropping python27 support in newer versions, and we should
> > think about how we want to do it too.
> > 
> > So where do projects that want to stop supporting python27 fit in the
> > OpenStack ecosystem? Or given the impending end of python27, why should
> > new projects be required to support it at all, or should we heavily
> > encourage new projects to be python3 only (if not require it)?
> > 
> > It's not an easy topic, and there are likely lots of opinions on the
> > matter, but it's something to start considering.
> > 
> > Cheers!
> > 
> > - Adrian Turjak
> 
> I think the time has definitely come to allow projects be py3 only.
> 
> https://review.openstack.org/#/c/561922/ should allow that from a
> governance perspective.
> 
> - Graham

(I replied on the patch because I saw that first, but I'll repeat myself
here for continuity.)

I don't think we're ready to make python 2 support optional. I do
think we should shift to emphasizing python 3 "first", though.

In order to allow projects to drop python 2 support I think we need
to wait for both distributions we claim to support to have good
python 3 support. Ubuntu has 3.5, but CentOS/RHEL does not, yet.
Red Hat has announced in the release notes for RHEL 7.5 that "the
next major release" of RHEL will not include python 2 and will
include python 3. At that point we can reasonably expect deployers
to start deploying OpenStack on python 3, and dropping python 2
support will become a realistic option.

I should add that we have plenty of constructive things to do yet
to prepare for that date. The Oslo team is currently working on
making python 3 the default for all of our secondary jobs (docs,
release notes, pep8, etc.). The next step will be to update the
functional test jobs to ensure they are all running under python 3
(at least).

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

[openstack-dev] [TC][election] TC Candidacy

[Zane Bitter]

Hello friends,
I've been working full-time on OpenStack for 6 years now, since the very 
early days of the Heat project back in 2012. Along the way I have served 
as PTL of Heat, where I am still a member of the core team, and 
colloborated with developers from many other projects, such as Mistral, 
Zaqar, Telemetry, and Keystone. I also worked on TripleO for a while, 
from which I learned a lot about both deploying OpenStack itself and 
deploying complex applications using OpenStack (since it uses an 
OpenStack undercloud to deploy OpenStack as an application).


Last year I wrote, and the TC approved, a resolution on the importance 
of catering to applications that autonomously make use of OpenStack APIs 
if we are to achieve OpenStack's mission:


https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html

(Since then a lot of great progress[1] has been made, with more 
coming[2].) Afterwards, a number of people remarked that up until that 
point, despite being familiar with all of the pieces, they had never 
really connected the dots to realise that there was no secure way for an 
application to authenticate to the OpenStack cloud it is running in 
without extensive manual intervention from the cloud operator.


I'm running for election to the Technical Committee because I think it's 
important that we have a TC that can, collectively, connect the dots in 
as many different ways as possible, to cater to the many different users 
and potential users of OpenStack. There are important discussions ahead 
-- both within the technical community and between the TC and the Board 
-- about where to draw the boundaries of OpenStack; the more user 
viewpoints that are represented, the better the result will be. We don't 
get as much feedback from developers of cloud-aware applications as we 
do from other end users, because in many cases OpenStack doesn't yet 
meet their minimum requirements. That is the gap I am hoping to bridge. 
If we succeed, OpenStack will not only gain a lot more users, but I 
expect more users will become contributors. I know from long experience 
that keeping up with the activity of the TC requires a substantial time 
commitment; I am fortunate to be in a position to contribute and I hope 
to be able to represent many of y'all who are unable to devote that 
amount of time.


I also plan to work with the TC to find more ways to guide projects 
toward maturity once they have joined the OpenStack community -- 
something we largely lost when the old incubation process went away.


Questions and comments are welcome!

thanks,
Zane.


[1] 
https://docs.openstack.org/keystone/queens/user/application_credentials.html
[2] 
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.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] [Nova] z/VM introducing a new config driveformat

[Dan Smith]

> I propose that we remove the z/VM driver blueprint from the runway at
> this time and place it back into the queue while work on the driver
> continues. At a minimum, we need to see z/VM CI running with
> [validation]run_validation = True in tempest.conf before we add the
> z/VM driver blueprint back into a runway in the future.

Agreed. I also want to see the CI reporting cleaned up so that it's
readable and consistent. Yesterday I pointed out some issues with the
fact that the actual config files being used are not the ones being
uploaded. There are also duplicate (but not actually identical) logs
from all services being uploaded, including things like a full compute
log from starting with the libvirt driver.

I'm also pretty troubled by the total lack of support for the metadata
service. I know it's technically optional on our matrix, but it's a
pretty important feature for a lot of scenarios, and it's also a
dependency for other features that we'd like to have wider support for
(like attached device metadata).

Going back to the spec, I see very little detail on some of the things
raised here, and very (very) little review back when it was first
approved. I'd also like to see more detail be added to the spec about
all of these things, especially around required special changes like
this extra AE agent.

--Dan

__
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] [all] TC Report 18-16

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-16.html

This the 16th week of the year, meaning I've been making these
reports for a full year. The
[first one](https://anticdent.org/tc-report-17.html) was in the 17th
week of 2017. The reports have changed quite a bit since then: Back
then there was still a once weekly TC meeting. That's since been
replaced by less formal office hours, three times a week. That's had
mixed results, reflected in the tone and content of these reports.
To some extent the decompression of TC activity has meant less
drama, intensity and apparent depth in the reports. But it may also
be the case that the TC hasn't done as much as it could or should.

With elections in progress, we could take advantage of this time to
reflect on the role of the TC and work to make sure the next term is
more active in shaping and sustaining OpenStack. At the time of this
writing there are ten hours left if you would like to nominate
yourself. Info on the [election
page](https://governance.openstack.org/election/).

There are nine candidates (so far) for seven slots. When nominations
close, there will be a week of "campaigning". This is an opportunity
for community members to question the candidates about any concerns.

(I'm running for reelection, you can read my
[nomination](https://git.openstack.org/cgit/openstack/election/plain/candidates/rocky/TC/cdent%40anticdent.org)
if you like. Please ask me any questions you may have.)

# Leadership Shadowing

Last
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-11.log.html#t2018-04-11T14:53:11)
there was some comparison between the Kubernetes and OpenStack
styles of "growing new leaders". In Kubernetes there is a shadowing
system that has mixed success, depending on the group.

# Forum and Summit

On
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-12.log.html#t2018-04-12T15:00:50)
there was final discussion on submitting sessions to [the
forum](http://forumtopics.openstack.org/).

Prior to the summit proper there will be a joint leadership meeting.
Thierry has started [a
thread](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129428.html)
seeking topics that the community would like to see raised at that
meeting. These meetings are the most significant formal engagement
the TC has with the board throughout the year.

# More on Kolla

Also on Thursday there was [more
discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-12.log.html#t2018-04-12T15:27:07)
on how kolla-k8s might evolve.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [openstack-ansible] Problems with Openstack services while migrating VMs

[Periyasamy Palanisamy]

Hi,

I'm trying to migrate controller and compute VMs installed with 
Openstack-Ansible across systems with following approach.
This is mainly to minimize the deployment time in the Jenkins CI environment.

Export steps:

  1.  Power off the VMs gracefully.
  2.  virsh dumpxml ${node} > $EXPORT_PATH/${node}.xml
  3.  cp /var/lib/libvirt/images/${node}.qcow2 $EXPORT_PATH/$node.qcow2
  4.  create a tar ball for the xml's and qcow2 images.


Import steps:

  1.  cp ${node}.qcow2 /var/lib/libvirt/images/
  2.  virsh define ${node}.xml
  3.  virsh start ${node}

After the import of the VMs, The openstack services (neutron-server, DHCP 
agent, Metering agent, Metadata agent, L3 agent, Open vSwitch agent, 
nova-conductor and nova-comute) are started in random order.
This causes neutron and nova is not able to find DHCP agent and compute 
accordingly to bring up the tenant VM and throws the error [1].

I have also tried to boot compute VM followed by controller VM. It also doesn't 
help.
Could you please let me know what is going wrong here ?

[1] https://paste.ubuntu.com/p/YNg2NnjvpS/ (fault section)

Thanks,
Periyasamy
__
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] How to handle python3 only projects

[Graham Hayes]

On 17/04/18 07:10, Adrian Turjak wrote:
> Hello devs,
> 
> The python27 clock of doom ticks closer to zero
> (https://pythonclock.org/) and officially dropping python27 support is
> going to have to happen eventually, that though is a bigger topic.
> 
> Before we get there outright what we should think about is what place
> python3 only projects have in OpenStack alongside ones that support both.
> 
> Given that python27's life is nearing the end, we should probably
> support a project either transitioning to only python3 or new projects
> that are only python3. Not to mention the potential inclusion of python3
> only libraries in global-requirements.
> 
> Potentially we should even encourage python3 only projects, and
> encourage deployers and distro providers to focus on python3 only (do
> we?). Python3 only projects are now a reality, python3 only libraries
> are now a reality, and most of OpenStack already supports python3. Major
> libraries are dropping python27 support in newer versions, and we should
> think about how we want to do it too.
> 
> So where do projects that want to stop supporting python27 fit in the
> OpenStack ecosystem? Or given the impending end of python27, why should
> new projects be required to support it at all, or should we heavily
> encourage new projects to be python3 only (if not require it)?
> 
> It's not an easy topic, and there are likely lots of opinions on the
> matter, but it's something to start considering.
> 
> Cheers!
> 
> - Adrian Turjak

I think the time has definitely come to allow projects be py3 only.

https://review.openstack.org/#/c/561922/ should allow that from a
governance perspective.

- Graham



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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Jay Pipes]

On 04/16/2018 09:20 PM, melanie witt wrote:
I propose that we remove the z/VM driver blueprint from the runway at 
this time and place it back into the queue while work on the driver 
continues. At a minimum, we need to see z/VM CI running with 
[validation]run_validation = True in tempest.conf before we add the z/VM 
driver blueprint back into a runway in the future.


Seems reasonable to me.

-jay

__
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] [Os-brick][Cinder] NVMe-oF NQN string

[Hamdy Khader]

Hi,

I think you're right, will drop the split and push change soon.


Regards,

Hamdy



From: Szwed, Maciej 
Sent: Monday, April 16, 2018 4:51 PM
To: OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [Os-brick][Cinder] NVMe-oF NQN string


Hi,

I’m wondering why in Os-brick implementation of NVMe-oF in 
os_brick/initiator/connectors/nvme.py, line 97 we do split on ‘nqn’. Connection 
properties, including ‘nqn’, are provided by Cinder driver and when user want 
to implement new driver that will use NVMe-of he/she needs to create NQN string 
with additional string and dot proceeding the desired NQN string. This 
additional string is unused across whole NVMe-oF implementation. This creates 
confusion for people when creating new Cinder driver. What was its purpose? Can 
we drop that split?



Regards,

Maciej
__
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] [openstack-infra] How to take over a project?

[Gary Kotton]

Hi,
You either need one of the ono core team or the neutron release team to add 
you. FYI - https://review.openstack.org/#/admin/groups/1001,members
Thanks
Gary

From: Sangho Shin 
Reply-To: OpenStack List 
Date: Tuesday, April 17, 2018 at 5:01 AM
To: OpenStack List 
Subject: [openstack-dev] [openstack-infra] How to take over a project?

Dear OpenStack Infra team,

I would like to know how to take over an OpenStack project.
I am a committer of the networking-onos project 
(https://github.com/openstack/networking-onos),
 and I would like to take over the project.
The current maintainer (cc’d) has already agreed with that.

Please let me know the process to take over (or change the maintainer of) the 
project.

BTW, it looks like even the current maintainer cannot create a new branch of 
the codes. How can we get the authority to create a new branch?

Thank you,

Sangho
__
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 for gong yongsheng

[龚永生]

Hi,


I am announcing my candidacy for a member of the Technical Committee.


Now I am CTO of 99cloud Inc., China. After discussing with my Team (My CEO, COO
and R department), I made up my mind. This means my company will continue
devoting itself into the OpenStack community, help the OpenStack to meet
customer’s needs and promote OpenStack to a new high.


I was previously a Neutron Core member and am the PTL of Tacker project.
Besides this, I am also making contribution to OpenCord project, which is the
edge platform for telecom central office. OpenCord project is using OpenStack
as the platform to instantiate the VNFs. One more open project I am leading my
company R to is akraino edge stack, a Linux Foundation project in formation,
which will create an open source software stack to improve the state of edge
cloud infrastructure for carrier, provider, and IoT networks. I think
OpenStack can play a good role in OpenCord and akraino as the infrastructure
manager.


I agree to Thierry Carrez with the concept of “Constellations” (representation
of groups of OpenStack components that answer a specific use case).
For example, in the case of MANO system, we need to improve Tacker with
OpenStack as NFVI. For DEVOPS, the ZUUL and the whole OpenStack’s CI
infrastructure is great, we can also introduce kubernetes into this
constellation so that we can meet the DEVOPS needs of container-based or
VM-based applications.


I am new to TC governance and have the passion to join TC. I am a technical
guy and hope I can help to glue the OpenStack projects and keep my eye on
their development. As a member of management team, I like to make others
succeed and then enjoy their success. So, I will support OpenStack project
teams to make OpenStack great again.


Thank you for your consideration.
Best Regards,


Gong Yongsheng (gongysh)


[1] 
http://stackalytics.com/?metric=commits=99cloud_id=gongysh=all
[2] http://stackalytics.com/?metric=commits=99cloud=all
[3] https://www.akraino.org/



__
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] [openstack-ansible] We need to change!

[Jean-Philippe Evrard]

Dear community,

Starting at the end of this month, I won't be able to work full time
on OpenStack-Ansible anymore.

I want to highlight the following:
Our current way of working is not sustainable in the long run, as a lot
of work (and therefore pressure) is concentrated on a few individuals.

I managed to get more people working on some parts of our code
(becoming cores on specific areas of knowledge, like mbuil on
networking, mnaser and gokhan on telemetry, johnsom on octavia,
mugsie on designate), but at the same time we have lost a
core reviewer on all our code base (mhayden).

I like the fact we are still innovating with our own deployment tooling,
bringing more features in, changing the deployment models to be always
more stable, more user-friendly.

But new features aren't all. We need people actively looking at the
quality of existing deliverables. We need to stretch those
responsibilities to more people.

I would be very happy if some people using OpenStack-Ansible
would help on:

* Bugs. We are reaching an all-time high amount of bugs pending.
  We need people actively cleaning those. We need someone to
  organize a bug smash. We need people willing to lead the bug
  triage process too.
* Releases. Our current release process is manual. People
  interested by how releases are handled should step in there
  (for example, what does in, and at what time).
  We also need to coordinate with the releases
  team, and improve our way to release.
* Jobs/state monitoring. I have spent an insane amount of time
  cleaning up after other people. That cannot be done any longer.
  If you're breaking a job, whether it's part of the
  openstack-ansible gates or not, you should be fixing it.
  Even if it's a non-voting job, or a periodic job.
  I'd like everyone to monitor our zuul dashboard, and take
  action based on that. When queens was close to release,
  everything job was green on the zuul dashboard. I did an
  experiment of 1 month without me fixing the upgrade jobs,
  and guess what: ALL (or almost ALL) the upgrade jobs are
  now broken. Please monitor [1] and actively help fixing
  the jobs. Remember, if everyone works on this, it would
  give a great feedback to new users, and it becomes a
  virtuous cycle.
* Reduce technical debt. We have so many variables, so many
  remnants of the past. This cycle is planned to be a
  cleanup. Let's simplify all of this, making sure the
  deployment of openstack with openstack-ansible ends
  up with a system KISS.
* Increasing voting test coverage. We need more code
  paths tested and we need those code path preventing
  bad patches to merge. It makes the reduction of
  technical debt easier.

Really thank you for your understanding.

Best regards,
Jean-Philippe (evrardjp)

[1]: 
http://zuul.openstack.org/builds.html?pipeline=periodic=openstack%2Fopenstack-ansible

__
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] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Hi everyone,

As you know the Technical Committee (the governance body representing
contributors producing OpenStack software) meets with other OpenStack
governance bodies (Board of Directors and User Committee) on the Sunday
before every Summit, and Vancouver will be no exception.

At the TC retrospective Forum session in Sydney we decided we should
more broadly ask our constituency for topics they would like us to cover
in that discussion.

Once the current election cycle is over and the new TC chair is picked,
we'll come up with a proposed agenda and submit it to the Chairman of
the Board for consideration.

So... Is there any specific topic you think we should cover in that
meeting ?

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

Re: [openstack-dev] [openstack][charms] Openstack + OVN

[Trinath Somanchi]

Hi Openstack-Charms team-

Please help us with your guidance to submit openstack-ovn charm.

/Trinath | NXP

From: Aakash Kt [mailto:aakash...@gmail.com]
Sent: Thursday, April 12, 2018 7:34 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [openstack][charms] Openstack + OVN

Hello,

Any update on getting to the development of this charm? I need some guidance on 
this.

Thank you,
Aakash

On Tue, Mar 27, 2018 at 10:27 PM, Aakash Kt 
> wrote:
Hello,

So an update about current status. The charm spec for charm-os-ovn has been 
merged (queens/backlog). I don't know what the process is after this, but I had 
a couple of questions for the development of the charm :

- I was wondering whether I need to use the charms.openstack package? Or can I 
just write using the reactive framework as is?
- If we do have to use charms.openstack, where can I find good documentation of 
the package? I searched online and could not find much to go on with.
- How much time do you think this will take to develop (not including test 
cases) ?

Do guide me on the further steps to bring this charm to completion :-)

Thank you,
Aakash


On Mon, Mar 19, 2018 at 5:37 PM, Aakash Kt 
> wrote:
Hi James,

Thank you for the previous code review.
I have pushed another patch. Also, I do not know how to reply to your review 
comments on gerrit, so I will reply to them here.

About the signed-off-message, I did not know that it wasn't a requirement for 
OpenStack, I assumed it was. I have removed it from the updated patch.

Thank you,
Aakash


On Thu, Mar 15, 2018 at 11:34 AM, Aakash Kt 
> wrote:
Hi James,

Just a small reminder that I have pushed a patch for review, according to 
changes you suggested :-)

Thanks,
Aakash

On Mon, Mar 12, 2018 at 2:38 PM, James Page 
> wrote:
Hi Aakash

On Sun, 11 Mar 2018 at 19:01 Aakash Kt 
> wrote:
Hi,

I had previously put in a mail about the development for openstack-ovn charm. 
Sorry it took me this long to get back, was involved in other projects.

I have submitted a charm spec for the above charm.
Here is the review link : 
https://review.openstack.org/#/c/551800/

Please look in to it and we can further discuss how to proceed.

I'll feedback directly on the review.

Thanks!

James

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




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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

For the question on AE documentation, it's open source in [1] and the
documentation for how to build and use is [2]
once our code is upstream, there are a set of documentation change which
will cover this image build process by
adding some links to there [3]

You are right, we need image to have our Active Engine, I think different
arch and platform might have their unique
requirements and our solution our Active Engine is very like to cloud-init
so no harm to add it from user's perspective
I think later we can upload image to some place so anyone is able to
consume it as test image if they like
because different arch's image (e.g x86 and s390x) can't be shared anyway.

For the config drive format you mentioned, actually, as previous
explanation and discussion witho Michael and Dan,
We found the iso9660 can be used (previously we made a bad assumption) and
we already changed the patch in [4],
so it's exactly same to other virt drivers you mentioned , we don't need
special format and iso9660 works perfect for our driver

It make sense to me we are temply moved out from runway, I suppose we can
adjust the CI to enable the run_ssh = true
with config drive functionalities very soon and we will apply for review
after that with the test result requested in our CI log.

Thanks

[1]
https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure
[2]
http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux
[3] https://review.openstack.org/#/q/status:open+project:openstack/nova
+branch:master+topic:bp/add-zvm-driver-rocky
[4]  https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.py
line 104

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   melanie witt 
To: openstack-dev@lists.openstack.org
Date:   04/17/2018 09:21 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
>  >>>The "iso file" will not be inside the guest, but rather passed to
> the guest as a block device, right?
> Cloud init expects to find a config drive with following requirements
> [1], in order to make cloud init able to consume config drive , we
> should be able to prepare it,
> in some hypervisor, you can define something like following to the VM
> then VM startup is able to consume it
> 
> but for z/VM case it allows disk to be created during VM create (define
> )stage but no disk format set, it's the operating system's
> responsibility to define the purpose of the
> disk, so what we do is
> 1) first when we build image ,we create a small AE like cloud-init but
> only purpose is to get files from z/VM internal pipe and handle config
> drive case

What does AE stand for? So, this means in order to use the z/VM driver,
users must have special images that will ensure the config drive will be
readable by cloud-init. They can't use standard cloud images.

> 2) During spawn we create config drive in nova-compute side then send
> the file to z/VM through z/VM internal pipe (omit detail here)
> 3) During startup of the virtual machine, the small AE is able to mount
> the file as loop device and then in turn cloud-init is able to handle it
>
> because this is our special case, we don't want to upload to cloud-init
> community because of uniqueness and as far as we can tell, no hook in
> cloud-init mechanism allowed as well
> to let us 'mount -o loop' ; also, from openstack point of view except
> this small AE (which is documented well) no special thing and
> inconsistent to other drivers
>
> [1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_number5_cloud-2Dinit_blob_master_cloudinit_sources_DataSourceConfigDrive.py-23L225=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0=3410axnNZ_62U3HOh6i7yivyc7HyTcqwx2xuKRDEeac=


Where is the AE documented? How do users obtain it? What tools are they
supposed to use to build images to use with the z/VM driver?

That aside, from what I can see, the z/VM driver behaves unlike any
other in-tree driver [0-5] in how it handles config drive. Drivers are
expected to create the config drive and present it to the guest in
iso9660 or vfat format without requirement of a custom image and the
existing drivers are doing that.

IMHO, if the z/VM driver can't be fixed to provide proper config drive
support, we won't be able to approve the implementation patches. I would
like to hear other opinions about it.

I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = 

Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower constraints

[Slawomir Kaplonski]

Hi,

Just for information to all who sends patches for Neutron.
Patch [1] is now merged so if in Your patch lower-constraints job is still 
failing with error like in this thread, please rebase Your patch on top of [1] 
instead of just rechecking which probably will not help.

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

> Wiadomość napisana przez Slawomir Kaplonski  w dniu 
> 16.04.2018, o godz. 12:41:
> 
> I just sent a patch to bump Ryu version in Neutron’s requirements to fix 
> lower constraints job there also: https://review.openstack.org/#/c/561579/
> 
> 
>> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
>> o godz. 09:13:
>> 
>> Please see https://review.openstack.org/561443
>> 
>> On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro"  wrote:
>> 
>>   On Sun, 15 Apr 2018 21:02:42 +0900,
>>   Gary Kotton wrote:
>>> 
>>> [1  ]
>>> [1.1  ]
>>> Hi,
>>> That sounds reasonable. I wonder if the RYU folk can chime in here.
>>> Thanks
>> 
>>   I don't fully understand the recent g-r change yet, but
>>   I guess neutron-dynamic-routing should  also have ryu>=4.24.
>>   I'll check this tommorrow.
>> 
>>> From: Akihiro MOTOKI 
>>> Reply-To: OpenStack List 
>>> Date: Sunday, April 15, 2018 at 12:43 PM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower 
>>> constraints
>>> 
>>> Gary,
>>> 
>>> I think this is caused by the recent pip change and pip no longer cannot 
>>> import pip from code. The right solution seems to bump the minimum version 
>>> of ryu.
>>> 
>>> Thought?
>>> 
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html
>>> 
>>> Akihiro
>>> 
>>> 2018/04/15 午後6:06 "Gary Kotton" 
>>> >:
>>> Hi,
>>> It seems like ther RYU import is breaking the project:
>>> 
>>> 
>>> 2018-04-15 
>>> 08:41:34.654681
>>>  | ubuntu-xenial | b'--- import errors ---\nFailed to import test module: 
>>> neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
>>>  (most recent call last):\n  File 
>>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>>  line 456, in _find_test_path\nmodule = 
>>> self._get_module_from_name(name)\n  File 
>>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>>  line 395, in _get_modu
>>le_from_name\n__import__(name)\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py",
>>  line 21, in \nfrom ryu.services.protocols.bgp import 
>> bgpspeaker\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py",
>>  line 21, in \nfrom ryu.lib.packet.bgp import (\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py>
>> ower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py>", 
>> line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6, ipv4, 
>> ipv6, lldp, mpls, packet,\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py",
>>  line 18, in \nfrom . import vlan\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/vlan.py",
>>  line 21, in \nfrom . import ipv4\n  File 
>> 

[openstack-dev] [all] How to handle python3 only projects

[Adrian Turjak]

Hello devs,

The python27 clock of doom ticks closer to zero
(https://pythonclock.org/) and officially dropping python27 support is
going to have to happen eventually, that though is a bigger topic.

Before we get there outright what we should think about is what place
python3 only projects have in OpenStack alongside ones that support both.

Given that python27's life is nearing the end, we should probably
support a project either transitioning to only python3 or new projects
that are only python3. Not to mention the potential inclusion of python3
only libraries in global-requirements.

Potentially we should even encourage python3 only projects, and
encourage deployers and distro providers to focus on python3 only (do
we?). Python3 only projects are now a reality, python3 only libraries
are now a reality, and most of OpenStack already supports python3. Major
libraries are dropping python27 support in newer versions, and we should
think about how we want to do it too.

So where do projects that want to stop supporting python27 fit in the
OpenStack ecosystem? Or given the impending end of python27, why should
new projects be required to support it at all, or should we heavily
encourage new projects to be python3 only (if not require it)?

It's not an easy topic, and there are likely lots of opinions on the
matter, but it's something to start considering.

Cheers!

- Adrian Turjak








__
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] [openstack-infra] How to take over a project?

[Ian Wienand]

On 04/17/2018 12:00 PM, Sangho Shin wrote:
> I would like to know how to take over an OpenStack project.  I am a
> committer of the networking-onos project
> (https://github.com/openstack/networking-onos
> ), and I would like to
> take over the project.

> The current maintainer (cc’d) has already agreed with that.

> Please let me know the process to take over (or change the
> maintainer of) the project.

Are you talking about the github project or the gerrit project?
Github is a read-only mirror of the project from gerrit.

You appear to already be a member of networking-onos-core [1] so you
have permissions to approve and reject changes.

> BTW, it looks like even the current maintainer cannot create a new
> branch of the codes. How can we get the authority to create a new
> branch?

Are you following something like [2]?

-i

[1] https://review.openstack.org/#/admin/groups/1001,members
[2] https://docs.openstack.org/infra/manual/drivers.html#feature-branches

__
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