[openstack-dev] [Docs][Elections] PTL candidacy for Queens

[Chason]

Hello everyone,

I would like to announce my candidacy for Documentation PTL (Queens).

First of all, I wish to introduce myself briefly. I have been working on the 
bugs
of openstack-manuals project since the Liberty release. And the most I fixed is
the bugs of the Install Guide. In my opinion, Openstack is not very friendly 
with
new hand. If they install their first openstack environment according to our 
Install
Guide which may not be very accurate, she or he would be in a mess. I will 
continue
to focus on document bugs whether as a reviewer or PTL.

In this cycle, Alex( asettle) has coordinated the doc migration work [1]. I 
wish to
take this opportunity to thank all members of the OpenStack community who 
partcipated
in this work. We cannot achieve such seriously bug stuff without your 
cooperation. :) 

As you can see, we removed several guides from openstack-manuals project. There 
are
still many things [2] we have not yet to accomplished after the doc migration.
Some of these problems we already have solutions. But the others need to be 
discussed.
We are welcome everyone to join in our discussion[3]. It would be wonderful if 
you can
give us some ideas!

If I am elected PTL of the Documentation project, my focuses for the coming 
release
are to grow the Documentation team, keep the accuracy of documents, and work 
closely
with other projects to help them imporve documents.

Thanks for your consideration, and I am looking forward to work together with 
all of
you on getting the OpenStack documents to the next stage.

Cheers,

Chason

Email: chason.c...@foxmail.com
IRC: chason
Launchpad: chen-xing

[1] https://etherpad.openstack.org/p/doc-migration-tracking
[2] https://etherpad.openstack.org/p/doc-future-problems
[3] https://etherpad.openstack.org/p/denver-doc-PTG


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

Re: [openstack-dev] [requirements][ptls] HELP! Thawing the requirements repo

[Akihiro Motoki]

2017-08-07 11:59 GMT+09:00 Tony Breeds :
> Hi All,
> So as you all know we've frozen the requirements repo and it will
> stay frozen until after all the cycle-with-milestones projects have
> stable/pike branches.  That's pretty normal.
>
> The last couple of cycles we've seen issues with projects that crate
> stable/pike branches *after* we've thawed/re-opened requirements repo
> for $next_release.
>
> What happens is those projects are still stabilising for pike but
> getting requirements updates for queens.  When they *do* branch for pike
> they quickly get a proposal-bot change which seems to take things
> backwards.  This bad for (at least) a couple of reasons.
>
> 1. Those projects are testing against the wrong requirements
> 2. You end up with a patch release for $project that radically changes
> the requirements for $project.

Yeah, totally agree the above.

>
> So I need some help identifying which projects are going to fall into
> this scenario.  The easy to identify ones are cycle-trailing and we can
> easily cope with that by as there are only 4 of them.  My instinct tells
> me that many of the neutron (stadium?) and horizon-plugin projects will
> fall into this boat.

I think neutron stadium and horizon plugin projects with
cycle-with-intermediary are potentially affected.
They tends to ship a final release (and cut a stable branch if necessary).

I think we can easily list such projects for official projects.
It is not easy to do it for hosted projects as we don't know their
release models.
Do we want to take care of hosted projects?


The following is about official projects.

According to the release repo, there is no *official* neutron stadium
projects with cycle-with-intermediary release model.
networking-hyperv (of the winstackers project) adopts
cycle-with-intermediary model and it looks affected.

Grepping the release deliverables, *official* horizon plugin projects
with cycle-with-intermediary models are:

$ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
| grep -v cycle-with-milestones | cut -d : -f 1
deliverables/pike/cloudkitty-dashboard.yaml
deliverables/pike/ironic-ui.yaml
deliverables/pike/karbor-dashboard.yaml
deliverables/pike/magnum-ui.yaml
deliverables/pike/manila-ui.yaml
deliverables/pike/monasca-ui.yaml
deliverables/pike/senlin-dashboard.yaml
deliverables/pike/solum-dashboard.yaml
deliverables/pike/tacker-horizon.yaml
deliverables/pike/vitrage-dashboard.yaml
deliverables/pike/watcher-dashboard.yaml
deliverables/pike/zun-ui.yaml


