Re: [openstack-dev] [heat] [magnum] Subjects to discuss during the summit

[Rabi Mishra]

Hi Spyros,

Thanks for starting this thread. My initial understanding was that the
planned session would more around
heat performance/scalability issues w/ magnum.

As most of the additional stuff you mentioned are around heat best
practices, I think the specs/reviews
would be a great place to start the discussion and we can also squeeze them
as part of the same session.

Some comments inline.

On Mon, Oct 10, 2016 at 9:24 PM, Spyros Trigazis  wrote:

> Hi Sergey,
>
> I have seen the session, I wanted to add more details to
> start the discussion earlier and to be better prepared.
>
> Thanks,
> Spyros
>
>
> On 10 October 2016 at 17:36, Sergey Kraynev  wrote:
>
>> Hi Spyros,
>>
>> AFAIK we already have special session slot related with your topic.
>> So thank you for the providing all items here.
>> Rabi, can we add link on this mail to etherpad ? (it will save our time
>> during session :) )
>>
>> On 10 October 2016 at 18:11, Spyros Trigazis  wrote:
>>
>>> Hi heat and magnum.
>>>
>>> Apart from the scalability issues that have been observed, I'd like to
>>> add few more subjects to discuss during the summit.
>>>
>>> 1. One nested stack per node and linear scale of cluster creation
>>> time.
>>>
>>> 1.1
>>> For large stacks, the creation of all nested stack scales linearly. We
>>> haven't run any tested using the convergence-engine.
>>>
>>
>From what I understand, magnum uses ResourceGroups and Template Resources.
(ex. Cluster->RGs->master/nodes) to build the cluster.

As the nested stack operations happen over rpc, they should be distributed
across all available engines.
So, the finding that the build time increases linearly is not good. It
would probably be worth providing more
details of heat configuration(ex. number of engine workers etc) on your
test setup. it would also be useful
to do some tests with convergence enabled, as that is the default from
newton.

Magnum seems to use a collection of software configs (scipts) as a
multipart mime with server
user_data. So the the build time for 'every node' would be dependent on the
time taken by these scripts
at boot.

1.2
>>> For large stacks, 1000 nodes, the final call to heat to fetch the
>>> IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status
>>> CREATE_COMPLETE but magnum's state is updated when this long final
>>> call is done. Can we do better? Maybe fetch only the master IPs or
>>> get he IPs in chunks.
>>>
>>

We seem load the nested stacks in memory to retrieve their outputs. That
would probably explain the
behaviour above, where you load all the nested stacks for the nodes to
fetch their ips. There is some
work[1][2] happening atm to change that.

[1] https://review.openstack.org/#/c/383839/
[2] https://review.openstack.org/#/c/384718


> 1.3
>>> After the stack create API call to heat, magnum's conductor
>>> busy-waits heat with a thread/cluster. (In case of a magnum conductor
>>> restart, we lose that thread and we can't update the status in
>>> magnum). Investigate better ways to sync the status between magnum
>>> and heat.
>>>
>> Rather than waiting/polling, probably you can implement an observer that
consumes events
from heat/event-sink and updates magnum accordingly? May be there are
better options too.


> 2. Next generation magnum clusters
>>>
>>> A need that comes up frequently in magnum is heterogeneous clusters.
>>> * We want to able to create cluster on different hardware, (e.g. spawn
>>>   vms on nodes with SSDs and nodes without SSDs or other special
>>>   hardware available only in some nodes of the cluster FPGA, GPU)
>>> * Spawn cluster across different AZs
>>>
>>> I'll describe briefly our plan here, for further information we have a
>>> detailed spec under review. [1]
>>>
>>> To address this issue we introduce the node-group concept in magnum.
>>> Each node-group will correspond to a different heat stack. The master
>>> nodes can be organized in one or more stacks, so as the worker nodes.
>>>
>>> We investigate how to implement this feature. We consider the
>>> following:
>>> At the moment, we have three template files, cluster, master and
>>> node, and all three template files create one stack. The new
>>> generation of clusters will have a cluster stack containing
>>> the resources in the cluster template, specifically, networks, lbaas
>>> floating-ips etc. Then, the output of this stack would be passed as
>>> input to create the master node stack(s) and the worker nodes
>>> stack(s).
>>>
>>


> 3. Use of heat-agent
>>>
>>> A missing feature in magnum is the lifecycle operations in magnum. For
>>> restart of services and COE upgrades (upgrade docker, kubernetes and
>>> mesos) we consider using the heat-agent. Another option is to create a
>>> magnum agent or daemon like trove.
>>>
>>> 3.1
>>> For restart, a few systemctl restart or service restart commands will
>>> be issued. [2]
>>>
>>> 3.2
>>> For upgrades there are three scenarios:
>>> 1. Upgrade a service which runs in a container. In this case, a small
>>

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Richard Jones]

On 11 October 2016 at 08:34, Tony Breeds  wrote:

> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
> > I think it would also make sense to *release* on the boundary of the
> switch;
> > so that it’s clear which phase a release followed.
>
> I agree, I don't really have a mechanism for do that though.  I didn't
> state
> this but my plan was to reach out the PTLs that have the
> stable:follows-policy
> tag and ask them to release.  I suppose I could go one step further and
> propose the change in openstack/releases but that seems a little like over
> reach to me.
>
> What do PTLs / stable CPLs think?
>

As long as "boundary" is a generous number of days (a week?) and not a
single point in time, I think this is sensible.


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

[openstack-dev] requests-mock

[Clay Gerrard]

Greetings!

Anyone have any experience to share positive or negative using
requests-mock?  I see it's been used to replace another dependency that had
some problems in many of the OpenStack python client libraries:

Added to global requirements -> https://review.openstack.org/#/c/104067
Added to novaclient -> https://review.openstack.org/#/c/112179/
Added to cinderclient -> https://review.openstack.org/#/c/106665/
Added to keystoneclient -> https://review.openstack.org/#/c/106659/

But I'm not sure how folks other than Jamie are getting on with it?  When
writing new tests do you tend to instinctively grab for requests-mock - or
do you mostly not notice it's there?  Any unexpected behaviors ever have
you checking it out with bzr and reading over the source?  Do you recall
ever having any bumps or bruises in the gate or in your development
workflow because of a new release from requests-mock?  No presumed fault on
Jamie!  It seems like he's doing a Herculean one-man job there; but it can
be difficult go it alone:

https://bugs.launchpad.net/requests-mock/+bug/1616690

It looks like the gate on this project is configured to run nova & keystone
client tests; so that may be sufficient to catch any sort of issue that
might come up in something that depends on it?  Presumably once he lands a
change - he does the update to global-requirements and then all of
OpenStack get's it from there?

I ask of course because I really don't understand how this works [1] :D

But anyway - Jamie was kind enough to offer to refactor some tests for us -
but in the process seems to require to bring in these new dependencies - so
I'm trying to evaluate if I can recommend requiring this code in order to
develop on swiftclient [2].

Any feedback is greatly appreciated!

-Clay

1. As you may know (thanks to some recently publicity) swift & swiftclient
joined OpenStack in the time of dinosaurs with a general policy of trying
to keep dependencies to a *minimum* - but then one day the policy changed
to... *always* add dependencies whenever possible?  j/k I'm not acctually
sure what the OpenStack policy is on dependency hygiene :D  Anyway, I can't
say *exactly* where that "general policy" came from originally?  Presumably
crieht or gholt just had some first hand experience that the dependencies
you choose to add have a HUGE impact on your project over it's lifetime -
or read something from Joel on Software -
http://www.joelonsoftware.com/articles/fog07.html - or traveled
into the future and read the "go proverbs" and google'd "npm breaks
internet, again".  Of course they've since moved on from OpenStack but the
general idea is still something that new contributors to swift &
swiftclient get acclimated to and the circle of confusion continues
https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles
- but hey!  maybe I can educate myself about the OpenStack policy/process;
add this dependency and maybe the next one too; then someday break the
cycle!?!?

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

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[courage angeh]

All the files you specified, i don't have them. i searched using find from
root but got nothing

On Tue, Oct 11, 2016 at 5:13 AM, courage angeh 
wrote:

> Here is the url of the error i get when i run zun --debug create --name
> test --image cirros --command "ping -c 4 8.8.8.8"  :
> http://paste.openstack.org/show/585268/
>
> On Tue, Oct 11, 2016 at 3:28 AM, courage angeh 
> wrote:
>
>> Thanks bu i hav No folder zun found under /etc But i did find a folder
>> keystone but no log file found in the folder
>>
>> On Tue, Oct 11, 2016 at 3:07 AM, Hongbin Lu 
>> wrote:
>>
>>> Several things to check:
>>>
>>> * Run “zun –debug create …” and check the output
>>>
>>> * Make sure your Keystone is running on 192.168.8.101
>>>
>>> * Check the Keystone log
>>>
>>> * Check the zun-api log
>>>
>>> * Check the config file under /etc/zun
>>>
>>> If you cannot figure it out, feel free to send me the outputs/logs above.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>>
>>> *From:* courage angeh [mailto:couragean...@gmail.com]
>>> *Sent:* October-10-16 9:09 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [Zun] ERROR: Not Authorized
>>>
>>>
>>>
>>> i did source the file before running that command,
>>>
>>> This are the environment that are set:
>>>
>>> OS_REGION_NAME=RegionOne
>>> OS_PROJECT_NAME=admin
>>> OS_IDENTITY_API_VERSION=2.0
>>> OS_PASSWORD=password
>>> OS_AUTH_URL=http://192.168.8.101:5000/v2.0
>>> OS_USERNAME=admin
>>> OS_TENANT_NAME=admin
>>> OS_VOLUME_API_VERSION=2
>>> OS_NO_CACHE=1
>>>
>>> Yet still when i run that command i still get thesame error msg and i
>>> have talking to the irc channel nut not reply from any one.
>>>
>>>
>>>
>>> On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu 
>>> wrote:
>>>
>>> Courage,
>>>
>>>
>>>
>>> As suggested by Denis in another reply, you might need to source the
>>> credential before issuing the command. If it doesn’t help, please feel free
>>> to ping us in the IRC channel (#openstack-zun).
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>>
>>> *From:* courage angeh [mailto:couragean...@gmail.com]
>>> *Sent:* October-10-16 10:40 AM
>>> *To:* openstack-dev@lists.openstack.org
>>> *Subject:* [openstack-dev] ERROR: Not Authorized
>>>
>>>
>>>
>>> i have problems running zun. When i try to run comaands lik:
>>>
>>> zun start test or
>>> zun create --name test --image cirros --command "ping -c 4 8.8.8.8"
>>>
>>> I get the error: ERROR: Not Authorized
>>>
>>> Futher searching it seem like i cann't connect to 
>>> http://192.168.8.101:5000/v2.0
>>>
>>> Please can someone help me?
>>>
>>> Thanks
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 12th October

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 12th October in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in Horizon
is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes and
full logs from our last meeting are available:

Minutes:
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-10-05-20.01.html
Log:
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-10-05-20.01.log.html


Cheers,

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

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[courage angeh]

Here is the url of the error i get when i run zun --debug create --name
test --image cirros --command "ping -c 4 8.8.8.8"  :
http://paste.openstack.org/show/585268/

On Tue, Oct 11, 2016 at 3:28 AM, courage angeh 
wrote:

> Thanks bu i hav No folder zun found under /etc But i did find a folder
> keystone but no log file found in the folder
>
> On Tue, Oct 11, 2016 at 3:07 AM, Hongbin Lu  wrote:
>
>> Several things to check:
>>
>> * Run “zun –debug create …” and check the output
>>
>> * Make sure your Keystone is running on 192.168.8.101
>>
>> * Check the Keystone log
>>
>> * Check the zun-api log
>>
>> * Check the config file under /etc/zun
>>
>> If you cannot figure it out, feel free to send me the outputs/logs above.
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>> *From:* courage angeh [mailto:couragean...@gmail.com]
>> *Sent:* October-10-16 9:09 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Zun] ERROR: Not Authorized
>>
>>
>>
>> i did source the file before running that command,
>>
>> This are the environment that are set:
>>
>> OS_REGION_NAME=RegionOne
>> OS_PROJECT_NAME=admin
>> OS_IDENTITY_API_VERSION=2.0
>> OS_PASSWORD=password
>> OS_AUTH_URL=http://192.168.8.101:5000/v2.0
>> OS_USERNAME=admin
>> OS_TENANT_NAME=admin
>> OS_VOLUME_API_VERSION=2
>> OS_NO_CACHE=1
>>
>> Yet still when i run that command i still get thesame error msg and i
>> have talking to the irc channel nut not reply from any one.
>>
>>
>>
>> On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu 
>> wrote:
>>
>> Courage,
>>
>>
>>
>> As suggested by Denis in another reply, you might need to source the
>> credential before issuing the command. If it doesn’t help, please feel free
>> to ping us in the IRC channel (#openstack-zun).
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>> *From:* courage angeh [mailto:couragean...@gmail.com]
>> *Sent:* October-10-16 10:40 AM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* [openstack-dev] ERROR: Not Authorized
>>
>>
>>
>> i have problems running zun. When i try to run comaands lik:
>>
>> zun start test or
>> zun create --name test --image cirros --command "ping -c 4 8.8.8.8"
>>
>> I get the error: ERROR: Not Authorized
>>
>> Futher searching it seem like i cann't connect to 
>> http://192.168.8.101:5000/v2.0
>>
>> Please can someone help me?
>>
>> Thanks
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[courage angeh]

Thanks bu i hav No folder zun found under /etc But i did find a folder
keystone but no log file found in the folder

On Tue, Oct 11, 2016 at 3:07 AM, Hongbin Lu  wrote:

> Several things to check:
>
> * Run “zun –debug create …” and check the output
>
> * Make sure your Keystone is running on 192.168.8.101
>
> * Check the Keystone log
>
> * Check the zun-api log
>
> * Check the config file under /etc/zun
>
> If you cannot figure it out, feel free to send me the outputs/logs above.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* courage angeh [mailto:couragean...@gmail.com]
> *Sent:* October-10-16 9:09 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Zun] ERROR: Not Authorized
>
>
>
> i did source the file before running that command,
>
> This are the environment that are set:
>
> OS_REGION_NAME=RegionOne
> OS_PROJECT_NAME=admin
> OS_IDENTITY_API_VERSION=2.0
> OS_PASSWORD=password
> OS_AUTH_URL=http://192.168.8.101:5000/v2.0
> OS_USERNAME=admin
> OS_TENANT_NAME=admin
> OS_VOLUME_API_VERSION=2
> OS_NO_CACHE=1
>
> Yet still when i run that command i still get thesame error msg and i have
> talking to the irc channel nut not reply from any one.
>
>
>
> On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu  wrote:
>
> Courage,
>
>
>
> As suggested by Denis in another reply, you might need to source the
> credential before issuing the command. If it doesn’t help, please feel free
> to ping us in the IRC channel (#openstack-zun).
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* courage angeh [mailto:couragean...@gmail.com]
> *Sent:* October-10-16 10:40 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] ERROR: Not Authorized
>
>
>
> i have problems running zun. When i try to run comaands lik:
>
> zun start test or
> zun create --name test --image cirros --command "ping -c 4 8.8.8.8"
>
> I get the error: ERROR: Not Authorized
>
> Futher searching it seem like i cann't connect to 
> http://192.168.8.101:5000/v2.0
>
> Please can someone help me?
>
> 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
>
>
>
> __
> OpenStack Development Mailing 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] [QA][Cinder]Removing Cinder v1 in Tempest

