Re: [openstack-dev] [All] A worked example of adding privsep to an OpenStack project

[ChangBo Guo]

Thanks Michael, that's very useful.

2018-05-08 10:05 GMT+08:00 Michael Still :

> Hi,
>
> further to last week's example of how to add a new privsep'ed call in
> Nova, I thought I'd write up how to add privsep to a new OpenStack project.
> I've used Cinder in this worked example, but it really applies to any
> project which wants to do things with escalated permissions.
>
> The write up is here -- http://www.madebymikal.com/
> adding-oslo-privsep-to-a-new-project-a-worked-example/
>
> Michael
>
> --
> Did this email leave you hoping to cause me pain? Good news!
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
> http://www.madebymikal.com/city2surf-2018/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing 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] A worked example of adding privsep to an OpenStack project

[Michael Still]

Hi,

further to last week's example of how to add a new privsep'ed call in Nova,
I thought I'd write up how to add privsep to a new OpenStack project. I've
used Cinder in this worked example, but it really applies to any project
which wants to do things with escalated permissions.

The write up is here --
http://www.madebymikal.com/adding-oslo-privsep-to-a-new-project-a-worked-example/

Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing 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] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Bios interface support
- BIOS Settings: Add BIOSInterface : https://review.openstack.org/507793 - 
Needs update
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579
- Hardware type cleanup
- https://review.openstack.org/#/q/topic:api-jobs to unblock api CI test 
cleanup
- https://review.openstack.org/#/q/status:open+topic:hw-types - Blocked 
pending api job cleanup
- Python-ironicclient things
- Wire in header microversion into client negotiation
- https://review.openstack.org/#/c/558027/
- Accept a version on set_provision_state
- https://review.openstack.org/#/c/557850/ 1x+2
- Remaining Rescue patches
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.) Needs Revision
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/ Needs Revision
- Bug Fixes
- Fixing ironic-inspector dnsmasq filter behavior 
https://review.openstack.org/#/c/566407/
- Revert virtualbmc SOL support due to leaking file descriptors 
https://review.openstack.org/566646
- House Keeping:
- CoreOS needs to be updated for IPA - 
https://review.openstack.org/#/c/566094/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
None
irmc:
None - a few works are work in progress
xclarity:
Fix XClarity parameters discrepancy: 
https://review.openstack.org/#/c/561405/ Needs Revision

Subproject priorities
-
bifrost:

ironic-inspector (or its client):
(dtantsur) bug fixes for the PXE filters:
Blacklist unknown hosts https://review.openstack.org/#/c/566407/
Correct tear down on SIGTERM https://review.openstack.org/#/c/563335/

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:
(dtantsur) do not run functional (API) tests in the CI:
sushy https://review.openstack.org/#/c/566577/ 1x+2
sushy-tools https://review.openstack.org/#/c/566578/ 1x+2

Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- initial version (much fewer features): 
https://github.com/dtantsur/ironic-bug-report
- Stats (new version, diff with 30 Apr 2018):
- Total bugs: 275 (-8)
-  of them untriaged: 236 (-20)
- Total RFEs: 231 (-7)
-  of them untriaged: 26 (-1)
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' 
deploy interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/ MERGED - Backport to stable/queens 
proposed

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- spec for deployment steps framework has merged: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/deployment-steps-framework.html
- status as of 7 May 2018:
- waiting for code from rloo, no timeframe yet

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 30 April 2018:
- Spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/generic-bios-config.html
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162 
MERGED
- Add bios_interface db field https://review.openstack.org/528609 MERGED
- BIOS Settings: Add DB API: https://review.openstack.org/511402 MERGED
- BIOS Settings: Add RPC object https://review.openstack.org/511714 
MERGED
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- story: https://storyboard.openstack.org/#!/story/2001795
- (may 7) 

Re: [openstack-dev] [all][requirements] uncapping eventlet

[John Dickinson]

I've discovered that eventlet 0.23.0 (released April 6) does break 
things for Swift. I'm not sure about other projects yet.


https://bugs.launchpad.net/swift/+bug/1769749

--John




On 7 May 2018, at 13:50, Doug Hellmann wrote:


Excerpts from Michel Peterson's message of 2018-05-07 17:54:02 +0300:
On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 


wrote:



We have made great progress on this but we do still have quite a
few of these patches that have not been approved.  Many are failing
test jobs and will need a little attention ( the failing 
requirements

jobs are real problems and rechecking will not fix them).  If you
have time to help, please jump in and take over a patch and get it
working.

https://review.openstack.org/#/q/status:open+topic:uncap-eventlet



I did a script to fix those and I've submitted patches.


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


__
OpenStack Development Mailing 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] [sdk] issues with using OpenStack SDK Python client

[gerard.d...@wipro.com]

more details about router deletion:

I tried replacing the "!=None" test with a try statement:

try:
onap_router = conn.network.find_router(ONAP_ROUTER_NAME)
conn.network.delete_router(onap_router.id)

(router print-out just before deleting):
openstack.network.v2.router.Router(revision=3, distributed=False, 
status=ACTIVE, tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, 
created_at=2018-05-07T20:37:56Z, name=ONAP_router, admin_state_up=True, 
tags=[], updated_at=2018-05-07T20:37:59Z, ha=False, 
id=9fc30b97-3942--856a-69c9e2368e02, availability_zone_hints=[], 
flavor_id=None, description=Router created for ONAP, 
availability_zones=['nova'], routes=[], external_gateway_info=None)


*** traceback.print_exception():
Traceback (most recent call last):
  File "auto_script_config_openstack_for_onap.py", line 158, in delete_all_ONAP
conn.network.delete_router(onap_router.id)
  File "/usr/local/lib/python3.5/dist-packages/openstack/network/v2/_proxy.py", 
line 2255, in delete_router
self._delete(_router.Router, router, ignore_missing=ignore_missing)
  File "/usr/local/lib/python3.5/dist-packages/openstack/proxy.py", line 41, in 
check
return method(self, expected, actual, *args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/openstack/proxy.py", line 146, 
in _delete
value=value,
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
847, in delete
self._translate_response(response, has_body=False, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
666, in _translate_response
exceptions.raise_from_response(response, error_message=error_message)
  File "/usr/local/lib/python3.5/dist-packages/openstack/exceptions.py", line 
212, in raise_from_response
http_status=http_status, request_id=request_id
openstack.exceptions.ConflictException: Unable to delete Router for 
9fc30b97-3942--856a-69c9e2368e02



(note: deleting the router from either the openstack CLI or from the Horizon 
GUI works fine)

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.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] [all][requirements] uncapping eventlet

[Doug Hellmann]

Excerpts from Michel Peterson's message of 2018-05-07 17:54:02 +0300:
> On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 
> wrote:
> 
> >
> > We have made great progress on this but we do still have quite a
> > few of these patches that have not been approved.  Many are failing
> > test jobs and will need a little attention ( the failing requirements
> > jobs are real problems and rechecking will not fix them).  If you
> > have time to help, please jump in and take over a patch and get it
> > working.
> >
> > https://review.openstack.org/#/q/status:open+topic:uncap-eventlet
> >
> >
> I did a script to fix those and I've submitted patches.

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

Re: [openstack-dev] Ironic Status Updates

[Doug Hellmann]

Excerpts from Julia Kreger's message of 2018-05-07 13:53:13 -0400:
> Greetings everyone,
> 
> For some time, Rama Yeleswarapu (rama_y) has been graciously sending
> out a weekly update for Ironic to the mailing list. We found out late
> last week that this contributor would be unable to continue to do so.
> While discussing this and searching for a volunteer, we came up with
> two important questions that we determined should have some answers.
> 
> The first being. Is anyone finding a weekly email useful for Ironic?
> 
> The second being: If it is useful, would there be an alternative
> format that may be even more useful? Largely it is presently a
> copy/paste of our general purpose whiteboard. Perhaps a stream of
> consciousness or commentary to convey the delta from week to week?
> 
> -Julia
> 

As a consumer of team updates from outside of the team, I do find
them valuable.

I think having a regular email update like that is a good communication
pattern we've started to establish with several teams, and I'm going
to ask the TC to help find ways to make those updates more visible
for folks who want to stay informed but can't spend the time it
takes to read all of the messages on the mailing list (blogs, RSS,
twitter, etc.).

So, I hope the Ironic team can find a volunteer (or several to share
the work?) to step in and continue with summaries in some form.

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

Re: [openstack-dev] [tc][goals] tracking status of old goals for new projects

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-05-07 14:06:35 +:
> On 2018-05-07 09:52:16 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > 3. We could do nothing to record the work related to the goal.
> [...]
> 
> For situations like 557863 I think I'd prefer either the status quo
> (the kolla deliverable _was_ already listed so it could make
> sense to update it in that document) or option #3 (the cycle for
> that goal is already well in the past, and certainly adding new
> deliverables like kolla-kubernetes to a past goal sets unrealistic
> expectations for future goals regardless of where we track them).
> 
> I really do, though, think we should simply accept that these goals
> don't always (or even usually?) reach 100% coverage and that at some
> point we need to be able to consider better means of keeping track
> of, e.g., which deliverables work on which Python versions. The
> goals process is excellent for reaching critical mass on such
> efforts, but should not be considered a source of long-term support
> documentation.

Right, it's that latter part I think we didn't really consider when we
started the whole process. I hope storyboard will make it easier to
address those cases in the future, because anyone can add a task and
mark it completed without triggering a bunch of review work for TC
members, which is the main objection I have to continuing to update the
documents in the governance repo.

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] [barbican] meeting cancelled for 5/7/2018

[Ade Lee]

Hi all, 

