[openstack-dev] [infra] Add support of different local.conf for subnodes

[joehuang]

Hello,

Very glad to know this patch "Add support of different local.conf for 
sub-nodes" https://review.openstack.org/#/c/407424/

Would like to know if each sub-node is allowed to use different local.conf, 
then can I customize the local.conf in primary-node and sub-node to setup 
multi-region gate/check test environment like 
http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup?

There are many repositories involved in multi-node devstack based gate/check 
test job, no clue how to customize the local.conf for sub-nodes, any help/guide 
would be appreciated.

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] [mistral][logo] Fwd: Mistral team draft logo

[Renat Akhmerov]

Please provide your feedback on the draft logo for Mistral.

My opinion: I think it looks pretty nice and it has valid associations in my 
mind with what Mistral does. Looking forward to seeing it coloured.

Renat Akhmerov
@Nokia

> Begin forwarded message:
> 
> From: Heidi Joy Tretheway 
> Subject: Mistral team draft logo
> Date: 2 December 2016 at 02:27:05 GMT+7
> To: Renat Akhmerov 
> 
> Thanks to you and your team for your patience as our illustrators created 
> nearly 60 project mascot logos. As I alerted you earlier, we weren’t happy 
> with the initial draft, so we pushed our illustrators to create a logo that 
> we’re truly happy with before we shared it with your team to review/react to 
> it. 
> 
> We now have a draft logo (without color) and we’d love for you to share this 
> form with your team for feedback: www.tinyurl.com/OSmascot 
>   - This really helps us stay organized, 
> evaluate conflicting feedback, and give a clear direction to the illustrators!
> 
> Please feel free to share this with your team and we’d love to have your 
> feedback by Tuesday, Dec. 13. I will be out of the office Dec. 2-12 but I 
> promise to respond to questions as swiftly as possible when I return, and the 
> feedback form includes an opportunity to flag me if you’d like a personal 
> reply to your comments on it.
> 
> We’re doing our best to get these ready for the PTG and I really appreciate 
> your team’s patience!
> 
> 
>   
> Heidi Joy Tretheway
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769  | Skype: heidi.tretheway 
> 
>     
>  
> 
> 

__
OpenStack Development Mailing 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] [devstack]VersionConflict exception during stack.sh - resend with explanation.

[Lenny Verkhovsky]

Hi Wanjing,
We had some similar issues in our CI, especially after we are running one of 
the stable branches.
The current workaround we’d found is removing all pip packs after devstack 
./clean.sh

Thanks
Lenny.

-Original Message-
From: Wanjing Xu (waxu) [mailto:w...@cisco.com] 
Sent: Wednesday, December 7, 2016 8:21 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [devstack]VersionConflict exception during 
stack.sh - resend with explanation.

Thanks Tony for reply
This is Jenkins third party.  So it is doing unstack and removing repo and 
stack again from master branch.  

It has been running OK and then it was disable for about a month.  Now when we 
reenabled it, it has this versionconflict one-by-one.  After I manually 
installed the required version for a lot of modules, it is OK now.  But I was 
just wondering why it won’t install the required package automatically instead 
of throwing exception?

You can look at our ci http://192.133.158.2:8080/job/cisco_zm_cinder/, look at 
all the failed cases yesterday.  I manually invoked pip install –c –e …   it 
will throw exception, is this really expected?  If it is not replace the 
modules with the required version, this kind of failure will happen again if 
somebody changed the requirement or constraints.

localadmin@ubuntu-dmz:/opt/stack/horizon$ sudo -H http_proxy= https_proxy= 
no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite 
/usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt 
-v -e /opt/stack/horizon Ignoring dnspython3: markers 'python_version == "3.4"' 
don't match your environment Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment Obtaining file:///opt/stack/horizon
  Running setup.py (path:/opt/stack/horizon/setup.py) egg_info for package from 
file:///opt/stack/horizon
Running command python setup.py egg_info
running egg_info
writing requirements to horizon.egg-info/requires.txt
writing horizon.egg-info/PKG-INFO
writing top-level names to horizon.egg-info/top_level.txt
writing dependency_links to horizon.egg-info/dependency_links.txt
writing pbr to horizon.egg-info/pbr.json
[pbr] Processing SOURCES.txt
[pbr] In git context, generating filelist from git
warning: no files found matching 'AUTHORS'
warning: no files found matching 'ChangeLog'
warning: no previously-included files matching '*.pyc' found anywhere in 
distribution
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.scss' under directory 'doc'
warning: no files found matching '*.js' under directory 'doc'
warning: no files found matching '*.html' under directory 'doc'
warning: no files found matching '*.conf' under directory 'doc'
warning: no files found matching '*.jpg' under directory 'doc'
warning: no files found matching '*.gif' under directory 'doc'
warning: no files found matching '*.csv' under directory 'horizon'
warning: no files found matching '*.template' under directory 'horizon'
warning: no files found matching '*.mo' under directory 'horizon'
warning: no files found matching '*.mo' under directory 
'openstack_dashboard'
warning: no files found matching '*.eot' under directory 
'openstack_dashboard'
warning: no files found matching '*.ttf' under directory 
'openstack_dashboard'
warning: no files found matching '*.woff' under directory 
'openstack_dashboard'
warning: no files found matching 'AUTHORS'
warning: no files found matching 'ChangeLog'
warning: no files found matching 'doc/source/_templates/.placeholder'
warning: no previously-included files found matching 
'openstack_dashboard/local/local_settings.py'
writing manifest file 'horizon.egg-info/SOURCES.txt'
  Source in /opt/stack/horizon has version 11.0.0.0b2.dev67, which satisfies 
requirement horizon==11.0.0.0b2.dev67 from file:///opt/stack/horizon Cleaning 
up...
Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, 
in main
status = self.run(options, args)
  File "/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 
335, in run
wb.build(autobuilding=True)
  File "/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
self.requirement_set.prepare_files(self.finder)
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, 
in prepare_files
ignore_dependencies=self.ignore_dependencies))
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, 
in _prepare_file
req_to_install.check_if_exists()
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 
1036, in check_if_exists
self.req.name
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
dist = 

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Jeffrey Zhang]

zhubingbing,

Congratulations, the vote passed with ( 10 votes, without a veto ).

I've added you to the appropriate group in Gerrit.  I'll give you
some training on the policies for core reviewers.

PS: Since Michal is out on vacation recently, I will take the PTL
duty for a while.

On Fri, Dec 2, 2016 at 11:05 AM, Swapnil Kulkarni 
wrote:

> On Tue, Nov 29, 2016 at 9:51 PM, Michał Jastrzębski 
> wrote:
> > Hello team!
> >
> > I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> > core teams. He did great job reviewing code during last couple of
> > months.
> >
> > Consider this proposal +1 from me, voting will be open for 1 week
> > (until Dec 6) or if we get unanimous agreement (or veto) before.
> >
> > Regards,
> > Michal
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> +1
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [devstack]VersionConflict exception during stack.sh - resend with explanation.

[Wanjing Xu (waxu)]

Thanks Tony for reply
This is Jenkins third party.  So it is doing unstack and removing repo and 
stack again from master branch.  

It has been running OK and then it was disable for about a month.  Now when we 
reenabled it, it has this versionconflict one-by-one.  After I manually 
installed the required version for a lot of modules, it is OK now.  But I was 
just wondering why it won’t install the required package automatically instead 
of throwing exception?

You can look at our ci http://192.133.158.2:8080/job/cisco_zm_cinder/, look at 
all the failed cases yesterday.  I manually invoked pip install –c –e …   it 
will throw exception, is this really expected?  If it is not replace the 
modules with the required version, this kind of failure will happen again if 
somebody changed the requirement or constraints.

localadmin@ubuntu-dmz:/opt/stack/horizon$ sudo -H http_proxy= https_proxy= 
no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite 
/usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt 
-v -e /opt/stack/horizon
Ignoring dnspython3: markers 'python_version == "3.4"' don't match your 
environment
Ignoring dnspython3: markers 'python_version == "3.5"' don't match your 
environment
Obtaining file:///opt/stack/horizon
  Running setup.py (path:/opt/stack/horizon/setup.py) egg_info for package from 
file:///opt/stack/horizon
Running command python setup.py egg_info
running egg_info
writing requirements to horizon.egg-info/requires.txt
writing horizon.egg-info/PKG-INFO
writing top-level names to horizon.egg-info/top_level.txt
writing dependency_links to horizon.egg-info/dependency_links.txt
writing pbr to horizon.egg-info/pbr.json
[pbr] Processing SOURCES.txt
[pbr] In git context, generating filelist from git
warning: no files found matching 'AUTHORS'
warning: no files found matching 'ChangeLog'
warning: no previously-included files matching '*.pyc' found anywhere in 
distribution
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.scss' under directory 'doc'
warning: no files found matching '*.js' under directory 'doc'
warning: no files found matching '*.html' under directory 'doc'
warning: no files found matching '*.conf' under directory 'doc'
warning: no files found matching '*.jpg' under directory 'doc'
warning: no files found matching '*.gif' under directory 'doc'
warning: no files found matching '*.csv' under directory 'horizon'
warning: no files found matching '*.template' under directory 'horizon'
warning: no files found matching '*.mo' under directory 'horizon'
warning: no files found matching '*.mo' under directory 
'openstack_dashboard'
warning: no files found matching '*.eot' under directory 
'openstack_dashboard'
warning: no files found matching '*.ttf' under directory 
'openstack_dashboard'
warning: no files found matching '*.woff' under directory 
'openstack_dashboard'
warning: no files found matching 'AUTHORS'
warning: no files found matching 'ChangeLog'
warning: no files found matching 'doc/source/_templates/.placeholder'
warning: no previously-included files found matching 
'openstack_dashboard/local/local_settings.py'
writing manifest file 'horizon.egg-info/SOURCES.txt'
  Source in /opt/stack/horizon has version 11.0.0.0b2.dev67, which satisfies 
requirement horizon==11.0.0.0b2.dev67 from file:///opt/stack/horizon
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, 
in main
status = self.run(options, args)
  File "/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 
335, in run
wb.build(autobuilding=True)
  File "/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
self.requirement_set.prepare_files(self.finder)
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, 
in prepare_files
ignore_dependencies=self.ignore_dependencies))
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, 
in _prepare_file
req_to_install.check_if_exists()
  File "/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 
1036, in check_if_exists
self.req.name
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
dist = get_provider(dist)
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
needed = self.resolve(parse_requirements(requirements))
  File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
raise VersionConflict(dist, 

Re: [openstack-dev] [OpenStack-Infra] [Infra] Ocata Summit Infra Sessions Recap

[Joshua Hesketh]

Thank you for the write up. Having missed being there in person it is much
appreciated :-)

On Wed, Dec 7, 2016 at 5:56 AM, Jeremy Stanley  wrote:

> I'm Cc'ing this to the openstack-infra ML but setting MFT to direct
> subsequent discussion to the openstack-dev ML so we can hopefully
> avoid further cross-posting as much as possible. If you're replying
> on a particular session topic, please update the Subject so that the
> subthreads are easier to keep straight.
>
> Apologies for the _extreme_ delay in getting this composed and sent
> out!
>
>
> Firehose
> 
>
> https://etherpad.openstack.org/p/ocata-infra-firehose
>
> This was primarily a brainstorming/roadmap session on possible
> future plans for the firehose.openstack.org service. Discussed was
> potential to have Zuul (post-v3) both consume and emit events over
> MQTT, as well as having StoryBoard (should probably support an
> analog of the events handled by lpmqtt at a minimum, probably easy
> to add given it already has an RabbitMQ one) and Nodepool event
> streams. The gerritbot consumer PoC was mentioned, but determined
> that it would be better to shelve that until planning for an
> Errbot-based gerritbot reimplementation is fleshed out.
>
> We talked about how the current logstash MQTT stream implementation,
> while interesting, has significant scaling (especially bandwidth)
> issues with the volume of logging we do in tests while only offering
> limited benefit. We could potentially make use of it in concern with
> a separate logstash for production server and Ansible logs, but it's
> efficacy for our job logs was called into question.
>
> We also spent much of the timeslot talking about possible
> integration with FedMesg (particularly that they're considering
> pluggable backend support which could include an MQTT
> implementation), which yields much opportunity for collaboration
> between our projects.
>
> One other topic which came up was how to do a future HA
> implementation, either by having publishers send to multiple brokers
> and configure consumers to have a primary/fallback behavior or my
> trying to implement a more integrated clustering solution with load
> balancing proxies. We concluded that current use cases don't demand
> anywhere near 100% message delivery and 100% uptime, so we can dig
> deeper when there's an actual use case.
>
>
> Status update and plans for task tracking
> -
>
> https://etherpad.openstack.org/p/ocata-infra-community-task-tracking
>
> As is traditional, we held a fishbowl on our ongoing task tracking
> woes. We started with a brief introduction of stakeholders who
> attended and the groups whose needs they were there to represent.
> After that, some presentation was made of recent StoryBoard
> development progress since Austin (including Gerrit integration,
> private story support for embargoed security issues, improved event
> timelines, better discoverability for boards and worklists, flexible
> task prioritization), as well as the existing backlog of blockers.
>
> We revisited the Infra spec on task tracking
> http://specs.openstack.org/openstack-infra/infra-specs/
> specs/task-tracker.html
> for the benefit of those present, and Kendall Nelson (diablo_rojo)
> agreed to pick up and continue with the excellent stakeholder
> blocking issues outreach/coordination work begun by Anita Kuno
> (anteaya).
>
>
> Next steps for infra-cloud
> --
>
> https://etherpad.openstack.org/p/ocata-infra-infra-cloud
>
> This was sort of a catch-all opportunity to hash out current plans
> and upcoming needs for the infra-cloud. We determined that the
> current heterogeneous hardware in the in-progress "chocolate" region
> should be split into two homogeneous regions named "chocolate" and
> "strawberry" (our "vanilla" region was already homogeneous). We also
> talked about ongoing work to get a quote from OSUOSL for hosting the
> hardware so that we can move it out of HPE data centers, and
> attempting to find funding once we have some figures firmed up.
>
> There were also some sideline discussions on possible monitoring and
> high-availability options for the underlying services.
> Containerization was, as always, brought up but the usual "not a fit
> for this use case" answers abounded. It was further suggested that
> using infra-cloud resources for things like special TripleO tests or
> Docker registry hosting were somehow in scope, but there are other
> solutions to these needs which should not be conflated with the
> purpose of the infra-cloud effort.
>
>
> Interactive infra-cloud debugging
> -
>
> https://etherpad.openstack.org/p/ocata-infra-infra-cloud-debugging
>
> The original intent for this session was to try to gather
> leaders/representatives from the various projects that we're relying
> on in the infra-cloud deployment and step through an interactive
> session debugging the sorts of 

Re: [openstack-dev] [cinder] consistency groups in ceph

[yang, xing]

Just want to clarify that when the driver gets a list of volume objects as an 
input parameter in create_group_from_src, volume.name will be in the format of 
volume-.  If you look at the database, however, the display_name field is 
None.

Xing


From: yang, xing [xing.y...@dell.com]
Sent: Tuesday, December 6, 2016 11:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

No, the new cloned image (volume) will get this name (volume-uuid) 
automatically.  The driver does not need to specify a name.

Xing


From: Victor Denisov [vdeni...@mirantis.com]
Sent: Tuesday, December 6, 2016 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

Does it mean that ceph as a backend for this feature is supposed to
provide an API which allows to specify the name of each cloned image?

V.

On Tue, Dec 6, 2016 at 7:17 PM, yang, xing  wrote:
> The new image name should be volume-uuid if you don’t change 
> volume_name_template in cinder.conf.  The display_name field will be None for 
> the new volume.
>
> Xing
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, December 6, 2016 7:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> How are the names chosen for those new cloned images?
>
> On Tue, Dec 6, 2016 at 10:04 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Yes, you are right.
>>
>> Thanks,
>> Xing
>>
>> 
>> From: Victor Denisov [vdeni...@mirantis.com]
>> Sent: Monday, December 5, 2016 7:13 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: Jason Dillaman
>> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>>
>> I just realized that probably we create images from individual
>> snapshots of that consistency group and add those images to the new
>> consistency group.
>> Am I correct?
>>
>> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
>>> Or probably when we clone a consistency group from a snapshot we
>>> should clone all the images in this consistency group?
>>>
>>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  
>>> wrote:
 Hi Xing,

 One more question. You mentioned that there is an operation: create
 consistency group from a snap shot.
 Does it mean that an image can be a member of several consistency groups?

 Thanks,
 V.

 On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