[Ken'ichi Ohmichi]

Thanks for pointing this up, Jordan

Before removing volume v1 API tests, it is nice to make the v2 API the
default of Tempest scenario tests.
Now the v1 and v2 is set as True on the default in the
configuration[1], and the v1 API is used in the scenario like [2].
So it is better to switch using v2 API on the default.

Thanks
Ken Ohmichi

---

[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L770
[2]: 
https://github.com/openstack/tempest/blob/master/tempest/scenario/manager.py#L83


2016-10-10 11:37 GMT-07:00 Matt Riedemann :
> On 10/10/2016 7:47 AM, Duncan Thomas wrote:
>>
>> If we can get them running on cinder patches via a different job, then
>> removing them from the common job afterwards seems reasonable.
>>
>> There's no strong will to remove them, several libraries still use them,
>> and given we're now supporting /all/ other API versions indefinitely,
>> keeping them around isn't that much of a burden.
>>
>> On 10 October 2016 at 15:32, Jordan Pittier > > wrote:
>>
>> Hi,
>> I'd like to reduce the duration of a full Tempest run and I noticed
>> that Cinder tests take a good amount of time (cumulative
>> time 2149sec vs 2256sec for Nova, source code [0])
>>
>> So I'd like to not run the Cinder v1 tests anymore, at least on the
>> master branches.
>>
>> I remember that Cinder  v1 is deprecated (it has been for what, 2
>> years ?) Is the removal scheduled ? I don't see/feel a lot of
>> efforts toward that removal but I may be missing something. Any way,
>> that's not really my business but it's not really fair to all the
>> projects that run the "common jobs" that Cinder "slows" everyone down.
>>
>> What do you think ?
>>
>> [0]
>> :
>> https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py
>>
>> 
>>
>>
>> 
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> So make it conditional in Tempest via a config option, disable volume v1
> tests by default for the integrated gate, and then add a new job that runs
> only on cinder changes (and maybe only in the experimental queue) that
> enables volume v1 tests. You could run it on cinder in the check/gate and
> skip the job from running unless something in the v1 API path is changed,
> there are examples of that in project-config.
>
> Nova used to have the v2 API in tree and this was kind of the eventual path
> to phasing out the Tempest testing on that code and got us to the point of
> removing the v2 *code*.  The compute v2 API itself is still honored via the
> v2.1 base microversion.
>
> --
>
> 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

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

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[Hongbin Lu]

Several things to check:
* Run “zun –debug create …” and check the output
* Make sure your Keystone is running on 192.168.8.101
* Check the Keystone log
* Check the zun-api log
* Check the config file under /etc/zun
If you cannot figure it out, feel free to send me the outputs/logs above.

Best regards,
Hongbin

From: courage angeh [mailto:couragean...@gmail.com]
Sent: October-10-16 9:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zun] ERROR: Not Authorized

i did source the file before running that command,
This are the environment that are set:

OS_REGION_NAME=RegionOne
OS_PROJECT_NAME=admin
OS_IDENTITY_API_VERSION=2.0
OS_PASSWORD=password
OS_AUTH_URL=http://192.168.8.101:5000/v2.0
OS_USERNAME=admin
OS_TENANT_NAME=admin
OS_VOLUME_API_VERSION=2
OS_NO_CACHE=1
Yet still when i run that command i still get thesame error msg and i have 
talking to the irc channel nut not reply from any one.

On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu 
mailto:hongbin...@huawei.com>> wrote:
Courage,

As suggested by Denis in another reply, you might need to source the credential 
before issuing the command. If it doesn’t help, please feel free to ping us in 
the IRC channel (#openstack-zun).

Best regards,
Hongbin

From: courage angeh 
[mailto:couragean...@gmail.com]
Sent: October-10-16 10:40 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] ERROR: Not Authorized

i have problems running zun. When i try to run comaands lik:

zun start test or
zun create --name test --image cirros --command "ping -c 4 8.8.8.8"

I get the error: ERROR: Not Authorized

Futher searching it seem like i cann't connect to http://192.168.8.101:5000/v2.0

Please can someone help me?

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

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

[openstack-dev] [openstack][nova] Port unbound from active VM

[Ajay Kalambur (akalambu)]

Hi
There seems to be a corner case bug in nova code. Steps to reproduce it are

  1.  Create a neutron port
  2.  Create a VM and launch instance with this port
  3.  Shutdown nova compute and network agent on compute node
  4.  Unbind port from VM and delete the VM (offline delete)
  5.  Now create a VM with same port but on a different VM
  6.  Bring up nova compute on old node

It basically runs the reap for deleted instances and cleanes up VM from 
libvirt. In the process it unbinds the pre-existing ports and ends up unbinding 
the port from an active VM
Reason nova simply sends a blind port-update with binding_host: “” even if that 
port is bound to a different instance


So following fix seemed to help any suggestions on a better fix

In nova/network/neutronv2/api.py. So basically when neutron sees no ports for 
this instance don’t attempt an unbind
In this case
data = neutron.list_ports(**search_opts)
Call in deallocate_for_instance returns empty ports




  # Reset device_id and device_owner for the ports that are skipped

if data.get('ports', []):

self._unbind_ports(context, ports_to_skip, neutron)

else:

LOG.debug("Neutron sees a different view of this port hence 
skipping unbind”)



Ajay

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

[Qiao, Liyong]

@Zhangshuai

I believe you running Magnum service in China’s server, please be note that K8s 
would pull images from gcr.io, so please be sure you can reach gcr.io in case 
of China Firewall blocking it.

—
Best Regards
  此致，
敬礼
Eli Qiao（乔立勇）Intel SSG OTC OpenStack Core Team


发件人: Ton Ngo mailto:t...@us.ibm.com>>
答复: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
日期: 2016年10月11日 星期二 上午5:36
至: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
主题: Re: [openstack-dev] [Magnum]

Hi zhangshuai,
We can only tell from the screenshots that the k8s master node failed. You will 
likely need
to use the CLI for further debugging. It might also be quicker to ask on the 
IRC.
Ton Ngo,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[courage angeh]

i did source the file before running that command,
This are the environment that are set:

OS_REGION_NAME=RegionOne
OS_PROJECT_NAME=admin
OS_IDENTITY_API_VERSION=2.0
OS_PASSWORD=password
OS_AUTH_URL=http://192.168.8.101:5000/v2.0
OS_USERNAME=admin
OS_TENANT_NAME=admin
OS_VOLUME_API_VERSION=2
OS_NO_CACHE=1

Yet still when i run that command i still get thesame error msg and i have
talking to the irc channel nut not reply from any one.

On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu  wrote:

> Courage,
>
>
>
> As suggested by Denis in another reply, you might need to source the
> credential before issuing the command. If it doesn’t help, please feel free
> to ping us in the IRC channel (#openstack-zun).
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* courage angeh [mailto:couragean...@gmail.com]
> *Sent:* October-10-16 10:40 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] ERROR: Not Authorized
>
>
>
> i have problems running zun. When i try to run comaands lik:
>
> zun start test or
> zun create --name test --image cirros --command "ping -c 4 8.8.8.8"
>
> I get the error: ERROR: Not Authorized
>
> Futher searching it seem like i cann't connect to 
> http://192.168.8.101:5000/v2.0
>
> Please can someone help me?
>
> 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
>
>
__
OpenStack Development Mailing 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] [Karbor] Questions about algorithm of building resource graph

[zengchen]

Hi karbor guys:


I have some questions about algorithm of building resource graph. I have 
described them in the attached file.
Any thoughts will be welcomed. Thanks very much!


zengchen

Questions about algorithm of building resource graph.pptx
Description: MS-Powerpoint 2007 presentation
__
OpenStack Development Mailing 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] Suggestions for OOO

[Joe Talerico]

Hey all,
The past couple of days I have making comments on IRC to discuss some
of the issues I have bumped into when scaling Newton to > 30 compute
nodes.

- `bulk import`, the operation to go from enroll -> manage can take
20-30 minutes to complete. Can we have this be a non-blocking
operation with a message to the user that they cannot continue until
the nodes they want to deploy on go from enroll->manage?
- overcloud deploy - when pxe completes I have seen a hand-full of
nodes not reboot, or just get jammed up in the pxe screen. When this
occurs I run:
$ for i in `nova list | grep -i 192 | awk '{print $12}' | awk -F=
'{print $2}'`; do if [[ $(ping -c 1 $i | grep "100%") ]]; then ironic
node-set-power-state $(ironic node-list | grep $(nova list | grep $i |
awk '{print $2}') | awk '{print $2}') off ; fi; done
# (192 is the first octet)
- Then -
$ for i in `nova list | grep -i 192 | awk '{print $12}' | awk -F=
'{print $2}'`; do if [[ $(ping -c 1 $i | grep "100%") ]]; then ironic
node-set-power-state $(ironic node-list | grep $(nova list | grep $i |
awk '{print $2}') | awk '{print $2}') on ; fi; done

This typically fixes the deployment so things can continue, however it
would be great to have this type of logic added to OOO, where if a
node goes from BUILD->ACTIVE, if it isn't reachable in 120 seconds,
ironic simply reboots the host..

Also, I suggest if the second attempt fails, reschedule the host --
sometimes I have seen where a raid controller or something goes bad
out of our control.

Thanks for listening!
rook

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

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Ian Cordasco]

On Oct 10, 2016 4:35 PM, "Tony Breeds"  wrote:
>
> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
>
> > I think it would also make sense to *release* on the boundary of the
switch;
> > so that it’s clear which phase a release followed.
>
> I agree, I don't really have a mechanism for do that though.  I didn't
state
> this but my plan was to reach out the PTLs that have the
stable:follows-policy
> tag and ask them to release.  I suppose I could go one step further and
> propose the change in openstack/releases but that seems a little like over
> reach to me.

I think it's a good idea for us to do it. I'm not sure you need more things
to do in a day, Tony. That said, I've had a hard time getting candidates
for back ports for Glance so it may not be a very interesting release (a
good thing obviously).
__
OpenStack Development Mailing 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] [Congress] Project for Ruben

[Tim Hinrichs]

Hi Ruben,

It's great that you've decided to add a datasource driver for Magnum.  A
datasource driver is a good place to start.

In terms of getting started, if you haven't read thru the docs, start
there.  The Cloud Services section will give you info on datasources; at
the end there is a section on Writing a Datasource driver.  The Policy
section will explain the policy language.
http://docs.openstack.org/developer/congress/

As mentioned below, Eric suggests the Monasca datasource to be a recent one
to use as an example.  The docs use Glance.

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

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Steve Martinelli]

On Mon, Oct 10, 2016 at 5:34 PM, Tony Breeds 
wrote:

> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
>
> > I think it would also make sense to *release* on the boundary of the
> switch;
> > so that it’s clear which phase a release followed.
>
> What do PTLs / stable CPLs think?
>

I would be for this, or at least encourage it. I've tried to do this with
keystone as well. When one release wraps up, I go through potential
candidates to backport and release a new version. I did this with mitaka
when we tagged newton rc1 (
https://github.com/openstack/releases/commit/1b0f12e1691fca956ae8d69cbc41737958a0a27f),
and I did this with liberty when we tagged mitaka rc1.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] Admin guide in-tree?

[Lana Brindley]

On 10/10/16 16:25, Andreas Jaeger wrote:
> On 2016-10-10 01:37, Steve Martinelli wrote:
>> On Oct 9, 2016 6:57 PM, "Lana Brindley" > > wrote:
>>>
>>> Why the rush?
>>
>> I think its more eagerness than rush. Project teams made a lot of head
>> way with the API ref and install guides being in-tree that they want to
>> keep the momentum with the admin guide.
> 
> Those teams are more than welcome to contribute today to the
> openstack-manuals repository! Is there anything we can help these?
> 
> Andreas
> 

Yes, Andreas makes a good point. If there's content you want in the guides now, 
we can help you with that.

Lana

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [OpenStack-Infra] [Infra] Meeting Tuesday October 11th at 19:00 UTC

[matthew wagoner]

Howdy,

Some associates of mine would like to show up to the meeting to ask some
questions about Zuul v3.  I will add an agenda item for such, and hope
there is enough time!

Thanks,
olaph

On Mon, Oct 10, 2016 at 12:10 PM, Elizabeth K. Joseph 
wrote:

> Hi everyone,
>
> The OpenStack Infrastructure (Infra) team is having our next weekly
> meeting on Tuesday October 11th, at 19:00 UTC in #openstack-meeting
>
> Meeting agenda available here:
> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_
> next_meeting
>
> Anyone is welcome to to add agenda items and everyone interested in
> the project infrastructure and process surrounding automated testing
> and deployment is encouraged to attend.
>
> In case you missed it or would like a refresher, the meeting minutes
> and full logs from our last meeting are available:
>
> Minutes: http://eavesdrop.openstack.org/meetings/infra/2016/infra.
> 2016-10-04-19.03.html
> Minutes (text):
> http://eavesdrop.openstack.org/meetings/infra/2016/infra.
> 2016-10-04-19.03.txt
> Log: http://eavesdrop.openstack.org/meetings/infra/2016/infra.
> 2016-10-04-19.03.log.html
>
> --
> Elizabeth Krumbach Joseph || Lyz || pleia2
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Eichberger, German]

+1 (even if it doesn’t matter)

From: Stephen Balukoff 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, October 10, 2016 at 4:39 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik 
(diltram) as Octavia Core

I agree whole-heartedly with johnsom's assessment of diltram's contributions. 
+1 from me!

On Mon, Oct 10, 2016 at 1:06 PM, Michael Johnson 
mailto:johnso...@gmail.com>> wrote:
Greetings Octavia and developer mailing list folks,

I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
core reviewer.

His contributions [1] are in line with other cores and he has been an
active member of our community.  He regularly attends our weekly
meetings, contributes good code, and provides solid reviews.

Overall I think Lubosz would make a great addition to the core review team.

Current Octavia cores, please respond with +1/-1.

Michael

[1] http://stackalytics.com/report/contribution/octavia/90

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

__
OpenStack Development Mailing 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] [QA] Presence at PTG Atlanta in February

[Ken'ichi Ohmichi]

Hi QA team,

As you know, the first PTG(Project Teams Gathering) happens at Atlanta
20th-24th February the next year.
After Barcelona, OpenStack Summit will be separated into two parts
(conferences and design sessions) and PTG is a new format for design
sessions for developers(Please see the detail on [1]).
QA is always important factor of developments, and I am thinking the
presence of QA project is good for the community.

Thanks
Ken Omichi

---
[1]: http://www.openstack.org/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

[openstack-dev] [ovn][networking-sfc]

[Murali R]

Networking-sfc and ovn install guide says "port_security" must be enabled
when enabling networkin-sfc  (networking-ovn/doc/source/install.rst -- line
165)

In my use cases it gets too complicated if I use port-security, so was
disabling it.

Please let me know if there is any hard requirement that this MUST be
enabled in Neutron?

-Murali
__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Brandon Logan]

+1

On Mon, 2016-10-10 at 13:06 -0700, Michael Johnson wrote:
> Greetings Octavia and developer mailing list folks,
> 
> I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
> core reviewer.
> 
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  He regularly attends our weekly
> meetings, contributes good code, and provides solid reviews.
> 
> Overall I think Lubosz would make a great addition to the core review
> team.
> 
> Current Octavia cores, please respond with +1/-1.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia/90
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Tony Breeds]

On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:

> I think it would also make sense to *release* on the boundary of the switch;
> so that it’s clear which phase a release followed.

I agree, I don't really have a mechanism for do that though.  I didn't state
this but my plan was to reach out the PTLs that have the stable:follows-policy
tag and ask them to release.  I suppose I could go one step further and
propose the change in openstack/releases but that seems a little like over
reach to me.

What do PTLs / stable CPLs think?

BTW: I see you've done this for neutron :)   Thanks!

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] [release][ansible][fuel][kolla][puppet][tripleo] proposed deadlines for cycle-trailing projects

[Alexey Shtokolov]

Doug,

We've finally fixed the blockers and tagged RC1 for all our repos.
We're going to have final RC this Friday (Oct14).

Could I ask you to create stable/newton branches for repos:
- openstack/fuel-agent
- openstack/fuel-astute
- openstack/fuel-library
- openstack/fuel-main
- openstack/fuel-menu
- openstack/fuel-nailgun-agent
- openstack/fuel-ostf
- openstack/fuel-qa
- openstack/fuel-ui
- openstack/fuel-virtualbox
- openstack/fuel-web
based on the tag 10.0.0rc1

Or should I do it myself?

Best regards,
Alexey Shtokolov

On Fri, Oct 7, 2016 at 10:16 PM, Doug Hellmann 
wrote:

> This week we tagged the final releases for projects using the
> cycle-with-milestones release model. Projects using the cycle-trailing
> model have two more weeks before their final release tags are due. In
> the time between now and then, we expect those projects to be preparing
> and tagging release candidates.
>
> Just as with the milestone-based projects, we want to manage the number,
> frequency, and timing of release candidates for cycle-trailing projects.
> With that in mind, I would like to propose the following rough timeline
> (my apologies for not preparing this sooner):
>
> 10 Oct -- All cycle-trailing projects tag at least their first RC.
> 13 Oct -- Soft deadline for cycle-trailing projects to tag a final RC.
> 18 Oct -- Hard deadline for cycle-trailing projects to tag a final RC.
> 20 Oct -- Re-tag the final RCs as a final release.
>
> Between the first and later release candidates, any translations and
> bug fixes should be merged.
>
> We want to leave a few days between the last release candidate and
> the final release so that downstream consumers of the projects can
> report issues against stable artifacts. Given the nature of most
> of our trailing projects, and the lateness of starting to discuss
> these deadlines, I don't think we need the same amount of time as
> we usually set aside for the milestone-based projects. Based on
> that assumption, I've proposed a 1 week soft goal and a 2 day hard
> deadline.
>
> Let me know what you think,
> Doug
>
> Newton schedule: https://releases.openstack.org/newton/schedule.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

Hi folks,

At godaddy we are looking to consume the various events emitted by 
[nova, neutron, glance, ...] and for a while we have been having some 
python code to handle these and parse them and turn the ones we care 
about back into useful objects.


At the current time though we are expanding who is going to be reading 
these events and those external services may *not* be written in python 
(servicenow for example).