I have a conflict for this week's meeting.  Therefore we will cancel
for this week and reconvene next week.

Thanks.

Ade

__
OpenStack Development Mailing 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] [sdk] identity proxy: users, groups, projects, membership, roles

[gerard.d...@wipro.com]

Hi,

I'm wondering if there are (or should be) operations in the Connection.identity 
proxy
to manage user and group membership to projects, and to manage user and group 
role assignments
(there are role management methods in the Project class, but I couldn't find 
them in the identity proxy):

The 8 operations could be something like that:
add|remove user|group to|from project   (i.e., manage 'Member' role for 
projects)
assign|unassign role to|from user|role  (any role)

Project operations:
Connection.identity.add_user_to_project(user, project, )
  user: instance or id
  project: project or id
Connection.identity.remove_user_from_project(user, project, )

Connection.identity.add_group_to_project(group, project, )
  group: instance or id
Connection.identity.remove_group_from_project(group, project, )


Role operations:
Connection.identity.assign_role_to_user(role, user, )
Connection.identity.unassign_role_from_user(role, user, )

Connection.identity.assign_role_to_group(role, group, )
Connection.identity.unassign_role_from_group(role, group, )

Cheers,
Gerard


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.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] [tc][goals] tracking status of old goals for new projects

[Mohammed Naser]

On Mon, May 7, 2018 at 9:52 AM, Doug Hellmann  wrote:
> There is a patch to update the Python 3.5 goal for Kolla [1]. While
> I'm glad to see the work happening, the change adds a new deliverable
> to an old goal, and it isn’t clear whether we want to use that
> approach for tracking goal work indefinitely. I see a few options.
>
> 1. We could update the existing document.
>
> 2. We could set up stories in storyboard like we are doing for newer
>goals.

I think that this is the way to go moving forward.  That will
encourage projects to still
hit these goals and track them in someway.

It also makes those changes much quicker to update for projects as they don't
have to go through the entire governance merge process.

> 3. We could do nothing to record the work related to the goal.
>
> I like option 2, because it means we will be consistent with future
> tracking data and we end up with fewer changes in the governance repo
> (which was the reason for moving to storyboard in the first place).
>
> What do others think?
>
> Doug
>
> [1] https://review.openstack.org/#/c/557863/
>
> __
> OpenStack Development Mailing 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] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi Training Team,

It’s a friendly reminder that our next meeting is in an hour, 2000 UTC, on 
#openstack-meeting-3.

Agenda is here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you in a bit!

Thanks,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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] Ironic Status Updates

[Julia Kreger]

Greetings everyone,

For some time, Rama Yeleswarapu (rama_y) has been graciously sending
out a weekly update for Ironic to the mailing list. We found out late
last week that this contributor would be unable to continue to do so.
While discussing this and searching for a volunteer, we came up with
two important questions that we determined should have some answers.

The first being. Is anyone finding a weekly email useful for Ironic?

The second being: If it is useful, would there be an alternative
format that may be even more useful? Largely it is presently a
copy/paste of our general purpose whiteboard. Perhaps a stream of
consciousness or commentary to convey the delta from week to week?

-Julia

__
OpenStack Development Mailing 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] CI & Tempest squad planning summary: Sprint 13

[Matt Young]

Greetings,

The TripleO CI & Tempest squads have begun work on Sprint 13.  Like most of
our sprints these are three weeks long and are planned on a Thursday or
Friday (depending on squad) and have a retrospective on Wednesday.  Sprint
13 runs from 2018-05-03 thru 2018-05-23.

More information regarding our process is available in the tripleo-specs
repository [1]. Ongoing meeting notes and other detail are always available
in the Squad Etherpads [2,3].

This sprint the CI squad is working on the Upgrades epic, and the Tempest
squad is refactoring python-tempestconf to in part enable the upstream
refstack group.


## Ruck / Rover:

* Matt Young (myoung) and Sagi Shnaidman (sshnaidm)
* https://review.rdoproject.org/etherpad/p/ruckrover-sprint13


## CI Squad