In addition, regarding neutron stadium projects and horizon plugin projects,
they also need to update the branch (from master to stable/pike) of
neutron or horizon repo
as they installs neutron or horizon using tox_install.sh
(in addition to the branch of requirements repo).
This needs to happen just after stable/pike branch of neutron or
horizon is created.

Thanks,
Akihiro

> Once we know the scope of the affected projects we can work out how to
> thaw the requirements repo with minimum impact.  The alternative is to
> have the requirements repo frozen for > 1 month which no one wants.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [requirements][ptls] HELP! Thawing the requirements repo

[Tony Breeds]

Hi All,
So as you all know we've frozen the requirements repo and it will
stay frozen until after all the cycle-with-milestones projects have
stable/pike branches.  That's pretty normal.

The last couple of cycles we've seen issues with projects that crate
stable/pike branches *after* we've thawed/re-opened requirements repo
for $next_release.

What happens is those projects are still stabilising for pike but
getting requirements updates for queens.  When they *do* branch for pike
they quickly get a proposal-bot change which seems to take things
backwards.  This bad for (at least) a couple of reasons.

1. Those projects are testing against the wrong requirements
2. You end up with a patch release for $project that radically changes
the requirements for $project.

So I need some help identifying which projects are going to fall into
this scenario.  The easy to identify ones are cycle-trailing and we can
easily cope with that by as there are only 4 of them.  My instinct tells
me that many of the neutron (stadium?) and horizon-plugin projects will
fall into this boat.

Once we know the scope of the affected projects we can work out how to
thaw the requirements repo with minimum impact.  The alternative is to
have the requirements repo frozen for > 1 month which no one wants.

Yours 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] Tracing (all the places)

[J3thro]

Hi,

I just want to add that we submitted a talk to openstack sydney summit too.
See https://www.openstack.org/summit/sydney-2017/vote-for-speakers/#/19608

On Fri, Aug 4, 2017 at 12:11 AM, Joshua Harlow 
wrote:

> vin...@vn.fujitsu.com wrote:
>
>> Hello harlowja,
>>
>> I'm really happy to see that you are back in this `tracing` topic [and
>> @boris-42 (too)].
>>
>
> We never left, haha, but ya, I can say (and probably boris would agree)
> that trying to get OSprofiler started and integrated somewhat 'burned' both
> of us (it involved a ton of convincing people of the value of it, when I
> had more hoped that the value of it was obvious). But I'm glad that people
> are starting to realize its value (even if they have to be told and
> educated by google or other companies that have been doing this for a long
> time).
>
>
>> Last week, we saw that Rajul proposed 02 new blueprint in OSprofiler [1]
>> and [2].
>> Besides, some other blueprints are being implemented in OSprofiler
>> such as overhead control [3] and OpenTracing compatible [4] [5]
>> (Uber Jaeger [6] is one of OpenTracing compatible tracer out there).
>>
>> For OpenTracing part, I have a PoC to make OSprofiler compatible with
>> OpenTracing specification at [5]. You can take a look at it this time too.
>> However, this time, I focus on reporting span/trace to other destinations
>> (rather than current drivers for OSprofiler[7]).
>>
>> OpenTracing API is changing a little bit fast for now, therefore, some
>> APIs will be deprecated soon.
>> I had some discussions with OpenTracing community about some trouble when
>> making OSprofiler
>> compatible with OpenTracing API.
>>
>
> Ya I expected this, opentracing also I think has a python
> client/wrapper(?), have you looked at what this offers (last time I checked
> most of opentracing was just a bunch of wrappers actually, and not much
> actually code that did anything unique)?
>
>
>> For OpenStack part, last cycle, Performance team and other OpenStack
>> developers added
>> OSprofiler support for many other projects (Nova, Magnum, Ironic, Zun ...)
>> and Panko, Aodh, Swift are on the way.
>>
>
> Yippe, now the bigger questions is where are all the UIs visualizing the
> traces (I know boris had https://boris-42.github.io/ngk.html but there
> has to be something nicer that perhaps the OpenTracing community has for a
> UI, ideally not a java monster like Zipkin, ha). Any thoughts there?
>
>
>> At last, hope you will join us (again) in OpenStack `tracing` things.
>>
>
> We shall see :-P
>
>
>> [1] https://blueprints.launchpad.net/osprofiler/+spec/asynchrono
>> us-trace-collection
>> [2] https://blueprints.launchpad.net/osprofiler/+spec/tail-based
>> -coherent-sampling
>> [3] https://blueprints.launchpad.net/osprofiler/+spec/osprofiler
>> -overhead-control
>> [4] https://blueprints.launchpad.net/osprofiler/+spec/opentracin
>> g-compatible
>> [5] https://review.openstack.org/#/c/480018/
>> [6] http://jaeger.readthedocs.io/en/latest/architecture/
>> [7] https://github.com/openstack/osprofiler/tree/master/osprofil
>> er/drivers
>>
>> Best regards,
>>
>> Vinh Nguyen Trong
>> PODC – Fujitsu Vietnam Ltd.
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Error when running quickstart.sh