So the question started to be raised of is there a documented 
format/schema for the events that are being emitted from various services> (there seems to be some at 
http://docs.openstack.org/developer/nova/notifications.html)?


Is there any repo that can be used to generate a object layer to 
translate these 'raw json' events into language specific objects (java, 
python, or other)?


Has anyone tried this, any luck with swagger to do this (or something 
like it)? Any repository of schemas that is being kept up to date as 
event notification versions change and/or are tweaked?


I think I saw that stacktach may have something (though not sure if that 
is updated anymore)... Any others folks are aware of?


-Josh


__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Stephen Balukoff]

I agree whole-heartedly with johnsom's assessment of diltram's
contributions. +1 from me!

On Mon, Oct 10, 2016 at 1:06 PM, Michael Johnson 
wrote:

> Greetings Octavia and developer mailing list folks,
>
> I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
> core reviewer.
>
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  He regularly attends our weekly
> meetings, contributes good code, and provides solid reviews.
>
> Overall I think Lubosz would make a great addition to the core review team.
>
> Current Octavia cores, please respond with +1/-1.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Michael Johnson]

Greetings Octavia and developer mailing list folks,

I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
core reviewer.

His contributions [1] are in line with other cores and he has been an
active member of our community.  He regularly attends our weekly
meetings, contributes good code, and provides solid reviews.

Overall I think Lubosz would make a great addition to the core review team.

Current Octavia cores, please respond with +1/-1.

Michael

[1] http://stackalytics.com/report/contribution/octavia/90

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

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[Hongbin Lu]

Courage,

As suggested by Denis in another reply, you might need to source the credential 
before issuing the command. If it doesn’t help, please feel free to ping us in 
the IRC channel (#openstack-zun).

Best regards,
Hongbin

From: courage angeh [mailto:couragean...@gmail.com]
Sent: October-10-16 10:40 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] ERROR: Not Authorized

i have problems running zun. When i try to run comaands lik:

zun start test or
zun create --name test --image cirros --command "ping -c 4 8.8.8.8"

I get the error: ERROR: Not Authorized

Futher searching it seem like i cann't connect to http://192.168.8.101:5000/v2.0

Please can someone help me?

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] [QA][Cinder]Removing Cinder v1 in Tempest

[Matt Riedemann]

On 10/10/2016 7:47 AM, Duncan Thomas wrote:

If we can get them running on cinder patches via a different job, then
removing them from the common job afterwards seems reasonable.

There's no strong will to remove them, several libraries still use them,
and given we're now supporting /all/ other API versions indefinitely,
keeping them around isn't that much of a burden.

On 10 October 2016 at 15:32, Jordan Pittier mailto:jordan.pitt...@scality.com>> wrote:

Hi,
I'd like to reduce the duration of a full Tempest run and I noticed
that Cinder tests take a good amount of time (cumulative
time 2149sec vs 2256sec for Nova, source code [0])

So I'd like to not run the Cinder v1 tests anymore, at least on the
master branches.

I remember that Cinder  v1 is deprecated (it has been for what, 2
years ?) Is the removal scheduled ? I don't see/feel a lot of
efforts toward that removal but I may be missing something. Any way,
that's not really my business but it's not really fair to all the
projects that run the "common jobs" that Cinder "slows" everyone down.

What do you think ?

[0]
: 
https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py





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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
--
Duncan Thomas


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



So make it conditional in Tempest via a config option, disable volume v1 
tests by default for the integrated gate, and then add a new job that 
runs only on cinder changes (and maybe only in the experimental queue) 
that enables volume v1 tests. You could run it on cinder in the 
check/gate and skip the job from running unless something in the v1 API 
path is changed, there are examples of that in project-config.


Nova used to have the v2 API in tree and this was kind of the eventual 
path to phasing out the Tempest testing on that code and got us to the 
point of removing the v2 *code*.  The compute v2 API itself is still 
honored via the v2.1 base microversion.


--

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] [nova] FYI, nova plans to have a room at the PTG in February

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2016-10-10 11:51:36 -0500:
> On 10/10/2016 8:59 AM, Sean McGinnis wrote:
> > On Mon, Oct 10, 2016 at 08:37:53AM -0400, Doug Hellmann wrote:
> >>> 
> >>
> >> We had a lot of feedback that the unstructured discussion time from
> >> the Friday "meetups" at the summits were the most productive time
> >> for teams, but I'm sure there are quite a few cases like what you
> >> describe. Maybe the solution is to schedule part, but not all, of
> >> the PTG time?
> >>
> >> It would be hard to say that a particular day is or is not scheduled,
> >> because not all teams will have rooms available to them every day.
> >> We could slice it the other way, though, and say that multi-project
> >> topics should be scheduled in the morning. That still leaves all
> >> of the afternoons for less structured discussions. Of course, not all
> >> teams will necessarily have multi-project topics.
> >
> > Having even just one day of scheduled topics might make it easier to
> > organize around topics that don't necessarily fall under the "cross
> > project" category, yet still affect more than one project and would
> > benefit from a set time for all to attend.
> >
> > Whether that is one day dedicated to that format, or something like AMs
> > scheduled, PMs freeform, I do think it is good to have the mix. We've
> > been able to make it through a lot of topics by not timeboxing certain
> > things, so the unscheduled part definitely has benefit.
> >
> > The risk with an AM/PM split would be, as an example, that Nova has
> > something scheduled that is significant to Cinder, so Cinder has to
> > dedicated a scheduled slot to match up with it. Just a thought, but if
> > we so split days like that, it might actually be good to have an A track
> > and B track, where A tracks have AMs scheduled and B tracks have PMs
> > scheduled. Maybe making things more complicated than they need to be,
> > but if Nova has scheduled sessions in the morning and Cinder
> > unscheduled, it might make it easy to take break and attend the other
> > sessions, and vice versa.
> >
> > 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
> >
> 
> I think we're probably over-complicating this. The nova/cinder midcycles 
> have happened at the same time in different timezones for the last two 
> releases. We've scheduled a time on a particular day and time that works 
> for both teams to get into a hangout session. Yes it's a scheduled 
> thing, but it's still pretty informal and when you only have to deal 
> with maybe a couple of those types of things during a midcycle it's not 
> overwhelming to plan ahead of time.
> 
> If the PTG turns into the design summit with 40 minute blocks of 
> discussion, it's going to really negatively impact the productivity of 
> midcycles.
> 

I think there's some perspective warping going on, and it's very
concerning to me.

Productivity inside the project is great, and we should definitely box
out more than just one day of the PTG for just those high bandwidth
internal project face to face discussions.

However, I think there's a danger of siloing even further if all three
days are just project team open ended face time. Those 40 minute sessions
may not seem productive to the project team, but they are massively
helpful for newcomers, for those who are shifting focus, and for those
who want to influence design at the early stages. They're also incredibly
useful for being able to tell the general developer community what the
project is doing, which I'm surprised more people don't want.

What I'd suggest is that we do have a single schedule, and that project
teams schedule their time to suit their needs, with the
following guidelines:

   If you are going to discuss a large spec for the first time in the
   week, dedicate a 40 minute session to that initial discussion on
   Wednesday.

   If you are going to discuss something that is controversial for the
   first time in the week, bring that up in a 40 minute summary session
   on Wednesday.

This might lead to what, 5 or 6 40 minute sessions on Wednesday at the
worst? The rest can just be project team work time. However, it gives
people like me, who want to make sure we're paying attention to the
right stuff in many projects a chance to introduce ourselves, raise a
hand and ask a few questions, and insert ourselves in the agenda so we
can be pinged and hopefully participate where it makes sense.

Whatever we do, please consider dismantling the silos, rather than
reinforcing them.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr

Re: [openstack-dev] [all][elections] Results of the TC Election

[Ed Leafe]

On Oct 10, 2016, at 11:58 AM, Clint Byrum  wrote:

>> I'd certainly appreciate a follow-up email towards the end of the voting 
>> period (i.e. it wouldn't even necessarily need to be a re-sending of the 
>> ballot link - finding that again is generally no problem). I wanted to 
>> see what the candidates had to say in response to the various questions 
>> on the mailing list before voting, but I was definitely starting to get 
>> nervous toward the end of the week that I might forget.
>> 
> Indeed. I think it might make sense to have a brief period between
> nomination deadline, and poll creation, maybe 1 week, to spark this
> debate and get the community engaged with the candidates. This goes for
> all of the elections.

Exactly. Most people vote when they get their email ballot, so discussions 
after that have limited impact.


-- 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] [all][elections] Results of the TC Election

[Clint Byrum]

Excerpts from Tony Breeds's message of 2016-10-10 10:49:12 +1100:
> Please join me in congratulating the 6 newly elected members of the TC.
> 
> Doug Hellmann (dhellmann)
> Emilien Macchi (emilienm)
> Jeremy Stanley (fungi)
> Monty Taylor (mordred)
> Sean Dague (sdague)
> Steve Martinelli (stevemar)
> 
> 
> Full results: 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
> 

Well obviously, the system is a disaster, and rigged bigly.

Congratulations to our newly elected TC members, and to all of those
nominated. It has truly been an honor to be mentioned in a list with
all of 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] [all][elections] Results of the TC Election

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-10-10 11:10:53 -0400:
> On 09/10/16 19:58, Tony Breeds wrote:
> > On Mon, Oct 10, 2016 at 10:49:12AM +1100, Tony Breeds wrote:
> >> Please join me in congratulating the 6 newly elected members of the TC.
> >>
> >> Doug Hellmann (dhellmann)
> >> Emilien Macchi (emilienm)
> >> Jeremy Stanley (fungi)
> >> Monty Taylor (mordred)
> >> Sean Dague (sdague)
> >> Steve Martinelli (stevemar)
> >>
> >>
> >> Full results: 
> >> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
> >
> > Following up on this  Here are some statistics for this election:
> >
> > +--+---+---+---+
> > | Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta 
> > %) |
> > +--+---+---+---+
> > |  10/2013 |   1106  (nan) |   342   (nan) | 30.92   (
> > nan) |
> > |  04/2014 |   1510  (  36.53) |   448   (  30.99) | 29.67   (  
> > -4.05) |
> > |  10/2014 |   1893  (  25.36) |   506   (  12.95) | 26.73   (  
> > -9.91) |
> > |  04/2015 |   2169  (  14.58) |   548   (   8.30) | 25.27   (  
> > -5.48) |
> > |  10/2015 |   2759  (  27.20) |   619   (  12.96) | 22.44   ( 
> > -11.20) |
> > |  04/2016 |   3284  (  19.03) |   652   (   5.33) | 19.85   ( 
> > -11.51) |
> > |  10/2016 |   3517  (   7.10) |   801   (  22.85) | 22.78   (  
> > 14.71) |
> > +--+---+---+---+
> >
> > Election CIVS links
> >  10/2014: 
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
> >  04/2015: 
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
> >  10/2015: 
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
> >  04/2016: 
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> >  10/2016: 
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
> >
> > It's interesting to note that we increased voter turnout this election,
> 
> This is truly excellent news :)
> 

I totally agree.

> > perhaps as a side effect of the complications with emailing the ballots?
> 
> That's an interesting idea, although I like to think it was also helped 
> by the fact that members of the community were actually engaging with 
> the candidates and generating a robust debate. Thanks Gordon, Clay, and 
> all the other folks whose questions helped to spark that - I hope we'll 
> see even more of it in future elections.
> 
> I'd certainly appreciate a follow-up email towards the end of the voting 
> period (i.e. it wouldn't even necessarily need to be a re-sending of the 
> ballot link - finding that again is generally no problem). I wanted to 
> see what the candidates had to say in response to the various questions 
> on the mailing list before voting, but I was definitely starting to get 
> nervous toward the end of the week that I might forget.
> 

Indeed. I think it might make sense to have a brief period between
nomination deadline, and poll creation, maybe 1 week, to spark this
debate and get the community engaged with the candidates. This goes for
all of the elections.


__
OpenStack Development Mailing 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] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Matt Riedemann]

On 10/10/2016 6:26 AM, Kashyap Chamarthy wrote:


Also, maybe you have noticed, given Eric's reply on this thread (and the
upstream libvir-list), it is agreed that virDomainGetBlockJobInfo()
should be fixed "to quit reporting cur==end when ready:false".  This
allows the existing Nova code work correctly without any changes.

Discusion on Eric's reply in this thread:

http://lists.openstack.org/pipermail/openstack-dev/2016-October/105194.html

And upstream libvir-list

https://www.redhat.com/archives/libvir-list/2016-October/msg00347.html



Yeah, that's goodness long-term, but OpenStack CI won't benefit from 
that for probably at least a couple of years.


--

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] [nova] FYI, nova plans to have a room at the PTG in February

[Matt Riedemann]

On 10/10/2016 8:59 AM, Sean McGinnis wrote:

On Mon, Oct 10, 2016 at 08:37:53AM -0400, Doug Hellmann wrote:




We had a lot of feedback that the unstructured discussion time from
the Friday "meetups" at the summits were the most productive time
for teams, but I'm sure there are quite a few cases like what you
describe. Maybe the solution is to schedule part, but not all, of
the PTG time?

It would be hard to say that a particular day is or is not scheduled,
because not all teams will have rooms available to them every day.
We could slice it the other way, though, and say that multi-project
topics should be scheduled in the morning. That still leaves all
of the afternoons for less structured discussions. Of course, not all
teams will necessarily have multi-project topics.


Having even just one day of scheduled topics might make it easier to
organize around topics that don't necessarily fall under the "cross
project" category, yet still affect more than one project and would
benefit from a set time for all to attend.

Whether that is one day dedicated to that format, or something like AMs
scheduled, PMs freeform, I do think it is good to have the mix. We've
been able to make it through a lot of topics by not timeboxing certain
things, so the unscheduled part definitely has benefit.

The risk with an AM/PM split would be, as an example, that Nova has
something scheduled that is significant to Cinder, so Cinder has to
dedicated a scheduled slot to match up with it. Just a thought, but if
we so split days like that, it might actually be good to have an A track
and B track, where A tracks have AMs scheduled and B tracks have PMs
scheduled. Maybe making things more complicated than they need to be,
but if Nova has scheduled sessions in the morning and Cinder
unscheduled, it might make it easy to take break and attend the other
sessions, and vice versa.

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



I think we're probably over-complicating this. The nova/cinder midcycles 
have happened at the same time in different timezones for the last two 
releases. We've scheduled a time on a particular day and time that works 
for both teams to get into a hangout session. Yes it's a scheduled 
thing, but it's still pretty informal and when you only have to deal 
with maybe a couple of those types of things during a midcycle it's not 
overwhelming to plan ahead of time.


If the PTG turns into the design summit with 40 minute blocks of 
discussion, it's going to really negatively impact the productivity of 
midcycles.


--

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

[openstack-dev] [tripleo] How To Review tripleo-validations

[Tomas Sedovic]

Hey everyone!

During the Newton cycle, we have added a new repository: 
tripleo-validations. This is a little guide on how to review the patches 
there.


All the validations are YAML files under the `validations` directory. 
They can optionally add files in `validations/library` (for Ansible 
modules) or `validations/files` for additional files or scripts to run.


Each validation is a self-contained check for something that could 
potentially break the deployment. Some of them verify the undercloud 
hardware, the introspected nodes for overcloud deployment, the heat 
templates, and some post-deployment checks.


Here's a list of things to pay attention to. You can look at this sample 
patch as you follow along:


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

* Check that the `hosts` section has a known value that fits the validation

This is currently: undercloud, overcloud, compute, controller or all. It 
describes the nodes the validation should run on. We need to update this 
to support the composable/custom roles[1].


You can see the source for these labels by running 
`scripts/tripleo-ansible-inventory --list` from the repo on the 
undercloud. You need to run `source stackrc` first.


* The `vars/metadata/name` section must exist and have a unique and 
descriptive name -- it should make it clear what the validation is for. 
This is displayed in the UI.


* The `vars/metadata/description` section must exist and describe what 
the validation is going to check and why. Where possible, the name and 
description should be enough to tell you where to look for when the 
validation fails. This is displayed in the UI.


* The `vars/metadata/groups` section should exist and have a list of 
stages throughout the deployment (pre-deployment, pre-introspection, 
post-deployment, etc.). These can be brand-new but they should make 
sense given what the validation is supposed to be doing.


* There may be additional `vars` after these -- those are variables that 
are going to be used within the validation steps.[2]


* The `tasks` section is a list of steps that Ansible is going to 
perform. They gather data, process it and verify what needs to happen.


Each task should have a name. It must also have a module name that's 
either the official Ansible module[3] or a custom one from the 
`validations/library` directory.


In addition, a task may also have a `failed_when` condition, possibly a 
`fail` message explaining the error, or a `register` section which takes 
the task's output and stores it in a variable available for late tasks.



* Ansible has three modules that seem to invoke a custom command, but 
each works differently: `command`, `shell` and `script`:


`command` invokes a single command with arguments you pass in. It 
doesn't do multiple commands, pipes or redirection. If you need any of 
those, use the `shell` module.