> You cannot remove a volume completely if there is still a group snapshot. 
>  You can remove the volume from the group but you can’t delete the volume 
> because it still has snapshot dependent on it.  So if you want to 
> completely remove a volume that is in a group, you can delete the group 
> snapshot first which will delete the individual snapshot.  After that you 
> can remove the volume from the group and delete the volume.
>
> More comments inline below.
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, November 8, 2016 12:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> One more question. What is the expected behavior if you remove a
> volume completely?
> [Xing] You cannot remove the volume completely (delete volume won't 
> succeed) if there is still a group snapshot.
>
> Should the group snapshot removed first? Should the volume snapshot be
> removed from the group snapshot?
> [Xing] Yes, you should delete the group snapshot first and that will 
> delete the volume snapshot as well.
>
> Should we keep the snapshot even if the image doesn't exist anymore?
> [Xing] You cannot delete the image (volume) if there is still a snapshot.
>
> Thanks,
> Victor.
>
> On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Please see my answers inline below.
>>
>> In Newton, we added support for Generic Volume Groups.  See doc below.  
>> CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
>> not implement CGs any more.  Instead, it can add CG support using 
>> Generic Volume Group interfaces.  I'm working on a dev doc to explain 
>> how to do this and will send an email to the mailing list when I'm done. 
>>  The Generic Volume 

Re: [openstack-dev] [cinder] consistency groups in ceph

[yang, xing]

No, the new cloned image (volume) will get this name (volume-uuid) 
automatically.  The driver does not need to specify a name.

Xing


From: Victor Denisov [vdeni...@mirantis.com]
Sent: Tuesday, December 6, 2016 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

Does it mean that ceph as a backend for this feature is supposed to
provide an API which allows to specify the name of each cloned image?

V.

On Tue, Dec 6, 2016 at 7:17 PM, yang, xing  wrote:
> The new image name should be volume-uuid if you don’t change 
> volume_name_template in cinder.conf.  The display_name field will be None for 
> the new volume.
>
> Xing
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, December 6, 2016 7:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> How are the names chosen for those new cloned images?
>
> On Tue, Dec 6, 2016 at 10:04 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Yes, you are right.
>>
>> Thanks,
>> Xing
>>
>> 
>> From: Victor Denisov [vdeni...@mirantis.com]
>> Sent: Monday, December 5, 2016 7:13 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: Jason Dillaman
>> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>>
>> I just realized that probably we create images from individual
>> snapshots of that consistency group and add those images to the new
>> consistency group.
>> Am I correct?
>>
>> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
>>> Or probably when we clone a consistency group from a snapshot we
>>> should clone all the images in this consistency group?
>>>
>>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  
>>> wrote:
 Hi Xing,

 One more question. You mentioned that there is an operation: create
 consistency group from a snap shot.
 Does it mean that an image can be a member of several consistency groups?

 Thanks,
 V.

 On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
> You cannot remove a volume completely if there is still a group snapshot. 
>  You can remove the volume from the group but you can’t delete the volume 
> because it still has snapshot dependent on it.  So if you want to 
> completely remove a volume that is in a group, you can delete the group 
> snapshot first which will delete the individual snapshot.  After that you 
> can remove the volume from the group and delete the volume.
>
> More comments inline below.
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, November 8, 2016 12:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> One more question. What is the expected behavior if you remove a
> volume completely?
> [Xing] You cannot remove the volume completely (delete volume won't 
> succeed) if there is still a group snapshot.
>
> Should the group snapshot removed first? Should the volume snapshot be
> removed from the group snapshot?
> [Xing] Yes, you should delete the group snapshot first and that will 
> delete the volume snapshot as well.
>
> Should we keep the snapshot even if the image doesn't exist anymore?
> [Xing] You cannot delete the image (volume) if there is still a snapshot.
>
> Thanks,
> Victor.
>
> On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Please see my answers inline below.
>>
>> In Newton, we added support for Generic Volume Groups.  See doc below.  
>> CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
>> not implement CGs any more.  Instead, it can add CG support using 
>> Generic Volume Group interfaces.  I'm working on a dev doc to explain 
>> how to do this and will send an email to the mailing list when I'm done. 
>>  The Generic Volume Group interface is very similar to CG interface, 
>> except that the Generic Volume Group requires an additional Group Type 
>> parameter to be created.  Using Group Type, CG can be a special type of 
>> Generic Volume Group.  Please feel free to grab me on Cinder IRC if you 
>> have any questions.  My IRC handle is xyang or xyang1.
>>
>> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>>
>> Thanks,
>> Xing
>>
>>
>> 

Re: [openstack-dev] [Infra][heat][QA] Tempest layer4 job failure due to heat devstack plugin switch.

[Ken'ichi Ohmichi]

2016-12-06 19:42 GMT-08:00 GHANSHYAM MANN :
> Hi All,
>
> Recently all gate heat gate jobs were switched to use heat devstack plugin
> and heat code was removed from devstack tree.
>
> During that tempest layer 4 job is missed and blocked the tempest gate[1].
> Also another heat job had issue for enabling plugin [2].
>
> Fixes are up for both job fix, hope infra team can merge those ASAP.
>
> - Tempest layer4 job fix - https://review.openstack.org/#/c/407807/
> - Heat job fix - https://review.openstack.org/#/c/407817/
>
> ..1
> http://logs.openstack.org/68/407768/1/check/gate-tempest-dsvm-layer4-ubuntu-xenial/9499d2a/logs/testr_results.html.gz
> ..2
> http://logs.openstack.org/14/406514/1/check/gate-tempest-dsvm-heat-identity-v3-only-nv/0e51c2b/logs/testr_results.html.gz

Thank you very much for your help, anyways.

Thanks
Ken Ohmichi

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

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

[Harm Sluiman]

yup agree

We have spent more time thinking through FPGA and GPU but certainly all devices 
are possible. 
Miroslav, you may recall in the isn examples I sent a while back I called them 
“programmable devices” ;-)

We may need to think about defining a crips line however between these managed 
devices versus anything attached by PCI, but maybe not. Up for discussion I 
think…


> On Dec 7, 2016, at 10:11 AM, Zhipeng Huang  wrote:
> 
> Hi Miroslav,
> 
> GPU and NVMe devices are definitely in my understanding within the scope of 
> Cyborg, however we need a road map for each type of accelerator devices :)
> 
> 
> On Wed, Dec 7, 2016 at 4:04 AM, Miroslav Halas  > wrote:
> Hello Harm,
> 
>  
> 
> Thank you for sharing. I was wondering if you have given any thoughts how 
> other type of devices other than FPGAs would fit into this framework. For 
> example, GPUs or block devices (such as NVMe drives) for exclusive access  by 
> the VMs. Could these type of devices be also managed by cyborg?
> 
>  
> 
> Thanks,
> 
>  
> 
> Miro Halas
> 
>  
> 
> From: Harm Sluiman [mailto:harm.slui...@gmail.com 
> ] 
> Sent: Saturday, December 03, 2016 4:54 AM
> To: Zhipeng Huang
> Cc: OpenStack Development Mailing List (not for usage questions); 
> rodolfo.alonso.hernan...@intel.com 
> ; Michele Paolino; Scott Kelso; 
> Roman Dobosz; Jim Golden; Miroslav Halas; pradeep.jagade...@huawei.com 
> ; michael.ro...@nokia.com 
> ; jian-feng.d...@intel.com 
> ; martial.mic...@nist.gov 
> ; Moshe Levi; Edan David; Francois Ozog; Fei 
> K Chen; jack...@huawei.com ; lil...@huawei.com 
> 
> Subject: Re: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
> 
>  
> 
> Team I promised to comment on NASCA and provide some thoughts and ppt on 
> flows for cyborg
> 
>  
> 
> Sorry for the delay.
> 
>  
> 
> I added a few words to the NASCA etherpad,
> 
>  
> 
> I waited for cyborg git to drop ppt but no luck yet so I put it here on 
> google drive. I hope you can reach it. follow it in show mode for a “rich” 
> experience ;-)
> 
> I captured some FPGA run time flows as background, and then some sequences of 
> lifecycle management. I have shared this with a few of you before.
> 
> https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM 
> 
> I am creating etherpad to discuss
> 
> https://etherpad.openstack.org/p/cyborg-initial-flow-discussion 
> 
> I am also creating an etherpad to discuss the in POC we have talked about for 
> February to help define the scope of Cyborg
> 
> https://etherpad.openstack.org/p/cyborg-initial-design-poc 
> 
>  
> 
>  
> 
> I would also like to intro/welcome a couple more people to the Cyborg topic
> 
>  
> 
> Chen, Fei  (aka Fei) from IBM research and the SuperVessel project among 
> other things
> 
> Jack Ng and Li Liu, my colleagues from Huawei that will be participating in 
> Cyborg and helping get our initial POC underway
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Thanks for your time.
> 宋哲
> Harm Sluiman
> 
> 
> 
> 
> 
>  
> 
> On Nov 23, 2016, at 11:49 PM, Zhipeng Huang  > wrote:
> 
>  
> 
> Hi team,
> 
>  
> 
> Thanks for the discussion and please find the minutes here 
> https://wiki.openstack.org/wiki/Cyborg/MeetingLogs 
> 
>  
> 
> On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang  > wrote:
> 
> Forward here again in case you have not registered to openstack-dev 
> mailinglist
> 
>  
> 
> -- Forwarded message --
> From: Zhipeng Huang >
> Date: Wed, Nov 23, 2016 at 8:34 PM
> Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> 
> 
> Hi Team,
> 
>  
> 
> Please find the meeting logistics and agendas at 
> https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting 
>  
> 
>  
> 
> --
> 
> Zhipeng (Howard) Huang
> 
>  
> 
> Standard Engineer
> 
> IT Standard & Patent/IT Prooduct Line
> 
> Huawei Technologies Co,. Ltd
> 
> Email: huangzhip...@huawei.com 
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
>  
> 
> (Previous)
> 
> Research Assistant
> 
> Mobile Ad-Hoc Network Lab, Calit2
> 
> University of 

Re: [openstack-dev] [all] Ocata Bugsmash

[Liyongle (Fred)]

Hi Sean, 

Thanks again for your contribution to this Bug Smash in China. This was the 5th 
Smash in China and this activity will continue in each release cycle. 

Hope more and more engineers and companies could join the activities. If we can 
work in the same week, the activity will be more productive. 

Best Regards. 

Fred (李永乐)

-Original Message-
From: Sean McGinnis [mailto:sean.mcgin...@gmx.com] 
Sent: 2016年12月7日 3:15
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [all] Ocata Bugsmash

Last week was the Ocata Bugsmash in Shenzhen, China. Many developers from 
around China gathered to debug, test, and fix a large number of bugs across 
many of the most popular projects.

I wanted to take an opportunity to thank Huawei, Intel, and everyone involved 
for making this event happen. It was great seeing so much focused attention on 
addressing our outstanding bugs, and I felt the event was very productive. 
Really great work done by the Chinese OpenStack community.

I also wanted to take the opportunity to spread the word about the event to 
others interested in being involved and any other companies that would be 
interested in running this type of event in other countries. I think a couple 
releases ago, things were able to be coordinated in at least a couple other 
locations.

As a PTL and core for Cinder, I would love to see this picked up again and make 
a bugsmash week happen every cycle across multiple locations. Just seeing how 
much the one group could get done in China - I can just imagine how much could 
be accomplished by a larger extended effort.

I have no involvement in the organizing or planning of this event, but if any 
vendors are interested in spreading this into a larger event, feel free to 
contact me directly for any feedback and thoughts from a participant 
perspective.

But I want to make sure full credit for this goes to Huawei and Intel for 
sponsoring this for five cycles in a row. In my opinion, it's a very valuable 
event to bring devs together from all over and really focus on improving 
OpenStack. Thank you again to all involved in making it happen.

Thanks,
Sean (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] [Infra][heat][QA] Tempest layer4 job failure due to heat devstack plugin switch.

[GHANSHYAM MANN]

Hi All,

Recently all gate heat gate jobs were switched to use heat devstack plugin
and heat code was removed from devstack tree.

During that tempest layer 4 job is missed and blocked the tempest gate[1].
Also another heat job had issue for enabling plugin [2].

Fixes are up for both job fix, hope infra team can merge those ASAP.

- Tempest layer4 job fix - https://review.openstack.org/#/c/407807/
- Heat job fix - https://review.openstack.org/#/c/407817/

..1
http://logs.openstack.org/68/407768/1/check/gate-tempest-dsvm-layer4-ubuntu-xenial/9499d2a/logs/testr_results.html.gz

..2
http://logs.openstack.org/14/406514/1/check/gate-tempest-dsvm-heat-identity-v3-only-nv/0e51c2b/logs/testr_results.html.gz


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

Re: [openstack-dev] [cinder] consistency groups in ceph

[Victor Denisov]

Does it mean that ceph as a backend for this feature is supposed to
provide an API which allows to specify the name of each cloned image?

V.

On Tue, Dec 6, 2016 at 7:17 PM, yang, xing  wrote:
> The new image name should be volume-uuid if you don’t change 
> volume_name_template in cinder.conf.  The display_name field will be None for 
> the new volume.
>
> Xing
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, December 6, 2016 7:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> How are the names chosen for those new cloned images?
>
> On Tue, Dec 6, 2016 at 10:04 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Yes, you are right.
>>
>> Thanks,
>> Xing
>>
>> 
>> From: Victor Denisov [vdeni...@mirantis.com]
>> Sent: Monday, December 5, 2016 7:13 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: Jason Dillaman
>> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>>
>> I just realized that probably we create images from individual
>> snapshots of that consistency group and add those images to the new
>> consistency group.
>> Am I correct?
>>
>> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
>>> Or probably when we clone a consistency group from a snapshot we
>>> should clone all the images in this consistency group?
>>>
>>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  
>>> wrote:
 Hi Xing,

 One more question. You mentioned that there is an operation: create
 consistency group from a snap shot.
 Does it mean that an image can be a member of several consistency groups?

 Thanks,
 V.

 On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
> You cannot remove a volume completely if there is still a group snapshot. 
>  You can remove the volume from the group but you can’t delete the volume 
> because it still has snapshot dependent on it.  So if you want to 
> completely remove a volume that is in a group, you can delete the group 
> snapshot first which will delete the individual snapshot.  After that you 
> can remove the volume from the group and delete the volume.
>
> More comments inline below.
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Tuesday, November 8, 2016 12:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> One more question. What is the expected behavior if you remove a
> volume completely?
> [Xing] You cannot remove the volume completely (delete volume won't 
> succeed) if there is still a group snapshot.
>
> Should the group snapshot removed first? Should the volume snapshot be
> removed from the group snapshot?
> [Xing] Yes, you should delete the group snapshot first and that will 
> delete the volume snapshot as well.
>
> Should we keep the snapshot even if the image doesn't exist anymore?
> [Xing] You cannot delete the image (volume) if there is still a snapshot.
>
> Thanks,
> Victor.
>
> On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
>> Hi Victor,
>>
>> Please see my answers inline below.
>>
>> In Newton, we added support for Generic Volume Groups.  See doc below.  
>> CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
>> not implement CGs any more.  Instead, it can add CG support using 
>> Generic Volume Group interfaces.  I'm working on a dev doc to explain 
>> how to do this and will send an email to the mailing list when I'm done. 
>>  The Generic Volume Group interface is very similar to CG interface, 
>> except that the Generic Volume Group requires an additional Group Type 
>> parameter to be created.  Using Group Type, CG can be a special type of 
>> Generic Volume Group.  Please feel free to grab me on Cinder IRC if you 
>> have any questions.  My IRC handle is xyang or xyang1.
>>
>> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>>
>> Thanks,
>> Xing
>>
>>
>> 
>> From: Victor Denisov [vdeni...@mirantis.com]
>> Sent: Monday, October 31, 2016 11:29 PM
>> To: openstack-dev@lists.openstack.org
>> Cc: Jason Dillaman
>> Subject: [openstack-dev] [cinder] consistency groups in ceph
>>
>> Hi,
>>
>> I'm working on consistency groups feature in ceph.
>> My question is about what kind of behavior does cinder expect from
>> storage 