* Put in place voting update jobs (
https://review.openstack.org/#/q/topic:gate_update)
* Add additional check/gate jobs to gate changes made this sprint.
* Refine the design for how we model releases in CI, taking into account
feedback from a collaborative design session with the Upgrades team
(etherpad http://ow.ly/da5L30jSeo8).

Epic: https://trello.com/c/cuKevn28/728-sprint-13-upgrades-goals
Tasks: http://ow.ly/yeIf30jScyj


## Tempest Squad

* Refactor pythyon-tempestconf tempest config by dynamically discovering
resources

In Scope: Keystone, Nova, Glance, Neutron, Cinder, Swift.

The following are specifically NOT in scope for Sprint 13  They are
tentatively planned for future sprints: Heat, Ironic, ec2api, Zaquar,
Mistral, Manila, Octavia, Horizon, Ceilometer.

Epic:
https://trello.com/c/efqE5XMr/734-sprint-13-refactor-python-tempestconf
Tasks: http://ow.ly/YOXh30jScEw


For any questions please find us in #tripleo

Thanks,

Matt

[1]
https://github.com/openstack/tripleo-specs/blob/master/specs/policy/ci-team-structure.rst
[2] https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
[3] https://etherpad.openstack.org/p/tripleo-tempest-squad-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

[openstack-dev] [neutron] Bug deputy report

[Hongbin Lu]

Hi all,

Below is the bug deputy report for last week (Apr 30 - May 6).

* https://bugs.launchpad.net/neutron/+bug/1767811 Confirmed. In DVR scenario, 
VM capture unexpected packet that should not be sent to the VM. The bug 
reporter self-assigned this bug.
* https://bugs.launchpad.net/neutron/+bug/1767829 Confirmed. Fullstack security 
group tests fails often on gate. Slawek Kaplonski is looking at it.
* https://bugs.launchpad.net/neutron/+bug/1768209 Confirmed. Some tempest tests 
don't check the 'l3-ha' extension when using the 'ha' attribute of routers. 
Dongcan Ye took this bug.
* https://bugs.launchpad.net/neutron/+bug/1768690 New. This is a RFE. Ironic 
team requested to add support for re-generating MAC address when updating a 
port. Neutron Driver team is looking at it.
* https://bugs.launchpad.net/neutron/+bug/1768952 In Progress. Neutron returned 
500 error on listing availability zones with filters. Hongbin Lu is working on 
a fix.
* https://bugs.launchpad.net/neutron/+bug/1768990 In Progress. External bridge 
is not re-configured if it is removed and re-created. Slawek Kaplonski is 
working on it.

Best regards,
Hongbin

__
OpenStack Development Mailing 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][requirements] uncapping eventlet

[Michel Peterson]

On Fri, Apr 20, 2018 at 11:06 PM, Doug Hellmann 
wrote:

>
> We have made great progress on this but we do still have quite a
> few of these patches that have not been approved.  Many are failing
> test jobs and will need a little attention ( the failing requirements
> jobs are real problems and rechecking will not fix them).  If you
> have time to help, please jump in and take over a patch and get it
> working.
>
> https://review.openstack.org/#/q/status:open+topic:uncap-eventlet
>
>
I did a script to fix those and I've submitted patches.
__
OpenStack Development Mailing 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] Technical Committee Status update, 7 May

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

There is a patch to update the Python 3.5 goal for Kolla [1]. The
change adds a new deliverable to the old goal, and it isn't clear
whether we want to do that. TC members, please share your opinion
in the openstack-dev thread [2].

[1] https://review.openstack.org/557863
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130236.html

I expanded the discussion of dropping py27 support from the original
governance patch [3] by starting a mailing list thread to discuss
a more detailed deprecation process and timeline [4]. There will
also be a forum session covering this topic in Vancouver [5].

[3] https://review.openstack.org/561922
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129866.html
[5] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21741/python-2-deprecation-timeline

John Garbutt started drafting a first constellation to describe
scientific computing workload use cases [6]. After some discussion
on that patch and in IRC, I proposed that we create a separate
repository to hold the constellation documents [7]. That repo now
exists, with the documentation team and TC as members of the core
review team.  There is a proposal to add it to the documentation
team's repo list [8].

* We could use volunteers to help finish making that repository
  ready to publish properly and to document the constellations
  sub-team in the documentation contributor's guide. Please contact
  me directly if you can help.

[6] https://review.openstack.org/565466
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130068.html
[8] https://review.openstack.org/565877

The change to retire the kolla-kubernetes project has reached a
majority and will be approved on 10 May [9].

[9] https://review.openstack.org/#/c/565385/

The Adjutant project application [10] is still under review, and
the only votes registered are opposed. I anticipate having the topic
of how we review project applications as one of several items we
discuss during the TC retrospective session as the summit [11].

[10] https://review.openstack.org/553643
[11] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21740/tc-retrospective

After a bit of discussion in IRC with Lance Bragstad and Harry
Rybacki, we agreed to try having the Keystone team manage the
implementation of a new spec for defining default roles across all
OpenStack services, rather than trying to review the openstack-specs
repository and review process. See [12] for details.

[12] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130207.html

== TC member actions/focus/discussions for the coming week(s) ==