The `script` module takes a script on the local compute (usually from 
the  `validations/files` directory) copies it to the host and executes 
it there.


Oh and finally, if you need to run a shell builtin, you'll have to 
execute the shell manually (e.g.: `command: sh -c "ulimit -n"`)


When reviewing, if you see any of those, make sure the correct module is 
used.


* A task may rely on a custom module (i.e. one that doesn't come with 
Ansible but we ship it directly ourselves). These modules live in 
`validations/library` and the file name without the extension must be 
the same as the module invocation.



Testing validations
---

If you have set `enable_validations` in `undercloud.conf` before 
installing the undercloud, all dependdencies, etc. should be ready.


Otherwise you need to do this on the undercloud:
1. install the Ansible package (yum install ansible)
2. sudo useradd validations
3. mistral execution-create tripleo.validations.v1.copy_ssh_key


After that, to test a validation:
1. clone the repo: git clone 
https://git.openstack.org/openstack/tripleo-validations

2. apply the patch
3. source stackrc
4. run-validation /path/to/validations/some-validation.yaml ~/.ssh/id_rsa

run-validation is a script that takes the full path to a validation and 
an SSH key to connect to the nodes being validated. This should all be 
available under the stack user in the typical dev environment.


If you wish to run the validation via Mistral, create a context.json file:

{ "validation_name": "some-validation" }

and run:

$ mistral execution-create tripleo.validations.v1.run_validation 
context.json


Note that for this to work, the validation must be under:

/usr/share/openstack-tripleo-validations/validations/some-validation.yaml

After that, call `mistral execution-get-output` to see the output of the 
validation.



Additional notes


* Documentation:

We have http://docs.openstack.org/developer/tripleo-validations/ which 
lists the existing validations. And the info on how to enable & run 
validations is in the tripleo-common readme, but all of this

[openstack-dev] [neutron] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Hi Common Classifier and OVS Flow Management community,

Feel free to add topics to the next meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier&action=edit§ion=5

Time, location and recurrence are unchanged, so the next meeting will be 
tomorrow (11th October) at 17:00 UTC [1] on #openstack-meeting [2].

Current agenda:

Important links about the Common Classifier / Common Classification Framework:
-  https://review.openstack.org/#/q/topic:bug/1476527
-  https://bugs.launchpad.net/networking-sfc/+bug/1476527
-  https://github.com/openstack/neutron-classifier
-  [3] included in topic above as well

Important links about OVS Flow Management:
-  https://review.openstack.org/#/q/topic:bug/1563967
-  https://bugs.launchpad.net/neutron/+bug/1563967


The spec in [3] seems to have reached a very stable state. If you haven't yet 
reviewed it to understand if and how your use cases fit there, be sure to do it 
as soon as possible.

[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

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] [Infra] Meeting Tuesday October 11th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday October 11th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-04-19.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-04-19.03.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-04-19.03.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA] Schema proposal for config file handling for services

[Alex Schultz]

On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold  wrote:
> Hi,
>
> in the rpm-packaging project we started to package the services and are
> currently discussing a possible schema for configuration files and
> snippets used by the systemd .service files (but this would also affect
> OCF resource agents).
> This affects packagers, endusers and config management systems (Chef,
> Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
> the list.

This also affects deployment tools so you may want to include tripleo,
kolla, fuel as they are downstream consumers and may have their own
assumptions about how services are launched.

>
> Most services (at least for SUSE and RDO) are using a single config
> (e.g. /etc/nova/nova.conf) when starting the service. Some services
> (e.g. neutron services like neutron-l3-agent) use multiple config files.
>
> There are multiple problems with that approach:
> - when using a config-mgmt-system, users may want to override a config
> option (for a feature that is not yet supported) but the
> config-mgmt-system will override the config later again.

Just to chime in here from a puppet standpoint, this is not a problem
because we provide a way for a user to add any extra options they wish
using the provider so it always ends up in the correct configuration
file.

> - when users adjust /etc/$service/$service.conf and a release update is
> done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
> overridden. That's good because the user changed something but otoh the
> file (with all it's config options and comments) is no longer correct.

Depending on the configuration management tool, the 'default' options
and comments may not even be there so I'm not sure this is actually
that much of a concern.  Also when you upgrade there is usually some
sort of upgrade process that has to go along with your configuration
management tool which should take care of this for you. So i'm not
sure this needs to be a packaging concern.

> - when config-mgmt-systems use templates for the $service.conf file,
> updating theses templates is a lot of work.

Yes which is why tools that don't use templates in the configuration
management tool makes this a non-issue.  I'm not sure this needs to be
a concern of packagers as it's an issue with the configuration
management tool of choice and many of these tools have switched away
from templates or are currently handling this.  If the configuration
management tool doesn't support this or is suffering from this, simply
adding conf.d support might help but then you also run into issues
about ensuring things are removed and cleaned up.

> - setting configuration options per service (let's say cinder-volume
> needs other config options than cinder-api) is not possible.

So I agree this is more likely a real problem, but i'm not sure this
should be solved by packaging as this probably needs to be addressed
in upstream.  Unless this is already a thing and it's just never been
properly implemented when deployed via packages. The issue I have with
only solving this via rpm packaging is that for tools that support
both rpms and debs this would lead to 2 different configuration
mechanisms.  So I would vote not to do anything different then what
debs also do unless both packaging methods are updated at the same
time.  Do we have any examples or instances where an end user would
specifically want to configure two of the services in a conflicting
fashion?  Or are there configuration options that fall into this
pattern? I thought the service specific items where in their own
configuration namespace to allow for such things. I would assume that
the bigger issue would be wanting to run two of the same service on
the same host with different configurations I would think that's where
something like containers would handle this case better than trying to
have multiple configuration files.

>
> So here's the proposal to fix theses problems. The proposal is based on
> what RDO is already doing with neutron and extends it a bit. Let's do it
> for Nova as an example:
>
> - /usr/share/nova/nova-dist.conf
> This is the configuration file a distribution (openSUSE, RDO, ...) can
> modify. It must not be modified by endusers and will be overridden with
> package updates
>
> - /etc/nova/nova.conf
> This is an empty file . Users/config-mgmt-systems can modify it and it
> will not be overridden (if changed) with a package update.
>
> - /etc/nova/conf.d/common/
> In this directory, config snippets can be added. By convention,
> config-mgmt-systems would install files starting with 100-XXX.conf,
> endusers would install files starting with 500-XXX.conf . Also this
> directory is used by all services (nova-api, nova-compute, ...).
>
> - /etc/nova/conf.d/$service/ (e.g. /etc/nova/conf.d/nova-compute/)
> Also a dir for config snippets (with same rules as for
> /etc/nova/conf.d/common/ ) but this dir is only used by $service (in
> this case nova-compute)
>
> - /usr/share/d

[openstack-dev] [acceleration][dpacc] Work session and Meetups in Barcelona Summit

[Zhipeng Huang]

Hi all,

For those of you (all cc'ed here) who have expressed interests in building
an OpenStack acceleration service, you are more than welcomed to
participate in the discussion we are now planning for Barcelona Summit.

As could be found here [1], we will have a work session on Friday for Nomad
project member meetup as well as Ocata development planning. Again, you are
more than welcomed to provide input on the etherpad.

We are also looking at having a ad-hoc OPNFV DPACC Meetup sometime between
Mon and Thurs. Please provide your time preference via [2].

[1]https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Nomad
[2]http://doodle.com/poll/8pfdmy6wrpc9cizp
-- 
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

Re: [openstack-dev] [all][API WG] How does one best express a time interval as an API filtering query?

[milanisko k]

FYI The patch: https://review.openstack.org/#/c/383862/

Cheers,
milan

pá 7. 10. 2016 v 10:13 odesílatel milanisko k  napsal:

> Guys,
>
> thanks for the suggestions! I like the coma separation as well, it's the
> closest to the ISO style.
> Let me propose the update.
>
> Cheers,
> milan
>
> čt 6. 10. 2016 v 19:28 odesílatel Jay Pipes  napsal:
>
> On 10/06/2016 11:43 AM, Jeremy Stanley wrote:
> > On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
> > [...]
> >> Problem with that is that ':' is a valid character within an ISO date,
> >> though I do like the 'between' prefix.  Now, '/' can be used if it's URL
> >> encoded, but I agree that that is non-ideal.  How about a syntax
> >> something like:
> >>
> >> ?finished_at=between:ISO_DATE_A@ISO_DATE_B
> &finished_at=between:ISO_DATE_C@ISO_DATE_D
> >
> > I'll admit I'm not up on the intricacies of URL expectations for
> > APIs, but why not just use a comma? That's not an unusual meaning
> > for it as punctuation (at least in English), and has the property
> > that it's not overloading a typical field separator within either
> > 8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
> > the month.)
>
> Yup, ++ on a comma.
>
> -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] [Glance] [stable] Bug backports

[Ian Cordasco]

 

-Original Message-
From: Erno Kuvaja 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: October 10, 2016 at 10:32:46
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [Glance] [stable] Bug backports

> On Mon, Oct 10, 2016 at 3:58 PM, Andrey Pavlov wrote:
> > Hi,
> >
> > I want to backport this bug -
> > https://bugs.launchpad.net/glance-store/+bug/1616556
> > but review for master is stuck since August -
> > https://review.openstack.org/#/c/357827/
> >
>  
> My stand on backporting this as I commented to the bug as well:
> """By the looks of it this really isn't a bug but a feature request
> and as such we should not backport it."""

Andrey,

My impression of that review is much the same as Erno's. That said, it seems 
folks want Tomoki's opinion. Could you get their review on that patch so we can 
get it merged for Ocata. It does seem to be a valuable and desirable option 
for glance_store.

Cheers,
--  
Ian Cordasco


__
OpenStack Development Mailing 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] [heat] [magnum] Subjects to discuss during the summit

[Spyros Trigazis]

Hi Sergey,

I have seen the session, I wanted to add more details to
start the discussion earlier and to be better prepared.

Thanks,
Spyros


On 10 October 2016 at 17:36, Sergey Kraynev  wrote:

> Hi Spyros,
>
> AFAIK we already have special session slot related with your topic.
> So thank you for the providing all items here.
> Rabi, can we add link on this mail to etherpad ? (it will save our time
> during session :) )
>
> On 10 October 2016 at 18:11, Spyros Trigazis  wrote:
>
>> Hi heat and magnum.
>>
>> Apart from the scalability issues that have been observed, I'd like to
>> add few more subjects to discuss during the summit.
>>
>> 1. One nested stack per node and linear scale of cluster creation
>> time.
>>
>> 1.1
>> For large stacks, the creation of all nested stack scales linearly. We
>> haven't run any tested using the convergence-engine.
>>
>> 1.2
>> For large stacks, 1000 nodes, the final call to heat to fetch the
>> IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status
>> CREATE_COMPLETE but magnum's state is updated when this long final
>> call is done. Can we do better? Maybe fetch only the master IPs or
>> get he IPs in chunks.
>>
>> 1.3
>> After the stack create API call to heat, magnum's conductor
>> busy-waits heat with a thread/cluster. (In case of a magnum conductor
>> restart, we lose that thread and we can't update the status in
>> magnum). Investigate better ways to sync the status between magnum
>> and heat.
>>
>> 2. Next generation magnum clusters
>>
>> A need that comes up frequently in magnum is heterogeneous clusters.
>> * We want to able to create cluster on different hardware, (e.g. spawn
>>   vms on nodes with SSDs and nodes without SSDs or other special
>>   hardware available only in some nodes of the cluster FPGA, GPU)
>> * Spawn cluster across different AZs
>>
>> I'll describe briefly our plan here, for further information we have a
>> detailed spec under review. [1]
>>
>> To address this issue we introduce the node-group concept in magnum.
>> Each node-group will correspond to a different heat stack. The master
>> nodes can be organized in one or more stacks, so as the worker nodes.
>>
>> We investigate how to implement this feature. We consider the
>> following:
>> At the moment, we have three template files, cluster, master and
>> node, and all three template files create one stack. The new
>> generation of clusters will have a cluster stack containing
>> the resources in the cluster template, specifically, networks, lbaas
>> floating-ips etc. Then, the output of this stack would be passed as
>> input to create the master node stack(s) and the worker nodes
>> stack(s).
>>
>> 3. Use of heat-agent
>>
>> A missing feature in magnum is the lifecycle operations in magnum. For
>> restart of services and COE upgrades (upgrade docker, kubernetes and
>> mesos) we consider using the heat-agent. Another option is to create a
>> magnum agent or daemon like trove.
>>
>> 3.1
>> For restart, a few systemctl restart or service restart commands will
>> be issued. [2]
>>
>> 3.2
>> For upgrades there are three scenarios:
>> 1. Upgrade a service which runs in a container. In this case, a small
>>script that runs in each node is sufficient. No vm reboot required.
>> 2. For an ubuntu based image or similar that requires a package upgrade
>>a similar small script is sufficient too. No vm reboot required.
>> 3. For our fedora atomic images, we need to perform a rebase on the
>>rpm-ostree files system which requires a reboot.
>> 4. Finally, a thought under investigation is replacing the nodes one
>>by one using a different image. e.g. Upgrade from fedora 24 to 25
>>with new versions of packages all in a new qcow2 image. How could
>>we update the stack for this?
>>
>> Options 1. and 2. can be done by upgrading all worker nodes at once or
>> one by one. Options 3. and 4. should be done one by one.
>>
>> I'm drafting a spec about upgrades, should be ready by Wednesday.
>>
>> Cheers,
>> Spyros
>>
>> [1] https://review.openstack.org/#/c/352734/
>> [2] https://review.openstack.org/#/c/368981/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Sergey.
>
> __
> OpenStack Development Mailing 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/li

[openstack-dev] [puppet] Standardization of Keystone authtoken

[Iury Gregory]

Hello everyone,

*tl;dr: *We will be removing all old parameters to configure the
keystone_authtoken section that was deprecated during the Newton Cycle. In
Ocata you will need to use the authtoken class for each module, except for
some modules that do not provide the support yet, for more details see this
bug [0].


During the Newton cycle we have worked to bring the capability to configure
the [keystone_authtoken] section with new parameters using the
puppet-keystone resource [1] , each module has its own class to configure
the section in configuration files using.

We had deprecated all other old parameters and this change is 100% backward
compatible, some modules haven't this change, please see this comment [2]
for the bug [0].

Now in Ocata we are removing the deprecated parameters, so you will need to
use the authtoken class in your manifests, the class should be declared
before the api services are configured, for example see [3].



[0] https://bugs.launchpad.net/puppet-aodh/+bug/1604463
[1] https://github.com/openstack/puppet-keystone/blob/
master/manifests/resource/authtoken.pp
[2] https://bugs.launchpad.net/puppet-aodh/+bug/1604463/comments/8
[3] https://github.com/openstack/puppet-openstack-integration/
blob/master/manifests/aodh.pp#L57-L68

-- 
~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] weekly meeting #93

[Iury Gregory]

Hi Puppeteers!


We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4

Here's the agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161011

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
Thanks

-- 
~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@gmail.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] [Glance] [stable] Bug backports

[Brian Rosmaita]

On 10/10/16, 11:31 AM, "Erno Kuvaja"  wrote:

>On Mon, Oct 10, 2016 at 3:58 PM, Andrey Pavlov 
>wrote:
>> Hi,
>>
>> I want to backport this bug -
>> https://bugs.launchpad.net/glance-store/+bug/1616556
>> but review for master is stuck since August -
>> https://review.openstack.org/#/c/357827/
>>
>
>My stand on backporting this as I commented to the bug as well:
>"""By the looks of it this really isn't a bug but a feature request
>and as such we should not backport it."""
>
>Thanks,
>Erno

The patch for master needs a bit of work.  After that's completed, we can
discuss a backport.  I'm inclined to agree with Erno, but am open to other
opinions.  It would help your case to enlist the opinion of the cinder
driver maintainer.

cheers,
brian

>
>> On Mon, Oct 10, 2016 at 4:05 PM, Ian Cordasco 
>> wrote:
>>>
>>> -Original Message-
>>> From: Ian Cordasco 
>>> Reply: Ian Cordasco 
>>> Date: October 7, 2016 at 08:47:19
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject:  [Glance] [stable] Bug backports
>>>
>>> > Hi Glancers!
>>> >
>>> > After the news that we all released Newton yesterday, it's time to
>>>start
>>> > thinking about
>>> > backports the future of our Mitaka and Liberty branches.
>>> >
>>> > I expect that Mitaka will start to enter Phase II [1] and Liberty's
>>> > end-of-life is right
>>> > around the corner [2] (2016-11-17). If there are bugs that are
>>>affecting
>>> > those branches
>>> > that need to be backported before their status changes, they should
>>>be
>>> > proposed immediately
>>> > and brought up at the Glance team meeting [3].
>>> >
>>> > [1]: 
>>>http://docs.openstack.org/project-team-guide/stable-branches.html
>>> > [2]: https://releases.openstack.org/
>>> > [3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting
>>>
>>>
>>> In case you missed it, Friday the 14th (October 2016) the stable team
>>> is moving Mitaka to Phase II and Liberty to Phase III [1].
>>>
>>> Please respond to this message with bugs and backport reviews that
>>> should land prior to Mitaka entering Phase II.
>>>
>>> [1]:
>>> 
>>>http://lists.openstack.org/pipermail/openstack-dev/2016-October/105302.h
>>>tml
>>>
>>> Cheers,
>>> --
>>> Ian Cordasco
>>>
>>> 
>>>
>>>__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Kind regards,
>> Andrey Pavlov.
>>
>> 
>>_
>>_
>> OpenStack Development Mailing 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] [heat] [magnum] Subjects to discuss during the summit