[openstack-dev] [nova] Is this a correct use of scheduler hints and nova-scheduler

[Zhenyu Zheng]

Hi all,

I want to ask a question about using scheduler-hints, could we add custom
scheduler keys to work with our custom filters? Is it designed to allow
vendors add own custom filters and keys?

Another question is, as we have now persistent scheduler-hints in request
spec, is it possible to show the scheduler-hints either in server-show or a
new API? Because vendors may be interested to have an idea on how this
instance was built in the first place.

Thanks.
__
OpenStack Development Mailing 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] [cinder] consistency groups in ceph

[yang, xing]

The new image name should be volume-uuid if you don’t change 
volume_name_template in cinder.conf.  The display_name field will be None for 
the new volume.

Xing


From: Victor Denisov [vdeni...@mirantis.com]
Sent: Tuesday, December 6, 2016 7:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

How are the names chosen for those new cloned images?

On Tue, Dec 6, 2016 at 10:04 AM, yang, xing  wrote:
> Hi Victor,
>
> Yes, you are right.
>
> Thanks,
> Xing
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, December 5, 2016 7:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> I just realized that probably we create images from individual
> snapshots of that consistency group and add those images to the new
> consistency group.
> Am I correct?
>
> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
>> Or probably when we clone a consistency group from a snapshot we
>> should clone all the images in this consistency group?
>>
>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  wrote:
>>> Hi Xing,
>>>
>>> One more question. You mentioned that there is an operation: create
>>> consistency group from a snap shot.
>>> Does it mean that an image can be a member of several consistency groups?
>>>
>>> Thanks,
>>> V.
>>>
>>> On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
 You cannot remove a volume completely if there is still a group snapshot.  
 You can remove the volume from the group but you can’t delete the volume 
 because it still has snapshot dependent on it.  So if you want to 
 completely remove a volume that is in a group, you can delete the group 
 snapshot first which will delete the individual snapshot.  After that you 
 can remove the volume from the group and delete the volume.

 More comments inline below.

 Thanks,
 Xing


 
 From: Victor Denisov [vdeni...@mirantis.com]
 Sent: Tuesday, November 8, 2016 12:04 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Jason Dillaman
 Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

 One more question. What is the expected behavior if you remove a
 volume completely?
 [Xing] You cannot remove the volume completely (delete volume won't 
 succeed) if there is still a group snapshot.

 Should the group snapshot removed first? Should the volume snapshot be
 removed from the group snapshot?
 [Xing] Yes, you should delete the group snapshot first and that will 
 delete the volume snapshot as well.

 Should we keep the snapshot even if the image doesn't exist anymore?
 [Xing] You cannot delete the image (volume) if there is still a snapshot.

 Thanks,
 Victor.

 On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
> Hi Victor,
>
> Please see my answers inline below.
>
> In Newton, we added support for Generic Volume Groups.  See doc below.  
> CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
> not implement CGs any more.  Instead, it can add CG support using Generic 
> Volume Group interfaces.  I'm working on a dev doc to explain how to do 
> this and will send an email to the mailing list when I'm done.  The 
> Generic Volume Group interface is very similar to CG interface, except 
> that the Generic Volume Group requires an additional Group Type parameter 
> to be created.  Using Group Type, CG can be a special type of Generic 
> Volume Group.  Please feel free to grab me on Cinder IRC if you have any 
> questions.  My IRC handle is xyang or xyang1.
>
> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, October 31, 2016 11:29 PM
> To: openstack-dev@lists.openstack.org
> Cc: Jason Dillaman
> Subject: [openstack-dev] [cinder] consistency groups in ceph
>
> Hi,
>
> I'm working on consistency groups feature in ceph.
> My question is about what kind of behavior does cinder expect from
> storage backends.
> I'm particularly interested in what happens to consistency groups
> snapshots when I remove an image from the group:
>
> Let's imagine I have a consistency group called CG. I have images in
> the consistency group:
> Im1, Im2, Im3, Im4.
> Let's imagine we have snapshots of this consistency group:
>
> 

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[fumihiko kakuma]

Hi Ryan,

I was trying to add a scenario test for neutron-dynamic-routing
since I have a conversation with Vikram about scenario test.
And I pushed patches to gerrit as I have finished almost making it.

Please check it.

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

Thank you
kakuma


On Tue, 6 Dec 2016 22:44:18 +
"Tidwell, Ryan"  wrote:

> This is at the top of my list to look at. I've been thinking a lot about how 
> to implement some tests. For instance, do we need to actually stand up a BGP 
> peer of some sort to peer neutron with and assert the announcements somehow? 
> Or should we assume that Ryu works properly and make sure we have solid 
> coverage of the driver interface somehow. I'm open to suggestions as to how 
> to approach this.
> 
> -Ryan
> 
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com] 
> Sent: Tuesday, December 06, 2016 2:36 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario 
> testing?
> 
> Hi all,
> 
> General query - Is there anyone in the Dynamic Routing community that is 
> planning on contributing a scenario test? As far as I could tell, none of the 
> current API tests would fail if, for example, the BGP agent was not running. 
> Please correct me if I'm wrong.
> 
> Thank you.
> 
> __
> OpenStack Development Mailing 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

-- 
fumihiko kakuma 


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

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

[Zhipeng Huang]

Hi Miroslav,

GPU and NVMe devices are definitely in my understanding within the scope of
Cyborg, however we need a road map for each type of accelerator devices :)


On Wed, Dec 7, 2016 at 4:04 AM, Miroslav Halas  wrote:

> Hello Harm,
>
>
>
> Thank you for sharing. I was wondering if you have given any thoughts how
> other type of devices other than FPGAs would fit into this framework. For
> example, GPUs or block devices (such as NVMe drives) for exclusive access
>  by the VMs. Could these type of devices be also managed by cyborg?
>
>
>
> Thanks,
>
>
>
> Miro Halas
>
>
>
> *From:* Harm Sluiman [mailto:harm.slui...@gmail.com]
> *Sent:* Saturday, December 03, 2016 4:54 AM
> *To:* Zhipeng Huang
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> rodolfo.alonso.hernan...@intel.com; Michele Paolino; Scott Kelso; Roman
> Dobosz; Jim Golden; Miroslav Halas; pradeep.jagade...@huawei.com;
> michael.ro...@nokia.com; jian-feng.d...@intel.com; martial.mic...@nist.gov;
> Moshe Levi; Edan David; Francois Ozog; Fei K Chen; jack...@huawei.com;
> lil...@huawei.com
> *Subject:* Re: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
>
>
>
> Team I promised to comment on NASCA and provide some thoughts and ppt on
> flows for cyborg
>
>
>
> Sorry for the delay.
>
>
>
> I added a few words to the NASCA etherpad,
>
>
>
> I waited for cyborg git to drop ppt but no luck yet so I put it here on
> google drive. I hope you can reach it. follow it in show mode for a “rich”
> experience ;-)
>
> I captured some FPGA run time flows as background, and then some sequences
> of lifecycle management. I have shared this with a few of you before.
>
> https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM
>
> I am creating etherpad to discuss
>
> https://etherpad.openstack.org/p/cyborg-initial-flow-discussion
>
> I am also creating an etherpad to discuss the in POC we have talked about
> for February to help define the scope of Cyborg
>
> https://etherpad.openstack.org/p/cyborg-initial-design-poc
>
>
>
>
>
> I would also like to intro/welcome a couple more people to the Cyborg topic
>
>
>
> Chen, Fei  (aka Fei) from IBM research and the SuperVessel project among
> other things
>
> Jack Ng and Li Liu, my colleagues from Huawei that will be participating
> in Cyborg and helping get our initial POC underway
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks for your time.
> 宋哲
> Harm Sluiman
>
>
>
>
>
>
> On Nov 23, 2016, at 11:49 PM, Zhipeng Huang  wrote:
>
>
>
> Hi team,
>
>
>
> Thanks for the discussion and please find the minutes here
> https://wiki.openstack.org/wiki/Cyborg/MeetingLogs
>
>
>
> On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang 
> wrote:
>
> Forward here again in case you have not registered to openstack-dev
> mailinglist
>
>
>
> -- Forwarded message --
> From: *Zhipeng Huang* 
> Date: Wed, Nov 23, 2016 at 8:34 PM
> Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> Hi Team,
>
>
>
> Please find the meeting logistics and agendas at
> https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
>
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
>
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
>
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, 

Re: [openstack-dev] [neutron][tricircle]DVR issue in cross Neutron networking

[joehuang]

Thank you Brian, some thoughts below :

> So net3 is a shared private network, perhaps just a shared VLAN.  And 
> something
> makes sure IP address allocations don't overlap.  Ok.

Yes, Tricircle will make sure IP address allocation don't overlap, and 
currently shared VLAN
was supported, next step is to support VxLAN.


>> [joehuang]  The data path is correct:  Instance1 -> R1 -> Instance4, return
>>   path:  Instance4 -> R2 ->Instance1.
>>  But R1 and R2 are located in two Neutrons. There will be some issue if 
>> you
>>  use VxLAN experience this, for VTEP needs to be populated into remote 
>> neutron
>>  (This is another topic). But you can try it using DVR+VLAN, and VLAN 
>> range should
>>  be able to accessible in both Neutron, i.e, in Neutron 1 and Neutron 2, 
>> enable
>>  DVR+VLAN, and manually create net3 and net4 in both neutron with same
>>  VLAN segment.

> So is the asymmetric setup causing this?  For example, if Instance4 used R1 as
> the gateway IP to net3 do things work?  I guess I would have to recommend 
> doing
> manual changes to the running config to prove it can work, then maybe we can
> figure out how to tweak the code.

If Instance4 used R1 as the gateway, then the north-south traffic has to goes 
to R1, the path is
long and it's not the intention for the application high-availability 
deployment. From the
application aspect, wants to realize north-south traffic redundancy in 
different OpenStack, so that
no matter which OpenStack cloud stopped working, the application can still 
provide service in 
other live OpenStack cloud.

On the other hand, because R1 is DVR, so even if instance4 used R1 as the 
gateway, no idea which
compute node in OpenStack 1 will serve as the gateway. For DVR mode, the Router 
should
be co-located in the same compute node.

The packet will be dropped when it reached the compute node for instance4 
because the DVR MAC
is allocated in OpenStack 1, and can not be recognized by compute node for 
instance4 in OpenStack 2.

So if we can find a way to make compute nodes in OpenStack2 can recognize the 
DVR MAC allocated
in OpenStack1, then the issue could be addressed, and vice versa.

The simplest idea is to make the DVR MAC being generated centrally and visible 
to all OpenStack clouds,
but it's not good idea to add more "global data", the less sharing data in 
multi-region clouds, the better.

Another idea to address this issue is to consider the generation and drop 
criteria for DVR MAC, if DVR MACs
are generated through an common algorithm in multiple OpenStack clouds, and 
compute node( just use this
rough concept here for simplify description) can recognize the DVR MAC is 
legal, then the packet can reach
the target instance.

Would like to know your thoughts.

Best Regards
Chaoyi Huang (joehuang)


From: Brian Haley [brian.ha...@hpe.com]
Sent: 07 December 2016 4:58
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][tricircle]DVR issue in cross Neutron 
networking

On 12/05/2016 10:38 PM, joehuang wrote:
> Hello, Brian,
>
> Thank you for your comment, see inline comments marked with [joehuang].
>
> The ASCII figure is not good in the plain text mail, you can check it at the 
> browser: 
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108447.html
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Brian Haley [brian.ha...@hpe.com]
> Sent: 06 December 2016 10:29
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][tricircle]DVR issue in cross Neutron 
> networking
>
> On 12/5/16 3:03 AM, joehuang wrote:
>> Hello,
>
> Hi Chaoyi,
>
> Comments inline below.
>
>>  Tricircle plans to provide L2 network across Neutron to ease supporting
>> high
>>  availability of application:
>>
>>  For example, in the following figure, the application is consisted of
>>  instance1 and instance2, these two instances will be deployed into two
>>  OpenStack. Intance1 will provide service through "ext net1"(i.e, external
>>  network in OpenStack1), and Instance2 will provide service through
>>  "ext net2". Instance1 and Instance2 will be plugged into same L2 network
>>  net3 for data replication( for example database replication ).
>>
>>   +-+   +-+
>>   |OpenStack1   |   |OpenStack2   |
>>   | |   | |
>>   | ext net1|   | ext net2|
>>   |   +-+-+ |   |   +-+-+ |
>>   | |   |   | |   |
>>   | |   |   | |   |
>>   |  +--+--+|   |  +--+--+|
>>   |  | ||   |  | ||
>>   |  | R1  ||   |  | R2  ||
>>   |  | ||   |  | ||
>>   |  +--+--+|   |  +--+--+|
>>   | |   |   | 

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Tidwell, Ryan]

I just saw this review [1] come in this afternoon. I'm starting to review and 
digest it, but it looks pretty slick. It looks like Ryu may have some test 
helpers that stand up Quagga in a container and allow you to interact with it 
natively in python. This gives us a clean way to set up a BGP peer that we can 
run assertions against to ensure neutron announces the correct routes. I see 
what looks like some decent scenario tests here. So it looks like we do have 
work in flight to address some test gaps in neutron-dynamic-routing.


-Ryan


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


From: Tidwell, Ryan
Sent: Tuesday, December 6, 2016 3:13:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario 
testing?

Thanks for the pointer. I'll take a look and see what can be leveraged.

-Ryan


_
From: Armando M. >
Sent: Tuesday, December 6, 2016 2:57 PM
Subject: Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario 
testing?
To: OpenStack Development Mailing List (not for usage questions) 
>




On 6 December 2016 at 14:44, Tidwell, Ryan 
> wrote:
This is at the top of my list to look at. I've been thinking a lot about how to 
implement some tests. For instance, do we need to actually stand up a BGP peer 
of some sort to peer neutron with and assert the announcements somehow? Or 
should we assume that Ryu works properly and make sure we have solid coverage 
of the driver interface somehow. I'm open to suggestions as to how to approach 
this.

Thomas Morin et al have had a few ideas and put together [1]. There are some 
similarities between the efforts. Something worth mulling over on.

Cheers,
Armando

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


-Ryan

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com]
Sent: Tuesday, December 06, 2016 2:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

Hi all,

General query - Is there anyone in the Dynamic Routing community that is 
planning on contributing a scenario test? As far as I could tell, none of the 
current API tests would fail if, for example, the BGP agent was not running. 
Please correct me if I'm wrong.

Thank you.

__
OpenStack Development Mailing 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] [Zun] About k8s integration

[Hongbin Lu]

Hi all,

This is a continued discussion of the k8s integration blueprint [1]. Currently, 
Zun exposes a container-oriented APIs that provides service for end-users to 
operate on containers (i.e. CRUD). At the last team meeting, we discussed how 
to introduce k8s to Zun as an alternative to the Docker driver. There are two 
approaches that has been discussed:

1. Introduce the concept of Pod. If we go with this approach, an API endpoint 
(i.e. /pods) will be added to the Zun APIs. Both Docker driver and k8s driver 
need to implement this endpoint. In addition, all the future drivers need to 
implement this endpoint as well (or throw a NotImplemented exception). Some of 
our team members raised concerns about this approach. The main concern is that 
this approach will hide a lot of k8s-specific features (i.e. replication 
controller) or there will be a lot of work to bring all those features to Zun.

  $ zun pod-create ... # this create a k8s pod (if k8s driver is used), or 
create a sandbox with a set of containers (if docker driver is used)
  $ zun create ... # this create a k8s pod with one container, or create a 
sandbox with one container

2. Introduce a dedicated k8s endpoint that acts as a proxy to k8s APIs. This 
will expose all the k8s features but users won't have a unified APIs across 
drivers.

  $ zun k8s pod create ... # this create a k8s pod
  $ zun docker container create ... # this create a docker container
  $ zun create ... # the behavior of this command is unclear

So far, we haven't decided which approach to use (or use a third approach), but 
we wanted to collect more feedback before making a decision. Thoughts?

[1] https://blueprints.launchpad.net/zun/+spec/k8s-integration

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] [tripleo] [ci]

[Steve Baker]

On Tue, Dec 6, 2016 at 9:34 PM, Ian Main  wrote:

> Wesley Hayutin wrote:
> > Greetings,
> >
> > I wanted to send a status update on the quickstart based containerized
> > compute ci.
> >
> > The work is here:
> > https://review.openstack.org/#/c/393348/
> >
> > I had two passes on the morning of Nov 30 in a row, then later that day
> the
> > deployment started to fail due the compute node loosing it's networking
> and
> > became unpingable.   After poking around and talking to a few folks its
> > likely that we're hitting at least one of two possible bugs [1-2]
> >
> > I am on pto next week but will periodically check in and can easily
> retest
> > if these resolve.
>
> I've been seeing this a lot too.  It's happening to both the controller and
> compute for me.  Probably because the controller is ALSO running the
> firstboot
> script in docker/ which is not what we want (or we need it to be smarter
> anyway).
>
> So far it appears that cloud-init is running our firstboot script but is
> not
> configuring networking.  If I run dhclient eth0 it comes up and has
> internet
> access etc.  Going to look into this more tomorrow.
>
>
>
This change might fix the issue https://review.openstack.org/#/c/407289/
__
OpenStack Development Mailing 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] [cinder] consistency groups in ceph

[Victor Denisov]

How are the names chosen for those new cloned images?

On Tue, Dec 6, 2016 at 10:04 AM, yang, xing  wrote:
> Hi Victor,
>
> Yes, you are right.
>
> Thanks,
> Xing
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, December 5, 2016 7:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jason Dillaman
> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>
> I just realized that probably we create images from individual
> snapshots of that consistency group and add those images to the new
> consistency group.
> Am I correct?
>
> On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
>> Or probably when we clone a consistency group from a snapshot we
>> should clone all the images in this consistency group?
>>
>> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  wrote:
>>> Hi Xing,
>>>
>>> One more question. You mentioned that there is an operation: create
>>> consistency group from a snap shot.
>>> Does it mean that an image can be a member of several consistency groups?
>>>
>>> Thanks,
>>> V.
>>>
>>> On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
 You cannot remove a volume completely if there is still a group snapshot.  
 You can remove the volume from the group but you can’t delete the volume 
 because it still has snapshot dependent on it.  So if you want to 
 completely remove a volume that is in a group, you can delete the group 
 snapshot first which will delete the individual snapshot.  After that you 
 can remove the volume from the group and delete the volume.

 More comments inline below.

 Thanks,
 Xing


 
 From: Victor Denisov [vdeni...@mirantis.com]
 Sent: Tuesday, November 8, 2016 12:04 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Jason Dillaman
 Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

 One more question. What is the expected behavior if you remove a
 volume completely?
 [Xing] You cannot remove the volume completely (delete volume won't 
 succeed) if there is still a group snapshot.

 Should the group snapshot removed first? Should the volume snapshot be
 removed from the group snapshot?
 [Xing] Yes, you should delete the group snapshot first and that will 
 delete the volume snapshot as well.

 Should we keep the snapshot even if the image doesn't exist anymore?
 [Xing] You cannot delete the image (volume) if there is still a snapshot.

 Thanks,
 Victor.

 On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
> Hi Victor,
>
> Please see my answers inline below.
>
> In Newton, we added support for Generic Volume Groups.  See doc below.  
> CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
> not implement CGs any more.  Instead, it can add CG support using Generic 
> Volume Group interfaces.  I'm working on a dev doc to explain how to do 
> this and will send an email to the mailing list when I'm done.  The 
> Generic Volume Group interface is very similar to CG interface, except 
> that the Generic Volume Group requires an additional Group Type parameter 
> to be created.  Using Group Type, CG can be a special type of Generic 
> Volume Group.  Please feel free to grab me on Cinder IRC if you have any 
> questions.  My IRC handle is xyang or xyang1.
>
> http://docs.openstack.org/admin-guide/blockstorage-groups.html
>
> Thanks,
> Xing
>
>
> 
> From: Victor Denisov [vdeni...@mirantis.com]
> Sent: Monday, October 31, 2016 11:29 PM
> To: openstack-dev@lists.openstack.org
> Cc: Jason Dillaman
> Subject: [openstack-dev] [cinder] consistency groups in ceph
>
> Hi,
>
> I'm working on consistency groups feature in ceph.
> My question is about what kind of behavior does cinder expect from
> storage backends.
> I'm particularly interested in what happens to consistency groups
> snapshots when I remove an image from the group:
>
> Let's imagine I have a consistency group called CG. I have images in
> the consistency group:
> Im1, Im2, Im3, Im4.
> Let's imagine we have snapshots of this consistency group:
>
> CGSnap1
> CGSnap2
> CGSnap3
>
> Snapshots of individual images in a consistency group snapshot I will call
> CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.
>
> Qustion 1:
> If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
> Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.
>
> Can CGSnap1 have less images than it already has: Im1, Im2, 

Re: [openstack-dev] [nova] placement/resource providers update 4

[melanie witt]

On Tue, 6 Dec 2016 16:04:14 -0500, Jay Pipes wrote:

We're discussing only doing:

 GET /resource_providers?

Once we start doing claims in the scheduler, we'll have the ability to do:

 POST /allocations
 {

 }


Thanks. FWIW, I'm not against simple non-JSON query params.

The last time we discussed this, I was against the idea of JSON blobs in 
query params from a usability standpoint and it was noted that GET with 
a request body isn't guaranteed to be forwarded properly when going 
through proxies because it's not described in the HTTP specification. So 
with that information, I thought POST as a read to e.g. 
/resource_providers/list was the best compromise.


That all arose because complex JSON bodies were described as a 
possibility for RP list requests. If that's not the case, then I didn't 
think we need to consider POST.


-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] [Neutron][Dynamic Routing] Plans for scenario testing?

[Assaf Muller]

On Tue, Dec 6, 2016 at 5:44 PM, Tidwell, Ryan  wrote:
> This is at the top of my list to look at.

Thanks Ryan that's good to know. I think that gating on some tests
that demonstrates that the project works end to end is a signal of
maturity and will help adoption.

> I've been thinking a lot about how to implement some tests. For instance, do 
> we need to actually stand up a BGP peer of some sort to peer neutron with and 
> assert the announcements somehow? Or should we assume that Ryu works properly 
> and make sure we have solid coverage of the driver interface somehow. I'm 
> open to suggestions as to how to approach this.
>
> -Ryan
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Tuesday, December 06, 2016 2:36 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario 
> testing?
>
> Hi all,
>
> General query - Is there anyone in the Dynamic Routing community that is 
> planning on contributing a scenario test? As far as I could tell, none of the 
> current API tests would fail if, for example, the BGP agent was not running. 
> Please correct me if I'm wrong.
>
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Tidwell, Ryan]

Thanks for the pointer. I'll take a look and see what can be leveraged.

-Ryan


_
From: Armando M. >
Sent: Tuesday, December 6, 2016 2:57 PM
Subject: Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario 
testing?
To: OpenStack Development Mailing List (not for usage questions) 
>




On 6 December 2016 at 14:44, Tidwell, Ryan 
> wrote:
This is at the top of my list to look at. I've been thinking a lot about how to 
implement some tests. For instance, do we need to actually stand up a BGP peer 
of some sort to peer neutron with and assert the announcements somehow? Or 
should we assume that Ryu works properly and make sure we have solid coverage 
of the driver interface somehow. I'm open to suggestions as to how to approach 
this.

Thomas Morin et al have had a few ideas and put together [1]. There are some 
similarities between the efforts. Something worth mulling over on.

Cheers,
Armando

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


-Ryan

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com]
Sent: Tuesday, December 06, 2016 2:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

Hi all,

General query - Is there anyone in the Dynamic Routing community that is 
planning on contributing a scenario test? As far as I could tell, none of the 
current API tests would fail if, for example, the BGP agent was not running. 
Please correct me if I'm wrong.

Thank you.

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

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



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

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Armando M.]

On 6 December 2016 at 14:44, Tidwell, Ryan  wrote:

> This is at the top of my list to look at. I've been thinking a lot about
> how to implement some tests. For instance, do we need to actually stand up
> a BGP peer of some sort to peer neutron with and assert the announcements
> somehow? Or should we assume that Ryu works properly and make sure we have
> solid coverage of the driver interface somehow. I'm open to suggestions as
> to how to approach this.
>

Thomas Morin et al have had a few ideas and put together [1]. There are
some similarities between the efforts. Something worth mulling over on.

Cheers,
Armando

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


>
> -Ryan
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Tuesday, December 06, 2016 2:36 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario
> testing?
>
> Hi all,
>
> General query - Is there anyone in the Dynamic Routing community that is
> planning on contributing a scenario test? As far as I could tell, none of
> the current API tests would fail if, for example, the BGP agent was not
> running. Please correct me if I'm wrong.
>
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Tidwell, Ryan]

This is at the top of my list to look at. I've been thinking a lot about how to 
implement some tests. For instance, do we need to actually stand up a BGP peer 
of some sort to peer neutron with and assert the announcements somehow? Or 
should we assume that Ryu works properly and make sure we have solid coverage 
of the driver interface somehow. I'm open to suggestions as to how to approach 
this.

-Ryan

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Tuesday, December 06, 2016 2:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

Hi all,

General query - Is there anyone in the Dynamic Routing community that is 
planning on contributing a scenario test? As far as I could tell, none of the 
current API tests would fail if, for example, the BGP agent was not running. 
Please correct me if I'm wrong.

Thank you.

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

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

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Armando M.]

On 6 December 2016 at 14:36, Assaf Muller  wrote:

> Hi all,
>
> General query - Is there anyone in the Dynamic Routing community that
> is planning on contributing a scenario test? As far as I could tell,
> none of the current API tests would fail if, for example, the BGP
> agent was not running. Please correct me if I'm wrong.
>

You are correct, I am working with Ryan to figure this gap out as
identified in [1]

[1] https://review.openstack.org/#/c/389397/15/specs/stadium/ocata.rst@105


>
> Thank you.
>
> __
> OpenStack Development Mailing 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] [Neutron][Dynamic Routing] Plans for scenario testing?

[Assaf Muller]

Hi all,

General query - Is there anyone in the Dynamic Routing community that
is planning on contributing a scenario test? As far as I could tell,
none of the current API tests would fail if, for example, the BGP
agent was not running. Please correct me if I'm wrong.

Thank you.

__
OpenStack Development Mailing 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] [devstack]VersionConflict exception during stack.sh - resend with explanation.

[Tony Breeds]

On Tue, Dec 06, 2016 at 08:02:23PM +, Wanjing Xu (waxu) wrote:
> 
> Hi, 
> My devstack had been OK a month ago. But recently it keeps having this
> VersionConflict  error.  If I manually install the required module version,
> it will move on but then it will error out at some other module.  I have
> manually installed and fixed about 8 such modules, still it is not ending.  I
> guess I have something fundamental that I missed.  Could somebody please help
> me?  I was reading the pip code, there is some replace_conflicting env, but I
> don’t know how to set it, maybe it is set in vendor package?

You'll need to provide a little more information.  I'm assuming that you have a
devstack setup that you're ./unstack,sh ; ./stack.sh to upgrade? and overtime
the repos are gettiing out of sync.

Can you explain what you're doing?