I have added the two items raised by TC members raised to the draft
agenda for the joint Board/TC/UC meeting to be held in Vancouver
(see the wiki page [13] under "Strategic Discussions" and "Next
steps for fixing bylaws typo"). Please keep in mind that the time
allocations and content of the meeting are still subject to change.

[13] https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMeeting

We will also hold a retrospective for the TC as a team on Monday
at the Forum.  Please be prepared to discuss things you think are
going well, things you think we need to change, items from our
backlog that you would like to work on, etc. [11]

I need to revise the patch to update the expectations for goal
champions based on existing feedback. [14]

[14] https://review.openstack.org/564060

We have several items on our backlog that need owners. TC members,
please review the storyboard list [15] and consider taking on one
of the tasks that we agreed we would do.

[15] https://storyboard.openstack.org/#!/project/923

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

If you expect your topic to require significant discussion or to
need input from members of the community other 

Re: [openstack-dev] [nova] Extra feature of vCPU allocation on demands

[Jay Pipes]

On 05/07/2018 05:55 AM, 倪蔚辰 wrote:

Hi, all

I would like to propose a blueprint (not proposed yet), which is related 
to openstack nova. I hope to have some comments by explaining my idea 
through this e-mail. Please contact me if anyone has any comment.


Background

Under current OpenStack, vCPUs assigned to each VM can be configured as 
dedicated or shared. In some scenarios, such as deploying Radio Access 
Network VNF, the VM is required to have dedicated vCPUs to insure the 
performance. However, in that case, each VM has a vCPU to do Guest OS 
housekeeping. Usually, this vCPU is not a high performance required vCPU 
and do not take high percentage of dedicated vCPU utilization. There is 
some vCPU resources waste.


Proposed feature

I hope to add an extra feature to flavor extra specs. It refers to how 
many dedicated vCPUs and how many shared vCPUs are needed for the VM. 
When VM requires vCPU, OpenStack allocates vCPUs on demands. In the 
background scenario, this idea can save many dedicated vCPUs which take 
Guest OS housekeeping. And the scenario stated above is only one use 
case for the feature. This feature potentially allows user to have more 
flexible VM design to save CPU resource.


Please see here:

https://review.openstack.org/#/c/555081/

Best,
-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] [nova] Extra feature of vCPU allocation on demands

[Eric Fried]

I will be interested to watch this develop.  In PowerVM we already have
shared vs. dedicated processors [1] along with concepts like capped vs.
uncapped, min/max proc units, weights, etc.  But obviously it's all
heavily customized to be PowerVM-specific.  If these concepts made their
way into mainstream Nova, we could hopefully adapt to use them and
remove some tech debt.

[1]
https://github.com/openstack/nova/blob/master/nova/virt/powervm/vm.py#L372-L401

On 05/07/2018 04:55 AM, 倪蔚辰 wrote:
> Hi, all
> 
> I would like to propose a blueprint (not proposed yet), which is related
> to openstack nova. I hope to have some comments by explaining my idea
> through this e-mail. Please contact me if anyone has any comment.
> 
>  
> 
> Background
> 
> Under current OpenStack, vCPUs assigned to each VM can be configured as
> dedicated or shared. In some scenarios, such as deploying Radio Access
> Network VNF, the VM is required to have dedicated vCPUs to insure the
> performance. However, in that case, each VM has a vCPU to do Guest OS
> housekeeping. Usually, this vCPU is not a high performance required vCPU
> and do not take high percentage of dedicated vCPU utilization. There is
> some vCPU resources waste.
> 
>  
> 
> Proposed feature
> 
> I hope to add an extra feature to flavor extra specs. It refers to how
> many dedicated vCPUs and how many shared vCPUs are needed for the VM.
> When VM requires vCPU, OpenStack allocates vCPUs on demands. In the
> background scenario, this idea can save many dedicated vCPUs which take
> Guest OS housekeeping. And the scenario stated above is only one use
> case for the feature. This feature potentially allows user to have more
> flexible VM design to save CPU resource.
> 
>  
> 
> Thanks.
> 
>  
> 
> Weichen
> 
> e-mail: niweic...@chinamobile.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
> 

__
OpenStack Development Mailing 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] [horizon] No meeting this week

[Ivan Kolodyazhny]

Hi team,

Due to the Victory Day, I won't be able to chair the meeting this week.
After a short conversation in the IRC, we decided to skip this meeting.
Feel free to add your topic to
https://wiki.openstack.org/wiki/Meetings/Horizon and see you next week!

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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] [nova] review runway status

[melanie witt]

Howdy everyone,

This is just a brief status about the blueprints currently occupying
review runways [0] and an ask for the nova-core team to give these
reviews priority for their code review focus.

* XenAPI: Support a new image handler for non-FS based SRs
https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement 


(jianghuaw_) [END DATE: 2018-05-11] series starting at
https://review.openstack.org/497201

* Add z/VM driver
https://blueprints.launchpad.net/nova/+spec/add-zvm-driver-rocky
(jichen) [END DATE: 2018-05-15] spec amendment
https://review.openstack.org/562154 and implementation series starting
at https://review.openstack.org/523387

* Local disk serial numbers 
https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers 
(mdbooth) [END DATE: 2018-05-16] series starting at 
https://review.openstack.org/526346


Cheers,
-melanie

[0] https://etherpad.openstack.org/p/nova-runways-rocky

__
OpenStack Development Mailing 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] TripleO deployment on OVB on public cloud