[Gary Kotton]

Sorry, my bad, when setting the guest to have vmkernel6Guest it works.

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Sunday, August 6, 2017 at 6:40 PM
To: OpenStack List 
Subject: [openstack-dev] [TripleO] Error when running quickstart.sh

Hi,
When I do this on a virtual host I get the following error:

Sunday 06 August 2017  08:22:04 -0700 (0:00:02.641)   0:06:45.482 *
failed: [127.0.0.2] (item={u'flavor': u'control', u'virtualbmc_port': 6230, 
u'name': u'control_0'}) => {"failed": true, "item": {"flavor": "control", 
"name": "control_0", "virtualbmc_port": 6230}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}
failed: [127.0.0.2] (item={u'flavor': u'compute', u'virtualbmc_port': 6231, 
u'name': u'compute_0'}) => {"failed": true, "item": {"flavor": "compute", 
"name": "compute_0", "virtualbmc_port": 6231}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}

Any suggestions on how I can work around this? Virsh capabilities are below [i]
Thanks
Gary

[i]
[root@centos ~]# virsh --connect qemu:///system capabilities


  
d5203442-743d-de37-8ade-7d7dc3e1971d

  x86_64
  Haswell-noTSX
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  16776696
  4194174
  0
  0
  

  
  








  

  


  selinux
  0
  system_u:system_r:svirt_t:s0
  system_u:system_r:svirt_tcg_t:s0


  dac
  0
  +107:+107
  +107:+107

  

  
hvm

  32
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  
  
  

  

  
hvm

  64
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  

  



__
OpenStack Development Mailing 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] Greetings! An invitation from GNOME.Asia Summit 2017

[biscuit kernel]

*Greetings!*

This is the GNOME.Asia Summit 2017 Chongqing committee and we are currently
authorized by the GNOME foundation to be the exclusive agency of the
GNOME.Asia Summit 2017 event. On behalf of the committee, we are inviting
you who are interested in this conference to join us in this event in
Chongqing, China during October 14th to October 16th 2017, and to be our
guests and conference presenters.

The GNOME.Asia Summit is known as a conference at the top level on the
field of open source developing in Asia. GNOME.Asia 2017 is sure to attract
about 600 participants. To celebrate the 20 years anniversary of GNOME as
well as the 10 years anniversary of the GNOME.Asia Summit, we are
inviting influential
professionals as well as Open-source enthusiasts to present their ideas and
research in this year’s GNOME.Asia Summit. As of now, many of our honored
guests have confirmed that they will be joining us in Chongqing University
to celebrate this great event and also to visit the Chongqing university
and the beautiful mountain city of Chongqing.