[Sergey Kraynev]

Hi Spyros,

AFAIK we already have special session slot related with your topic.
So thank you for the providing all items here.
Rabi, can we add link on this mail to etherpad ? (it will save our time
during session :) )

On 10 October 2016 at 18:11, Spyros Trigazis  wrote:

> Hi heat and magnum.
>
> Apart from the scalability issues that have been observed, I'd like to
> add few more subjects to discuss during the summit.
>
> 1. One nested stack per node and linear scale of cluster creation
> time.
>
> 1.1
> For large stacks, the creation of all nested stack scales linearly. We
> haven't run any tested using the convergence-engine.
>
> 1.2
> For large stacks, 1000 nodes, the final call to heat to fetch the
> IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status
> CREATE_COMPLETE but magnum's state is updated when this long final
> call is done. Can we do better? Maybe fetch only the master IPs or
> get he IPs in chunks.
>
> 1.3
> After the stack create API call to heat, magnum's conductor
> busy-waits heat with a thread/cluster. (In case of a magnum conductor
> restart, we lose that thread and we can't update the status in
> magnum). Investigate better ways to sync the status between magnum
> and heat.
>
> 2. Next generation magnum clusters
>
> A need that comes up frequently in magnum is heterogeneous clusters.
> * We want to able to create cluster on different hardware, (e.g. spawn
>   vms on nodes with SSDs and nodes without SSDs or other special
>   hardware available only in some nodes of the cluster FPGA, GPU)
> * Spawn cluster across different AZs
>
> I'll describe briefly our plan here, for further information we have a
> detailed spec under review. [1]
>
> To address this issue we introduce the node-group concept in magnum.
> Each node-group will correspond to a different heat stack. The master
> nodes can be organized in one or more stacks, so as the worker nodes.
>
> We investigate how to implement this feature. We consider the
> following:
> At the moment, we have three template files, cluster, master and
> node, and all three template files create one stack. The new
> generation of clusters will have a cluster stack containing
> the resources in the cluster template, specifically, networks, lbaas
> floating-ips etc. Then, the output of this stack would be passed as
> input to create the master node stack(s) and the worker nodes
> stack(s).
>
> 3. Use of heat-agent
>
> A missing feature in magnum is the lifecycle operations in magnum. For
> restart of services and COE upgrades (upgrade docker, kubernetes and
> mesos) we consider using the heat-agent. Another option is to create a
> magnum agent or daemon like trove.
>
> 3.1
> For restart, a few systemctl restart or service restart commands will
> be issued. [2]
>
> 3.2
> For upgrades there are three scenarios:
> 1. Upgrade a service which runs in a container. In this case, a small
>script that runs in each node is sufficient. No vm reboot required.
> 2. For an ubuntu based image or similar that requires a package upgrade
>a similar small script is sufficient too. No vm reboot required.
> 3. For our fedora atomic images, we need to perform a rebase on the
>rpm-ostree files system which requires a reboot.
> 4. Finally, a thought under investigation is replacing the nodes one
>by one using a different image. e.g. Upgrade from fedora 24 to 25
>with new versions of packages all in a new qcow2 image. How could
>we update the stack for this?
>
> Options 1. and 2. can be done by upgrading all worker nodes at once or
> one by one. Options 3. and 4. should be done one by one.
>
> I'm drafting a spec about upgrades, should be ready by Wednesday.
>
> Cheers,
> Spyros
>
> [1] https://review.openstack.org/#/c/352734/
> [2] https://review.openstack.org/#/c/368981/
>
> __
> OpenStack Development Mailing 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,
Sergey.
__
OpenStack Development Mailing 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] [Glance] [stable] Bug backports

[Erno Kuvaja]

On Mon, Oct 10, 2016 at 3:58 PM, Andrey Pavlov  wrote:
> Hi,
>
> I want to backport this bug -
> https://bugs.launchpad.net/glance-store/+bug/1616556
> but review for master is stuck since August -
> https://review.openstack.org/#/c/357827/
>

My stand on backporting this as I commented to the bug as well:
"""By the looks of it this really isn't a bug but a feature request
and as such we should not backport it."""

Thanks,
Erno

> On Mon, Oct 10, 2016 at 4:05 PM, Ian Cordasco 
> wrote:
>>
>> -Original Message-
>> From: Ian Cordasco 
>> Reply: Ian Cordasco 
>> Date: October 7, 2016 at 08:47:19
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject:  [Glance] [stable] Bug backports
>>
>> > Hi Glancers!
>> >
>> > After the news that we all released Newton yesterday, it's time to start
>> > thinking about
>> > backports the future of our Mitaka and Liberty branches.
>> >
>> > I expect that Mitaka will start to enter Phase II [1] and Liberty's
>> > end-of-life is right
>> > around the corner [2] (2016-11-17). If there are bugs that are affecting
>> > those branches
>> > that need to be backported before their status changes, they should be
>> > proposed immediately
>> > and brought up at the Glance team meeting [3].
>> >
>> > [1]: http://docs.openstack.org/project-team-guide/stable-branches.html
>> > [2]: https://releases.openstack.org/
>> > [3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting
>>
>>
>> In case you missed it, Friday the 14th (October 2016) the stable team
>> is moving Mitaka to Phase II and Liberty to Phase III [1].
>>
>> Please respond to this message with bugs and backport reviews that
>> should land prior to Mitaka entering Phase II.
>>
>> [1]:
>> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105302.html
>>
>> Cheers,
>> --
>> Ian Cordasco
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> OpenStack Development Mailing 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] ERROR: Not Authorized

[Denis Makogon]

Hello Courage.

It may appear that you didn't set authorization environment variables to
your OpenStack (i assume you're running devstack).
So just do

*source $PATHTODEVSTACKREPO/keystone.rc*

Kind regards,
Denis Makogon


2016-10-10 17:39 GMT+03:00 courage angeh :

> i have problems running zun. When i try to run comaands lik:
>
> zun start test or
> zun create --name test --image cirros --command "ping -c 4 8.8.8.8"
>
> I get the error: ERROR: Not Authorized
>
> Futher searching it seem like i cann't connect to 
> http://192.168.8.101:5000/v2.0
>
> Please can someone help me?
>
> 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
>
>
__
OpenStack Development Mailing 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] [chef] Adding calbers to openstack-chef-core

[Samuel Cassiba]

Hi,

Given as there have been no objections, I have added calbers to
openstack-chef-core. With that, we reinstate a 2x +2 rule for changes.
Congrats Christoph!

Best,

-sc

On Wed, Oct 5, 2016 at 1:02 AM, j.kl...@cloudbau.de  wrote:
> Hi,
>
> sounds good, +1 from me.
>
> Cheers,
> Jan
>
>> On 05 Oct 2016, at 05:44, Samuel Cassiba  wrote:
>>
>> Ohai Chefs!
>>
>> I would like to nominate Christoph Albers (irc: calbers) for
>> openstack-chef-core.
>>
>> Christoph has consistently provided great quality reviews over the
>> Newton cycle. He has been instrumental in getting the cookbooks up to
>> speed with Identity v3 and openstackclient. During Mitaka, his reviews
>> were crucial to the refactor work that took place during that cycle.
>> From the quality of his reviews, he has a solid understanding of the
>> codebase and I think he is qualified to be a core reviewer.
>>
>> This will bring us back up to three dedicated core reviewers, and I
>> would like to reimplement a 2x +2 policy for changes.
>>
>> If there are no objections, I will put in a change at the end of the
>> week. Consider this a +1 vote from me.
>>
>> Thanks,
>>
>> -sc
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Zane Bitter]

On 09/10/16 19:58, Tony Breeds wrote:

On Mon, Oct 10, 2016 at 10:49:12AM +1100, Tony Breeds wrote:

Please join me in congratulating the 6 newly elected members of the TC.

Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Monty Taylor (mordred)
Sean Dague (sdague)
Steve Martinelli (stevemar)


Full results: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010


Following up on this  Here are some statistics for this election:

+--+---+---+---+
| Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta %) |
+--+---+---+---+
|  10/2013 |   1106  (nan) |   342   (nan) | 30.92   (nan) |
|  04/2014 |   1510  (  36.53) |   448   (  30.99) | 29.67   (  -4.05) |
|  10/2014 |   1893  (  25.36) |   506   (  12.95) | 26.73   (  -9.91) |
|  04/2015 |   2169  (  14.58) |   548   (   8.30) | 25.27   (  -5.48) |
|  10/2015 |   2759  (  27.20) |   619   (  12.96) | 22.44   ( -11.20) |
|  04/2016 |   3284  (  19.03) |   652   (   5.33) | 19.85   ( -11.51) |
|  10/2016 |   3517  (   7.10) |   801   (  22.85) | 22.78   (  14.71) |
+--+---+---+---+

Election CIVS links
 10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
 04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
 10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
 04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
 10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010

It's interesting to note that we increased voter turnout this election,


This is truly excellent news :)


perhaps as a side effect of the complications with emailing the ballots?


That's an interesting idea, although I like to think it was also helped 
by the fact that members of the community were actually engaging with 
the candidates and generating a robust debate. Thanks Gordon, Clay, and 
all the other folks whose questions helped to spark that - I hope we'll 
see even more of it in future elections.


I'd certainly appreciate a follow-up email towards the end of the voting 
period (i.e. it wouldn't even necessarily need to be a re-sending of the 
ballot link - finding that again is generally no problem). I wanted to 
see what the candidates had to say in response to the various questions 
on the mailing list before voting, but I was definitely starting to get 
nervous toward the end of the week that I might forget.


cheers,
Zane.

__
OpenStack Development Mailing 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] [heat] [magnum] Subjects to discuss during the summit

[Spyros Trigazis]

Hi heat and magnum.

Apart from the scalability issues that have been observed, I'd like to
add few more subjects to discuss during the summit.

1. One nested stack per node and linear scale of cluster creation
time.

1.1
For large stacks, the creation of all nested stack scales linearly. We
haven't run any tested using the convergence-engine.

1.2
For large stacks, 1000 nodes, the final call to heat to fetch the
IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status
CREATE_COMPLETE but magnum's state is updated when this long final
call is done. Can we do better? Maybe fetch only the master IPs or
get he IPs in chunks.

1.3
After the stack create API call to heat, magnum's conductor
busy-waits heat with a thread/cluster. (In case of a magnum conductor
restart, we lose that thread and we can't update the status in
magnum). Investigate better ways to sync the status between magnum
and heat.

2. Next generation magnum clusters

A need that comes up frequently in magnum is heterogeneous clusters.
* We want to able to create cluster on different hardware, (e.g. spawn
  vms on nodes with SSDs and nodes without SSDs or other special
  hardware available only in some nodes of the cluster FPGA, GPU)
* Spawn cluster across different AZs

I'll describe briefly our plan here, for further information we have a
detailed spec under review. [1]

To address this issue we introduce the node-group concept in magnum.
Each node-group will correspond to a different heat stack. The master
nodes can be organized in one or more stacks, so as the worker nodes.

We investigate how to implement this feature. We consider the
following:
At the moment, we have three template files, cluster, master and
node, and all three template files create one stack. The new
generation of clusters will have a cluster stack containing
the resources in the cluster template, specifically, networks, lbaas
floating-ips etc. Then, the output of this stack would be passed as
input to create the master node stack(s) and the worker nodes
stack(s).

3. Use of heat-agent

A missing feature in magnum is the lifecycle operations in magnum. For
restart of services and COE upgrades (upgrade docker, kubernetes and
mesos) we consider using the heat-agent. Another option is to create a
magnum agent or daemon like trove.

3.1
For restart, a few systemctl restart or service restart commands will
be issued. [2]

3.2
For upgrades there are three scenarios:
1. Upgrade a service which runs in a container. In this case, a small
   script that runs in each node is sufficient. No vm reboot required.
2. For an ubuntu based image or similar that requires a package upgrade
   a similar small script is sufficient too. No vm reboot required.
3. For our fedora atomic images, we need to perform a rebase on the
   rpm-ostree files system which requires a reboot.
4. Finally, a thought under investigation is replacing the nodes one
   by one using a different image. e.g. Upgrade from fedora 24 to 25
   with new versions of packages all in a new qcow2 image. How could
   we update the stack for this?

Options 1. and 2. can be done by upgrading all worker nodes at once or
one by one. Options 3. and 4. should be done one by one.

I'm drafting a spec about upgrades, should be ready by Wednesday.

Cheers,
Spyros

[1] https://review.openstack.org/#/c/352734/
[2] https://review.openstack.org/#/c/368981/
__
OpenStack Development Mailing 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] [Glance] [stable] Bug backports

[Andrey Pavlov]

Hi,

I want to backport this bug -
https://bugs.launchpad.net/glance-store/+bug/1616556
but review for master is stuck since August -
https://review.openstack.org/#/c/357827/

On Mon, Oct 10, 2016 at 4:05 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Ian Cordasco 
> Reply: Ian Cordasco 
> Date: October 7, 2016 at 08:47:19
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  [Glance] [stable] Bug backports
>
> > Hi Glancers!
> >
> > After the news that we all released Newton yesterday, it's time to start
> thinking about
> > backports the future of our Mitaka and Liberty branches.
> >
> > I expect that Mitaka will start to enter Phase II [1] and Liberty's
> end-of-life is right
> > around the corner [2] (2016-11-17). If there are bugs that are affecting
> those branches
> > that need to be backported before their status changes, they should be
> proposed immediately
> > and brought up at the Glance team meeting [3].
> >
> > [1]: http://docs.openstack.org/project-team-guide/stable-branches.html
> > [2]: https://releases.openstack.org/
> > [3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting
>
>
> In case you missed it, Friday the 14th (October 2016) the stable team
> is moving Mitaka to Phase II and Liberty to Phase III [1].
>
> Please respond to this message with bugs and backport reviews that
> should land prior to Mitaka entering Phase II.
>
> [1]: http://lists.openstack.org/pipermail/openstack-dev/
> 2016-October/105302.html
>
> Cheers,
> --
> Ian Cordasco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [kolla] We plan to be in PTG

[Michał Jastrzębski]

Everyone,

Kolla plans to be part of PTG in Atlanta. I hope to see you all there!

Regards,
inc0

__
OpenStack Development Mailing 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] ERROR: Not Authorized

[courage angeh]

i have problems running zun. When i try to run comaands lik:

zun start test or
zun create --name test --image cirros --command "ping -c 4 8.8.8.8"

I get the error: ERROR: Not Authorized

Futher searching it seem like i cann't connect to http://192.168.8.101:5000/v2.0

Please can someone help me?

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] [glance] priorities for the next two weeks

[Brian Rosmaita]

On 10/10/16, 6:01 AM, "Flavio Percoco"  wrote:

>Hey Brian,
>
>Thanks for sending the summary out. Top-posting since it's kinda
>unrelated to
>the list of topics below.
>
>Are the cycle priorities going to be documented as we did in Mitaka?
>
>https://github.com/openstack/glance-specs/tree/master/priorities
>
>I'd personally advice for this. It'd be better to have this in a place
>where
>other members of the community can easily go to.
>
>Flavio

Yes, I was planning on putting up a patch to glance-specs during the design
summit after we've had a chance to hash out the priorities in Barcelona.
In
addition to being available to the wider community, it will allow people
who
weren't able to attend the Summit (which includes, unfortunately, almost
the
entire Glance team) to have the opportunity to provide input on what we
discuss
at the Summit.

At this point, we already have three priorities carried over from Newton,
and
I just want to make sure we keep the momentum going.

cheers,
brian