[Ben Nemec]

Hi,

I wanted to make everyone aware that I recorded a demo of running an OVB 
deployment on a public cloud.  As I say in the video, this is 
significant because in the past OVB has largely been limited to running 
in our special-purpose CI clouds, which have distinctly finite capacity 
and are generally not as available for developer access.  Anybody can 
use a public cloud though, and it opens up a bunch more potential capacity.


Anyway, the demo and a more detailed writeup are available here: 
http://blog.nemebean.com/content/openstack-virtual-baremetal-public-cloud


It's running on Vexxhost because that's the first public cloud I found 
that had all the features necessary to run OVB.  If anyone knows of 
others that meet the requirements I'd certainly be interested to hear 
about it.


Hopefully this can help with the developer hardware constraints that we 
seem to be constantly fighting in TripleO.  Let me know if you have any 
feedback.


Thanks.

-Ben

__
OpenStack Development Mailing 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][goals] tracking status of old goals for new projects

[Jeremy Stanley]

On 2018-05-07 09:52:16 -0400 (-0400), Doug Hellmann wrote:
[...]
> 3. We could do nothing to record the work related to the goal.
[...]

For situations like 557863 I think I'd prefer either the status quo
(the kolla deliverable _was_ already listed so it could make
sense to update it in that document) or option #3 (the cycle for
that goal is already well in the past, and certainly adding new
deliverables like kolla-kubernetes to a past goal sets unrealistic
expectations for future goals regardless of where we track them).

I really do, though, think we should simply accept that these goals
don't always (or even usually?) reach 100% coverage and that at some
point we need to be able to consider better means of keeping track
of, e.g., which deliverables work on which Python versions. The
goals process is excellent for reaching critical mass on such
efforts, but should not be considered a source of long-term support
documentation.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

[openstack-dev] [tc][goals] tracking status of old goals for new projects

[Doug Hellmann]

There is a patch to update the Python 3.5 goal for Kolla [1]. While
I'm glad to see the work happening, the change adds a new deliverable
to an old goal, and it isn’t clear whether we want to use that
approach for tracking goal work indefinitely. I see a few options.

1. We could update the existing document.

2. We could set up stories in storyboard like we are doing for newer
   goals.

3. We could do nothing to record the work related to the goal.

I like option 2, because it means we will be consistent with future
tracking data and we end up with fewer changes in the governance repo
(which was the reason for moving to storyboard in the first place).

What do others think?

Doug

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

__
OpenStack Development Mailing 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][ptls] final stages of python 3 transition

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2018-05-07 13:36:34 +0200:
> We've been juggling with python3, ansible and multiple distros for a while 
> now.
> That dance hasn't been fruitful: many hidden issues, either due to
> ansible modules, or our own modules, or upgrade issues.
> 
> I've recently decided to simplify the python2/3 story.
> 
> Queens and all the stable branches will be python2 only (python3 will
> not be used anymore, to simplify the code)
> 
> For Rocky, we plan to use as much as possible the distribution
> packages for the python stack, if it's recent enough for our source
> installs.
> Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no
> appropriate package, so we are pip installing things (and using
> python2).
> So... If people work on Ubuntu 18.04 support, we could try a python3
> only system. Nobody worked on it right now.
> Same for CentOS, because there is no usage of packages, we could use
> Software Collections and have centos as a python3 only system. Sadly,
> nobody has the cycles to do it now.
> 
> I am expecting we'll be using/seeing a lot more python3 in the future
> with S, and wish for a python3 only "S" release.
> But this solely depends on the work done in R to make sure 18.04 is
> ready, as this would be our example, and "stepping stone" towards both
> python2 and python3.
> 
> I am not sure this answers your question, as this is more gray than a
> black or white answer.
> But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04
> at least, and other distros as a stretch goal.
> 
> Best regards,
> Jean-Philippe Evrard (evrardjp)
> 

I think your answer does help. It sounds like, unsurprisingly, you are
depending on work upstream in two different directions: You need the
OpenStack contributor community to ensure the code works on the platform
using Python 3, and then you need the OS vendors to provide appropriate
packages using Python 3.

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

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

[Jean-Philippe Evrard]

We've been juggling with python3, ansible and multiple distros for a while now.
That dance hasn't been fruitful: many hidden issues, either due to
ansible modules, or our own modules, or upgrade issues.

I've recently decided to simplify the python2/3 story.

Queens and all the stable branches will be python2 only (python3 will
not be used anymore, to simplify the code)

For Rocky, we plan to use as much as possible the distribution
packages for the python stack, if it's recent enough for our source
installs.
Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no
appropriate package, so we are pip installing things (and using
python2).
So... If people work on Ubuntu 18.04 support, we could try a python3
only system. Nobody worked on it right now.
Same for CentOS, because there is no usage of packages, we could use
Software Collections and have centos as a python3 only system. Sadly,
nobody has the cycles to do it now.