We welcome you to join us and give your presentations short and long alike.
And we welcome you to share us with your newest ideas of Open-source and to
shed lights on the open-source communities. Here you can find the details
of conference presenting https://www.gnome.org/events/2
017/06/gnome-asia-summit-2017-call-for-papers/

Please feel free to visit our official website https://2017.gnome.asia/ for
more information.If you find this event appealing to you, please do not
hesitate to contact us. We are more than happy to provide any details
regarding this event and also to answer any questions you may have.


please note that the application will be closed on August 15th, 2017. So if
you have intention of joining, please do not hesitate to submit your
application through the following link
 http://cn.mikecrm.com/nhrytIP


Also follow us on social media
facebook 
twitter 
google+ 
weibo 

Sincerely yours



*Speakers Calling Team*
*GNOME.Asia 2017 Committee*
Email: *kernel_biscuit.gn...@chongqinglug.org
*
Website: https://2017.gnome.asia/

*Please follow our social media for the latest news of GNOME.Asia 2017*.

   - facebook 
   - twitter 
   - google+ 
   - weibo 
__
OpenStack Development Mailing 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] [glance] priorities for the week 08/06-08/10

[Brian Rosmaita]

The priority for this week is to get ready for RC-1, which we should cut on
Wednesday 08/09

Please look over the following patches:

https://review.openstack.org/#/c/491249/
-- and be on the lookout for other image-import related patches
https://review.openstack.org/#/c/431709/
https://review.openstack.org/#/c/479047/
https://review.openstack.org/#/c/490651/
https://review.openstack.org/#/c/486674/
https://review.openstack.org/#/c/451449/

These are devstack patches, but you might want to take a quick look for
awareness:
https://review.openstack.org/#/c/490903
https://review.openstack.org/#/c/490904

Don't merge other stuff (except maybe doc changes) without checking first
in #openstack-glance.

cheers,
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] [TripleO] Error when running quickstart.sh

[Gary Kotton]

Hi,
When I do this on a virtual host I get the following error:

Sunday 06 August 2017  08:22:04 -0700 (0:00:02.641)   0:06:45.482 *
failed: [127.0.0.2] (item={u'flavor': u'control', u'virtualbmc_port': 6230, 
u'name': u'control_0'}) => {"failed": true, "item": {"flavor": "control", 
"name": "control_0", "virtualbmc_port": 6230}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}
failed: [127.0.0.2] (item={u'flavor': u'compute', u'virtualbmc_port': 6231, 
u'name': u'compute_0'}) => {"failed": true, "item": {"flavor": "compute", 
"name": "compute_0", "virtualbmc_port": 6231}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}

Any suggestions on how I can work around this? Virsh capabilities are below [i]
Thanks
Gary

[i]
[root@centos ~]# virsh --connect qemu:///system capabilities


  
d5203442-743d-de37-8ade-7d7dc3e1971d

  x86_64
  Haswell-noTSX
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  16776696
  4194174
  0
  0
  

  
  








  

  


  selinux
  0
  system_u:system_r:svirt_t:s0
  system_u:system_r:svirt_tcg_t:s0


  dac
  0
  +107:+107
  +107:+107

  

  
hvm

  32
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  
  
  

  

  
hvm

  64
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  

  



__
OpenStack Development Mailing 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] [api-wg][glance] introducing Images API v2.6

[Brian Rosmaita]

We've decided to introduce the MVP of the new image import functionality as
an EXPERIMENTAL version 2.6 of the Images API.  The CURRENT version will
remain at 2.5 (introduced in Ocata).

Why we're doing this and what this means for deployers/users is explained
in the releasenote on the patch that bumps the API version:

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

We plan to get this into RC-1, so please leave comments on the patch at
your earliest convenience.

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