>
>On 07/10/16 18:50 +, Brian Rosmaita wrote:
>>I'd like to reiterate what we discussed during the "Core Awareness" topic
>>at yesterday's Glance weekly meeting for those who weren't able to attend
>>or read through the meeting logs yet.
>>
>>Three Ocata priorities have already been determined:
>>(1) image import refactor
>>(2) community images (including image 'visibility' enhancements)
>>(3) rolling upgrades, specifically the database strategy for
>>zero-downtime
>>upgrades
>>
>>There's a sub-team working on image import (weekly sync in
>>#openstack-glance at 14:00 UTC).
>>
>>Any cores not working on image import, please direct your attention to
>>community images:
>>- https://review.openstack.org/369110
>>
>>- https://review.openstack.org/366354
>>- https://review.openstack.org/379852
>>With timely reviews, we may be able to land this before the summit.
>>Additionally, it's important to have the code merged so for the sub-team
>>working on rolling upgrades, so they can demonstrate how the strategy
>>will
>>work on a real-life migration.
>>
>>As far as rolling upgrades reviews go, there are a lot of comments on the
>>database strategy spec, but not many of these are from Glance cores.  It
>>would be good to take a look to sanity check the strategy being proposed:
>>- https://review.openstack.org/#/c/331740/
>>Additionally, there's a patch for moving db migrations from
>>SQLAlchemy-migrate to Alembic:
>>- https://review.openstack.org/#/c/374278/
>>And a patch up to make the switch to Alembic:
>>- https://review.openstack.org/#/c/382958/
>>Please take the time to look these over.  If you have reservations about
>>the move to Alembic, now's the time to make them heard.
>>
>>So, those are the Glance priorities for the next two weeks.
>>
>>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
>
>-- 
>@flaper87
>Flavio Percoco


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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Doug Hellmann]

Excerpts from John Davidge's message of 2016-10-10 13:24:18 +:
> On 10/10/16, 5:36 AM, Monty Taylor wrote:
> 
> >It's really nice to see that we had an increase in turnout percentage
> >even in the face of having our largest electorate yet.
> >
> >Thanks for all your great work!!!
> >
> >Monty
> 
> +100
> 
> Thank you as well to all the candidates and standing TC members who took
> part in this process. The past few weeks have really opened my eyes to
> what our TC deals with day-to-day, and the huge amount of work that goes
> into making things run smoothly.
> 
> Special thanks to Thierry and Doug in particular for what was at times a
> heated debate. I have a lot to learn from you both about keeping a level
> head on the ML :)
> 
> Cheers and congrats,
> 
> John
> 

Thanks, John, I appreciate all of the discussion this time around.
It's nice to see more folks engaging on the issues and exploring
possible solutions. I hope that everyone who ran will stay actively
involved in those discussions throughout the term.

And thanks again to the election supervisors! Things went very smoothly,
considering the technical challenges our growth has presented.

Doug

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Sean Dague]

On 10/10/2016 10:13 AM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2016-10-10 09:23:43 -0400:
>> On 10/10/2016 08:37 AM, Doug Hellmann wrote:
>> 
>>> We had a lot of feedback that the unstructured discussion time from
>>> the Friday "meetups" at the summits were the most productive time
>>> for teams, but I'm sure there are quite a few cases like what you
>>> describe. Maybe the solution is to schedule part, but not all, of
>>> the PTG time?
>>>
>>> It would be hard to say that a particular day is or is not scheduled,
>>> because not all teams will have rooms available to them every day.
>>> We could slice it the other way, though, and say that multi-project
>>> topics should be scheduled in the morning. That still leaves all
>>> of the afternoons for less structured discussions. Of course, not all
>>> teams will necessarily have multi-project topics.
>>>
>>> We could also just say, as I think Thierry was hinting at elsewhere
>>> in this thread, that each team should publish its own schedule of
>>> topics using some sort of unconference-like system (notecards on a
>>> board, etherpad, whatever). That might make it harder to resolve
>>> conflicts, though.
>>>
>>> What do other folks think?
>>
>> I feel like when we went down this path for the PTG, one of the
>> assurances was that it would be unstructured time, like the midcycles,
>> which is very productive. Having a long running etherpad is fine (and
>> kind of expected), but I think building timeboxing in before the event
>> seems odd.
>>
>> There are so many unknowns here, but taking away one of the primary
>> things that made midcycles productive for people in teams, to optimize
>> for track hopping, seems odd.
>>
>> If there are topics that span teams, there are 2 days up front. Ensuring
>> there is space to expand topics into there would be good, and not just
>> make those horizontal effort days.
>>
>> -Sean
>>
> 
> So you're proposing that we use time on Monday and Tuesday for
> multi-project as well as cross-project discussions? That works for
> me.  It may mean some folks who were planning to skip those and
> arrive later in the week will show up earlier and participate in
> more discussions.
> 
> Do we have space for those sorts of meetings on Monday and Tuesday?

Yes, or at least allow some flexibility for it. I think scheduler
service breakout would be a good topic to fit into there (one of the
examples listed earlier). The kinds of things we know will impact a set
of projects.

On the technology/support from, it feels like it would be good to have
the equivalent of meeting bot running for every room the entire time
(maybe in project channels?). So that #topic and #agree could be
recorded there and broadcast in a way that it would be easy for everyone
to see.

-Sean


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-10-10 09:23:43 -0400:
> On 10/10/2016 08:37 AM, Doug Hellmann wrote:
> 
> > We had a lot of feedback that the unstructured discussion time from
> > the Friday "meetups" at the summits were the most productive time
> > for teams, but I'm sure there are quite a few cases like what you
> > describe. Maybe the solution is to schedule part, but not all, of
> > the PTG time?
> > 
> > It would be hard to say that a particular day is or is not scheduled,
> > because not all teams will have rooms available to them every day.
> > We could slice it the other way, though, and say that multi-project
> > topics should be scheduled in the morning. That still leaves all
> > of the afternoons for less structured discussions. Of course, not all
> > teams will necessarily have multi-project topics.
> > 
> > We could also just say, as I think Thierry was hinting at elsewhere
> > in this thread, that each team should publish its own schedule of
> > topics using some sort of unconference-like system (notecards on a
> > board, etherpad, whatever). That might make it harder to resolve
> > conflicts, though.
> > 
> > What do other folks think?
> 
> I feel like when we went down this path for the PTG, one of the
> assurances was that it would be unstructured time, like the midcycles,
> which is very productive. Having a long running etherpad is fine (and
> kind of expected), but I think building timeboxing in before the event
> seems odd.
> 
> There are so many unknowns here, but taking away one of the primary
> things that made midcycles productive for people in teams, to optimize
> for track hopping, seems odd.
> 
> If there are topics that span teams, there are 2 days up front. Ensuring
> there is space to expand topics into there would be good, and not just
> make those horizontal effort days.
> 
> -Sean
> 

So you're proposing that we use time on Monday and Tuesday for
multi-project as well as cross-project discussions? That works for
me.  It may mean some folks who were planning to skip those and
arrive later in the week will show up earlier and participate in
more discussions.

Do we have space for those sorts of meetings on Monday and Tuesday?

Doug

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

Re: [openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

[Sean McGinnis]

On Mon, Oct 10, 2016 at 03:47:39PM +0300, Duncan Thomas wrote:
> If we can get them running on cinder patches via a different job, then
> removing them from the common job afterwards seems reasonable.
> 
> There's no strong will to remove them, several libraries still use them,
> and given we're now supporting /all/ other API versions indefinitely,
> keeping them around isn't that much of a burden.
> 

We attempted to remove v1, but after a discussion in Tokyo realized that
we can't easily do that. We're stuck with it, at least for some time.

But that said, as you point out we have had it marked as deprecated for
quite a while and I do think it's not really necessary to run the v1
tests on every single run. Especially as we add v3 functionality that
diverges from v2.

We will continue to fix v1 issues if they are found, but that is not the
focus of our efforts and I agree it's not really worth slowing everyone
down for something that is basically in "maintenance mode".

Sean (smcginnis)

> On 10 October 2016 at 15:32, Jordan Pittier 
> wrote:
> 
> > Hi,
> > I'd like to reduce the duration of a full Tempest run and I noticed that
> > Cinder tests take a good amount of time (cumulative time 2149sec vs 2256sec
> > for Nova, source code [0])
> >
> > So I'd like to not run the Cinder v1 tests anymore, at least on the master
> > branches.
> >
> > I remember that Cinder  v1 is deprecated (it has been for what, 2 years ?)
> > Is the removal scheduled ? I don't see/feel a lot of efforts toward that
> > removal but I may be missing something. Any way, that's not really my
> > business but it's not really fair to all the projects that run the "common
> > jobs" that Cinder "slows" everyone down.
> >
> > What do you think ?
> >
> > [0] : https://github.com/JordanP/openstack-snippets/blob/
> > master/tempest-timing/tempest_timing.py
> >
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> 
> -- 
> -- 
> Duncan Thomas

> __
> OpenStack Development Mailing 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] [new][ironic] ironic-lib 2.1.1 release (newton)

[no-reply]

We are grateful to announce the release of:

ironic-lib 2.1.1: Ironic common library

This release is part of the newton stable release series.

Download the package from:

https://pypi.python.org/pypi/ironic-lib

For more details, please see below.

Changes in ironic-lib 2.1.0..2.1.1
--

3a052c9 Fix check for GPT partioned device
7323bf5 Fix creating config drive for whole disk images
8591dec Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview  |  1 +
ironic_lib/disk_utils.py| 10 +-
3 files changed, 9 insertions(+), 8 deletions(-)




__
OpenStack Development Mailing 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] FYI, nova plans to have a room at the PTG in February

[Sean McGinnis]

On Mon, Oct 10, 2016 at 08:37:53AM -0400, Doug Hellmann wrote:
> > 
> 
> We had a lot of feedback that the unstructured discussion time from
> the Friday "meetups" at the summits were the most productive time
> for teams, but I'm sure there are quite a few cases like what you
> describe. Maybe the solution is to schedule part, but not all, of
> the PTG time?
> 
> It would be hard to say that a particular day is or is not scheduled,
> because not all teams will have rooms available to them every day.
> We could slice it the other way, though, and say that multi-project
> topics should be scheduled in the morning. That still leaves all
> of the afternoons for less structured discussions. Of course, not all
> teams will necessarily have multi-project topics.

Having even just one day of scheduled topics might make it easier to
organize around topics that don't necessarily fall under the "cross
project" category, yet still affect more than one project and would
benefit from a set time for all to attend.

Whether that is one day dedicated to that format, or something like AMs
scheduled, PMs freeform, I do think it is good to have the mix. We've
been able to make it through a lot of topics by not timeboxing certain
things, so the unscheduled part definitely has benefit.

The risk with an AM/PM split would be, as an example, that Nova has
something scheduled that is significant to Cinder, so Cinder has to
dedicated a scheduled slot to match up with it. Just a thought, but if
we so split days like that, it might actually be good to have an A track
and B track, where A tracks have AMs scheduled and B tracks have PMs
scheduled. Maybe making things more complicated than they need to be,
but if Nova has scheduled sessions in the morning and Cinder
unscheduled, it might make it easy to take break and attend the other
sessions, and vice versa.

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-dev] [mistral] Cancelling team meeting - 10/10/2016

[Deja, Dawid]

Hi,

We decided to cancel today’s team meeting because most people are either busy 
with release activities or on holidays. You can share your status as a reply 
for this mail.

My status: I have uploaded spec for workflow preconditions[1], please take a 
look when you have free time.

Thanks,
Dawid Deja

[1] https://review.openstack.org/#/c/384467/
__
OpenStack Development Mailing 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] [new][murano] murano-pkg-check 0.2.0 release

[no-reply]

We are high-spirited to announce the release of:

murano-pkg-check 0.2.0: Murano package validator tool

The source is available from:

http://git.openstack.org/cgit/openstack/murano-pkg-check

Download the package from:

https://pypi.python.org/pypi/murano-pkg-check

Please report issues through launchpad:

http://bugs.launchpad.net/murano-pkg-check

For more details, please see below.

Changes in murano-pkg-check 0.1.1..0.2.0


4eb0173 Improve class and method regexps
ef9e96d Readme has now some running examples
d872761 Updated from global requirements
5d25764 Catch block validation
b54814e update homepage with developer documentation page
1ac54a9 Making Default optional in Match strcuture
b12e6c9 Allow methods to be empty and error when not dict
3949928 Change Error to Warning for missing name of namespace
80a6886 Improving tests for metadata in Murano Classes
8d0898e Fix i18n set up
02544c5 Fix bug with loading buffer in ZipLoader in py3
554a9ed Updated from global requirements
c9e8de4 Add tools/tox_install.sh script


Diffstat (except docs and test files)
-

README.rst |  29 --
muranopkgcheck/checkers/code_structure.py  |  28 --
muranopkgcheck/i18n.py |   2 +-
muranopkgcheck/pkg_loader.py   |   3 +-
muranopkgcheck/validators/base.py  |   1 +
muranopkgcheck/validators/muranopl.py  |  65 +++--
requirements.txt   |   6 +-
setup.cfg  |   8 +-
setup.py   |   2 +-
test-requirements.txt  |   4 +-
tools/tox_install.sh   |  55 +++
tox.ini|   3 +-
16 files changed, 287 insertions(+), 48 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8ce956a..89f51ba 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ pbr>=1.6 # Apache-2.0
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT
@@ -10,2 +10,2 @@ stevedore>=1.16.0 # Apache-2.0
-semantic_version>=2.3.1 # BSD
-oslo.i18n>=2.1.0 # Apache-2.0
\ No newline at end of file
+semantic-version>=2.3.1 # BSD
+oslo.i18n>=2.1.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index a3fcd81..3db356e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9,2 +9,2 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.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] [new][ironic] ironic-lib 2.2.0 release (ocata)

[no-reply]

We are excited to announce the release of:

ironic-lib 2.2.0: Ironic common library

This release is part of the ocata release series.

Download the package from:

https://pypi.python.org/pypi/ironic-lib

For more details, please see below.

Changes in ironic-lib 2.1.0..2.2.0
--

c10121b Remove unneeded disk_utils.mkfs() function
448627a Updated from global requirements
4fc0078 Add py35 to tox environments
ddef39b Fix check for GPT partioned device
33af42c Fix creating config drive for whole disk images
36109e5 TrivialFix: Remove cfg import unused
96c287d Add match_root_device_hints() to the utils.py module
57a164d Sync tools/tox_install.sh
dccd7b1 Extend parse_root_device_hints to support operators
8429c01 Using assertIsNone() is preferred over assertEqual()


Diffstat (except docs and test files)
-

ironic_lib/disk_utils.py|  24 ++--
ironic_lib/utils.py | 240 +++-
requirements.txt|   2 +-
tools/tox_install.sh|  66 +-
tox.ini |   2 +-
8 files changed, 488 insertions(+), 100 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9b1b50b..4ce67db 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -13 +13 @@ six>=1.9.0 # MIT
-oslo.log>=1.14.0 # Apache-2.0
+oslo.log>=3.11.0 # Apache-2.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] [new][keystone] keystoneauth1 2.13.0 release (ocata)

[no-reply]

We are chuffed to announce the release of:

keystoneauth1 2.13.0: Authentication Library for OpenStack Identity

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/keystoneauth

Download the package from:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

Changes in keystoneauth1 2.12.1..2.13.0
---

811cd1f Updated from global requirements
1004db0 Updated from global requirements
a0fed84 Updated from global requirements
c563c8b Use mockpatch fixtures from fixtures
edb6122 Updated from global requirements
e69cbe6 Updated from global requirements
290ee82 Updated from global requirements
4179d36 Updated from global requirements
1306c8b Fix parameters for Kerberos Auth Plugin
c5aeaf6 Test that v3fedkerb plugin loads
194a504 Updated from global requirements
151f313 doc: remove unused import
2d3e376 Raise NotImplementedError instead of NotImplemented
50e8ace standardize release note page ordering
814298a Update reno for stable/newton


Diffstat (except docs and test files)
-

keystoneauth1/extras/_saml2/v3/saml2.py|  2 +-
keystoneauth1/extras/kerberos/__init__.py  |  6 ++-
keystoneauth1/extras/kerberos/_loading.py  |  2 +-
keystoneauth1/identity/v3/base.py  |  4 +-
keystoneauth1/identity/v3/oidc.py  |  2 +-
keystoneauth1/loading/base.py  |  2 +-
.../unit/extras/kerberos/test_fedkerb_loading.py   | 48 ++
releasenotes/source/index.rst  |  1 +
releasenotes/source/newton.rst |  6 +++
requirements.txt   |  4 +-
setup.cfg  |  2 +-
test-requirements.txt  | 10 ++---
14 files changed, 79 insertions(+), 24 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7fea9a8..f6d31de 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ iso8601>=0.1.11 # MIT
-positional>=1.0.1 # Apache-2.0
+positional>=1.1.1 # Apache-2.0
@@ -10 +10 @@ six>=1.9.0 # MIT
-stevedore>=1.16.0 # Apache-2.0
+stevedore>=1.17.1 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index adc760a..7b277d1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -14 +14 @@ oslo.config>=3.14.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0
@@ -17 +17 @@ oslotest>=1.10.0 # Apache-2.0
-os-testr>=0.7.0 # Apache-2.0
+os-testr>=0.8.0 # Apache-2.0
@@ -21,2 +21,2 @@ reno>=1.8.0 # Apache2
-requests-mock>=1.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+requests-mock>=1.1 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
@@ -26 +26 @@ testtools>=1.4.0 # MIT
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT



__
OpenStack Development Mailing 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] [new][keystone] keystonemiddleware 4.10.0 release (ocata)

[no-reply]

We are stoked to announce the release of:

keystonemiddleware 4.10.0: Middleware for OpenStack Identity

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/keystonemiddleware

Download the package from:

https://pypi.python.org/pypi/keystonemiddleware

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 4.9.0..4.10.0
---

b8024ff Return and use an app wherever possible
6a5ef48 Refactor audit tests to use create_middleware
98b639a Use oslo_messaging conf fixture
23808e1 Extract oslo_messaging specific audit tests
2892744 Use the mocking fixture in notifier tests
d1f8a4f Updated from global requirements
6ced68d Use method constant_time_compare from oslo.utils
f2792d7 Raise NotImplementedError instead of NotImplemented
3e95edf Updated from global requirements
aab9c28 Updated from global requirements
cbe9acc standardize release note page ordering
7ed7511 Update reno for stable/newton
c43c8e4 Globalize authentication failure error
b347acf Updated from global requirements


Diffstat (except docs and test files)
-

keystonemiddleware/auth_token/__init__.py  |   5 +-
keystonemiddleware/auth_token/_memcache_crypt.py   |  27 +-
releasenotes/source/index.rst  |   1 +
releasenotes/source/newton.rst |   6 +
requirements.txt   |   4 +-
test-requirements.txt  |   5 +-
14 files changed, 311 insertions(+), 339 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 2bf8572..98244b8 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ oslo.config>=3.14.0 # Apache-2.0
-oslo.context>=2.6.0 # Apache-2.0
+oslo.context>=2.9.0 # Apache-2.0
@@ -12 +12 @@ pbr>=1.6 # Apache-2.0
-positional>=1.0.1 # Apache-2.0
+positional>=1.1.1 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 97b9086..2845998 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ pycrypto>=2.6 # Public Domain
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0
@@ -15 +15 @@ reno>=1.8.0 # Apache2
-requests-mock>=1.0 # Apache-2.0
+requests-mock>=1.1 # Apache-2.0
@@ -21,0 +22 @@ python-memcached>=1.56 # PSF
+WebTest>=2.0 # MIT



__
OpenStack Development Mailing 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] FYI, nova plans to have a room at the PTG in February

[Sean Dague]

On 10/10/2016 08:37 AM, Doug Hellmann wrote:

> We had a lot of feedback that the unstructured discussion time from
> the Friday "meetups" at the summits were the most productive time
> for teams, but I'm sure there are quite a few cases like what you
> describe. Maybe the solution is to schedule part, but not all, of
> the PTG time?
> 
> It would be hard to say that a particular day is or is not scheduled,
> because not all teams will have rooms available to them every day.
> We could slice it the other way, though, and say that multi-project
> topics should be scheduled in the morning. That still leaves all
> of the afternoons for less structured discussions. Of course, not all
> teams will necessarily have multi-project topics.
> 
> We could also just say, as I think Thierry was hinting at elsewhere
> in this thread, that each team should publish its own schedule of
> topics using some sort of unconference-like system (notecards on a
> board, etherpad, whatever). That might make it harder to resolve
> conflicts, though.
> 
> What do other folks think?

I feel like when we went down this path for the PTG, one of the
assurances was that it would be unstructured time, like the midcycles,
which is very productive. Having a long running etherpad is fine (and
kind of expected), but I think building timeboxing in before the event
seems odd.

There are so many unknowns here, but taking away one of the primary
things that made midcycles productive for people in teams, to optimize
for track hopping, seems odd.

If there are topics that span teams, there are 2 days up front. Ensuring
there is space to expand topics into there would be good, and not just
make those horizontal effort days.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][elections] Results of the TC Election

[John Davidge]

On 10/10/16, 5:36 AM, Monty Taylor wrote:

>It's really nice to see that we had an increase in turnout percentage
>even in the face of having our largest electorate yet.
>
>Thanks for all your great work!!!
>
>Monty

+100

Thank you as well to all the candidates and standing TC members who took
part in this process. The past few weeks have really opened my eyes to
what our TC deals with day-to-day, and the huge amount of work that goes
into making things run smoothly.

Special thanks to Thierry and Doug in particular for what was at times a
heated debate. I have a lot to learn from you both about keeping a level
head on the ML :)

Cheers and congrats,

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

__
OpenStack Development Mailing 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] [Glance] [stable] Bug backports

[Ian Cordasco]

-Original Message-
From: Ian Cordasco 
Reply: Ian Cordasco 
Date: October 7, 2016 at 08:47:19
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [Glance] [stable] Bug backports

> Hi Glancers!
>
> After the news that we all released Newton yesterday, it's time to start 
> thinking about
> backports the future of our Mitaka and Liberty branches.
>
> I expect that Mitaka will start to enter Phase II [1] and Liberty's 
> end-of-life is right
> around the corner [2] (2016-11-17). If there are bugs that are affecting 
> those branches
> that need to be backported before their status changes, they should be 
> proposed immediately
> and brought up at the Glance team meeting [3].
>
> [1]: http://docs.openstack.org/project-team-guide/stable-branches.html
> [2]: https://releases.openstack.org/
> [3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting


In case you missed it, Friday the 14th (October 2016) the stable team
is moving Mitaka to Phase II and Liberty to Phase III [1].

Please respond to this message with bugs and backport reviews that
should land prior to Mitaka entering Phase II.

[1]: http://lists.openstack.org/pipermail/openstack-dev/2016-October/105302.html

Cheers,
--
Ian Cordasco

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

Re: [openstack-dev] [openstack-infra] gerrit branch

[Gary Kotton]

Thanks! That worked. Much appreciated

On 10/10/16, 3:39 PM, "Doug Hellmann"  wrote:

Excerpts from Gary Kotton's message of 2016-10-10 12:26:24 +:
> Hi,
> Maybe someone can help out here. We are trying to create an initial 
release for vmware-nsxlib. I am following the instructions on 
http://docs.openstack.org/infra/manual/creators.html
> When I try and push the tag I get:
> 
> gkotton@ubuntu:~/vmware-nsxlib$ git push gerrit 0.1.0
> fatal: 'gerrit' does not appear to be a git repository
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> gkotton@ubuntu:~/vmware-nsxlib$ git branch -a
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/master
> 
> Any idea what is missing?
> Thanks
> Gary

I don't see a remote/gerrit/master in that list of branches. It
looks like your gerrit remote isn't set up. Try "git review -s" to
initialize the repo to talk to gerrit, and then re-run the "git
push" command you have there.

Doug

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


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

Re: [openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

[Duncan Thomas]

If we can get them running on cinder patches via a different job, then
removing them from the common job afterwards seems reasonable.

There's no strong will to remove them, several libraries still use them,
and given we're now supporting /all/ other API versions indefinitely,
keeping them around isn't that much of a burden.

On 10 October 2016 at 15:32, Jordan Pittier 
wrote:

> Hi,
> I'd like to reduce the duration of a full Tempest run and I noticed that
> Cinder tests take a good amount of time (cumulative time 2149sec vs 2256sec
> for Nova, source code [0])
>
> So I'd like to not run the Cinder v1 tests anymore, at least on the master
> branches.
>
> I remember that Cinder  v1 is deprecated (it has been for what, 2 years ?)
> Is the removal scheduled ? I don't see/feel a lot of efforts toward that
> removal but I may be missing something. Any way, that's not really my
> business but it's not really fair to all the projects that run the "common
> jobs" that Cinder "slows" everyone down.
>
> What do you think ?
>
> [0] : https://github.com/JordanP/openstack-snippets/blob/
> master/tempest-timing/tempest_timing.py
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-- 
Duncan Thomas
__
OpenStack Development Mailing 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] [telemetry] Telemetry presence at PTG in February

[Julien Danjou]

Hi team,

I'd like to know if members and supporters of the Telemetry team would
like to request a space in February 2017 during the next PTG¹ in
Atlanta.

It may be hard to schedule enough in advance, but if you got a feeling
whether you'll be there and want to discuss some things, it's time to
say so.

¹  http://www.openstack.org/ptg

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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] [openstack-infra] gerrit branch

[Doug Hellmann]

Excerpts from Gary Kotton's message of 2016-10-10 12:26:24 +:
> Hi,
> Maybe someone can help out here. We are trying to create an initial release 
> for vmware-nsxlib. I am following the instructions on 
> http://docs.openstack.org/infra/manual/creators.html
> When I try and push the tag I get:
> 
> gkotton@ubuntu:~/vmware-nsxlib$ git push gerrit 0.1.0
> fatal: 'gerrit' does not appear to be a git repository
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> gkotton@ubuntu:~/vmware-nsxlib$ git branch -a
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/master
> 
> Any idea what is missing?
> Thanks
> Gary

I don't see a remote/gerrit/master in that list of branches. It
looks like your gerrit remote isn't set up. Try "git review -s" to
initialize the repo to talk to gerrit, and then re-run the "git
push" command you have there.

Doug

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Doug Hellmann]

Excerpts from Duncan Thomas's message of 2016-10-10 14:47:12 +0300:
> On 7 October 2016 at 19:53, Clint Byrum  wrote:
> 
> >
> > My hope was that it would be "the summit without the noise". Sounds like
> > it will be "the summit without the noise, or the organization".
> >
> > I'd really like to see time boxes for most if not all of it, even if many
> > of the boxes are just half a day of "work time" which means "we want to
> > work on stuff together without the overhead of less involved participants."
> >
> > The two days of cross project is awesome. But there are also big
> > single-project initiatives that have cross-project interest anyway.
> >
> > For instance, the movement of the scheduler out of Nova is most definitely
> > a Nova session, but it has ramifications for oslo, performance, neutron,
> > cinder, architecture, API-WG, etc.  etc. If we don't know when Nova is
> > going to discuss it, how can we be there to influence that discussion?
> 
> 
> I've got to agree entirely here. I am mostly interested in cinder stuff,
> but I've interest and a stake in specific nova and glance topics... getting
> involved in those is going to be impossible without some sort of schedule.
> 

We had a lot of feedback that the unstructured discussion time from
the Friday "meetups" at the summits were the most productive time
for teams, but I'm sure there are quite a few cases like what you
describe. Maybe the solution is to schedule part, but not all, of
the PTG time?

It would be hard to say that a particular day is or is not scheduled,
because not all teams will have rooms available to them every day.
We could slice it the other way, though, and say that multi-project
topics should be scheduled in the morning. That still leaves all
of the afternoons for less structured discussions. Of course, not all
teams will necessarily have multi-project topics.

We could also just say, as I think Thierry was hinting at elsewhere
in this thread, that each team should publish its own schedule of
topics using some sort of unconference-like system (notecards on a
board, etherpad, whatever). That might make it harder to resolve
conflicts, though.

What do other folks think?

Doug

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

[openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

[Jordan Pittier]

Hi,
I'd like to reduce the duration of a full Tempest run and I noticed that
Cinder tests take a good amount of time (cumulative time 2149sec vs 2256sec
for Nova, source code [0])

So I'd like to not run the Cinder v1 tests anymore, at least on the master
branches.

I remember that Cinder  v1 is deprecated (it has been for what, 2 years ?)
Is the removal scheduled ? I don't see/feel a lot of efforts toward that
removal but I may be missing something. Any way, that's not really my
business but it's not really fair to all the projects that run the "common
jobs" that Cinder "slows" everyone down.

What do you think ?

[0] :
https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py

-- 
 

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

[openstack-dev] [openstack-infra] gerrit branch

[Gary Kotton]

Hi,
Maybe someone can help out here. We are trying to create an initial release for 
vmware-nsxlib. I am following the instructions on 
http://docs.openstack.org/infra/manual/creators.html
When I try and push the tag I get:

gkotton@ubuntu:~/vmware-nsxlib$ git push gerrit 0.1.0
fatal: 'gerrit' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

gkotton@ubuntu:~/vmware-nsxlib$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Duncan Thomas]

On 7 October 2016 at 19:53, Clint Byrum  wrote:

>
> My hope was that it would be "the summit without the noise". Sounds like
> it will be "the summit without the noise, or the organization".
>
> I'd really like to see time boxes for most if not all of it, even if many
> of the boxes are just half a day of "work time" which means "we want to
> work on stuff together without the overhead of less involved participants."
>
> The two days of cross project is awesome. But there are also big
> single-project initiatives that have cross-project interest anyway.
>
> For instance, the movement of the scheduler out of Nova is most definitely
> a Nova session, but it has ramifications for oslo, performance, neutron,
> cinder, architecture, API-WG, etc.  etc. If we don't know when Nova is
> going to discuss it, how can we be there to influence that discussion?


I've got to agree entirely here. I am mostly interested in cinder stuff,
but I've interest and a stake in specific nova and glance topics... getting
involved in those is going to be impossible without some sort of schedule.

-- 
Duncan Thomas
__
OpenStack Development Mailing 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] weekly meeting

[Emilien Macchi]

Greetings,

We'll have our weekly meeting tomorrow at 2pm UTC on
#openstack-meeting-alt (freenode).

This is our regular agenda:
https://wiki.openstack.org/wiki/Meetings/TripleO#Regular_agenda

If you have anything outstanding to discuss, please add it to this etherpad:
https://etherpad.openstack.org/p/tripleo-meeting-items

Tomorrow, we'll focus on Newton final release schedule, and OpenStack Summit.


See you tomorrow!
Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Kashyap Chamarthy]

On Fri, Oct 07, 2016 at 03:32:14PM -0500, Matt Riedemann wrote:
> On 10/6/2016 7:58 AM, Kashyap Chamarthy wrote:
> > -
> > We expose the state of the copy job in the XML and forward the READY
> > event from qemu to the users.
> > 
> > A running copy job exposes itself in the xml as:
> > 
> > 
> >   
> >   
> >   
> >   
> > 
> > 
> >   
> >   [...]
> > 
> > 
> > While the ready copy job is exposed as:
> > 
> > 
> >   
> >   
> >   
> >> ready='yes'>
> > 
> > 
> >   
> >   [...]
> > 

[...]

> Thanks for the great libvirtd log analysis, that's really helpful see what's
> going on and where we fail.

Took some time to write that, glad to know that at least one person has
read it :-)

> I've replied in Matthew's patch, which I think we can get in now regardless
> and backport.

Yes, noticed it just now.

> As for the fix, it sounds like mdbooth is going to work on the event
> listener code, which I'm hesitant to backport, but honestly this is such a
> latent broken flow that I don't think we really need to backport any fixes,
> at least for the event listener work to fix this long-term. The swap-volume
> test is disabled by default in Tempest and we enable it in devstack, so we
> can control which CI environments it runs in.
 
Agreed.


Also, maybe you have noticed, given Eric's reply on this thread (and the
upstream libvir-list), it is agreed that virDomainGetBlockJobInfo()
should be fixed "to quit reporting cur==end when ready:false".  This
allows the existing Nova code work correctly without any changes.

Discusion on Eric's reply in this thread:

http://lists.openstack.org/pipermail/openstack-dev/2016-October/105194.html

And upstream libvir-list

https://www.redhat.com/archives/libvir-list/2016-October/msg00347.html

-- 
/kashyap

__
OpenStack Development Mailing 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][cinder] Schedule Instances according to Local disk based Volume?

[Erlon Cruz]

Kevin,

Now that you had a first feedback about the idea, as Jay said, the next
steps is to write a blueprint/spec so other folks in Cinder can better
understand/suggest/vote on what you are proposing.


Erlon

On Sat, Oct 8, 2016 at 12:14 AM, Zhenyu Zheng 
wrote:

> So do we like the idea of "volume based scheduling?"
>
> On Tue, Sep 27, 2016 at 11:39 AM, Joshua Harlow 
> wrote:
>
>> Huang Zhiteng wrote:
>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow >> > wrote:
>>>
>>> Huang Zhiteng wrote:
>>>
>>>
>>> On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow
>>> mailto:harlo...@fastmail.com>
>>> >>
>>>
>>> wrote:
>>>
>>>  Huang Zhiteng wrote:
>>>
>>>  In eBay, we did some inhouse change to Nova so that our
>>> big data
>>>  type of
>>>  use case can have physical disks as ephemeral disk for
>>> this type of
>>>  flavors.  It works well so far.   My 2 cents.
>>>
>>>
>>>  Is there a published patch (or patchset) anywhere that
>>> people can
>>>  look at for said in-house changes?
>>>
>>>
>>> Unfortunately no, but I think we can publish it if there are
>>> enough
>>> interests.  However, I don't think that can be easily adopted
>>> onto
>>> upstream Nova since it depends on other in-house changes we've
>>> done to Nova.
>>>
>>>
>>> Is there any blog, or other that explains the full bunch of changes
>>> that ebay has done (u got me curious)?
>>>
>>> The nice thing about OSS is that if u just get the patchsets out
>>> (even to github or somewhere), those patches may trigger things to
>>> change to match your usecase better just by the nature of people
>>> being able to read them; but if they are never put out there, then
>>> well ya, it's a little hard to get anything to change.
>>>
>>>
>>> Anything stopping a full release of all in-house changes?
>>>
>>> Even if they are not 'super great quality' it really doesn't matter
>>> :)
>>>
>>> Apology for sidetracking the topic a bit.  While we encourage our
>>> engineers to embrace community and open source, I think we didn't do a
>>> good job to actually emphasize that. 'Time To Market' is another factor,
>>> usually a feature requirement becomes deployed service in 2,3 sprint
>>> (4~6 weeks), but you know how much can be done in same amount of time in
>>> community, especially with Nova. :)
>>>
>>
>> Ya, sorry for side-tracking,
>>
>> Overall yes I do know getting changes done in upstream is not a 4-6 week
>> process (though maybe someday it could be). In general I don't want to turn
>> this into a rant, and thankfully I think there is a decent LWN article
>> about this kind of situation already. You might like it :)
>>
>> https://lwn.net/Articles/647524/ (replace embedded linux/kernel in this
>> with openstack and imho it's equally useful/relevant).
>>
>>
>> -Josh
>>
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA] Schema proposal for config file handling for services