I am expecting we'll be using/seeing a lot more python3 in the future
with S, and wish for a python3 only "S" release.
But this solely depends on the work done in R to make sure 18.04 is
ready, as this would be our example, and "stepping stone" towards both
python2 and python3.

I am not sure this answers your question, as this is more gray than a
black or white answer.
But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04
at least, and other distros as a stretch goal.

Best regards,
Jean-Philippe Evrard (evrardjp)

__
OpenStack Development Mailing 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-ansible] Implement rotations for meetings handling

[Jean-Philippe Evrard]

I think Jesse sumarized things elegantly.

Here is an analogy for you, to complement the answer with more
background. Let me compare our state with a new company,
as this is a a notion people many people can relate to.

Initially we were a startup. Only a few people were working on OSA on
its creation. And they were busy doing everything.
But then we grew, and we continue to grow. At some point, those few
people doing everything didn't (or don't) have the time to do
everything anymore (because of the growing nature). So OSA, like any
business, needs to learn how to grow bigger.

One of the way is to distribute work as much as we can into the more
appropriate persons.
We started doing that by distributing core duties for roles.
We are now adding the meeting organisation.
I have a few other ideas where shared ownership will help the project
mature and allow more growth in the future, but one step at a time :)

Best regards,
Jean-Philippe Evrard (evrardjp)

__
OpenStack Development Mailing 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] [tempest] Proposing Felipe Monteiro for Tempest core

[Andrea Frittoli]

+1!!



On Sat, 28 Apr 2018, 11:29 am Ghanshyam Mann, 
wrote:

> Hi Tempest Team,
>
> I would like to propose  Felipe Monteiro (irc: felipemonteiro) to Tempest
> core.
>
> Felipe has been an active contributor to the Tempest  since the Pike
> cycle. He has been doing lot of review and commits since then. Filling
> the gaps on service clients side and their testing and lot other
> areas. He has demonstrated the good quality and feedback while his
> review.
>
> He has good understanding of Tempest source code and project missions
> & goal. IMO his efforts are highly valuable and it will be great to
> have him in team.
>
>
> As per usual practice, please vote +1 or -1 to the nomination. I will
> keep this nomination open for a week or until everyone voted.
>
> Felipe Reviews and Commit -
>
> https://review.openstack.org/#/q/reviewer:felipe.monte...@att.com+project:openstack/tempest
>
> https://review.openstack.org/#/q/owner:felipe.monte...@att.com+project:openstack/tempest
>
> -gmann
>
> __
> OpenStack Development Mailing 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-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Hi all,

I updated more information to this guideline in [1].
Please must take a view on [1] to see what's been updated.
will likely to keep update on that etherpad if new Q or issue found.

Will keep trying to make this process as painless for you as possible,
so please endure with us for now, and sorry for any inconvenience