Also can you please provide the out of:
pip freeze | sort
for repo in /opt/stack/* ; do (cd $repo ; [ -d .git ] && git describe ) ; done

That will help us understand what you have and why the constratints file
appears to be ineffective.

Tony.


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

Re: [openstack-dev] [nova] placement/resource providers update 4

[Sylvain Bauza]

Le 06/12/2016 22:02, Ed Leafe a écrit :
> On Dec 6, 2016, at 2:42 PM, Jay Pipes  wrote:
> 
>> Oh, absolutely, I wasn't arguing about length of URI or anything.
>>
>> To be clear, I could either go the above route or even do a POST 
>> /resource_providers that returns a list of resource providers instead of 
>> creating a resource provider. Don't mind either way.
>>
>> But, we should definitely agree on which this is going to be ASAP.
> 
> http://specs.openstack.org/openstack/api-wg/guidelines/uri.html#complex-queries
> 
> There is no compelling reason that anyone has put forth for using POST; they 
> all seem to boil down to “I prefer it”, without any good technical reasoning 
> behind it. Since this is new development, we should be good OpenStack 
> citizens and ensure that our APIs are consistent with the rest of OpenStack.
> 
> 

Just to be clear, there was a consensus between Matt, Laski, Dan and I
having a POST method instead of having a GET one.

I provided a POST method for a new resource called "claim" but okay, I
can try to modify my change using POST /resource_provider returning a 200.

-Sylvain

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

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

Re: [openstack-dev] [Horizon] Draft team mascot

[Jason Rist]

On 12/06/2016 01:48 PM, Richard Jones wrote:
> >> On 6 Dec 2016, at 20:19, Richard Jones  wrote:
> >> Please let me know what you think (by December 12) of this draft for
> >> our Horizon team mascot.
> >
> On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
>  wrote:
> > Are we missing an attachment / link ?
>
> Weird! Trying again:
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Much UI, such OpenStack, wow.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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] placement/resource providers update 4

[Ed Leafe]

On Dec 6, 2016, at 3:00 PM, melanie witt  wrote:
> 
> Last time I was aware of the discussion, I thought that sophisticated queries 
> for a list of resource providers would involve specifying a structured JSON 
> payload. That is where I don't tend to think a query string in the URI is so 
> usable. Are we assuming user queries will be relatively simple?

I’m not sure where there was discussion of sophisticated queries, or exactly 
what would constitute a sophisticated query. We designed resource providers so 
that they would have simple integer inventories, and traits so that they would 
be simple booleans. So the queries should be similarly simple.


-- Ed Leafe






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

Re: [openstack-dev] [nova] placement/resource providers update 4

[Jay Pipes]

On 12/06/2016 04:00 PM, melanie witt wrote:

On Tue, 6 Dec 2016 15:42:18 -0500, Jay Pipes wrote:

On 12/06/2016 03:28 PM, Ed Leafe wrote:

On Dec 6, 2016, at 2:16 PM, Jay Pipes  wrote:


I would prefer:

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048

to "group" the resources parameter together. When we add in trait
lookups, we're going to want a way to clearly delineate between
resource classes and traits other than just knowing resource classes
are ALL_CAPS...

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
 =storage:ssd,hw:cpu:x86:avx2
 =virt:hyperv:gen2


OK, that’s fine. The URI path is still just 126 characters, well below
the limit of around 8K. It still seems anything but scary.


Oh, absolutely, I wasn't arguing about length of URI or anything.

To be clear, I could either go the above route or even do a POST
/resource_providers that returns a list of resource providers instead of
creating a resource provider. Don't mind either way.

But, we should definitely agree on which this is going to be ASAP.


Last time I was aware of the discussion, I thought that sophisticated
queries for a list of resource providers would involve specifying a
structured JSON payload. That is where I don't tend to think a query
string in the URI is so usable. Are we assuming user queries will be
relatively simple?

From what I recall, the ideas were:

1. GET with non-JSON query string if simple, else GET with JSON body
(which is not covered by HTTP spec)

2. GET with JSON query string to cover both simple and sophisticated
queries

3. POST with JSON body to a /resource_providers/list URI to cover both
simple and sophisticated queries

Which option are we talking about now? 1? Or a version of it where
queries are assumed to be simple and no JSON structure at all?


We're discussing only doing:

 GET /resource_providers?

Once we start doing claims in the scheduler, we'll have the ability to do:

 POST /allocations
 {
all kinds of stuff :)>

 }

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] placement/resource providers update 4

[Ed Leafe]

On Dec 6, 2016, at 2:42 PM, Jay Pipes  wrote:

> Oh, absolutely, I wasn't arguing about length of URI or anything.
> 
> To be clear, I could either go the above route or even do a POST 
> /resource_providers that returns a list of resource providers instead of 
> creating a resource provider. Don't mind either way.
> 
> But, we should definitely agree on which this is going to be ASAP.

http://specs.openstack.org/openstack/api-wg/guidelines/uri.html#complex-queries

There is no compelling reason that anyone has put forth for using POST; they 
all seem to boil down to “I prefer it”, without any good technical reasoning 
behind it. Since this is new development, we should be good OpenStack citizens 
and ensure that our APIs are consistent with the rest of OpenStack.


-- Ed Leafe






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

Re: [openstack-dev] [nova] placement/resource providers update 4

[melanie witt]

On Tue, 6 Dec 2016 15:42:18 -0500, Jay Pipes wrote:

On 12/06/2016 03:28 PM, Ed Leafe wrote:

On Dec 6, 2016, at 2:16 PM, Jay Pipes  wrote:


I would prefer:

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048

to "group" the resources parameter together. When we add in trait
lookups, we're going to want a way to clearly delineate between
resource classes and traits other than just knowing resource classes
are ALL_CAPS...

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
 =storage:ssd,hw:cpu:x86:avx2
 =virt:hyperv:gen2


OK, that’s fine. The URI path is still just 126 characters, well below
the limit of around 8K. It still seems anything but scary.


Oh, absolutely, I wasn't arguing about length of URI or anything.

To be clear, I could either go the above route or even do a POST
/resource_providers that returns a list of resource providers instead of
creating a resource provider. Don't mind either way.

But, we should definitely agree on which this is going to be ASAP.


Last time I was aware of the discussion, I thought that sophisticated 
queries for a list of resource providers would involve specifying a 
structured JSON payload. That is where I don't tend to think a query 
string in the URI is so usable. Are we assuming user queries will be 
relatively simple?


From what I recall, the ideas were:

1. GET with non-JSON query string if simple, else GET with JSON body 
(which is not covered by HTTP spec)


2. GET with JSON query string to cover both simple and sophisticated queries

3. POST with JSON body to a /resource_providers/list URI to cover both 
simple and sophisticated queries


Which option are we talking about now? 1? Or a version of it where 
queries are assumed to be simple and no JSON structure at all?


-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] [neutron][tricircle]DVR issue in cross Neutron networking

[Brian Haley]

On 12/05/2016 10:38 PM, joehuang wrote:

Hello, Brian,

Thank you for your comment, see inline comments marked with [joehuang].

The ASCII figure is not good in the plain text mail, you can check it at the 
browser: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108447.html

Best Regards
Chaoyi Huang (joehuang)


From: Brian Haley [brian.ha...@hpe.com]
Sent: 06 December 2016 10:29
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][tricircle]DVR issue in cross Neutron 
networking

On 12/5/16 3:03 AM, joehuang wrote:

Hello,


Hi Chaoyi,

Comments inline below.


 Tricircle plans to provide L2 network across Neutron to ease supporting
high
 availability of application:

 For example, in the following figure, the application is consisted of
 instance1 and instance2, these two instances will be deployed into two
 OpenStack. Intance1 will provide service through "ext net1"(i.e, external
 network in OpenStack1), and Instance2 will provide service through
 "ext net2". Instance1 and Instance2 will be plugged into same L2 network
 net3 for data replication( for example database replication ).

  +-+   +-+
  |OpenStack1   |   |OpenStack2   |
  | |   | |
  | ext net1|   | ext net2|
  |   +-+-+ |   |   +-+-+ |
  | |   |   | |   |
  | |   |   | |   |
  |  +--+--+|   |  +--+--+|
  |  | ||   |  | ||
  |  | R1  ||   |  | R2  ||
  |  | ||   |  | ||
  |  +--+--+|   |  +--+--+|
  | |   |   | |   |
  | |   |   | |   |
  | +---+-+-+   |   | +---+-+-+   |
  | net1  | |   | net2  | |
  |   | |   |   | |
  |  ++--+  |   |  ++--+  |
  |  | Instance1 |  |   |  | Instance2 |  |
  |  +---+  |   |  +---+  |
  | |   |   | |   |
  | |   | net3  | |   |
  |  +--+-++  |
  | |   | |
  +-+   +-+


Are Openstack1 and 2 simply different compute nodes?

[joehuang] No, OpenStack 1 and 2 are two OpenStack clouds, each OpenStack cloud
 includes its own services like Nova, Cinder, Neutron. That 
means
 R1, net1 are network objects in OpenStack cloud1 ( Neutron1)
 R2, net2 are network objects in OpenStack cloud2 ( Neutron2),
 but net3 will be a shared L2 network existing in both 
OpenStack cloud1 and
 OpenStack cloud2, i.e in Neutron 1 and Neutron 2.


So net3 is a shared private network, perhaps just a shared VLAN.  And something 
makes sure IP address allocations don't overlap.  Ok.



 When we deploy the application in such a way, no matter which part of the
 application stops providing service, the other part can still provide
 service, and take the workload from the failure one. It'll bring the
failure
 tolerance no matter the failure is due to OpenStack crush or upgrade, or
 part of the application crush or upgrade.

 This mode can work very well and helpful, and router R1 R2 can run in DVR
 or legacy mode.

 While during the discussion and review of the spec:
 https://review.openstack.org/#/c/396564/, in this deployment, the end user
 has to add two NICs for each instance, one for the net3(a L2 network across
 OpenStack). And the net3 (a L2 network across OpenStack) can not be allowed
 to add_router_interface to router R1 R2, this is not good in networking.

 If the end user wants to do so, there is DVR MAC issues if more than one L2
 network across OpenStack are performed add_router_interface to router
R1 R2.

 Let's look at the following deployment scenario:
 +-+   +---+
 |OpenStack1   |   |OpenStack2 |
 | |   |   |
 | ext net1|   | ext net2  |
 |   +-+-+ |   |   +-+-+   |
 | |   |   | | |
 | |   |   | | |
 | +---+--+|   |  +--+---+ |
 | |  ||   |  |  | |
 | |R1||   |  |   R2 | |
 | |  ||   |  |  | |
 | ++--+--+|   |  +--+-+-+ |
 |  |  |   |   | | |   |
 |  |  |   | net3  | | |   |
 |  |   -+-+---+-+--+  |   |
 |  || |   |   |   |   |
 |  | +--+---+ |   | +-+-+ |   |
 |  | | Instance1| |   | | Instance2 | |   |
 |  | +--+ |   

Re: [openstack-dev] [Horizon] Draft team mascot

[Richard Jones]

>> On 6 Dec 2016, at 20:19, Richard Jones  wrote:
>> Please let me know what you think (by December 12) of this draft for
>> our Horizon team mascot.
>
On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
 wrote:
> Are we missing an attachment / link ?

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

Re: [openstack-dev] [nova] placement/resource providers update 4

[Jay Pipes]

On 12/06/2016 03:28 PM, Ed Leafe wrote:

On Dec 6, 2016, at 2:16 PM, Jay Pipes  wrote:


I would prefer:

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048

to "group" the resources parameter together. When we add in trait lookups, 
we're going to want a way to clearly delineate between resource classes and traits other 
than just knowing resource classes are ALL_CAPS...

GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
 =storage:ssd,hw:cpu:x86:avx2
 =virt:hyperv:gen2


OK, that’s fine. The URI path is still just 126 characters, well below the 
limit of around 8K. It still seems anything but scary.


Oh, absolutely, I wasn't arguing about length of URI or anything.

To be clear, I could either go the above route or even do a POST 
/resource_providers that returns a list of resource providers instead of 
creating a resource provider. Don't mind either way.


But, we should definitely agree on which this is going to be ASAP.

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] [Horizon] Draft team mascot

[Rob Cresswell (rcresswe)]

Are we missing an attachment / link ?

:)

> On 6 Dec 2016, at 20:19, Richard Jones  wrote:
> 
> Hi folks,
> 
> Please let me know what you think (by December 12) of this draft for
> our Horizon team mascot.
> 
> __
> OpenStack Development Mailing 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] placement/resource providers update 4

[Ed Leafe]

On Dec 6, 2016, at 2:16 PM, Jay Pipes  wrote:

> I would prefer:
> 
> GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
> 
> to "group" the resources parameter together. When we add in trait lookups, 
> we're going to want a way to clearly delineate between resource classes and 
> traits other than just knowing resource classes are ALL_CAPS...
> 
> GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
>  =storage:ssd,hw:cpu:x86:avx2
>  =virt:hyperv:gen2

OK, that’s fine. The URI path is still just 126 characters, well below the 
limit of around 8K. It still seems anything but scary.

-- Ed Leafe






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

[openstack-dev] [Neutron][DVR] - No IRC Meeting this week

[Brian Haley]

Hi Folks,

We will not have a DVR sub-team meeting this week since neither Swami nor myself 
will be there to chair it.


We will resume our meetings next week on December 14th.

If you have any questions please ping us on IRC or send an email to the list.

https://wiki.openstack.org/wiki/Meetings/Neutron-DVR

Thanks,

-Brian

__
OpenStack Development Mailing 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] Draft team mascot

[Richard Jones]

Hi folks,

Please let me know what you think (by December 12) of this draft for
our Horizon team mascot.

__
OpenStack Development Mailing 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] placement/resource providers update 4

[Jay Pipes]

On 12/06/2016 02:02 PM, Ed Leafe wrote:

On Dec 6, 2016, at 9:56 AM, Chris Dent  wrote:


* There is unresolved debate about the structure of the request being
 made to the API. Is it POST or a GET, does it have a body or use
 query strings? The plan is to resolve this discussion in the review
 of the code at [3].


I personally prefer the POST after reading about the differences between the 
two, and when reviewing the spec on this. I'm not crazy about the scheduler 
having to pass a giant json string as a query parameter to a GET request on the 
placement API, I'd rather do that with a request body.


I think the giant json package (wherever it may reside) will only
become a thing when we are doing actual claims via the /allocations
endpoint, in which case a POST will be the right thing (since we're
doing a right). The query against /resource_providers is merely to
limit a large list of resource providers to a smaller list of
resource providers, based on a relatively small number of
parameters.


GET /resource_providers?DISK_GB=40=2_MB=2048

For the life of me I can't see what's so scary about this. Sure, we may add a 
few more in the future, but it's never going to grow to gigantic proportions.


I would prefer:

 GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048

to "group" the resources parameter together. When we add in trait 
lookups, we're going to want a way to clearly delineate between resource 
classes and traits other than just knowing resource classes are ALL_CAPS...


 GET /resource_providers?resources=DISK_GB:40,VCPU:2,MEMORY_MB:2048
  =storage:ssd,hw:cpu:x86:avx2
  =virt:hyperv:gen2

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] [devstack]VersionConflict exception during stack.sh

[Wanjing Xu (waxu)]

Thanks for replying .  Sorry I did not write explanation in this email. So I 
sent another one.  Basically, there are too many of this kind of conflicts, I 
already manually fixed about 8, still more.  If I  fix them all this time, it 
may still happen down the road if somebody update constrains or requrements.  I 
am just wondering why this thing was not happening before.  I noticed that pip 
was updated to version 9, my old good one was using pip version 8

On 12/6/16, 11:58 AM, "Beliveau, Ludovic"  wrote

Try to manually uninstall it first: sudo pip uninstall python-heatclient

Then launch devstack again.  It will re-install the right version.

/ludovic

-Original Message-
From: Wanjing Xu (waxu) [mailto:w...@cisco.com] 
Sent: December-06-16 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack]VersionConflict exception during stack.sh

 Hi

2016-12-06 18:50:28.095 | +inc/python:setup_package:354 ?[m? 
pip_install -e /opt/stack/horizon
2016-12-06 18:50:28.881 | +inc/python:pip_install:155   ?[m? 
sudo -H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= 
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c 
/opt/stack/requirements/upper-constraints.txt --upgrade -e /opt/stack/horizon
2016-12-06 18:50:29.930 | Ignoring dnspython3: markers 'python_version == 
"3.4"' don't match your environment
2016-12-06 18:50:29.931 | Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment
2016-12-06 18:50:30.276 | Obtaining file:///opt/stack/horizon
2016-12-06 18:50:33.097 | Exception:
2016-12-06 18:50:33.098 | Traceback (most recent call last):
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
2016-12-06 18:50:33.098 | status = self.run(options, args)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 335, in 
run
2016-12-06 18:50:33.098 | wb.build(autobuilding=True)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
2016-12-06 18:50:33.098 | 
self.requirement_set.prepare_files(self.finder)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
2016-12-06 18:50:33.098 | ignore_dependencies=self.ignore_dependencies))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, in 
_prepare_file
2016-12-06 18:50:33.098 | req_to_install.check_if_exists()
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 1036, in 
check_if_exists
2016-12-06 18:50:33.098 | self.req.name
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
2016-12-06 18:50:33.098 | dist = get_provider(dist)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
2016-12-06 18:50:33.098 | return working_set.find(moduleOrReq) or 
require(str(moduleOrReq))[0]
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
2016-12-06 18:50:33.098 | needed = 
self.resolve(parse_requirements(requirements))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
2016-12-06 18:50:33.098 | raise VersionConflict(dist, 
req).with_context(dependent_req)
2016-12-06 18:50:33.098 | ContextualVersionConflict: (python-heatclient 
1.5.0 (/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-heatclient>=1.6.1'), set(['horizon']))
2016-12-06 18:50:33.233 | +inc/python:pip_install:1 ?[m? 
exit_trap
2016-12-06 18:50:33.240 | +./stack.sh:exit_trap:487 ?[m? 
local r=2
2016-12-06 18:50:33.250 | ++./stack.sh:exit_trap:488 ?[m? 
jobs -p
2016-12-06 18:50:33.260 | +./stack.sh:exit_trap:488 ?[m? 
jobs=
2016-12-06 18:50:33.269 | +./stack.sh:exit_trap:491 ?[m? [[ 
-n '' ]]
2016-12-06 18:50:33.278 | +./stack.sh:exit_trap:497 ?[m? 
kill_spinner

__
OpenStack Development Mailing 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 

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

[Miroslav Halas]

Hello Harm,

Thank you for sharing. I was wondering if you have given any thoughts how other 
type of devices other than FPGAs would fit into this framework. For example, 
GPUs or block devices (such as NVMe drives) for exclusive access  by the VMs. 
Could these type of devices be also managed by cyborg?

Thanks,

Miro Halas

From: Harm Sluiman [mailto:harm.slui...@gmail.com]
Sent: Saturday, December 03, 2016 4:54 AM
To: Zhipeng Huang
Cc: OpenStack Development Mailing List (not for usage questions); 
rodolfo.alonso.hernan...@intel.com; Michele Paolino; Scott Kelso; Roman Dobosz; 
Jim Golden; Miroslav Halas; pradeep.jagade...@huawei.com; 
michael.ro...@nokia.com; jian-feng.d...@intel.com; martial.mic...@nist.gov; 
Moshe Levi; Edan David; Francois Ozog; Fei K Chen; jack...@huawei.com; 
lil...@huawei.com
Subject: Re: [acceleration]Team Biweekly Meeting 2016.11.23 agenda

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

Sorry for the delay.

I added a few words to the NASCA etherpad,

I waited for cyborg git to drop ppt but no luck yet so I put it here on google 
drive. I hope you can reach it. follow it in show mode for a “rich” experience 
;-)
I captured some FPGA run time flows as background, and then some sequences of 
lifecycle management. I have shared this with a few of you before.
https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM
I am creating etherpad to discuss
https://etherpad.openstack.org/p/cyborg-initial-flow-discussion
I am also creating an etherpad to discuss the in POC we have talked about for 
February to help define the scope of Cyborg
https://etherpad.openstack.org/p/cyborg-initial-design-poc


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

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






Thanks for your time.
宋哲
Harm Sluiman





On Nov 23, 2016, at 11:49 PM, Zhipeng Huang 
> wrote:

Hi team,

Thanks for the discussion and please find the minutes here 
https://wiki.openstack.org/wiki/Cyborg/MeetingLogs

On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang 
> wrote:
Forward here again in case you have not registered to openstack-dev mailinglist

-- Forwarded message --
From: Zhipeng Huang >
Date: Wed, Nov 23, 2016 at 8:34 PM
Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
To: "OpenStack Development Mailing List (not for usage questions)" 
>

Hi Team,

Please find the meeting logistics and agendas at 
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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

[openstack-dev] [devstack]VersionConflict exception during stack.sh - resend with explanation.

[Wanjing Xu (waxu)]

Hi, 
My devstack had been OK a month ago. But recently it keeps having this 
VersionConflict  error.  If I manually install the required module version, it 
will move on but then it will error out at some other module.  I have manually 
installed and fixed about 8 such modules, still it is not ending.  I guess I 
have something fundamental that I missed.  Could somebody please help me?  I 
was reading the pip code, there is some replace_conflicting env, but I don’t 
know how to set it, maybe it is set in vendor package?

Thanks
2016-12-06 18:50:28.095 | +inc/python:setup_package:354 ?[m? 
pip_install -e /opt/stack/horizon
2016-12-06 18:50:28.881 | +inc/python:pip_install:155   ?[m? 
sudo -H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= 
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c 
/opt/stack/requirements/upper-constraints.txt --upgrade -e /opt/stack/horizon
2016-12-06 18:50:29.930 | Ignoring dnspython3: markers 'python_version == 
"3.4"' don't match your environment
2016-12-06 18:50:29.931 | Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment
2016-12-06 18:50:30.276 | Obtaining file:///opt/stack/horizon
2016-12-06 18:50:33.097 | Exception:
2016-12-06 18:50:33.098 | Traceback (most recent call last):
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
2016-12-06 18:50:33.098 | status = self.run(options, args)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 335, in 
run
2016-12-06 18:50:33.098 | wb.build(autobuilding=True)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
2016-12-06 18:50:33.098 | 
self.requirement_set.prepare_files(self.finder)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
2016-12-06 18:50:33.098 | ignore_dependencies=self.ignore_dependencies))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, in 
_prepare_file
2016-12-06 18:50:33.098 | req_to_install.check_if_exists()
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 1036, in 
check_if_exists
2016-12-06 18:50:33.098 | self.req.name
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
2016-12-06 18:50:33.098 | dist = get_provider(dist)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
2016-12-06 18:50:33.098 | return working_set.find(moduleOrReq) or 
require(str(moduleOrReq))[0]
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
2016-12-06 18:50:33.098 | needed = 
self.resolve(parse_requirements(requirements))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
2016-12-06 18:50:33.098 | raise VersionConflict(dist, 
req).with_context(dependent_req)
2016-12-06 18:50:33.098 | ContextualVersionConflict: (python-heatclient 
1.5.0 (/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-heatclient>=1.6.1'), set(['horizon']))
2016-12-06 18:50:33.233 | +inc/python:pip_install:1 ?[m? 
exit_trap
2016-12-06 18:50:33.240 | +./stack.sh:exit_trap:487 ?[m? 
local r=2
2016-12-06 18:50:33.250 | ++./stack.sh:exit_trap:488 ?[m? 
jobs -p
2016-12-06 18:50:33.260 | +./stack.sh:exit_trap:488 ?[m? 
jobs=
2016-12-06 18:50:33.269 | +./stack.sh:exit_trap:491 ?[m? [[ 
-n '' ]]
2016-12-06 18:50:33.278 | +./stack.sh:exit_trap:497 ?[m? 
kill_spinner



__
OpenStack Development Mailing 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] [devstack]VersionConflict exception during stack.sh

[Beliveau, Ludovic]

Try to manually uninstall it first: sudo pip uninstall python-heatclient

Then launch devstack again.  It will re-install the right version.

/ludovic

-Original Message-
From: Wanjing Xu (waxu) [mailto:w...@cisco.com] 
Sent: December-06-16 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack]VersionConflict exception during stack.sh

 Hi

2016-12-06 18:50:28.095 | +inc/python:setup_package:354  
pip_install -e /opt/stack/horizon
2016-12-06 18:50:28.881 | +inc/python:pip_install:155    sudo 
-H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= 
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c 
/opt/stack/requirements/upper-constraints.txt --upgrade -e /opt/stack/horizon
2016-12-06 18:50:29.930 | Ignoring dnspython3: markers 'python_version == 
"3.4"' don't match your environment
2016-12-06 18:50:29.931 | Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment
2016-12-06 18:50:30.276 | Obtaining file:///opt/stack/horizon
2016-12-06 18:50:33.097 | Exception:
2016-12-06 18:50:33.098 | Traceback (most recent call last):
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
2016-12-06 18:50:33.098 | status = self.run(options, args)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 335, in 
run
2016-12-06 18:50:33.098 | wb.build(autobuilding=True)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
2016-12-06 18:50:33.098 | self.requirement_set.prepare_files(self.finder)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
2016-12-06 18:50:33.098 | ignore_dependencies=self.ignore_dependencies))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, in 
_prepare_file
2016-12-06 18:50:33.098 | req_to_install.check_if_exists()
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 1036, in 
check_if_exists
2016-12-06 18:50:33.098 | self.req.name
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
2016-12-06 18:50:33.098 | dist = get_provider(dist)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
2016-12-06 18:50:33.098 | return working_set.find(moduleOrReq) or 
require(str(moduleOrReq))[0]
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
2016-12-06 18:50:33.098 | needed = 
self.resolve(parse_requirements(requirements))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
2016-12-06 18:50:33.098 | raise VersionConflict(dist, 
req).with_context(dependent_req)
2016-12-06 18:50:33.098 | ContextualVersionConflict: (python-heatclient 1.5.0 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-heatclient>=1.6.1'), set(['horizon']))
2016-12-06 18:50:33.233 | +inc/python:pip_install:1  
exit_trap
2016-12-06 18:50:33.240 | +./stack.sh:exit_trap:487  local 
r=2
2016-12-06 18:50:33.250 | ++./stack.sh:exit_trap:488  jobs 
-p
2016-12-06 18:50:33.260 | +./stack.sh:exit_trap:488  jobs=
2016-12-06 18:50:33.269 | +./stack.sh:exit_trap:491  [[ -n 
'' ]]
2016-12-06 18:50:33.278 | +./stack.sh:exit_trap:497  
kill_spinner

__
OpenStack Development Mailing 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] [devstack]VersionConflict exception during stack.sh

[Wanjing Xu (waxu)]

 Hi

2016-12-06 18:50:28.095 | +inc/python:setup_package:354  
pip_install -e /opt/stack/horizon
2016-12-06 18:50:28.881 | +inc/python:pip_install:155    sudo 
-H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= 
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c 
/opt/stack/requirements/upper-constraints.txt --upgrade -e /opt/stack/horizon
2016-12-06 18:50:29.930 | Ignoring dnspython3: markers 'python_version == 
"3.4"' don't match your environment
2016-12-06 18:50:29.931 | Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment
2016-12-06 18:50:30.276 | Obtaining file:///opt/stack/horizon
2016-12-06 18:50:33.097 | Exception:
2016-12-06 18:50:33.098 | Traceback (most recent call last):
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
2016-12-06 18:50:33.098 | status = self.run(options, args)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 335, in 
run
2016-12-06 18:50:33.098 | wb.build(autobuilding=True)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
2016-12-06 18:50:33.098 | self.requirement_set.prepare_files(self.finder)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
2016-12-06 18:50:33.098 | ignore_dependencies=self.ignore_dependencies))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, in 
_prepare_file
2016-12-06 18:50:33.098 | req_to_install.check_if_exists()
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 1036, in 
check_if_exists
2016-12-06 18:50:33.098 | self.req.name
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
2016-12-06 18:50:33.098 | dist = get_provider(dist)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
2016-12-06 18:50:33.098 | return working_set.find(moduleOrReq) or 
require(str(moduleOrReq))[0]
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
2016-12-06 18:50:33.098 | needed = 
self.resolve(parse_requirements(requirements))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
2016-12-06 18:50:33.098 | raise VersionConflict(dist, 
req).with_context(dependent_req)
2016-12-06 18:50:33.098 | ContextualVersionConflict: (python-heatclient 1.5.0 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-heatclient>=1.6.1'), set(['horizon']))
2016-12-06 18:50:33.233 | +inc/python:pip_install:1  
exit_trap
2016-12-06 18:50:33.240 | +./stack.sh:exit_trap:487  local 
r=2
2016-12-06 18:50:33.250 | ++./stack.sh:exit_trap:488  jobs 
-p
2016-12-06 18:50:33.260 | +./stack.sh:exit_trap:488  jobs=
2016-12-06 18:50:33.269 | +./stack.sh:exit_trap:491  [[ -n 
'' ]]
2016-12-06 18:50:33.278 | +./stack.sh:exit_trap:497  
kill_spinner

__
OpenStack Development Mailing 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] [puppet] Virtual midcycle/sprint - Jan 11/12

[Alex Schultz]

Hey everyone,

We're going to be running a small midcycle/sprint on January 11-12,
2017 in #puppet-openstack on freenode.  We will be reviewing the work
items for Ocata and doing some bug triage. Feel free to add additional
topics to the etherpad[0].

Thanks,
-Alex

[0] https://etherpad.openstack.org/p/puppet-openstack-ocata-midcycle

__
OpenStack Development Mailing 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] Ocata Bugsmash

[Sean McGinnis]

Last week was the Ocata Bugsmash in Shenzhen, China. Many developers
from around China gathered to debug, test, and fix a large number of
bugs across many of the most popular projects.

I wanted to take an opportunity to thank Huawei, Intel, and everyone
involved for making this event happen. It was great seeing so much
focused attention on addressing our outstanding bugs, and I felt the
event was very productive. Really great work done by the Chinese
OpenStack community.

I also wanted to take the opportunity to spread the word about the event
to others interested in being involved and any other companies that
would be interested in running this type of event in other countries. I
think a couple releases ago, things were able to be coordinated in at
least a couple other locations.

As a PTL and core for Cinder, I would love to see this picked up again and
make a bugsmash week happen every cycle across multiple locations. Just
seeing how much the one group could get done in China - I can just
imagine how much could be accomplished by a larger extended effort.

I have no involvement in the organizing or planning of this event, but
if any vendors are interested in spreading this into a larger event,
feel free to contact me directly for any feedback and thoughts from a
participant perspective.

But I want to make sure full credit for this goes to Huawei and Intel
for sponsoring this for five cycles in a row. In my opinion, it's a very
valuable event to bring devs together from all over and really focus on
improving OpenStack. Thank you again to all involved in making it
happen.

Thanks,
Sean (smcginnis)

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

Re: [openstack-dev] [nova] placement/resource providers update 4

[Ed Leafe]

On Dec 6, 2016, at 9:56 AM, Chris Dent  wrote:

>>> * There is unresolved debate about the structure of the request being
>>>  made to the API. Is it POST or a GET, does it have a body or use
>>>  query strings? The plan is to resolve this discussion in the review
>>>  of the code at [3].
>> 
>> I personally prefer the POST after reading about the differences between the 
>> two, and when reviewing the spec on this. I'm not crazy about the scheduler 
>> having to pass a giant json string as a query parameter to a GET request on 
>> the placement API, I'd rather do that with a request body.
> 
> I think the giant json package (wherever it may reside) will only
> become a thing when we are doing actual claims via the /allocations
> endpoint, in which case a POST will be the right thing (since we're
> doing a right). The query against /resource_providers is merely to
> limit a large list of resource providers to a smaller list of
> resource providers, based on a relatively small number of
> parameters.

GET /resource_providers?DISK_GB=40=2_MB=2048

For the life of me I can't see what's so scary about this. Sure, we may add a 
few more in the future, but it's never going to grow to gigantic proportions. 


-- Ed Leafe






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

[openstack-dev] [Infra] Ocata Summit Infra Sessions Recap

[Jeremy Stanley]

I'm Cc'ing this to the openstack-infra ML but setting MFT to direct
subsequent discussion to the openstack-dev ML so we can hopefully
avoid further cross-posting as much as possible. If you're replying
on a particular session topic, please update the Subject so that the
subthreads are easier to keep straight.

Apologies for the _extreme_ delay in getting this composed and sent
out!


Firehose


https://etherpad.openstack.org/p/ocata-infra-firehose

This was primarily a brainstorming/roadmap session on possible
future plans for the firehose.openstack.org service. Discussed was
potential to have Zuul (post-v3) both consume and emit events over
MQTT, as well as having StoryBoard (should probably support an
analog of the events handled by lpmqtt at a minimum, probably easy
to add given it already has an RabbitMQ one) and Nodepool event
streams. The gerritbot consumer PoC was mentioned, but determined
that it would be better to shelve that until planning for an
Errbot-based gerritbot reimplementation is fleshed out.

We talked about how the current logstash MQTT stream implementation,
while interesting, has significant scaling (especially bandwidth)
issues with the volume of logging we do in tests while only offering
limited benefit. We could potentially make use of it in concern with
a separate logstash for production server and Ansible logs, but it's
efficacy for our job logs was called into question.

We also spent much of the timeslot talking about possible
integration with FedMesg (particularly that they're considering
pluggable backend support which could include an MQTT
implementation), which yields much opportunity for collaboration
between our projects.

One other topic which came up was how to do a future HA
implementation, either by having publishers send to multiple brokers
and configure consumers to have a primary/fallback behavior or my
trying to implement a more integrated clustering solution with load
balancing proxies. We concluded that current use cases don't demand
anywhere near 100% message delivery and 100% uptime, so we can dig
deeper when there's an actual use case.


Status update and plans for task tracking
-

https://etherpad.openstack.org/p/ocata-infra-community-task-tracking

As is traditional, we held a fishbowl on our ongoing task tracking
woes. We started with a brief introduction of stakeholders who
attended and the groups whose needs they were there to represent.
After that, some presentation was made of recent StoryBoard
development progress since Austin (including Gerrit integration,
private story support for embargoed security issues, improved event
timelines, better discoverability for boards and worklists, flexible
task prioritization), as well as the existing backlog of blockers.

We revisited the Infra spec on task tracking
http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html
for the benefit of those present, and Kendall Nelson (diablo_rojo)
agreed to pick up and continue with the excellent stakeholder
blocking issues outreach/coordination work begun by Anita Kuno
(anteaya).


Next steps for infra-cloud
--

https://etherpad.openstack.org/p/ocata-infra-infra-cloud

This was sort of a catch-all opportunity to hash out current plans
and upcoming needs for the infra-cloud. We determined that the
current heterogeneous hardware in the in-progress "chocolate" region
should be split into two homogeneous regions named "chocolate" and
"strawberry" (our "vanilla" region was already homogeneous). We also
talked about ongoing work to get a quote from OSUOSL for hosting the
hardware so that we can move it out of HPE data centers, and
attempting to find funding once we have some figures firmed up.

There were also some sideline discussions on possible monitoring and
high-availability options for the underlying services.
Containerization was, as always, brought up but the usual "not a fit
for this use case" answers abounded. It was further suggested that
using infra-cloud resources for things like special TripleO tests or
Docker registry hosting were somehow in scope, but there are other
solutions to these needs which should not be conflated with the
purpose of the infra-cloud effort.


Interactive infra-cloud debugging
-

https://etherpad.openstack.org/p/ocata-infra-infra-cloud-debugging

The original intent for this session was to try to gather
leaders/representatives from the various projects that we're relying
on in the infra-cloud deployment and step through an interactive
session debugging the sorts of failures we see arise on the servers.
The idea was that this would be potentially educational for some
since this is a live bare metal "production" deployment of Nova,
Neutron, Keystone, Glance, et cetera with all the warts and rough
edges that operators handle on a daily basis but our developers may
not have directly experienced.

As well-intentioned as 

Re: [openstack-dev] [neutron] trunk api performance and scale measurments

[Tidwell, Ryan]

Bence,

I had been meaning to go a little deeper with performance benchmarking, but 
I’ve been crunched for time. Thanks for doing this, this is some great analysis.

As Armando mentioned, L2pop seemed to be the biggest impediment to control 
plane performance.  If I were to use trunks heavily in production I would 
consider A) not using overlays that would leverage L2pop (ie VLAN or flat 
segmentation) or B) disabling L2pop and dealing with the MAC learning overhead 
in the overlay.  Another consideration is the rpc_timeout setting, I tested 
with rpc_timeout=300 and I didn’t really encounter any rpc_timeouts. However, 
there may be other reasons operators may have for not bumping rpc_timeout up 
that high.

I failed to make much mention of it in previous write-ups, but I also 
encountered scale issues with listing ports after a certain threshold. I 
haven’t gone back to identify where the tipping point is, but I did notice that 
Horizon began to really bog down as I added ports to the system. On the surface 
it didn’t seem to matter whether these ports were used as subports or not, the 
sheer volume of ports added to the system seemed to cause both Horizon and more 
importantly GET on v2.0/ports to really bog down.

-Ryan

From: Armando M. [mailto:arma...@gmail.com]
Sent: Monday, December 05, 2016 8:37 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] trunk api performance and scale 
measurments



On 5 December 2016 at 08:07, Jay Pipes 
> wrote:
On 12/05/2016 10:59 AM, Bence Romsics wrote:
Hi,

I measured how the new trunk API scales with lots of subports. You can
find the results here:

https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling

Hope you find it useful. There are several open ends, let me know if
you're interested in following up some of them.

Great info in there, Ben, thanks very much for sharing!

Bence,

Thanks for the wealth of information provided, I was looking forward to it! The 
results of the experimentation campaign makes me somewhat confident that trunk 
feature design is solid, or at least that is what it looks like! I'll look into 
why there is a penalty on port-list, because that's surprising for me too.

I also know that the QE team internally at HPE has done some perf testing 
(though I don't have results publicly available yet), but what I can share at 
this point is:

  *   They also disabled l2pop to push the boundaries of trunk deployments;
  *   They disabled OVS firewall (though for reasons orthogonal to scalability 
limits introduced by the functionality);
  *   They flipped back to ovsctl interface, as it turned out to be one of 
components that introduced some penalty. Since you use native interface, it'd 
be nice to see what happens if you flipped this switch too;
  *   RPC timeout of 300.
On a testbed of 3 controllers and 7 computes, this is at high level what they 
found out the following:

  *   100 trunks, with 1900 subports took about 30 mins with no errors;
  *   500 subports take about 1 min to bind to a trunk;
  *   Booting a VM on trunk with 100 subports takes as little as 15 seconds to 
successful ping. Trunk goes from BUILD -> ACTIVE within 60 seconds of booting 
the VM;
  *   Scaling to 700 VM's incrementally on trunks with 100 initial subports is 
constant (e.g. booting time stays set at ~15 seconds).
I believe Ryan Tidwell may have more on this.

Cheers,
Armando



-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

__
OpenStack Development Mailing 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] [cinder] consistency groups in ceph

[yang, xing]

Hi Victor,

Yes, you are right.

Thanks,
Xing


From: Victor Denisov [vdeni...@mirantis.com]
Sent: Monday, December 5, 2016 7:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

I just realized that probably we create images from individual
snapshots of that consistency group and add those images to the new
consistency group.
Am I correct?

On Mon, Dec 5, 2016 at 3:20 PM, Victor Denisov  wrote:
> Or probably when we clone a consistency group from a snapshot we
> should clone all the images in this consistency group?
>
> On Mon, Dec 5, 2016 at 3:15 PM, Victor Denisov  wrote:
>> Hi Xing,
>>
>> One more question. You mentioned that there is an operation: create
>> consistency group from a snap shot.
>> Does it mean that an image can be a member of several consistency groups?
>>
>> Thanks,
>> V.
>>
>> On Tue, Nov 8, 2016 at 6:21 AM, yang, xing  wrote:
>>> You cannot remove a volume completely if there is still a group snapshot.  
>>> You can remove the volume from the group but you can’t delete the volume 
>>> because it still has snapshot dependent on it.  So if you want to 
>>> completely remove a volume that is in a group, you can delete the group 
>>> snapshot first which will delete the individual snapshot.  After that you 
>>> can remove the volume from the group and delete the volume.
>>>
>>> More comments inline below.
>>>
>>> Thanks,
>>> Xing
>>>
>>>
>>> 
>>> From: Victor Denisov [vdeni...@mirantis.com]
>>> Sent: Tuesday, November 8, 2016 12:04 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Cc: Jason Dillaman
>>> Subject: Re: [openstack-dev] [cinder] consistency groups in ceph
>>>
>>> One more question. What is the expected behavior if you remove a
>>> volume completely?
>>> [Xing] You cannot remove the volume completely (delete volume won't 
>>> succeed) if there is still a group snapshot.
>>>
>>> Should the group snapshot removed first? Should the volume snapshot be
>>> removed from the group snapshot?
>>> [Xing] Yes, you should delete the group snapshot first and that will delete 
>>> the volume snapshot as well.
>>>
>>> Should we keep the snapshot even if the image doesn't exist anymore?
>>> [Xing] You cannot delete the image (volume) if there is still a snapshot.
>>>
>>> Thanks,
>>> Victor.
>>>
>>> On Tue, Nov 1, 2016 at 7:02 AM, yang, xing  wrote:
 Hi Victor,

 Please see my answers inline below.

 In Newton, we added support for Generic Volume Groups.  See doc below.  
 CGs will be migrated to Generic Volume Groups gradually.  Drivers should 
 not implement CGs any more.  Instead, it can add CG support using Generic 
 Volume Group interfaces.  I'm working on a dev doc to explain how to do 
 this and will send an email to the mailing list when I'm done.  The 
 Generic Volume Group interface is very similar to CG interface, except 
 that the Generic Volume Group requires an additional Group Type parameter 
 to be created.  Using Group Type, CG can be a special type of Generic 
 Volume Group.  Please feel free to grab me on Cinder IRC if you have any 
 questions.  My IRC handle is xyang or xyang1.

 http://docs.openstack.org/admin-guide/blockstorage-groups.html

 Thanks,
 Xing


 
 From: Victor Denisov [vdeni...@mirantis.com]
 Sent: Monday, October 31, 2016 11:29 PM
 To: openstack-dev@lists.openstack.org
 Cc: Jason Dillaman
 Subject: [openstack-dev] [cinder] consistency groups in ceph

 Hi,

 I'm working on consistency groups feature in ceph.
 My question is about what kind of behavior does cinder expect from
 storage backends.
 I'm particularly interested in what happens to consistency groups
 snapshots when I remove an image from the group:

 Let's imagine I have a consistency group called CG. I have images in
 the consistency group:
 Im1, Im2, Im3, Im4.
 Let's imagine we have snapshots of this consistency group:

 CGSnap1
 CGSnap2
 CGSnap3

 Snapshots of individual images in a consistency group snapshot I will call
 CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.

 Qustion 1:
 If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
 Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.

 Can CGSnap1 have less images than it already has: Im1, Im2, Im3.

 [Xing]  Once a snapshot is taken from a CG, it can no longer be changed.  
 It is a point-in-time copy.  CGSnap1 cannot be modified.

 Question 2:
 If we remove image2 from the consistency group. Does it mean that
 snapshots of this 

[openstack-dev] [swift] Failed to restore swift from file backup

[Konstantin Danilov]

Hi all,

I try to make a backup of swift cluster by stopping server and backup all files.
Then I create one more cluster with absolutely the same settings and
restore all files
from backup on it. As result swift is working and  'swift glance list'
gives the same
correct list as before, but 'swift glance download' gives 404 for 2
objects of 3.
This 2 object fully available on original cluster and they id
correctly returned by
'list'. 'info' on them return 404  as well. I try to inspect swift db
but it looks correct
as far as I can tell.

Swift log contains no information about this error, except for 404.

CLI results:

# swift list glance
12eb98e1-9f11-44b2-8e92-3320466b65ec
f102e08c-c95e-4594-9994-0f08e25abc28
f99d47a1-5a47-48b1-a723-37b0e86f5edb

# swift stat glance 12eb98e1-9f11-44b2-8e92-3320466b65ec
Object HEAD failed:
http://172.16.27.2:8080/v1/AUTH_fdaed187f1d8483fa5a527634f79054a/glance/12eb98e1-9f11-44b2-8e92-3320466b65ec
404 Not Found

root@node-1:~# swift stat glance f102e08c-c95e-4594-9994-0f08e25abc28
   Account: AUTH_fdaed187f1d8483fa5a527634f79054a
 Container: glance
Object: f102e08c-c95e-4594-9994-0f08e25abc28
  Content Type: application/octet-stream
Content Length: 13287936
 Last Modified: Fri, 02 Dec 2016 00:53:13 GMT
  ETag: ee1eca47dc88f4879d8a229cc70a07c6
 Accept-Ranges: bytes
Connection: close
   X-Timestamp: 1480639992.36531
X-Trans-Id: tx18c34995fb2e4648ad419-005846f370

# swift stat glance f99d47a1-5a47-48b1-a723-37b0e86f5edb
Object HEAD failed:
http://172.16.27.2:8080/v1/AUTH_fdaed187f1d8483fa5a527634f79054a/glance/f99d47a1-5a47-48b1-a723-37b0e86f5edb
404 Not Found

# swift --version
swift 2.4.0

How to investigate this? What files I need to check on disk?
Or update some setting for swift to show me more error information in log?

Thanks

-- 
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis

skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.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] [neutron] Vlan aware VMs or trunking

[Armando M.]

On 6 December 2016 at 08:49, Vasyl Saienko  wrote:

> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it should work in the following way:
>
>1. It is possible to group neutron ports to trunks.
>2. When trunk is created parent port should be defined:
>Only one port can be parent.
>segmentation of parent port is set as native or untagged vlan on the
>trunk.
>3. Other ports may be added as subports to existing trunk.
>When subport is added to trunk *segmentation_type* and *segmentation_id
>*should be specified.
>segmentation_id of subport is set as allowed vlan on the trunk
>
> Non-admin user do not know anything about *segmentation_type* and
> *segmentation_id.*
>

Segmentation type and ID are used to multiplex/demultiplex traffic in/out
of the guest associated to a particular trunk. Aside the fact that the only
supported type is VLAN at the moment (if ever), the IDs are user provided
to uniquely identify the traffic coming in/out of the trunked networks so
that it can reach the appropriate vlan interface within the guest. The
documentation [1] is still in flight, but it clarifies this point.

HTH
Armando

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


> So it is strange that those fields are mandatory when subport is added to
> trunk. Furthermore they may conflict with port's network segmentation_id
> and type. Why we can't inherit segmentation_type and segmentation_id from
> network settings of subport?
>
> References:
> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu
> ide/source/config-trunking.rst
> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>
> Thanks in advance,
> Vasyl Saienko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Vlan aware VMs or trunking

[Kevin Benton]

The segmentation type of the trunk (how the VM attached to the parent port
sees the traffic) has nothing to do with the provider segmentation details
(how the traffic will be encapsulated when it leaves the compute node).

You're right that a normal user won't know the latter details, but they
don't need to. The user specifies how they want traffic from arbitrary
networks encapsulated into their VM. So they can say they want netA on vlan
100, netB on vlan 200, and that's what the VM will see - even if netA is a
GRE network and netB is a vlan network on vlan 3000.

On Dec 6, 2016 08:51, "Vasyl Saienko"  wrote:

> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it should work in the following way:
>
>1. It is possible to group neutron ports to trunks.
>2. When trunk is created parent port should be defined:
>Only one port can be parent.
>segmentation of parent port is set as native or untagged vlan on the
>trunk.
>3. Other ports may be added as subports to existing trunk.
>When subport is added to trunk *segmentation_type* and *segmentation_id
>*should be specified.
>segmentation_id of subport is set as allowed vlan on the trunk
>
> Non-admin user do not know anything about *segmentation_type* and
> *segmentation_id.* So it is strange that those fields are mandatory when
> subport is added to trunk. Furthermore they may conflict with port's
> network segmentation_id and type. Why we can't inherit segmentation_type
> and segmentation_id from network settings of subport?
>
> References:
> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [1] https://review.openstack.org/#/c/361776/15/doc/networking-
> guide/source/config-trunking.rst
> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>
> Thanks in advance,
> Vasyl Saienko
>
> __
> OpenStack Development Mailing 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] [neutron] Vlan aware VMs or trunking

[Vasyl Saienko]

Hello Neutron Community,


I've found that nice feature vlan-aware-vms was implemented in Newton [0].
However the usage of this feature for regular users is impossible, unless
I'm missing something.

As I understood correctly it should work in the following way:

   1. It is possible to group neutron ports to trunks.
   2. When trunk is created parent port should be defined:
   Only one port can be parent.
   segmentation of parent port is set as native or untagged vlan on the
   trunk.
   3. Other ports may be added as subports to existing trunk.
   When subport is added to trunk *segmentation_type* and
*segmentation_id *should
   be specified.
   segmentation_id of subport is set as allowed vlan on the trunk

Non-admin user do not know anything about *segmentation_type* and
*segmentation_id.* So it is strange that those fields are mandatory when
subport is added to trunk. Furthermore they may conflict with port's
network segmentation_id and type. Why we can't inherit segmentation_type
and segmentation_id from network settings of subport?

References:
[0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[1]
https://review.openstack.org/#/c/361776/15/doc/networking-guide/source/config-trunking.rst
[2] https://etherpad.openstack.org/p/trunk-api-dump-newton

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

Re: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver based LBaaSv2

[Kosnik, Lubosz]

Hello Zhi,
So currently we’re working on dropping LBasSv2 support.
Octavia is a big-tent project providing lbass in OpenStack and after merging 
LBasS v2 API in Octavia we will deprecate that project and in next 2 releases 
we’re planning to completely wipe out that code repository. If you would like 
to help with LBasS in OpenStack you’re more than welcome to start working with 
us on Octavia.

Cheers,
Lubosz Kosnik
Cloud Software Engineer OSIC

On Dec 6, 2016, at 6:04 AM, Gary Kotton 
> wrote:

Hi,
I think that there is a move to Octavia. I suggest reaching out to that 
community and see how these changes can be added. Sounds like a nice addition
Thanks
Gary

From: zhi >
Reply-To: OpenStack List 
>
Date: Tuesday, December 6, 2016 at 11:06 AM
To: OpenStack List 
>
Subject: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver 
based LBaaSv2

Hi, all

I am considering add some new extensions for HAProxy driver based Neutron 
LBaaSv2.

Extension 1, multi subprocesses supported. By following this document[1], I 
think we can let our HAProxy based LBaaSv2 support this feature. By adding this 
feature, we can enhance loadbalancers performance.

Extension 2, http keep-alive supported. By following this document[2], we can 
make our loadbalancers more effective.


Any comments are welcome!

Thanks
Zhi Chang


[1]: 
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#cpu-map
[2]: 
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option%20http-keep-alive
__
OpenStack Development Mailing 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] [MassivelyDistributed] IRC meeting tomorrow 15:00 UTC

[lebre . adrien]

Dear all, 

Let me remind you that Massively Distributed Clouds WG meeting is scheduled 
tomorrow afternoon (15:00 UTC time)
Agenda is available at :  
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016(line 
77). 
Feel free to complete it. 

Best regards, 
ad_rien_

__
OpenStack Development Mailing 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] [Kuryr][Magnum] How stable is kuryr-kubernetes?

[Antoni Segura Puimedon]

On Tue, Dec 6, 2016 at 9:10 AM, Mikhail Fedosin  wrote:

> Hi folks!
>

Hi Mikhail!


>
> We at Samsung are trying to integrate containers in OpenStack and at this
> moment we are looking at Kubernetes deployed by Magnum, which works good
> enough for now.
>
> One challenge we have faced recently is making containers able to
> communicate with Nova VM instances (in other words we want to integrate
> Neutron in Kubernetes) and Kuryr seems to be a right solution (based on its
> description). Unfortunately there is a lack of documentation, but from
> various presentations on youtube I got that kuryr has been split in two
> projects (kuryr-libnetwork for Docker Swarm and kuryr-kubernetes for
> Kubernetes respectively, and they both share a common library called
> "kuryr").
>

That's exactly right!


> kuryr-libnetwork continues previous works, which the community has been
> implementing for over a year. It looks stable, nevertheless it doesn't work
> with the latest Docker 1.12.
>

It works with 1.12, but not with 1.12's Swarm mode, since that is hardcoded
to use Docker's overlay driver, that is expected to change.


> kuryr-kubernetes is rather new, and I wonder if it can be already used (at
> least on devstack), or maybe some further efforts are required.
>

We have a previous python3 (and lbaasv1) only prototype that can be used to
test how it all works:

 https://github.com/midonet/kuryr/tree/k8s

With kuryr-kubernetes we are now reaching the stage to have services
supported again (they were supported in the above prototype). There is
devstack for

https://github.com/openstack/kuryr-kubernetes

The current state is that CNI patch [1] is about to be merged and the
service watchers should come in soon.



> Then please enlighten me about current status of Magnum-Kuryr integration.
> I saw that this was discussed in Barcelona and Austin, but in Magnum's
> master it's still unavailable. Also it will be great if you point at the
> responsible person with whom I can discuss it more detailed and see how I
> can be involved in the development.
>

For Magnum integration we have to move kuryr-libnetwork's container-in-vm
support[2][3] (that is being merged this week) to kuryr-kubernetes (which
only supports bare-metal binding right now). Once that is done, work can
begin on Magnum using it in either  macvlan, ipvlan, vlan mode (there's two
modes here, one container - one vlan, and one subnet, one vlan).

You can reach out to apuimedo (me), ivc_, irenab or vikasc about
kuryr-kubernetes and the same plus ltomasbo, lmdaly and mchiappero about
the container-in-vm.

Regards,

Toni


[1] https://review.openstack.org/#/c/404038/
[2] https://review.openstack.org/#/c/400365/
[3] https://review.openstack.org/#/c/402462/

>
> Thanks,
> Mike
>
> __
> OpenStack Development Mailing 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] placement/resource providers update 4

[Chris Dent]

On Fri, 2 Dec 2016, Matt Riedemann wrote:

Some responses within to clarify a few points.


On 12/2/2016 12:04 PM, Chris Dent wrote:

There are some things to consider as that work progresses:

* The bit about aggregates in the previous section: the list of
  returned resource providers needs to include associated providers.


nit: I think you mean associated _aggregates_ here.


Not really. The only thing that can show up when doing a request to
GET /resource_providers is a resource provider. So in this case what
I meant was returning some resource providers that are associated
with another one _because of_ aggregates.


* There is unresolved debate about the structure of the request being
  made to the API. Is it POST or a GET, does it have a body or use
  query strings? The plan is to resolve this discussion in the review
  of the code at [3].


I personally prefer the POST after reading about the differences between the 
two, and when reviewing the spec on this. I'm not crazy about the scheduler 
having to pass a giant json string as a query parameter to a GET request on 
the placement API, I'd rather do that with a request body.


I think the giant json package (wherever it may reside) will only
become a thing when we are doing actual claims via the /allocations
endpoint, in which case a POST will be the right thing (since we're
doing a right). The query against /resource_providers is merely to
limit a large list of resource providers to a smaller list of
resource providers, based on a relatively small number of
parameters.

Honestly I skimmed this part because I'm mostly concerned with immediate 
priorities, but understand if you need to do a brain dump for posterity and 
tire kicking.


Yeah, this is mostly just to make sure that we have some idea of
what's on the radar and whether we're being remotely realistic.

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

Re: [openstack-dev] [cinder] consistency groups in ceph

[Sean McGinnis]

On Mon, Dec 05, 2016 at 04:13:44PM -0800, Victor Denisov wrote:
> I just realized that probably we create images from individual
> snapshots of that consistency group and add those images to the new
> consistency group.
> Am I correct?

That is correct.

__
OpenStack Development Mailing 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] [classifier] Common Classifier / Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classification Framework developers and interested parties are invited 
for today's meeting. The agenda is below, feel free to add more topics.

https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_6_December_2016

1700 UTC @ #openstack-meeting.

Best regards,
Igor.

__
OpenStack Development Mailing 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] "Spec review process" now exists as a policy

[Julie Pichon]

Hi folks,

As discussed in the last couple of TripleO meeting, the information on
the wiki about how to review specs [1] was migrated into a policy at
[2]. Hopefully this will help make the information more visible, and
new additions (like the one that came up at [3]) will be easier to
consider for addition.

Thanks for all the work on the initial document, which is pretty awesome.

Julie

[1] https://wiki.openstack.org/wiki/TripleO/SpecReviews
[2] 
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/spec-review.html
[3] https://review.openstack.org/#/c/407533/

__
OpenStack Development Mailing 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] [keystone] Custom ProjectID upon creation

[Andrey Grebennikov]

>
>
>>
>> I'm surprised any AD administrator let Keystone write to it. I've always
>> hear the inverse that AD admins never would allow keystone to write to it,
>> therefore it was never used for Projects or Assignments. Users were
>> likewise read-only when AD was involved.
>>
>> I have seen normal LDAP setups work with Keystone and used in both
>> read/write mode (but even still the write-allowed was the extreme minority).
>>
>
> Yes agreed. AD administrators are generally pretty protective of write
> access. And especially so of some Linux-based open source project writing
> into their Windows kingdom. We got over our lack of being able to store
> assignment in LDAP, mainly because the blocker was not Keystone, it was
> corporate policy.
>
> Neither the admins allow to write to the AD (even though it is not quite
true and there were at least 2 projects where writing to AD was allowed
(specific groups) and they were Very big customers) nor I mentioned that.
What was happening all the time is read-only AD with project and
assignments Stored in the AD. Which means whenever you need the project and
the user has to have access to it - the admin creates the group in AD and
adds users to the according groups. It looked not Very transparent (because
the roles were stored in the separate group and the assignments were not
very clear), but admins could live with that.

As for everything else that's been discussed, I think database replication
> is easier, and when you're not replicating tokens, there's just not that
> much traffic across the WAN. It's been very stable for us, especially since
> we started using Fernet tokens.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Grebennikov
Principal Deployment Engineer
Mirantis Inc, Austin TX
__
OpenStack Development Mailing 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] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

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

[Matt Riedemann]

On 12/2/2016 9:22 AM, Matt Riedemann wrote:

I'm proposing that we add Stephen Finucane to the nova-core team.
Stephen has been involved with nova for at least around a year now,
maybe longer, my ability to tell time in nova has gotten fuzzy over the
years. Regardless, he's always been eager to contribute and over the
last several months has done a lot of reviews, as can be seen here:

https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com

http://stackalytics.com/report/contribution/nova/180

Stephen has been a main contributor and mover for the config option
cleanup series that last few cycles, and he's a go-to person for a lot
of the NFV/performance features in Nova like NUMA, CPU pinning, huge
pages, etc.

I think Stephen does quality reviews, leaves thoughtful comments, knows
when to hold a +1 for a patch that needs work, and when to hold a -1
from a patch that just has some nits, and helps others in the project
move their changes forward, which are all qualities I look for in a
nova-core member.

I'd like to see Stephen get a bit more vocal / visible, but we all
handle that differently and I think it's something Stephen can grow into
the more involved he is.

So with all that said, I need a vote from the core team on this
nomination. I honestly don't care to look up the rules too much on
number of votes or timeline, I think it's pretty obvious once the
replies roll in which way this goes.



I'm pleased to welcome Stephen to the nova-core team:

https://review.openstack.org/#/admin/groups/25,members

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Performance][shaker] Triangular topology

[Ilya Shakhat]

Hi Matt,

I would suggest to let users specify custom topology in Shaker scenario via
graphs (e.g. directed triangle would look like: A -> B, B -> C, C -> A),
where every pair of nodes is pair of VMs and every edge corresponds to the
traffic flow. The above example will be deployed as 6 VMs, 2 per compute
node (since we need to separate ingress and egress flows).

I already have a patch that allows to deploy graph-based topology:
https://review.openstack.org/#/c/407495/ but it does not configure
concurrency properly yet (concurrency still increments by pairs, solution
tbd)

Please check whether my approach suits your use case, feedback appreciated
:)

Thanks,
Ilya

2016-11-24 19:57 GMT+04:00 Matthieu Simonin :

> Hi Ilya,
>
> Thanks for your answer, let me know your findings.
> In any case I'll be glad to help if needed.
>
> Matt
>
> ps : I just realized that I missed a proper subjet to the thread :(.
> If this thread continue it's maybe better to change that.
>
> - Mail original -
> > De: "Ilya Shakhat" 
> > À: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Envoyé: Jeudi 24 Novembre 2016 13:03:33
> > Objet: Re: [openstack-dev] [Performance][shaker]
> >
> > Hi Matt,
> >
> > Out of the box Shaker doesn't support such topology.
> > It shouldn't be hard to implement though. Let me check what needs to be
> > done.
> >
> > Thanks,
> > Ilya
> >
> > 2016-11-24 13:49 GMT+03:00 Matthieu Simonin :
> >
> > > Hello,
> > >
> > > I'm looking to shaker capabilities and I'm wondering if this kind
> > > of accomodation (see attachment also) can be achieved
> > >
> > > Ascii (flat) version :
> > >
> > > CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
> > > CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
> > > CN2 (2n VMs) <- n flows -> CN3 (2n VMs)
> > >
> > > In this situation concurrency could be mapped to the number of
> > > simultaneous flows in use per link.
> > >
> > > Best,
> > >
> > > 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 Development Mailing 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] [devstack][neutron-lbaas][octavia] About installing Devstack on Ubuntu

[Bernard Cafarelli]

On 6 December 2016 at 13:12, Jens Rosenboom  wrote:
> 2016-12-06 7:16 GMT+01:00 Yipei Niu :
>> Hi, All,
>>
>> I failed installing devstack on Ubuntu. The detailed info of local.conf and
>> error is pasted in http://paste.openstack.org/show/591493/.
>>
>> BTW, python2.7 is installed in Ubuntu, and Python.h can be found under
>> /usr/include/python2.7.
>>
>> stack@stack-VirtualBox:~$ locate Python.h
>>
>> /usr/include/python2.7/Python.h
>>
>>
>> However, after I comment the configuration related to Neutron-LBaaS and
>> Octavia in local.conf, it successes.
>>
>> Is it a bug? How to fix it? Look forward to your comments. Thanks.
>
> The failure does not happen on your local machine, but inside building
> a disk-image for octavia. It seems to be a regression caused by
> https://review.openstack.org/402250 and there is a bug report with a
> proposed fix at https://bugs.launchpad.net/tripleo/+bug/1646977

Indeed, this is the reason it fails (breaking the image building
part), Michael Johnson actually sent a few patches to fix it in
Octavia:

https://review.openstack.org/#/c/356590/ (octavia diff to remove
dependency on tripleo-image-elements)
https://review.openstack.org/#/c/406420/ (diskimage-builder fix to
install python in pip-and-virtualenv element)
https://review.openstack.org/#/c/406413/ (diskimage-builder fix to run
sysctl on image, not host)


-- 
Bernard Cafarelli

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

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

[John Garbutt]

+1 from me.

He will be a great add. I really enjoyed working with him as part of OSIC
early on in his Nova journey, and I trust him to a great job as part of the
core team.

John

On Sun, 4 Dec 2016 at 00:00, Michael Still  wrote:

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

[Jens Rosenboom]

2016-12-06 7:16 GMT+01:00 Yipei Niu :
> Hi, All,
>
> I failed installing devstack on Ubuntu. The detailed info of local.conf and
> error is pasted in http://paste.openstack.org/show/591493/.
>
> BTW, python2.7 is installed in Ubuntu, and Python.h can be found under
> /usr/include/python2.7.
>
> stack@stack-VirtualBox:~$ locate Python.h
>
> /usr/include/python2.7/Python.h
>
>
> However, after I comment the configuration related to Neutron-LBaaS and
> Octavia in local.conf, it successes.
>
> Is it a bug? How to fix it? Look forward to your comments. Thanks.

The failure does not happen on your local machine, but inside building
a disk-image for octavia. It seems to be a regression caused by
https://review.openstack.org/402250 and there is a bug report with a
proposed fix at https://bugs.launchpad.net/tripleo/+bug/1646977

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

Re: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver based LBaaSv2

[Gary Kotton]

Hi,
I think that there is a move to Octavia. I suggest reaching out to that 
community and see how these changes can be added. Sounds like a nice addition
Thanks
Gary

From: zhi 
Reply-To: OpenStack List 
Date: Tuesday, December 6, 2016 at 11:06 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron][lbaas] New extensions for HAProxy driver 
based LBaaSv2

Hi, all

I am considering add some new extensions for HAProxy driver based Neutron 
LBaaSv2.

Extension 1, multi subprocesses supported. By following this document[1], I 
think we can let our HAProxy based LBaaSv2 support this feature. By adding this 
feature, we can enhance loadbalancers performance.

Extension 2, http keep-alive supported. By following this document[2], we can 
make our loadbalancers more effective.


Any comments are welcome!

Thanks
Zhi Chang


[1]: 
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#cpu-map
[2]: 
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option%20http-keep-alive
__
OpenStack Development Mailing 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] [devstack] About installing devstack on Ubuntu

[Qiming Teng]

Try:

 apt-get install python-dev 

BTW, this list is about openstack developers. For questions about
installation and usage, please post to openst...@lists.openstack.org
or try ask.openstack.org

Regards,
  Qiming

On Tue, Dec 06, 2016 at 02:07:58PM +0800, Yipei Niu wrote:
> Hi, All,
> 
> I failed installing devstack on Ubuntu. The detailed info of local.conf and
> error is pasted in http://paste.openstack.org/show/591493/.
> 
> BTW, python2.7 is installed in Ubuntu, and Python.h can be found under
> /usr/include/python2.7.
> 
> stack@stack-VirtualBox:~$ locate Python.h
> 
> /usr/include/python2.7/Python.h
> 
> 
> Look forward to your comments. Thanks.
> 
> Best regards,
> Yipei

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


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

Re: [openstack-dev] [neutron] Is it possible that creating a port and binding it with 2 IPs

[Kevin Benton]

+1. Also, if you just need an additional IP for the instance that isn't
used by other instances, you can do a port update and add additional IPs to
the fixed_ips field.

On Tue, Dec 6, 2016 at 1:09 AM, Neil Jerram  wrote:

> Hi Vincent,
>
> Your initial observation is correct: each port is associated with a
> Neutron network, and will get one IPv4 and one IPv6 address from the
> subnets associated with that network.
>
> To add additional IPs to a port, you can use the allowed-address-pairs
> extension.
>
> Regards,
>  Neil
>
>
> *From: *Vincent.Chao
> *Sent: *Tuesday, 6 December 2016 06:43
> *To: *OpenStack Development Mailing List (not for usage questions)
> *Reply To: *OpenStack Development Mailing List (not for usage questions)
> *Subject: *[openstack-dev] [neutron] Is it possible that creating a port
> and binding it with 2 IPs
>
> Hi Neutrons,
>
> As my observation from the flow table, every created port seems bound with
> only one IP address.
> I was wondering is neutron support this function which can bind a port
> with two IPs?
>
> For example, a VNF load balancer, which has a VIP and a real IP.
> And this VNF receives packets with the destination of a VIP or a real IP
> through one port.
>
> Any corrections or suggestions are welcome.
> Thanks in advance.
>
> Vincent
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Is it possible that creating a port and binding it with 2 IPs

[Neil Jerram]

  Hi Vincent,Your initial observation is correct: each port is associated with a Neutron network, and will get one IPv4 and one IPv6 address from the subnets associated with that network.To add additional IPs to a port, you can use the allowed-address-pairs extension. Regards,      Neil From: Vincent.ChaoSent: Tuesday, 6 December 2016 06:43To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: [openstack-dev] [neutron] Is it possible that creating a port and binding it with 2 IPsHi Neutrons,As my observation from the flow table, every created port seems bound with only one IP address. I was wondering is neutron support this function which can bind a port with two IPs?For example, a VNF load balancer, which has a VIP and a real IP.And this VNF receives packets with the destination of a VIP or a real IP through one port.Any corrections or suggestions are welcome.Thanks in advance.Vincent


__
OpenStack Development Mailing 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][lbaas] New extensions for HAProxy driver based LBaaSv2

[zhi]

Hi, all

I am considering add some new extensions for HAProxy driver based Neutron
LBaaSv2.

Extension 1, multi subprocesses supported. By following this document[1], I
think we can let our HAProxy based LBaaSv2 support this feature. By adding
this feature, we can enhance loadbalancers performance.

Extension 2, http keep-alive supported. By following this document[2], we
can make our loadbalancers more effective.


Any comments are welcome!

Thanks
Zhi Chang


[1]: http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#cpu-map
[2]:
http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#option%20http-keep-alive
__
OpenStack Development Mailing 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] [Kuryr][Magnum] How stable is kuryr-kubernetes?

[Mikhail Fedosin]

Hi folks!

We at Samsung are trying to integrate containers in OpenStack and at this
moment we are looking at Kubernetes deployed by Magnum, which works good
enough for now.

One challenge we have faced recently is making containers able to
communicate with Nova VM instances (in other words we want to integrate
Neutron in Kubernetes) and Kuryr seems to be a right solution (based on its
description). Unfortunately there is a lack of documentation, but from
various presentations on youtube I got that kuryr has been split in two
projects (kuryr-libnetwork for Docker Swarm and kuryr-kubernetes for
Kubernetes respectively, and they both share a common library called
"kuryr"). kuryr-libnetwork continues previous works, which the community
has been implementing for over a year. It looks stable, nevertheless it
doesn't work with the latest Docker 1.12. kuryr-kubernetes is rather new,
and I wonder if it can be already used (at least on devstack), or maybe
some further efforts are required.

Then please enlighten me about current status of Magnum-Kuryr integration.
I saw that this was discussed in Barcelona and Austin, but in Magnum's
master it's still unavailable. Also it will be great if you point at the
responsible person with whom I can discuss it more detailed and see how I
can be involved in the development.

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