[Thomas Bechtold]

Hi,

in the rpm-packaging project we started to package the services and are
currently discussing a possible schema for configuration files and
snippets used by the systemd .service files (but this would also affect
OCF resource agents).
This affects packagers, endusers and config management systems (Chef,
Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
the list.

Most services (at least for SUSE and RDO) are using a single config
(e.g. /etc/nova/nova.conf) when starting the service. Some services
(e.g. neutron services like neutron-l3-agent) use multiple config files.

There are multiple problems with that approach:
- when using a config-mgmt-system, users may want to override a config
option (for a feature that is not yet supported) but the
config-mgmt-system will override the config later again.
- when users adjust /etc/$service/$service.conf and a release update is
done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
overridden. That's good because the user changed something but otoh the
file (with all it's config options and comments) is no longer correct.
- when config-mgmt-systems use templates for the $service.conf file,
updating theses templates is a lot of work.
- setting configuration options per service (let's say cinder-volume
needs other config options than cinder-api) is not possible.

So here's the proposal to fix theses problems. The proposal is based on
what RDO is already doing with neutron and extends it a bit. Let's do it
for Nova as an example:

- /usr/share/nova/nova-dist.conf
This is the configuration file a distribution (openSUSE, RDO, ...) can
modify. It must not be modified by endusers and will be overridden with
package updates

- /etc/nova/nova.conf
This is an empty file . Users/config-mgmt-systems can modify it and it
will not be overridden (if changed) with a package update.

- /etc/nova/conf.d/common/
In this directory, config snippets can be added. By convention,
config-mgmt-systems would install files starting with 100-XXX.conf,
endusers would install files starting with 500-XXX.conf . Also this
directory is used by all services (nova-api, nova-compute, ...).

- /etc/nova/conf.d/$service/ (e.g. /etc/nova/conf.d/nova-compute/)
Also a dir for config snippets (with same rules as for
/etc/nova/conf.d/common/ ) but this dir is only used by $service (in
this case nova-compute)

- /usr/share/doc/packages/openstack-nova/nova.conf.sample
The unmodified sample config from upstream

- /etc/nova/README
Explaining the configuration structure and where to find the whole
sample config.


So starting nova-api would be:
nova-api --config-file /usr/share/nova/nova-dist.conf
 --config-file /etc/nova/nova.conf
 --config-dir /etc/nova/conf.d/common/
 --config-dir /etc/nova/conf.d/nova-api/


The order of command line switches (--config-file/--config-dir) is
important here. Also --config-dir is ordering the files. So adding a
config snippet to /etc/nova/conf.d/nova-api/ with
e.g. [DEFAULT]bind_port would override the option from the previous
configs (last found option wins).


Feedback very welcome!

Cheers,

Tom

__
OpenStack Development Mailing 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] Getting the UI to talk with Undercloud API service endpoints

[Julie Pichon]

On 7 October 2016 at 20:30, Dan Sneddon  wrote:
> Do you know how awesome it would be if you put this idea into a Blueprint at
> http://blueprints.launchpad.net? That would be super-awesome.
> File it under tripleo-ui project here if you have a few minutes:
>
> https://blueprints.launchpad.net/specs/+new

That does sound awesome! Slight correction: from Ocata the tripleo-ui
blueprints should live in the 'tripleo' Launchpad project as well [1],
the other tracker is/will be deprecated.

Additional thoughts:

> - Original Message -
>> Hi -
>>
>> Great suggestions, Dan.
>>
>> To recap, we followed that up with a few other ideas on irc and we eventually
>> came to a point to test some of this, with slight modification.
>>
>> UI also ships with a configuration file that can override the endpoint
>> information received from Keystone. The file is located at
>> /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js.
>>
>> Part of making this work means enabling SSL on the Undercloud when the UI
>> component is selected for installation in undercloud.conf. I think this is
>> going to be a pretty reasonable request, but I'm interested in hearing
>> feedback from this, and what other implications it may have, that I can't
>> think of. The changes I made were all one-off, unmanaged changes, just to
>> test this idea out. I'll be doing some more tests but will probably be
>> looking for acceptance shortly.

Just a note that the UI is currently installed by default on the
undercloud. So this may mean either the undercloud becomes SSL by
default, or that we need to switch the UI to not being installed by
default.

>> Once SSL was enabled on the Undercloud, I made two edits to haproxy.cfg that
>> were pretty straightforward: added a 'listen' server directive for UI to
>> both terminate SSL and forward the request to Apache, and added a 'bind'
>> statement for each service that UI expects to talk to (keystone, heat,
>> ironic, mistral, swift, zaqar-websocket).
>>
>> Once those configuration changes were made, I had a very pleasant experience
>> using the UI. It worked exactly as expected. I think this might be a viable
>> option.
>>
>> Thoughts?

Exciting stuff! Thank you for looking into this and I look forward to
seeing the blueprint. I'm happy to try and give a hand with
implementing/testing the changes to get this done as well.

Thanks,

Julie

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101747.html

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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Flavio Percoco]

On 10/10/16 00:36 -0400, Monty Taylor wrote:

On 10/09/2016 07:58 PM, Tony Breeds wrote:

On Mon, Oct 10, 2016 at 10:49:12AM +1100, Tony Breeds wrote:

Please join me in congratulating the 6 newly elected members of the TC.

Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Monty Taylor (mordred)
Sean Dague (sdague)
Steve Martinelli (stevemar)


Full results: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010


Following up on this  Here are some statistics for this election:

+--+---+---+---+
| Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta %) |
+--+---+---+---+
|  10/2013 |   1106  (nan) |   342   (nan) | 30.92   (nan) |
|  04/2014 |   1510  (  36.53) |   448   (  30.99) | 29.67   (  -4.05) |
|  10/2014 |   1893  (  25.36) |   506   (  12.95) | 26.73   (  -9.91) |
|  04/2015 |   2169  (  14.58) |   548   (   8.30) | 25.27   (  -5.48) |
|  10/2015 |   2759  (  27.20) |   619   (  12.96) | 22.44   ( -11.20) |
|  04/2016 |   3284  (  19.03) |   652   (   5.33) | 19.85   ( -11.51) |
|  10/2016 |   3517  (   7.10) |   801   (  22.85) | 22.78   (  14.71) |
+--+---+---+---+

Election CIVS links
 10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
 04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
 10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
 04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
 10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010

It's interesting to note that we increased voter turnout this election,
perhaps as a side effect of the complications with emailing the ballots?


Not that I want to put any more stress on our friends over at Cornell -
I'd be curious to see what effect re-sending ballots every day of the
period would have on turnout. It's not a particularly easy thing to do a
meaningful double-blind test of, of course.


If it's possible, I'd advocate for this. With such a large community, it's
sometimes better to over-communicate. We all get many emails, we are all humans
and we can miss some of the emails we get.

Cheers,
Flavio


It's really nice to see that we had an increase in turnout percentage
even in the face of having our largest electorate yet.

Thanks for all your great work!!!

Monty







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



--
@flaper87
Flavio Percoco


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] [glance] priorities for the next two weeks

[Flavio Percoco]

Hey Brian,

Thanks for sending the summary out. Top-posting since it's kinda unrelated to
the list of topics below.

Are the cycle priorities going to be documented as we did in Mitaka?

https://github.com/openstack/glance-specs/tree/master/priorities

I'd personally advice for this. It'd be better to have this in a place where
other members of the community can easily go to.

Flavio

On 07/10/16 18:50 +, Brian Rosmaita wrote:

I'd like to reiterate what we discussed during the "Core Awareness" topic
at yesterday's Glance weekly meeting for those who weren't able to attend
or read through the meeting logs yet.

Three Ocata priorities have already been determined:
(1) image import refactor
(2) community images (including image 'visibility' enhancements)
(3) rolling upgrades, specifically the database strategy for zero-downtime
upgrades

There's a sub-team working on image import (weekly sync in
#openstack-glance at 14:00 UTC).

Any cores not working on image import, please direct your attention to
community images:
- https://review.openstack.org/369110

- https://review.openstack.org/366354
- https://review.openstack.org/379852
With timely reviews, we may be able to land this before the summit.
Additionally, it's important to have the code merged so for the sub-team
working on rolling upgrades, so they can demonstrate how the strategy will
work on a real-life migration.

As far as rolling upgrades reviews go, there are a lot of comments on the
database strategy spec, but not many of these are from Glance cores.  It
would be good to take a look to sanity check the strategy being proposed:
- https://review.openstack.org/#/c/331740/
Additionally, there's a patch for moving db migrations from
SQLAlchemy-migrate to Alembic:
- https://review.openstack.org/#/c/374278/
And a patch up to make the switch to Alembic:
- https://review.openstack.org/#/c/382958/
Please take the time to look these over.  If you have reservations about
the move to Alembic, now's the time to make them heard.

So, those are the Glance priorities for the next two weeks.

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


--
@flaper87
Flavio Percoco


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] [cinder] How to retrieve volume_driver

[Gorka Eguileor]

On 07/10, cr...@interia.pl wrote:
> Hi Erlon.
>
> Thank you for the reply. I need to collect this information to generate sort 
> of overview of drivers used in given environment. Obviously, it potentially 
> is a multiple backed one. This information does not need to be pulled from 
> the cinder API - I can assume I work under root on host on which cinder 
> service is running.
>
> Parsing of cinder.conf comes with usual problems related to trying to get 
> runtime information from config file. It is very prone to suddenly stop 
> working due to changes in OpenStack itself. We may also potentially run into 
> a situation in which config file has been modified, but Cinder has not been 
> restarted (or worse, file is currently being edited and we read garbage). 
> Now, if it comes to that I can live with those problems, but I was hoping a 
> cleaner solution exists (as mentioned earlier - volume_backend_name, defined 
> in same config, is very easy to retrieve).
>
> Thanks again and best regards,
> Lukasz
>

Hi Lukasz,

Every approach I can think of has its own disadvantages, so you should
evaluate which disadvantages you can live with:

- Reading from the configuration with a Python script using cinder,
  oslo_config, or manually.  This has the out of sync issues you
  mentioned.

- Reading it from Cinder's log files, this requires that the volume
  service is running in debug log level.

- Patching Cinder to add a new API to get this information.  This means
  you have custom code and your data collecting program doesn't work
  with standard Cinder services.

- Using GDB 7 and later, that supports extending GDB with Python, to get
  this information from the running service.  This has a couple of
  disadvantages, one is you have to be really careful with what you are
  doing since you could "break" the running Cinder service, and the
  other disadvantage is that it will pause the whole service while you
  attach, get the info and detach from the service.  I will be talking
  about how to do this sort of thing in a Barcelona Summit talk [1]
  showcasing a case where the benefits outweigh the risks.

Cheers,
Gorka.

[1]: 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15159/cinder-always-on-reliability-and-scalability-guide


> Użytkownik "Erlon Cruz"  napisał(a):
> > Temat: Re: [openstack-dev] [cinder] How to retrieve volume_driver
> > Data: 2016-10-07 14:19
> > Nadawca: "Erlon Cruz" 
> > Adresat: "OpenStack Development Mailing List (not for usage questions)" 
> > ;
> >
> > Hi Luzasz, 
> > This information (volume_driver) is only used on driver loading so, its not 
> > available outside Cinder context. Can you tell how and why you need that? 
> > And why parsing the conf file is not enough for you?
> > Erlon
> > On Fri, Oct 7, 2016 at 9:05 AM,   wrote:
> > Dear all.
> >
> >
> > I'm a PHD student from Poland and have found out about this list from 
> > Openstack wiki. Could you kindly tell me, if there is a way to retrieve, 
> > from outside of OpenStack code, volume_driver for given backend? Preferably 
> > - without a need to parse the cinder.conf file?
> >
> >
> > It is fairly easy to retrieve the volume_backend_name, which in most 
> > scenarios seems to describe the driver type used. However, in general 
> > scenario, this is just a custom string entered by the admin. I would 
> > greatly appreciate, if someone could point me to a way to acquire the 
> > unique stirng, identifying the driver type used - the ona that is passed as 
> > volume_driver in cinder.conf.
> >
> >
> > Thank you in advance for your time.
> >
> >
> > Best regards,
> >
> > Lukasz
> >
> > __
> >
> > OpenStack Development Mailing 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] [ironic][neutron] ML2 plugin for Ironic needs

[Vasyl Saienko]

Hello Community,

Ironic and Neutron projects have become integrated even closer with
multitenancy implementation in Ironic.

There are 2 bugs that require separate ML2 driver specifically for Ironic
needs:


   -

   Booting ironic instance, Neutron port remains in down state [0]
   -

   Ironic needs to synchronize port status change events with Neutron [1]


I was told (commented) that keeping code in Neutron tree is not right
approach [2]. Of course I agree that Neutron has powerful and flexible
support of out-of-tree ML2 drivers and such functionality must be a
separate ML2 plugin.

So the question to consult with the whole community:

Do we need a new networking-ironic-* ML2 driver?

To fix [0] and [1] we can use existing networking-generic-switch [3] ML2
driver [4,5]. It was designed specially for Ironic case. It already helps
us to test Ironic multitenancy on the gates.

My team would prefer supporting one driver without multiplying entities.

[0] https://bugs.launchpad.net/neutron/+bug/1599836

[1] https://bugs.launchpad.net/ironic/+bug/1304673

[2] https://bugs.launchpad.net/neutron/+bug/1610898

[3] https://github.com/openstack/networking-generic-switch

[4] https://review.openstack.org/357779

[5] https://review.openstack.org/357780


Sincerely,
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] [nova] Getting DetachedInstanceError from sqlalchemy on instance.get_by_uuid()

[Michał Dulko]

On 10/07/2016 11:04 PM, Beliveau, Ludovic wrote:
>
> Hi all,
>
>  
>
> In kilo (yeah I know it’s an old release, but still :)), I was getting
> a nova errors for DetachedInstanceError on instance.get_by_uuid().
>
>  
>



>  
>
> Has anybody seen this issue before or something similar ?
>
>  
>
> Thanks for the help,
>
> /ludovic
>

Take a look on post [1]. Looks like this was improved in Oslo in Kilo
and adopted in Nova in Mitaka [2].

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104857.html\
[2]  https://blueprints.launchpad.net/nova/+spec/new-oslodb-enginefacade


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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Maish Saidel-Keesing]

I would also like to add my deepest gratitude for all your hard work
that goes into this process every six months.

Thank you, all of you for all the hard work that goes on behind the
scenes to make this possible

Congratulations to all the re-elected and newly elected members of the TC.


-- 
Best Regards,
Maish Saidel-Keesing

On 10/10/16 02:49, Tony Breeds wrote:
> Please join me in congratulating the 6 newly elected members of the TC.
>
> Doug Hellmann (dhellmann)
> Emilien Macchi (emilienm)
> Jeremy Stanley (fungi)
> Monty Taylor (mordred)
> Sean Dague (sdague)
> Steve Martinelli (stevemar)
>
>
> Full results: 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
>
> Thank you to all candidates who stood for election, having a good group of
> candidates helps engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to 
> ensure
> your voice is heard.
>
> Thank you for another great round.
>
> Here's to Ocata!
>
> 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-dev] [Tacker] Presence at PTG Atlanta

[Sripriya Seetharam]

Hi Tackers,

As you all know, the first PTG meetup (Pike cycle) is happening at Atlanta, Feb 
20-24, 2017. This is as per the new format starting after Barcelona conference, 
where design summit happens in between two OpenStack conferences. Please read 
[1] for more details. I believe our traditional virtual mid cycle meetups have 
been effective for project scoping and discussions and we could have something 
similar for design summit. We can discuss in the upcoming Tacker weekly meeting 
and also in mailing list to provide our decision.

Thanks,
Sripriya

[1] https://www.openstack.org/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