*[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
*

2018-05-05 12:15 GMT+08:00 Rico Lin :

> looping heat-dashboard team
>
> 2018-05-05 12:02 GMT+08:00 Rico Lin :
>
>> Dear all Heat members and friends
>>
>> As you might award, OpenStack projects are scheduled to migrating ([5])
>> from Launchpad to StoryBoard [1].
>> For whom who like to know where to file a bug/blueprint, here are some
>> heads up for you.
>>
>> *What's StoryBoard?*
>> StoryBoard is a cross-project task-tracker, contains numbers of
>> ``project``, each project contains numbers of ``story`` which you can think
>> it as an issue or blueprint. Within each story, contains one or multiple
>> ``task`` (task separate stories into the tasks to resolve/implement). To
>> learn more about StoryBoard or how to make a good story, you can reference
>> [6].
>>
>> *How to file a bug?*
>> This is actually simple, use your current ubuntu-one id to access to
>> storyboard. Then find the corresponding project in [2] and create a story
>> to it with a description of your issue. We should try to create tasks which
>> to reference with patches in Gerrit.
>>
>> *How to work on a spec (blueprint)?*
>> File a story like you used to file a Blueprint. Create tasks for your
>> plan. Also you might want to create a task for adding spec( in heat-spec
>> repo) if your blueprint needs documents to explain.
>> I still leave current blueprint page open, so if you like to create a
>> story from BP, you can still get information. Right now we will start work
>> as task-driven workflow, so BPs should act no big difference with a bug in
>> StoryBoard (which is a story with many tasks).
>>
>> *Where should I put my story?*
>> We migrate all heat sub-projects to StoryBoard to try to keep the impact
>> to whatever you're doing as small as possible. However, if you plan to
>> create a new story, *please create it under heat project [4]* and tag it
>> with what it might affect with (like python-heatclint, heat-dashboard,
>> heat-agents). We do hope to let users focus their stories in one place so
>> all stories will get better attention and project maintainers don't need to
>> go around separate places to find it.
>>
>> *How to connect from Gerrit to StoryBoard?*
>> We usually use following key to reference Launchpad
>> Closes-Bug: ###
>> Partial-Bug: ###
>> Related-Bug: ###
>>
>> Now in StoryBoard, you can use following key.
>> Task: ##
>> Story: ##
>> you can find more info in [3].
>>
>> *What I need to do for my exists bug/bps?*
>> Your bug is automatically migrated to StoryBoard, however, the reference
>> in your patches ware not, so you need to change your commit message to
>> replace the old link to launchpad to new links to StoryBoard.
>>
>> *Do we still need Launchpad after all this migration are done?*
>> As the plan, we won't need Launchpad for heat anymore once we have done
>> with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
>> provide new information as many as possible. Hopefully, we can make
>> everyone happy. For those newly created bugs during/after migration, don't
>> worry we will disallow further create new bugs/bps and do a second migrate
>> so we won't missed yours.
>>
>> [1] https://storyboard.openstack.org/
>> [2] https://storyboard.openstack.org/#!/project_group/82
>> [3] https://docs.openstack.org/infra/manual/developers.html#
>> development-workflow
>> [4] https://storyboard.openstack.org/#!/project/989
>> [5] https://docs.openstack.org/infra/storyboard/migration.html
>> [6] https://docs.openstack.org/infra/storyboard/gui/tasks_
>> stories_tags.html#what-is-a-story
>>
>>
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [nova] Extra feature of vCPU allocation on demands

[倪蔚辰]

Hi, all

I would like to propose a blueprint (not proposed yet), which is related to
openstack nova. I hope to have some comments by explaining my idea through
this e-mail. Please contact me if anyone has any comment. 

 

Background

Under current OpenStack, vCPUs assigned to each VM can be configured as
dedicated or shared. In some scenarios, such as deploying Radio Access
Network VNF, the VM is required to have dedicated vCPUs to insure the
performance. However, in that case, each VM has a vCPU to do Guest OS
housekeeping. Usually, this vCPU is not a high performance required vCPU and
do not take high percentage of dedicated vCPU utilization. There is some
vCPU resources waste. 

 

Proposed feature

I hope to add an extra feature to flavor extra specs. It refers to how many
dedicated vCPUs and how many shared vCPUs are needed for the VM. When VM
requires vCPU, OpenStack allocates vCPUs on demands. In the background
scenario, this idea can save many dedicated vCPUs which take Guest OS
housekeeping. And the scenario stated above is only one use case for the
feature. This feature potentially allows user to have more flexible VM
design to save CPU resource. 

 

Thanks.

 

Weichen 

e-mail: niweic...@chinamobile.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] [tap-as-a-service] publish on pypi

[Takashi Yamamoto]

thank you. done. https://pypi.org/project/tap-as-a-service/

On Fri, Mar 30, 2018 at 8:27 AM, Clark Boylan  wrote:
> On Wed, Mar 28, 2018, at 7:59 AM, Takashi Yamamoto wrote:
>> hi,
>>
>> i'm thinking about publishing the latest release of tap-as-a-service on pypi.
>> background: https://review.openstack.org/#/c/555788/
>> iirc, the naming (tap-as-a-service vs neutron-taas) was one of concerns
>> when we talked about this topic last time. (long time ago. my memory is dim.)
>> do you have any ideas or suggestions?
>> probably i'll just use "tap-as-a-service" unless anyone has strong opinions.
>> because:
>> - it's the name we use the most frequently
>> - we are not neutron (yet?)
>
> http://git.openstack.org/cgit/openstack/tap-as-a-service/tree/setup.cfg#n2 
> shows that tap-as-a-service is the existing package name so probably a good 
> one to go with as anyone that already has it installed from source should 
> have pip do the right thing when talking to pypi.
>
> Clark
>
> __
> OpenStack Development Mailing 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] [Zun] Announce change of Zun core reviewer team

[Shu M.]

+1. Welcome!!

Cheers,
Shu

2018-05-03 12:20 GMT+09:00 Shuai Zhao :

> +1 for Ji Wei :-)
>
> On Thu, May 3, 2018 at 4:40 AM, Hongbin Lu  wrote:
>
>> Hi all,
>>
>> I would like to announce the following change on the Zun core reviewers
>> team:
>>
>> + Ji Wei
>>
>> Ji Wei has been working on Zun for a while. His contributions include
>> blueprints, bug fixes, code reviews, etc. In particular, I would like to
>> highlight that he has implemented two blueprints [1][2], both of which are
>> not easy to implement. Based on his high-quality work in the past, I
>> believe he will serve the core reviewer role very well.
>>
>> This proposal had been voted within the existing core team and was
>> unanimously approved. Welcome to the core team Ji Wei.
>>
>> [1] https://blueprints.launchpad.net/zun/+spec/glance-support-tag
>> [2] https://blueprints.launchpad.net/zun/+spec/zun-rebuild-on-local-node
>>
>> Best regards,
>> Hongbin
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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