[openstack-dev] [kolla] Rabbitmq keeps restarting

[Xu Yun]

Hello,

I’m trying to deploy a stack using kolla, and it always fail because the
rabbitmq containers keep restarting.
The following is information of my environment:
- 3 controller nodes, 6 compute notes and 5 storage nodes
- CentOS 7.3 1611
- docker was 17.05.0-ce, switched to 1.12.6 already, devicemapper with
direct-lvm mode
- Ocata binary images built at 2017-09-07
- kolla-ansible 4.0.2
- no log found in log volume
- docker logs rabbitmq
=INFO REPORT 14-Sep-2017::11:54:44 ===
Clusterer stopping node now.
INFO:__main__:Loading config file at
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Copying service configuration files
INFO:__main__:Deleting file /etc/rabbitmq/rabbitmq-env.conf
INFO:__main__:Coping file from
/var/lib/kolla/config_files/rabbitmq-env.conf to
/etc/rabbitmq/rabbitmq-env.conf
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq-env.conf owner to
rabbitmq:rabbitmq
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq-env.conf permission
to 0600
INFO:__main__:Deleting file /etc/rabbitmq/rabbitmq.config
INFO:__main__:Coping file from
/var/lib/kolla/config_files/rabbitmq.config to /etc/rabbitmq/rabbitmq.config
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq.config owner to
rabbitmq:rabbitmq
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq.config permission to
0600
INFO:__main__:Deleting file /etc/rabbitmq/rabbitmq-clusterer.config
INFO:__main__:Coping file from
/var/lib/kolla/config_files/rabbitmq-clusterer.config to
/etc/rabbitmq/rabbitmq-clusterer.config
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq-clusterer.config
owner to rabbitmq:rabbitmq
INFO:__main__:Setting file /etc/rabbitmq/rabbitmq-clusterer.config
permission to 0600
INFO:__main__:Deleting file /etc/rabbitmq/definitions.json
INFO:__main__:Coping file from
/var/lib/kolla/config_files/definitions.json to
/etc/rabbitmq/definitions.json
INFO:__main__:Setting file /etc/rabbitmq/definitions.json owner to
rabbitmq:rabbitmq
INFO:__main__:Setting file /etc/rabbitmq/definitions.json permission to
0600
INFO:__main__:Writing out command to execute
INFO:__main__:Setting permission for /var/lib/rabbitmq
INFO:__main__:Setting permission for /var/lib/rabbitmq/mnesia
INFO:__main__:Setting permission for /var/lib/rabbitmq/.erlang.cookie
INFO:__main__:Setting permission for /var/lib/rabbitmq/mnesia/rabbit.pid
INFO:__main__:Setting permission for
/var/lib/rabbitmq/mnesia/rabbit-cluster.config
INFO:__main__:Setting permission for /var/log/kolla/rabbitmq
Running command: '/usr/sbin/rabbitmq-server'

=INFO REPORT 14-Sep-2017::11:58:11 ===
Clusterer stopping node now.

Would please give me some hints how to deal with this problem? Thank you.

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

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Akihiro Motoki]

+1 thanks for organizing this

2017-09-12 17:23 GMT-06:00 Miguel Lavalle :
> Dear Neutrinos,
>
> Our social event will take place on Thursday September 12th at 7:30pm. The
> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
> minutes walk.
>
> I have a reservation for a group of 30 people under my name. Please respond
> to this message with your attendance confirmation by Wednesday night, so I
> can get a more accurate head count.
>
> Looking forward to see y'all Thursday night
>
> Best regards
>
> Miguel
>
> __
> OpenStack Development Mailing 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] [ptg] Simplification in OpenStack

[Samuel Cassiba]

On Tue, Sep 12, 2017 at 3:53 PM, Boris Pavlovic  wrote:
> Mike,
>
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described in
> the etherpad mostly..

This is exactly how one gets started, though, by dragging the
skeletons to light. I, too, was unable to attend due to scheduling,
but as PTL of a project complicated by years of tech debt, before even
being an anointed OpenStack project, this topic is of particular
interest to me.

>
> TC should work on shrinking the OpenStack use cases and moving towards the
> product (box) complete solution instead of pieces of bunch barely related
> things..

I agree and disagree with what you say here. Shrinking use cases
misses the mark an order of magnitude or three. However, focusing on
the outcome is exactly what needs to happen for everyone to walk away
with the warm fuzzies, upstream and downstream alike.

>
> Simple things to improve:
> This is going to allow community to work together, and actually get feedback
> in standard way, and incrementally improve quality.
>
> 1) There should be one and only one:
> 1.1) deployment/packaging(may be docker) upgrade mechanism used by everybody
> 1.2) monitoring/logging/tracing mechanism used by everybody
> 1.3) way to configure all services (e.g. k8 etcd way)
> 2) Projects must have standardize interface that allows these projects to
> use them in same way.
> 3) Testing & R should be performed only against this standard deployment

You keep using that word. This feels like a "you can have it any color
you like, so long as it's black" argument. This is great for
manufacturing tangible products that sit on a shelf somewhere. Not so
much for a collection of software, already well into the maturation
phase, that is the collective output of hundreds, nay, thousands of
minds. What you propose almost never happens in practice, as nice as
it sounds. The outcome is significantly more important than what
people to do get there. I hereby refer to XKCD rule #927 on the topic
of standards, only partly in jest.

>
> Hard things to improve:
>
> OpenStack projects were split in far from ideal way, which leads to bunch of
> gaps that we have now:
> 1.1) Code & functional duplications:  Quotas, Schedulers, Reservations,
> Health checks, Loggign, Tracing, 

Yup. Large software projects have some duplication, it's natural and
requires occasional love. It takes people to actively battle the tech
debt, and not everyone has the luxury of a fully dedicated team.

> 1.2) Non optimal workflows (booting VM takes 400 DB requests) because data
> is stored in Cinder,Nova,Neutron

SQL is SQL, though, so I don't see what you're getting at. I'm sure
some things need some tuning and queries need some optimization, but I
hung up my DBA hat years ago.

> 1.3) Lack of resources (as every project is doing again and again same work
> about same parts)

I read that last part to mean people and not so much technical
limitations. If I've correctly read things with my corporate lens on,
that's a universal pain that is felt by nearly every specialized field
of work, and OpenStack is by no means unique. Downstream consumers of
OpenStack code are only willing to financially support so many
specialists, and they can support more than the Foundation. If the
problem is people, convince more people to contribute, since we're
remaking the universe.

>
> What we can do:
>
> 1) Simplify internal communication
> 1.1) Instead of AMQP for internal communication inside projects use just
> HTTP, load balancing & retries.

In my experiences, AMQP has mostly sat there in the background, until
someone comes along and touches it. We haven't touched the
openstack-ops-messaging cookbook beyond testing enhancements and
deprecations in at least a cycle because it just works. Retries just
mask an underlying problem. With my operator hat on, I don't want my
client to try N times if the service is intermittently failing.

>
> 2) Use API Gateway pattern
> 3.1) Provide to use high level API one IP address with one client
> 3.2) Allows to significant reduce load on Keystone because tokens are
> checked only in API gateway
> 3.3) Simplifies communication between projects (they are now in trusted
> network, no need to check token)

I don't see this as being something to beholden OpenStack development
teams to implement and maintain, even if people pay for this
functionality or implement it on their own. That's more of a use case,
not a feature request.

>
> 3) Fix the OpenStack split
> 3.1) Move common functionality to separated internal services: Scheduling,
> Logging, Monitoring, Tracing, Quotas, Reservations (it would be even better
> if this thing would have more or less monolithic architecture)

No, please, just... no. A monolithic architecture is fine for dev, but
it falls apart prematurely in the lifecycle when you throw the spurs
to it.

> 3.2) 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Boris Pavlovic]

Jay,

All that you say exactly explains the reason why more and more companies
are leaving OpenStack.

Companies and actually end users care only about their things and how can
they get their job done. They want thing that they can run and support
easily and that resolves their problems.

They initially think that it's a good idea to take a OpenStack as a
Framework and build sort of product on top of it because it's so open and
large and everybody uses...

Soon they understand that OpenStack has very complicated operations because
it's not designed to be a product but rather framework and that the
complexity of running OpenStack is similar to development in house solution
and as time is spend they have only few options: move to public cloud or
some other private cloud solution...

We as a community can continue saying that the current OpenStack approach
is the best and keep loosing customers/users/community, or change something
drastically, like bring technical leadership to OpenStack Foundation that
is going to act like benevolent dictator that  focuses OpenStack effort on
shrinking uses cases, redesigning architecture and moving to the right
direction...

I know this all sounds like a big change, but let's be honest current
situation doesn't look healthy...
By the way, almost all successful projects in open source have benevolent
dictator and everybody is OK with that's how things works...


Awesome news. I will keep this in mind when users (like GoDaddy) ask Nova
> to never break anything ever and keep behaviour like scheduler retries that
> represent giant technical debt.


I am writing here on my behalf (using my personal email, if you haven't
seen), are we actually Open Source? or Enterprise Source?

More over I don't think that what you say is going to be an issue for
GoDaddy, at least soon, because we still can't upgrade, because it's NP
complete problem (even if you run just core projects), which is what my
email was about, and I saw the same stories in bunch of other companies.


Yes, let's definitely go the opposite direction of microservices and
> loosely coupled domains which is the best practices of software development
> over the last two decades. While we're at it, let's rewrite OpenStack
> projects in COBOL.


I really don't want to answer on this provocation, because it shifts the
focus from major topic. But I really can't stop myself ;)

- There is no sliver bullet in programming. For example, would Git or Linux
be better if it was written using microservices approach?
- Mircroservices are obsolete you should use new hype thing called FaaS (I
am just curios when these FaaS fellow are going to implement modules for
FaaS and when they are going to understand that they will need actually
everything development in programming languages (OOP, AOP, DI, ...) to glue
these things;) )
- I was talking about architectural changes, not a programming language, so
it's sort of big type mismatch and logically wrong. However, what's wrong
with Cobol? If you use right architecture and right algorithms it will
definitely work better than implementation of program in any other language
with wrong architecture and bad algorithms... so not sure that I understand
this point/joke...


Best regards,
Boris Pavlovic

On Wed, Sep 13, 2017 at 10:44 AM, Jay Pipes  wrote:

> On 09/12/2017 06:53 PM, Boris Pavlovic wrote:
>
>> Mike,
>>
>> Great intiative, unfortunately I wasn't able to attend it, however I have
>> some thoughts...
>> You can't simplify OpenStack just by fixing few issues that are described
>> in the etherpad mostly..
>>
>> TC should work on shrinking the OpenStack use cases and moving towards
>> the product (box) complete solution instead of pieces of bunch barely
>> related things..
>>
>
> OpenStack is not a product. It's a collection of projects that represent a
> toolkit for various cloud-computing functionality.
>
> *Simple things to improve: *
>> /This is going to allow community to work together, and actually get
>> feedback in standard way, and incrementally improve quality. /
>>
>> 1) There should be one and only one:
>> 1.1) deployment/packaging(may be docker) upgrade mechanism used by
>> everybody
>>
>
> Good luck with that :) The likelihood of the deployer/packager community
> agreeing on a single solution is zero.
>
> 1.2) monitoring/logging/tracing mechanism used by everybody
>>
>
> Also close to zero chance of agreeing on a single solution. Better to
> focus instead on ensuring various service projects are monitorable and
> transparent.
>
> 1.3) way to configure all services (e.g. k8 etcd way)
>>
>
> Are you referring to the way to configure k8s services or the way to
> configure/setup an *application* that is running on k8s? If the former,
> then there is *not* a single way of configuring k8s services. If the
> latter, there isn't a single way of configuring that either. In fact,
> despite Helm being a popular new entrant to the k8s application package
> format 

[openstack-dev] Forum Topic Submission

[Shamail Tahir]

Hi Forum Brainstormers,

Wow! Some great topics in the etherpads so far. This event is going to be
amazing.

We're less than a week away now from opening the "formal submission" part
of the process.

If you haven't already, please start prioritizing the top sessions from
your list of ideas. Starting next week, the formal submission will ask for
a written abstract, and one or more session leaders for each session you
want to submit.

Late to the party? Check out the topic brainstorming at:
*https://wiki.openstack.org/wiki/Forum/Sydney2017*


and on a mailing list near you!

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

[openstack-dev] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

[Michał Jastrzębski]

Hello my dearest of communities,

During deployment tools session on PTG we discussed need for deep
health checking and metering of running services. It's very relevant
in context of containers (especially k8s) and HA. Things like
watchdog, heartbeats or exposing relative metrics (I don't want to get
into design here, suffice to say it's non-trivial problem to solve).

We would like to start a "task force", few volunteers from both
deployment tool side (ops, ha) and project dev teams. We would like to
design together a proper health check mechanism for one of projects to
create best practices and design, that later could be implemented in
all other services.

We would to ask for volunteer project team to join us and spearhead this effort.

Regards,
Michal

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

Re: [openstack-dev] [masakari] No IRC meeting this week

[Sam P]

Hi All,

 We are planning to have meeting on Sep 14 Thursday 4:00-5:00pm in
Ballroom C in PTG venue.
 Place and time might change suddenly. In that case I will send
updates to this thread.
--- Regards,
Sampath



On Mon, Sep 11, 2017 at 7:05 PM, Sam P  wrote:
> Hi All,
>
>  As we discussed in our last week IRC meeting, there will be no IRC
> meting today.
> I will check the possible/available space in PTG venue and send
> details for PTG meetup.
> [1] is the agenda for the meeting.
>
> [1] https://etherpad.openstack.org/p/masakari-queens-workitems
> --- Regards,
> Sampath

__
OpenStack Development Mailing 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][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

Thanks for the discussion yesterday.

Some notes about the topics we covered:
- Itroduction ETSI:
  - https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf
- Introduction OpenStack:
  - https://nfvwiki.etsi.org/images/OpenStack_ETSI_NFV_workshop.pdf
- TST003 gaps
  - I will collect user stories for the gaps and collect feedback to make the 
gap desciptions better
- Glare
   - I will help from ETSI NFV side to implement the needed API and descriptions
- Plugtest
  - https://nfvwiki.etsi.org/images/NFV_PoCs_and_Plugtests.pdf
- Collaboration:
  - https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf

Br,
Gerg0


From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Tuesday, September 5, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Pierre Lynch_Internet ; Ildiko Vancsa 
; 'Silvia Almagia' ; Diego 
Lopez_Internet ; Perala, Timo (Nokia - FI/Espoo) 
; Laurent Vreck ; Michele 
CARIGNANI 
Subject: RE: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hi,

We can try to squeeze it into the schedule. Can you collect your discussion 
topics to an etherpad so we can decide on the timing of the timeslot?

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Tuesday, September 5, 2017 3:46 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Yes, It will be even better! I can record a demo and publish it before the 
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) 
> wrote:
Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0


-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017


> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [murano] ptg meetup

[Rong Zhu]

Sure, early in the morning on Friday is OK to me, Paul what about your opinion?
And Felipe, you can chose the time which is suitable for you.



On Wed, Sep 13, 2017 at 4:08 PM, MONTEIRO, FELIPE C  wrote:
> I can only meet early in the morning on Friday, as I fly out around 1:00 PM.
>
> -Original Message-
> From: Rong Zhu [mailto:aaronzhu1...@gmail.com]
> Sent: Wednesday, September 13, 2017 10:46 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [murano] ptg meetup
>
> Friday is OK to me, shall we meet in Colorado Ballroom D after the
> launch about 1:00pm?
> The etherpad for the Murano PTG discuss is here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_murano-2Ddenver-2Dptg=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=t1ipKFe-cgxaN4CjHbutaTPW18FbITdonk4Y28bNQV8=
>
> Regards,
> Rong Zhu
>
>
>
> On Wed, Sep 13, 2017 at 10:17 AM, Paul Bourke  wrote:
>> Hi,
>>
>> Would those of us at the PTG like to agree on a time to meet for an informal
>> Murano chat? Does Friday suit?
>>
>> Regards,
>> -Paul
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=8N05GW-gsXrgV5fYwpJW5yuWQXCoWLkdzZOhnU5uxkQ=
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=8N05GW-gsXrgV5fYwpJW5yuWQXCoWLkdzZOhnU5uxkQ=
> __
> OpenStack Development Mailing 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] [murano] ptg meetup

[MONTEIRO, FELIPE C]

I can only meet early in the morning on Friday, as I fly out around 1:00 PM.

-Original Message-
From: Rong Zhu [mailto:aaronzhu1...@gmail.com] 
Sent: Wednesday, September 13, 2017 10:46 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [murano] ptg meetup

Friday is OK to me, shall we meet in Colorado Ballroom D after the
launch about 1:00pm?
The etherpad for the Murano PTG discuss is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_murano-2Ddenver-2Dptg=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=t1ipKFe-cgxaN4CjHbutaTPW18FbITdonk4Y28bNQV8=
 

Regards,
Rong Zhu



On Wed, Sep 13, 2017 at 10:17 AM, Paul Bourke  wrote:
> Hi,
>
> Would those of us at the PTG like to agree on a time to meet for an informal
> Murano chat? Does Friday suit?
>
> Regards,
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=8N05GW-gsXrgV5fYwpJW5yuWQXCoWLkdzZOhnU5uxkQ=
>  

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=99MwOGS8f94dZlR1q8Mw2mkTpOJByI9DK9opxIsq58g=8N05GW-gsXrgV5fYwpJW5yuWQXCoWLkdzZOhnU5uxkQ=
 
__
OpenStack Development Mailing 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] all you need to know for PTG TripleO-related topics

[Tony Breeds]

On Wed, Sep 13, 2017 at 02:07:20PM -0600, John Fulton wrote:
> On Thu, Sep 7, 2017 at 12:32 PM, Emilien Macchi  wrote:
> > If you use Google Calendar, you really want to use this one:
> > https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics
> >
> > Or view in HTML here:
> > https://calendar.google.com/calendar/embed?src=c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com=America/Denver
> >
> > Which contains an updated agenda for TripleO related topics.
> >
> > We'll track everything in this etherpad:
> > https://etherpad.openstack.org/p/tripleo-ptg-queens
> 
> TripleO Schedule Update for Thursday.
> 
> 10:45am - 11:30am: Ceph integration futures
> 3:30pm - 4:30pm: Non x86_64 arch support

This discussion will be a lot more productive if we have someone (some
people ;P) from Ironic in the room.  Dimitry, you've commented on the
bugs and etherpad.  Are you able to be there?

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] [tripleo] all you need to know for PTG TripleO-related topics

[John Fulton]

On Thu, Sep 7, 2017 at 12:32 PM, Emilien Macchi  wrote:
> If you use Google Calendar, you really want to use this one:
> https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics
>
> Or view in HTML here:
> https://calendar.google.com/calendar/embed?src=c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com=America/Denver
>
> Which contains an updated agenda for TripleO related topics.
>
> We'll track everything in this etherpad:
> https://etherpad.openstack.org/p/tripleo-ptg-queens

TripleO Schedule Update for Thursday.

10:45am - 11:30am: Ceph integration futures
3:30pm - 4:30pm: Non x86_64 arch support

The chairs of the above sessions have agreed to trade times. The
etherpad has been updated but not (yet?) the google calendar.

Thanks,
  John (fultonj)

>
> I'm looking forward to seeing you folks!
> Have safe trips,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] Recent Changes in os-testr and migrating to stestr

[Matthew Treinish]

Hi Everyone,

People might have noticed the recently os-testr 1.0.0 was recently released and
made some pretty big changes to the internals of the ostestr script. ostestr was
originally created to replace the local pretty_tox.sh scripts in all the 
projects
with a consistent interface. Because of that the script originally literally 
just
would use subprocess to run testr. However, in the 1.0.0 release this has 
changed
and now uses stestr's python interface to run tests. [1]

stestr[2][3] is a fork of testr I started several months ago. The testrepository
project is pretty much completely inactive at this point and has several long
standing bugs. stestr was started to address these bugs, but also limits the 
scope
to just a parallel python test runner. (instead of a generic test runner runner
like testr is) The best example of the improvements stestr brings fixes the dbm
issue between python versions so you don't have to delete the times.dbm file
anymore between. (but there are a lot of other improvements so far)

So what does this mean for current ostestr users, in most cases not much. The
only external differences are that the repository by default is are to .stestr
instead of .testrepository and ostestr will emit a warning until a .stestr.conf
file is created. This probably means .stestr/ should be added to .gitignore
before too long, but it's not really a blocker. There is an issue with neutron
(and networking-*) functional tests because their post-test-hook runs chmod on
.testrepository unconditionally. This will need to be updated for things to
with the new ostestr version pass.

As for the warning about the .stestr.conf ostestr parses the .testr.conf and
tries to guess the parameters it needs to run, but it's not a perfect process
and that's why adding a .stestr.conf is best. I've seen a couple of cases where
projects were setting custom env variable in the .testr.conf where this process
didn't work and creating a .stestr.conf and adding the env vars to tox.ini was
the only way to address this.

Moving forward I'd like to get everything switched over to using stestr, either
directly or indirectly via ostestr. (although longer term I'd like to see the
ostestr script go away because it doesn't really do anything anymore) This way
we can get everything using an actively maintained test runner.

I'd also like to apologize for the timing of this transition, we originally
intended to just test the waters during the PTG while people were f2f and debug
issues. But, we wanted to wait until after the PTG (for obvious reasons) to make
the big cut over. But, things ballooned kinda quickly and we're now using the 
new
version of ostestr. I'll be around all week at the PTG or on irc to help people
that might be having issues related to the new os-testr release.

Thanks,

-Matt Treinish

[1] https://review.openstack.org/#/c/488441/
[2] https://github.com/mtreinish/stestr
[3] http://stestr.readthedocs.io/en/latest/


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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

We now have an ether pad

https://etherpad.openstack.org/p/contributor-portal

—
Mike Perez

On September 13, 2017 at 11:47:16, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> We’ll be meeting with the Documentation team at the ptg in ballroom c today 
> at 14:30 local
> time to discuss progress. Join us and lets help make our on-boarding 
> experience better
> for new contributors!
>
> —
> Mike Perez
>
> On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
> >
> >
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress bar somewhere to show how close you are 
> > to being ready
> > to contribute to whatever team. Of course there are a lot of other fancy 
> > things we can
> come
> > up with, but I think getting something up as an initial pass would be 
> > better than what
> we
> > have today.
> >
> > Here's an example of what the sections/chapters could look like:
> >
> > - Code
> > * Volumes (Cinder)
> > * IRC
> > * Git
> > * Account Setup
> > * Generating Configs
> > * Compute (Nova)
> > * IRC
> > * Git
> > * Account Setup
> > * Something about hypervisors (matrix?)
> > - Use Cases
> > * Products (Product working group)
> > * IRC
> > * Git
> > * Use Case format
> >
> > There are some rough mock up ideas [4]. Probably Sphinx will be fine for 
> > this. Potentially
> > we could use this content for conference lunch and learns, upstream 
> > university, and
> > the on-boarding events at the Forum. What do you all think?
> >
> > [1] - http://docs.openstack.org/upstream-training/irc.html
> > [2] - http://docs.openstack.org/upstream-training/git.html
> > [3] - http://docs.openstack.org/upstream-training/accounts.html
> > [4] - 
> > https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0
> >
> > —
> >
> > Mike Perez
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] Re?: [Neutron] Denver Team Dinner

[Isaku Yamahata]

+1

On Wed, Sep 13, 2017 at 07:28:31AM -0600,
Thomas Morin  wrote:

> +1
> 
> -Thomas
> 
> 
> Takashi Yamamoto, 2017-09-13 03:05:
> > +1
> > 
> > On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
> >  wrote:
> > > +1
> > > thanks for organizing!
> > > 
> > > On Wed, 13 Sep 2017 14:18:45 +0900,
> > > Brian Haley wrote:
> > > > 
> > > > +1
> > > > 
> > > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > > +1
> > > > > 
> > > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > > wrote:
> > > > > > +1
> > > > > > 
> > > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > > lonski.pl>
> > > > > > wrote:
> > > > > > > 
> > > > > > > +1
> > > > > > > 
> > > > > > > ???
> > > > > > > Best regards
> > > > > > > Slawek Kaplonski
> > > > > > > sla...@kaplonski.pl
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > > com> w dniu
> > > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > > 
> > > > > > > > Dear Neutrinos,
> > > > > > > > 
> > > > > > > > Our social event will take place on Thursday September
> > > > > > > > 12th at 7:30pm.
> > > > > > > > The venue is going to be https://www.famousdaves.com/Denv
> > > > > > > > er-Stapleton. It is
> > > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > > translates to an easy 9
> > > > > > > > minutes walk.
> > > > > > > > 
> > > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > > name. Please
> > > > > > > > respond to this message with your attendance confirmation
> > > > > > > > by Wednesday
> > > > > > > > night, so I can get a more accurate head count.
> > > > > > > > 
> > > > > > > > Looking forward to see y'all Thursday night
> > > > > > > > 
> > > > > > > > Best regards
> > > > > > > > 
> > > > > > > > Miguel
> > > > > > > > 
> > > > > > > > _
> > > > > > > > _
> > > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > > questions)
> > > > > > > > Unsubscribe:
> > > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> > > > > > > > ribe
> > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> > > > > > > > tack-dev
> > > > > > > 
> > > > > > > 
> > > > > > > ___
> > > > > > > ___
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
> > > > > > > ect:unsubscribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
> > > > > > > ck-dev
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _
> > > > > > _
> > > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > > > > > t: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-d
> > > > > ev
> > > > > 
> > > > 
> > > > 
> > > > _
> > > > _
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > > subscribe
> > > > 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:unsu
> > > bscribe
> > > 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: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

-- 
Isaku Yamahata 

__
OpenStack 

Re: [openstack-dev] [nova] [placement] Modeling SR-IOV with nested resource providers

[Chris Dent]

On Wed, 13 Sep 2017, Jay Pipes wrote:

We still need a way to represent a request to placement to find allocation 
candidates for like resources, though. As you pointed out, I've thought about 
using multiple requests to placement from the conductor or scheduler. We 
could also do something like this:


GET 
/allocation_candidates?resources=VCPU:1,MEMORY_MB:1024=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_1=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_2


To clarify, this translates to:

* give me one compute node with 1 VCPU and 1024 MEMORY_MB that has
* 2 vf
  * both on physnet A
  * one on switch 1
  * one on switch 2


--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Denver PTG sessions video

[Miguel Lavalle]

Hi Neutrinos,

We are broadcasting and recording the PTG sessions in Denver. You can watch
live (with a little delay) or you can watch the recorded video at your own
convenience. I am posting the links in the etherpad, lines 62 - 68:
https://etherpad.openstack.org/p/neutron-queens-ptg

Please keep in mind that the times shown in the etherpad are in US Mountain
Daylight Time, which is UTC - 6. We will be announcing the topic we are
covering here:  http://ptg.openstack.org/ptg.html


Best regards

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

Re: [openstack-dev] [nova] [placement] Modeling SR-IOV with nested resource providers

[Jay Pipes]

On 09/05/2017 11:02 AM, Andrey Volkov wrote:

For example, I have SR-IOV PF with four ports (P_i), two of them are
connected to one switch (SW_1) and other two to another (SW_2). I
would like to get VFs from distinct ports connected to distinct
switches (more details can be found in spec [1]), how it can be
modeled with nested resource providers?

Several possible solutions I see:

1)
   --- compute node -
  / /  \ \--
-/ /\\---
   /  /  \   \
  SR-IOV PF SR-IOV PF SR-IOV PF SR-IOV PF
(traits:P1,SW1)  (traits:P2,SW1)   (traits:P3,SW2)   
  (traits:P4,SW2)

 : : : :
/ \   / \   / \   / \
   /   \ /   \ /   \ /   \
VF1VF2VF3VF4VF5VF6VF7VF8


2)
 compute node
   /  \
 /  \
SR-IOV PF   SR-IOV PF
   (traits:SW1)(traits:SW2)
 /  \/  \
/\  /\
   SR-IOV PF SR-IOV PF SR-IOV PF SR-IOV PF
  (traits:P1)   (traits:P2)   (traits:P3)   (traits:P4)
  : : : :
 / \   / \   / \   / \
/   \ /   \ /   \ /   \
 VF1VF2VF3VF4VF5VF6VF7VF8


3) Use tags for inventories, so the problem can be solved without 
complex structures.


Are the described options applicable or there are other to solve the issue?


Hey Andrey, sorry for the long delay in getting back to you on this.

A few points to consider.

First, you would only need to have VFs represented as separate nodes in 
the tree (i.e. separate resource providers) if the VFs had different 
traits associated with them (for instance, if some hardware offloads 
were programmable on some of the VFs but not others).


Secondly, the port should not be a trait. I think perhaps you're 
referring to a physical network as a port, though. If this is the case, 
then yes, you'd want that physical network to be a custom trait (e.g. 
CUSTOM_PHYSNET_INTRANET or something like that).


So, with that said, you're looking instead at a structure like this:

CN
|--> PF1
|--> PF2
|--> PF3
|--> PF4

with the following records in the inventories table:

RPRC  Total
--
CNVCPU4
CNMEMORY_MB   8192
RP1   SRIOV_NET_VF2
RP2   SRIOV_NET_VF2
RP3   SRIOV_NET_VF2
RP4   SRIOV_NET_VF2

and the following in the resource_provider_traits table:

RPTRAIT
---
RP1   CUSTOM_PHYSNET_A
RP1   CUSTOM_SWITCH_1
RP2   CUSTOM_PHYSNET_B
RP2   CUSTOM_SWITCH_1
RP3   CUSTOM_PHYSNET_A
RP3   CUSTOM_SWITCH_2
RP4   CUSTOM_PHYSNET_B
RP4   CUSTOM_SWITCH_2

We discussed yesterday that the Neutron ML2 agent would be responsible 
for inserting trait associations for the resource providers representing 
the SRIOV physical functions.


We still need a way to represent a request to placement to find 
allocation candidates for like resources, though. As you pointed out, 
I've thought about using multiple requests to placement from the 
conductor or scheduler. We could also do something like this:


 GET 
/allocation_candidates?resources=VCPU:1,MEMORY_MB:1024=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_1=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_2


Best,
-jay

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

[openstack-dev] [trove] Please welcome Samuel Matzek, Luke Browning and Manoj Kumar to the Trove core team

[Amrith Kumar]

​Pl​
ease join me in welcoming Samuel Matzek, Luke Browning and Manoj Kumar to
the Trove core team.


-amrith
__
OpenStack Development Mailing 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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hey all,

We’ll be meeting with the Documentation team at the ptg in ballroom c
today at 14:30 local time to discuss progress. Join us and lets help
make our on-boarding experience better for new contributors!

—
Mike Perez

On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
>
>
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Configs
> * Compute (Nova)
> * IRC
> * Git
> * Account Setup
> * Something about hypervisors (matrix?)
> - Use Cases
> * Products (Product working group)
> * IRC
> * Git
> * Use Case format
>
> There are some rough mock up ideas [4]. Probably Sphinx will be fine for 
> this. Potentially
> we could use this content for conference lunch and learns, upstream 
> university, and
> the on-boarding events at the Forum. What do you all think?
>
> [1] - http://docs.openstack.org/upstream-training/irc.html
> [2] - http://docs.openstack.org/upstream-training/git.html
> [3] - http://docs.openstack.org/upstream-training/accounts.html
> [4] - 
> https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0
>
> —
>
> Mike Perez

__
OpenStack Development Mailing 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] [ptg] Simplification in OpenStack

[Jay Pipes]

On 09/12/2017 06:53 PM, Boris Pavlovic wrote:

Mike,

Great intiative, unfortunately I wasn't able to attend it, however I 
have some thoughts...
You can't simplify OpenStack just by fixing few issues that are 
described in the etherpad mostly..


TC should work on shrinking the OpenStack use cases and moving towards 
the product (box) complete solution instead of pieces of bunch barely 
related things..


OpenStack is not a product. It's a collection of projects that represent 
a toolkit for various cloud-computing functionality.



*Simple things to improve: *
/This is going to allow community to work together, and actually get 
feedback in standard way, and incrementally improve quality. /


1) There should be one and only one:
1.1) deployment/packaging(may be docker) upgrade mechanism used by 
everybody


Good luck with that :) The likelihood of the deployer/packager community 
agreeing on a single solution is zero.



1.2) monitoring/logging/tracing mechanism used by everybody


Also close to zero chance of agreeing on a single solution. Better to 
focus instead on ensuring various service projects are monitorable and 
transparent.



1.3) way to configure all services (e.g. k8 etcd way)


Are you referring to the way to configure k8s services or the way to 
configure/setup an *application* that is running on k8s? If the former, 
then there is *not* a single way of configuring k8s services. If the 
latter, there isn't a single way of configuring that either. In fact, 
despite Helm being a popular new entrant to the k8s application package 
format discussion, k8s itself is decidedly *not* opinionated about how 
an application is configured. Use a CMDB, use Helm, use env variables, 
use confd, use whatever. k8s doesn't care.


2) Projects must have standardize interface that allows these projects 
to use them in same way.


Give examples of services that communicate over *non-standard* 
interfaces. I don't know of any.



3) Testing & R should be performed only against this standard deployment


Sorry, this is laughable. There will never be a standard deployment 
because there are infinite use cases that infrastructure supports. 
*Your* definition of what works for GoDaddy is decidedly different from 
someone else's definition of what works for them.



*Hard things to improve: *

OpenStack projects were split in far from ideal way, which leads to 
bunch of gaps that we have now:
1.1) Code & functional duplications:  Quotas, Schedulers, Reservations, 
Health checks, Loggign, Tracing, 


There is certainly code duplication in some areas, yes.

1.2) Non optimal workflows (booting VM takes 400 DB requests) because 
data is stored in Cinder,Nova,Neutron


Sorry, I call bullshit on this. It does not take 400 DB requests to boot 
a VM. Also: the DB is not at all the bottleneck in the VM launch 
process. You've been saying it is for years with no justification to 
back you up. Pointing to a Rally scenario that doesn't reflect a 
real-world usage of OpenStack services isn't useful.


1.3) Lack of resources (as every project is doing again and again same 
work about same parts)


Provide specific examples please.


What we can do:

*1) Simplify internal communication *
1.1) Instead of AMQP for internal communication inside projects use just 
HTTP, load balancing & retries.


Prove to me that this would solve a problem. First describe what the 
problem is, then show me that using AMQP is the source of that problem, 
then show me that using HTTP requests would solve that problem.



*2) Use API Gateway pattern *
3.1) Provide to use high level API one IP address with one client
3.2) Allows to significant reduce load on Keystone because tokens are 
checked only in API gateway
3.3) Simplifies communication between projects (they are now in trusted 
network, no need to check token)


Why is this a problem for OpenStack projects to deal with? If you want a 
single IP address for all APIs that your users consume, then simply 
deploy all the public-facing services on a single set of web servers and 
make each service's root endpoint be a subresource on the root IP/DNS name.



*3) Fix the OpenStack split *
3.1) Move common functionality to separated internal services: 
Scheduling, Logging, Monitoring, Tracing, Quotas, Reservations (it would 
be even better if this thing would have more or less monolithic 
architecture)


Yes, let's definitely go the opposite direction of microservices and 
loosely coupled domains which is the best practices of software 
development over the last two decades. While we're at it, let's rewrite 
OpenStack projects in COBOL.


3.2) Somehow deal with defragmentation of resources e.g. VM Volumes and 
Networks data which is heavily connected.


How are these things connected?


*4) Don't be afraid to break things*
Maybe it's time for OpenStack 2:

  * In any case most of people provide API on top of OpenStack for usage
  * In any case there is no standard and easy way to upgrade 

So 

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Jakub Libosvar]

+1

On 12/09/2017 21:44, Terry Wilson wrote:
> +1
> 
> On Tue, Sep 12, 2017 at 6:23 PM, Miguel Lavalle  wrote:
>> Dear Neutrinos,
>>
>> Our social event will take place on Thursday September 12th at 7:30pm. The
>> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
>> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
>> minutes walk.
>>
>> I have a reservation for a group of 30 people under my name. Please respond
>> to this message with your attendance confirmation by Wednesday night, so I
>> can get a more accurate head count.
>>
>> Looking forward to see y'all Thursday night
>>
>> Best regards
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing 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] [tripleo] TripleO UI and CLI feature parity

[Honza Pokorny]

On 2017-09-13 12:45, Dan Prince wrote:
> On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek  wrote:
> 
> > Hello all,
> >
> > As we are in the planning phase for Queens cycle, I'd like to open the
> > discussion on the topic of CLI (tripleoclient) and GUI (tripleo-ui) feature
> > parity.
> >
> > Two years ago, when TripleO UI was started, it was agreed that in order to
> > provide API for GUI and to achieve compatibility between GUI and CLI, the
> > TripleO business logic gets extracted from tripleoclient into
> > tripleo-common library and it will be provided through Mistral actions and
> > workflows so GUI and other potential clients can use it.
> >
> > The problem:
> >
> > Currently we are facing a recurring problem that when a new feature is
> > added to TripleO it often gets a correctly implemented business logic in
> > form of utility functions in tripleo-common but those are then used
> > directly by tripleoclient. At this point the feature is considered complete
> > as it is integrated in CLI and passes CI tests. The consequences of this
> > approach are:
> >
> > - there is no API for the new feature, so the feature is only usable by CLI
> > - part of the business logic still lives in tripleoclient
> > - GUI can not support the feature and gets behind CLI capabilities
> > - GUI contributors need to identify the new feature, raise bugs [1],
> > feature then gets API support in tripleo-common
> > - API implementation is not tested in CI
> > - GUI and CLI diverges in how that feature is operated as business logic
> > is implemented twice, which has number of negative effects on TripleO
> > functionality (backwards compatibility, upgrades...)
> >
> 
> Nice summary here. I think we do need to be more careful in how we add
> features to python-tripleoclient so that we guard against breaking some of
> the UI use cases. We have guarded some features on this front in the past
> during the review process. When TripleO validations was added for instance
> we were extra careful in how we execute Ansible (via Mistral) so that both
> the UI and CLI could run it.
> 
> 
> >
> > The biggest point of divergence between GUI and CLI is that CLI tends to
> > generate a set of local files which are then put together when deploy
> > command is run whereas GUI operates on Deployment plan which is stored in
> > Swift and accessed through API provided by tripleo-common.
> >
> > The described problem currently affects all of the features which CLI uses
> > to generate files which are used in deploy command (e.g. Roles management,
> > Container images preparation, Networks management etc.) There is no API for
> > those features and therefore GUI can't support them until Mistral actions
> > and workflows are implemented for it.
> >
> > Proposed solution:
> >
> > We should stop considering TripleO as a set of utility scripts used to
> > construct 'deploy' command, we should rather consider TripleO as a
> > deployment application which has its internal state (Deployment plan in
> > Swift) which is accessed and modified via API.
> > TripleO feature should be considered complete when API for it is created.
> > CLI should solely use TripleO business logic through Mistral actions and
> > workflows provided by tripleo-common - same as any other client has to.
> >
> > Results of this change are:
> > - tripleoclient is extremely lightweight, containing no tripleo business
> > logic
> >
> 
> The python-client may be "lightweight" but the downstream packages that
> typically install this are extremely heavy. This is largely due to the
> instack-undercloud requirements that could arguably be split out into a
> separate subpackage. Just a minor nit, that we might consider making the
> package lighter for RPMs as well.
> 
> 
> > - tripleo-common API is tested in CI as it is used by CLI
> > - tripleoclient and tripleo-ui are perfectly compatible, interoperable and
> > its features and capabilities match
> > - TripleO business logic lives solely in tripleo-common and is operated
> > the same way by any client
> > - no new backward compatibility problems caused by releasing features
> > which are not supported by API are not introduced
> > - new features related to Ansible or containers are available to all
> > clients
> > - upgrades work the same way for deployments deployed via CLI and GUI
> > - deployment is replicable without need of keeping the the deploy command
> > and generated files around (exported deployment plan has all the
> > information)
> >
> > Note that argument of convenience of being able to modify deployment files
> > locally is less and less relevant as we are incrementally moving from
> > forcing user to modify templates manually (all the jinja templating,
> > roles_data.yaml, network_data.yaml generation, container images
> > preparation, derive parameters workflows etc.). In Pike we have made
> > changes to simplify the way Deployment plan is stored and it is extremely
> > easy to import and export it 

Re: [openstack-dev] [murano] ptg meetup

[Rong Zhu]

Friday is OK to me, shall we meet in Colorado Ballroom D after the
launch about 1:00pm?
The etherpad for the Murano PTG discuss is here:
https://etherpad.openstack.org/p/murano-denver-ptg

Regards,
Rong Zhu



On Wed, Sep 13, 2017 at 10:17 AM, Paul Bourke  wrote:
> Hi,
>
> Would those of us at the PTG like to agree on a time to meet for an informal
> Murano chat? Does Friday suit?
>
> Regards,
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo] TripleO UI and CLI feature parity

[Dan Prince]

On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek  wrote:

> Hello all,
>
> As we are in the planning phase for Queens cycle, I'd like to open the
> discussion on the topic of CLI (tripleoclient) and GUI (tripleo-ui) feature
> parity.
>
> Two years ago, when TripleO UI was started, it was agreed that in order to
> provide API for GUI and to achieve compatibility between GUI and CLI, the
> TripleO business logic gets extracted from tripleoclient into
> tripleo-common library and it will be provided through Mistral actions and
> workflows so GUI and other potential clients can use it.
>
> The problem:
>
> Currently we are facing a recurring problem that when a new feature is
> added to TripleO it often gets a correctly implemented business logic in
> form of utility functions in tripleo-common but those are then used
> directly by tripleoclient. At this point the feature is considered complete
> as it is integrated in CLI and passes CI tests. The consequences of this
> approach are:
>
> - there is no API for the new feature, so the feature is only usable by CLI
> - part of the business logic still lives in tripleoclient
> - GUI can not support the feature and gets behind CLI capabilities
> - GUI contributors need to identify the new feature, raise bugs [1],
> feature then gets API support in tripleo-common
> - API implementation is not tested in CI
> - GUI and CLI diverges in how that feature is operated as business logic
> is implemented twice, which has number of negative effects on TripleO
> functionality (backwards compatibility, upgrades...)
>

Nice summary here. I think we do need to be more careful in how we add
features to python-tripleoclient so that we guard against breaking some of
the UI use cases. We have guarded some features on this front in the past
during the review process. When TripleO validations was added for instance
we were extra careful in how we execute Ansible (via Mistral) so that both
the UI and CLI could run it.


>
> The biggest point of divergence between GUI and CLI is that CLI tends to
> generate a set of local files which are then put together when deploy
> command is run whereas GUI operates on Deployment plan which is stored in
> Swift and accessed through API provided by tripleo-common.
>
> The described problem currently affects all of the features which CLI uses
> to generate files which are used in deploy command (e.g. Roles management,
> Container images preparation, Networks management etc.) There is no API for
> those features and therefore GUI can't support them until Mistral actions
> and workflows are implemented for it.
>
> Proposed solution:
>
> We should stop considering TripleO as a set of utility scripts used to
> construct 'deploy' command, we should rather consider TripleO as a
> deployment application which has its internal state (Deployment plan in
> Swift) which is accessed and modified via API.
> TripleO feature should be considered complete when API for it is created.
> CLI should solely use TripleO business logic through Mistral actions and
> workflows provided by tripleo-common - same as any other client has to.
>
> Results of this change are:
> - tripleoclient is extremely lightweight, containing no tripleo business
> logic
>

The python-client may be "lightweight" but the downstream packages that
typically install this are extremely heavy. This is largely due to the
instack-undercloud requirements that could arguably be split out into a
separate subpackage. Just a minor nit, that we might consider making the
package lighter for RPMs as well.


> - tripleo-common API is tested in CI as it is used by CLI
> - tripleoclient and tripleo-ui are perfectly compatible, interoperable and
> its features and capabilities match
> - TripleO business logic lives solely in tripleo-common and is operated
> the same way by any client
> - no new backward compatibility problems caused by releasing features
> which are not supported by API are not introduced
> - new features related to Ansible or containers are available to all
> clients
> - upgrades work the same way for deployments deployed via CLI and GUI
> - deployment is replicable without need of keeping the the deploy command
> and generated files around (exported deployment plan has all the
> information)
>
> Note that argument of convenience of being able to modify deployment files
> locally is less and less relevant as we are incrementally moving from
> forcing user to modify templates manually (all the jinja templating,
> roles_data.yaml, network_data.yaml generation, container images
> preparation, derive parameters workflows etc.). In Pike we have made
> changes to simplify the way Deployment plan is stored and it is extremely
> easy to import and export it in case when some manual changes are needed.
>
> Proposed action items:
> - Document what feature complete means in TripleO and how features should
> be accessed by clients
> - Identify steps to achieve feature parity between CLI and 

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Miguel Angel Ajo Pelayo]

+1! Thanks for organizing

On Wed, Sep 13, 2017 at 10:11 AM, Sandhya Dasu (sadasu) 
wrote:

> +1
>
> Thanks for organizing.
>
> On 9/13/17, 7:28 AM, "Thomas Morin"  wrote:
>
> +1
>
> -Thomas
>
>
> Takashi Yamamoto, 2017-09-13 03:05:
> > +1
> >
> > On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
> >  wrote:
> > > +1
> > > thanks for organizing!
> > >
> > > On Wed, 13 Sep 2017 14:18:45 +0900,
> > > Brian Haley wrote:
> > > >
> > > > +1
> > > >
> > > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > > +1
> > > > >
> > > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > > wrote:
> > > > > > +1
> > > > > >
> > > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > > lonski.pl>
> > > > > > wrote:
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > —
> > > > > > > Best regards
> > > > > > > Slawek Kaplonski
> > > > > > > sla...@kaplonski.pl
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > > com> w dniu
> > > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > >
> > > > > > > > Dear Neutrinos,
> > > > > > > >
> > > > > > > > Our social event will take place on Thursday September
> > > > > > > > 12th at 7:30pm.
> > > > > > > > The venue is going to be https://www.famousdaves.com/
> Denv
> > > > > > > > er-Stapleton. It is
> > > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > > translates to an easy 9
> > > > > > > > minutes walk.
> > > > > > > >
> > > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > > name. Please
> > > > > > > > respond to this message with your attendance confirmation
> > > > > > > > by Wednesday
> > > > > > > > night, so I can get a more accurate head count.
> > > > > > > >
> > > > > > > > Looking forward to see y'all Thursday night
> > > > > > > >
> > > > > > > > Best regards
> > > > > > > >
> > > > > > > > Miguel
> > > > > > > >
> > > > > > > > __
> ___
> > > > > > > > _
> > > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > > questions)
> > > > > > > > Unsubscribe:
> > > > > > > > OpenStack-dev-request@lists.
> openstack.org?subject:unsubsc
> > > > > > > > ribe
> > > > > > > > http://lists.openstack.org/
> cgi-bin/mailman/listinfo/opens
> > > > > > > > tack-dev
> > > > > > >
> > > > > > >
> > > > > > > __
> _
> > > > > > > ___
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe: OpenStack-dev-request@lists.
> openstack.org?subj
> > > > > > > ect:unsubscribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> opensta
> > > > > > > ck-dev
> > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> _
> > > > > > _
> > > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > > Unsubscribe: OpenStack-dev-request@lists.
> openstack.org?subjec
> > > > > > t: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-d
> > > > > ev
> > > > >
> > > >
> > > >
> > > > 
> _
> > > > _
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: OpenStack-dev-request@lists.
> openstack.org?subject:un
> > > > subscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> > >
> > > 
> ___
> > > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request@lists.
> openstack.org?subject:unsu
> > > bscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > 
> _
> > _
> > OpenStack 

[openstack-dev] [ptg][i18n][doc] Install Guides Testing

[Petr Kovar]

Hi all,

Just a reminder that we are meeting tomorrow at 9 am in Colorado Ballroom C
for an Install Guides testing session.

Interested? Sign up here:
https://etherpad.openstack.org/p/docs-i18n-ptg-queens

See you there!
pk


On Fri, 01 Sep 2017 09:47:18 +0200
Frank Kloeker  wrote:

> Good morning,
> 
> it's only a week to the next PTG in Denver. I would like to invite you 
> to visit our project etherpad on [1]. We as I18n team are together with 
> the Doc team in the same room and we share also our planning on the 
> etherpad.
> Monday morning we reserved some time to say "Hello" to everybody. Take 
> the chance to meet us and let me know if you have some topics for the 
> translation team.
> 
> kind regards
> 
> Frank (eumel8)
> PTL I18n
> 
> [1] https://etherpad.openstack.org/p/docs-i18n-ptg-queens
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


__
OpenStack Development Mailing 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] [ptg][docs][i18n] Team lunch today

[Petr Kovar]

Hi all,

For those attending the PTG in Denver, let's have team lunch today. We'd
meet at 12 pm in front of the PTG registration desk. 

See you there,
pk

__
OpenStack Development Mailing 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] [murano] ptg meetup

[Paul Bourke]

Hi,

Would those of us at the PTG like to agree on a time to meet for an 
informal Murano chat? Does Friday suit?


Regards,
-Paul

__
OpenStack Development Mailing 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] Re : [Neutron] Denver Team Dinner

[Sandhya Dasu (sadasu)]

+1

Thanks for organizing.

On 9/13/17, 7:28 AM, "Thomas Morin"  wrote:

+1

-Thomas


Takashi Yamamoto, 2017-09-13 03:05:
> +1
> 
> On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
>  wrote:
> > +1
> > thanks for organizing!
> > 
> > On Wed, 13 Sep 2017 14:18:45 +0900,
> > Brian Haley wrote:
> > > 
> > > +1
> > > 
> > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > +1
> > > > 
> > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > wrote:
> > > > > +1
> > > > > 
> > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > lonski.pl>
> > > > > wrote:
> > > > > > 
> > > > > > +1
> > > > > > 
> > > > > > —
> > > > > > Best regards
> > > > > > Slawek Kaplonski
> > > > > > sla...@kaplonski.pl
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > com> w dniu
> > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > 
> > > > > > > Dear Neutrinos,
> > > > > > > 
> > > > > > > Our social event will take place on Thursday September
> > > > > > > 12th at 7:30pm.
> > > > > > > The venue is going to be https://www.famousdaves.com/Denv
> > > > > > > er-Stapleton. It is
> > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > translates to an easy 9
> > > > > > > minutes walk.
> > > > > > > 
> > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > name. Please
> > > > > > > respond to this message with your attendance confirmation
> > > > > > > by Wednesday
> > > > > > > night, so I can get a more accurate head count.
> > > > > > > 
> > > > > > > Looking forward to see y'all Thursday night
> > > > > > > 
> > > > > > > Best regards
> > > > > > > 
> > > > > > > Miguel
> > > > > > > 
> > > > > > > _
> > > > > > > _
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe:
> > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> > > > > > > ribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> > > > > > > tack-dev
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > ___
> > > > > > OpenStack Development Mailing List (not for usage
> > > > > > questions)
> > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
> > > > > > ect:unsubscribe
> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
> > > > > > ck-dev
> > > > > > 
> > > > > 
> > > > > 
> > > > > _
> > > > > _
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > > > > t: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-d
> > > > ev
> > > > 
> > > 
> > > 
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > subscribe
> > > 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:unsu
> > bscribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [kolla] kolla-ansible 5.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for kolla-ansible for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/pike

Release notes for kolla-ansible can be found at:

http://docs.openstack.org/releasenotes/kolla-ansible/




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

[openstack-dev] [kolla] kolla 5.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for kolla for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/pike

Release notes for kolla can be found at:

http://docs.openstack.org/releasenotes/kolla/




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

[openstack-dev] [keystone] Does the policy.json for trusts works?

[Adrian Turjak]

Hello Keystone devs!

I've been playing with some policy changes and realised that the trust
policy rules were mostly blank. Which, based on how the policy logic
works means that any authed user can list trusts:
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142

But... in practive that doesn't appear to be the case, only admin can
list/create/etc trusts. Which is good since it doesn't really make sense
for any authed user to see all trusts (or does it?). What it does raise
is, does the policy actually work for trusts, or is an admin requirement
policy hardcoded somewhere for them?

Now I've played with the keystone policy, setting an admin only policy
blank, lets say project list, does let any authed user to use that API.
So from that we know that a blank policy has that logic. The 'default'
rule only comes into play when a rule isn't present. Such as me setting
a policy as "rule:rule_that_doesnt_exist" which would invoke the default
rule, so we know that is happening here either.

So... back to how I got here. The policy for trusts doesn't appear to
work as written. They are blank (and they probably shouldn't be), and
based on that policy, they should be visible to all authed users. Even
if I do put an explicit rule in them, they don't seem to take effect.
Can someone else confirm I'm not going mad? Or that potentially I'm
missing the point entirely (which for my sanity is also welcome :P).

I even checked if it was maybe extension specific, but the consumer
policy for the oauth extension does appear to work. If I blank it, any
authed user can list consumers.

If I'm not mad, we should probably work out why this doesn't work, but
before we fix it, we should also add a better default rule since we
probably don't want all authed users seeing ALL trusts.

Cheers,
Adrian




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

Re: [openstack-dev] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Arne Wiebalck]

> On 13 Sep 2017, at 16:52, Matt Riedemann  wrote:
> 
> On 9/13/2017 3:24 AM, Arne Wiebalck wrote:
>> I’m reviving this thread to check if the suggestion to address potentially 
>> stale connection
>> data by an admin command (or a scheduled task) made it to the planning for 
>> one of the
>> upcoming releases?
> 
> It hasn't, but we're at the PTG this week so I can throw it on the list of 
> topics.


That’d be great, thanks!

--
Arne Wiebalck
CERN IT

__
OpenStack Development Mailing 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 coming week (09/08-09/14)

[Kekane, Abhishek]

Hi Brian,

Thanks a lot for appreciation.
It was a great opportunity for me to work along with you, jokke and other 
peoples on glance pike cycle. A huge learning platform for me. It is my 
pleasure to be a part of glance core.

Thank you,

Abhishek Kekane



From: Brian Rosmaita 
Sent: Friday, September 8, 2017 6:25:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] priorities for the coming week (09/08-09/14)

Hello Glancers,

1. No meeting on Sept 14 due to PTG.

2. The PTG schedule for Glance is available.  There are etherpads
associated with each session.  If you cannot attend the PTG but are
interested in a session, please put questions/comments on the
appropriate etherpad.  We won't be livecasting the sessions, but we
will have IRC open to  #openstack-glance and #openstack-ptg, and we'll
be taking notes on the session etherpad
- https://etherpad.openstack.org/p/glance-queens-ptg

3. We have bugs targeted to Q-1, so you can't go wrong this week by
reviewing any patches associated with them:
- https://launchpad.net/glance/+milestone/queens-1
- also https://review.openstack.org/#/c/493654/ and
https://review.openstack.org/#/c/492651/

4. We'll be triaging and prioritizing bugs on Thursday (22:30-23:30
UTC) and having a bugfix session Friday, Sept 15 (15:00-18:00 UTC).
Feel free to join in!

Have a good week, everyone!

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Morales, Victor]

As far as I remember the reason to have everything on a single file is because 
we’re trying to make Apache to load the configuration values during the startup.

On 9/6/17, 9:19 PM, "Thomas Bechtold"  wrote:

Hi Kevin,

On 04.09.2017 15:01, Kevin Benton wrote:
> Yes, unfortunately I didn't make it back to the patch in time to adjust 
> devstack to dump all of the configuration into one file (instead of 
> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).

You don't have to put everything into one file. oslo.config supports per 
service config files and conf.d dirs[1].
So eg. dhcp_agent.ini could be put into 
/etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with .conf).
Maybe that's more readable than a single huge config file?

Best,

Tom

[1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2


__
OpenStack Development Mailing 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] confirming Abhishek Kekane for glance core

[Kekane, Abhishek]

Hi Brian,

Thanks a lot for appreciation.
It was a great opportunity for me to work along with you, jokke and other 
peoples on glance pike cycle. A huge learning platform for me. It is my 
pleasure to be a part of glance core.

Thank you,

Abhishek Kekane



From: Brian Rosmaita 
Sent: Wednesday, September 13, 2017 6:14:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] confirming Abhishek Kekane for glance core

Back in June, I asked Abhishek Kekane to serve as glance core during
the Pike cycle [0].  His contributions exceeded all expectations.
Abhishek's careful reviews, bug fixes, patches, and general
contributions to the community were instrumental in Glance completing
the Pike release.  I'm happy to announce that Abhishek has agreed to
continue to serve the OpenStack community as a Glance core
contributor, and this note confirms his status as a "regular" member
of the Glance core group, with all the rights and privileges
pertaining thereto.

(I just want it to be completely clear before our Queens design
discussions begin this morning that there's nothing provisional about
Abhishek's glance core status -- he's a full-fledged glance core.)

Thanks again to Abhishek for his hard work during the Pike cycle, and
I look forward to working with him for many cycles to come.

cheers,
brian


[0] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118503.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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - transitioning PTL role to Miguel Lavalle

[reedip banerjee]

Damn :(
Kevin , you have been excellent , and this is a sad, sad news ! I hope you
continue to work with the project you strengthen with your expertise...
Miguel Lavalle , +2 to you :)

On Wed, Sep 13, 2017 at 4:10 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Kevin!, and thank you for all the effort and energy you have put into
> openstack-neutron during the last few years. It's been great to have you on
> the project.
>
> On Mon, Sep 11, 2017 at 5:18 PM, Ihar Hrachyshka 
> wrote:
>
>> It's very sad news for the team, but I hope that Kevin will still be
>> able to contribute, or at least stay in touch. I am sure Miguel will
>> successfully lead the community in Queens and beyond. Thanks to Miguel
>> for stepping in the ring. Thanks to Kevin for his leadership in recent
>> cycles.
>>
>> King is dead, long live the King!
>>
>> Ihar
>>
>> On Fri, Sep 8, 2017 at 8:59 PM, Kevin Benton  wrote:
>> > Hi everyone,
>> >
>> > Due to a change in my role at my employer, I no longer have time to be
>> the
>> > PTL of Neutron. Effective immediately, I will be transitioning the PTL
>> role
>> > to Miguel Lavalle.
>> >
>> > Miguel is an excellent leader in the community and has experience
>> reviewing
>> > patches as a core, reviewing feature requests and specs as a driver,
>> > implementing cross-project features, handling docs, and on-boarding new
>> > contributors.
>> >
>> > We will make the switch official next week at the PTG with the
>> appropriate
>> > patches to the governance repo.
>> >
>> > If anyone has any concerns with this transition plan, please reach out
>> to
>> > me, Thierry, or Doug Hellmann.
>> >
>> > Cheers,
>> > Kevin Benton
>> >
>> > 
>> __
>> > 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: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
>
>


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

Re: [openstack-dev] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Matt Riedemann]

On 9/13/2017 3:24 AM, Arne Wiebalck wrote:
I’m reviving this thread to check if the suggestion to address 
potentially stale connection
data by an admin command (or a scheduled task) made it to the planning 
for one of the

upcoming releases?


It hasn't, but we're at the PTG this week so I can throw it on the list 
of topics.


--

Thanks,

Matt

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

[openstack-dev] Kolla team dinner tonight (Sept 13) in Denver downtown

[Vikram Hosakote (vhosakot)]

The Kolla team is planning for dinner tonight Wednesday September 13th
in Denver downtown after today’s PTG session.

This will be a self-paid team dinner.  So, your operating cost depends on
the size of the container you eat in and the ingress policies that control
the number of ReplicaSets for your beer ;)

If you are not contributing to Kolla, Kolla-ansible or Kolla-kubernetes and
would like to join, you are welcome.

Regards,
Vikram Hosakote
IRC:  vhosakot
__
OpenStack Development Mailing 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] Re : [Neutron] Denver Team Dinner

[Thomas Morin]

+1

-Thomas


Takashi Yamamoto, 2017-09-13 03:05:
> +1
> 
> On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
>  wrote:
> > +1
> > thanks for organizing!
> > 
> > On Wed, 13 Sep 2017 14:18:45 +0900,
> > Brian Haley wrote:
> > > 
> > > +1
> > > 
> > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > +1
> > > > 
> > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > wrote:
> > > > > +1
> > > > > 
> > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > lonski.pl>
> > > > > wrote:
> > > > > > 
> > > > > > +1
> > > > > > 
> > > > > > —
> > > > > > Best regards
> > > > > > Slawek Kaplonski
> > > > > > sla...@kaplonski.pl
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > com> w dniu
> > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > 
> > > > > > > Dear Neutrinos,
> > > > > > > 
> > > > > > > Our social event will take place on Thursday September
> > > > > > > 12th at 7:30pm.
> > > > > > > The venue is going to be https://www.famousdaves.com/Denv
> > > > > > > er-Stapleton. It is
> > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > translates to an easy 9
> > > > > > > minutes walk.
> > > > > > > 
> > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > name. Please
> > > > > > > respond to this message with your attendance confirmation
> > > > > > > by Wednesday
> > > > > > > night, so I can get a more accurate head count.
> > > > > > > 
> > > > > > > Looking forward to see y'all Thursday night
> > > > > > > 
> > > > > > > Best regards
> > > > > > > 
> > > > > > > Miguel
> > > > > > > 
> > > > > > > _
> > > > > > > _
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe:
> > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> > > > > > > ribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> > > > > > > tack-dev
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > ___
> > > > > > OpenStack Development Mailing List (not for usage
> > > > > > questions)
> > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
> > > > > > ect:unsubscribe
> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
> > > > > > ck-dev
> > > > > > 
> > > > > 
> > > > > 
> > > > > _
> > > > > _
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > > > > t: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-d
> > > > ev
> > > > 
> > > 
> > > 
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > subscribe
> > > 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:unsu
> > bscribe
> > 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: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

[openstack-dev] [PTG] [I18n] No IRC meeting this week

[Frank Kloeker]

Good morning,

this week we will not hold an IRC meeting for the I18n team. Take the 
opportunity to meet us in real together with the Documentation Team 
today at the PTG in Colorado Ballroom C or ping us in #openstack-i18n or 
#openstack-ptg. Announcements as usualy on [1].


kind regards

Frank (eumel8)
PTL I18n

[1] http://ptg.openstack.org/ptg.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-dev] [glance] confirming Abhishek Kekane for glance core

[Brian Rosmaita]

Back in June, I asked Abhishek Kekane to serve as glance core during
the Pike cycle [0].  His contributions exceeded all expectations.
Abhishek's careful reviews, bug fixes, patches, and general
contributions to the community were instrumental in Glance completing
the Pike release.  I'm happy to announce that Abhishek has agreed to
continue to serve the OpenStack community as a Glance core
contributor, and this note confirms his status as a "regular" member
of the Glance core group, with all the rights and privileges
pertaining thereto.

(I just want it to be completely clear before our Queens design
discussions begin this morning that there's nothing provisional about
Abhishek's glance core status -- he's a full-fledged glance core.)

Thanks again to Abhishek for his hard work during the Pike cycle, and
I look forward to working with him for many cycles to come.

cheers,
brian


[0] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118503.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] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Arne Wiebalck]

Matt, all,

I’m reviving this thread to check if the suggestion to address potentially 
stale connection
data by an admin command (or a scheduled task) made it to the planning for one 
of the
upcoming releases?

Thanks!
 Arne


On 16 Jun 2017, at 09:37, Saverio Proto 
> wrote:

Hello Matt,

It is true that we are refreshing something that rarely changes. But
if you deliver a cloud service for several years, at one point you
might have to do these parameters changes.

Something that should not change rarely are the secrets of the ceph
users to talk to the ceph cluster. Good security would suggest
periodic secret rotation, but today this is not really feasible.

I know the problem is also that you cannot change stuff in libvirt
while the VMs are running. Maybe is time for a discussion with libvirt
developers to make our voice louder about required features ?

The goal would be to change on the fly the ceph/rbd secret that a VM
uses to access a volume, while the VM is running. I think this is very
important.

thank you

Saverio


2017-06-09 6:15 GMT+02:00 Matt Riedemann 
>:
On 6/8/2017 1:39 PM, melanie witt wrote:

On Thu, 8 Jun 2017 08:58:20 -0500, Matt Riedemann wrote:

Nova stores the output of the Cinder os-initialize_connection info API in
the Nova block_device_mappings table, and uses that later for making volume
connections.

This data can get out of whack or need to be refreshed, like if your ceph
server IP changes, or you need to recycle some secret uuid for your ceph
cluster.

I think the only ways to do this on the nova side today are via volume
detach/re-attach, reboot, migrations, etc - all of which, except live
migration, are disruptive to the running guest.


I believe the only way to work around this currently is by doing a 'nova
shelve' followed by a 'nova unshelve'. That will end up querying the
connection_info from Cinder and update the block device mapping record for
the instance. Maybe detach/re-attach would work too but I can't remember
trying it.


Shelve has it's own fun set of problems like the fact it doesn't terminate
the connection to the volume backend on shelve. Maybe that's not a problem
for Ceph, I don't know. You do end up on another host though potentially,
and it's a full delete and spawn of the guest on that other host. Definitely
disruptive.


I've kicked around the idea of adding some sort of admin API interface
for refreshing the BDM.connection_info on-demand if needed by an operator.
Does anyone see value in this? Are operators doing stuff like this already,
but maybe via direct DB updates?

We could have something in the compute API which calls down to the
compute for an instance and has it refresh the connection_info from Cinder
and updates the BDM table in the nova DB. It could be an admin action API,
or part of the os-server-external-events API, like what we have for the
'network-changed' event sent from Neutron which nova uses to refresh the
network info cache.

Other ideas or feedback here?


We've discussed this a few times before and we were thinking it might be
best to handle this transparently and just do a connection_info refresh +
record update inline with the request flows that will end up reading
connection_info from the block device mapping records. That way, operators
won't have to intervene when connection_info changes.


The thing that sucks about this is if we're going to be refreshing something
that maybe rarely changes for every volume-related operation on the
instance. That seems like a lot of overhead to me (nova/cinder API
interactions, Cinder interactions to the volume backend, nova-compute round
trips to conductor and the DB to update the BDM table, etc).


At least in the case of Ceph, as long as a guest is running, it will
continue to work fine if the monitor IPs or secrets change because it will
continue to use its existing connection to the Ceph cluster. Things go wrong
when an instance action such as resize, stop/start, or reboot is done
because when the instance is taken offline and being brought back up, the
stale connection_info is read from the block_device_mapping table and
injected into the instance, and so it loses contact with the cluster. If we
query Cinder and update the block_device_mapping record at the beginning of
those actions, the instance will get the new connection_info.

-melanie




--

Thanks,

Matt


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Arne Wiebalck
CERN IT

Re: [openstack-dev] [Neutron] Denver Team Dinner

[Takashi Yamamoto]

+1

On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
 wrote:
> +1
> thanks for organizing!
>
> On Wed, 13 Sep 2017 14:18:45 +0900,
> Brian Haley wrote:
>>
>> +1
>>
>> On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
>> > +1
>> >
>> > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  wrote:
>> >> +1
>> >>
>> >> On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński 
>> >> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> —
>> >>> Best regards
>> >>> Slawek Kaplonski
>> >>> sla...@kaplonski.pl
>> >>>
>> >>>
>> >>>
>> >>>
>>  Wiadomość napisana przez Miguel Lavalle  w dniu
>>  12.09.2017, o godz. 17:23:
>> 
>>  Dear Neutrinos,
>> 
>>  Our social event will take place on Thursday September 12th at 7:30pm.
>>  The venue is going to be https://www.famousdaves.com/Denver-Stapleton. 
>>  It is
>>  located 0.4 miles from the Renaissance Hotel, which translates to an 
>>  easy 9
>>  minutes walk.
>> 
>>  I have a reservation for a group of 30 people under my name. Please
>>  respond to this message with your attendance confirmation by Wednesday
>>  night, so I can get a more accurate head count.
>> 
>>  Looking forward to see y'all Thursday night
>> 
>>  Best regards
>> 
>>  Miguel
>> 
>>  __
>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe:
>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>>
>> >>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe: 
>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Denver Team Dinner

[IWAMOTO Toshihiro]

+1
thanks for organizing!

On Wed, 13 Sep 2017 14:18:45 +0900,
Brian Haley wrote:
> 
> +1
> 
> On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > +1
> > 
> > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  wrote:
> >> +1
> >> 
> >> On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński 
> >> wrote:
> >>> 
> >>> +1
> >>> 
> >>> —
> >>> Best regards
> >>> Slawek Kaplonski
> >>> sla...@kaplonski.pl
> >>> 
> >>> 
> >>> 
> >>> 
>  Wiadomość napisana przez Miguel Lavalle  w dniu
>  12.09.2017, o godz. 17:23:
>  
>  Dear Neutrinos,
>  
>  Our social event will take place on Thursday September 12th at 7:30pm.
>  The venue is going to be https://www.famousdaves.com/Denver-Stapleton. 
>  It is
>  located 0.4 miles from the Renaissance Hotel, which translates to an 
>  easy 9
>  minutes walk.
>  
>  I have a reservation for a group of 30 people under my name. Please
>  respond to this message with your attendance confirmation by Wednesday
>  night, so I can get a more accurate head count.
>  
>  Looking forward to see y'all Thursday night
>  
>  Best regards
>  
>  Miguel
>  
>  __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> 
> >>> 
> >>> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> 
> >> 
> >> 
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> 
> __
> OpenStack Development Mailing 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] [FEMDC] IRC meeting Today 15:00 UTC

[lebre . adrien]

Dear all, 

Back from the Opendev event on edge infrastructures, I forgot to announce our 
IC meeting, today at 15:00 UTC. 

As usual, the agenda is available at: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
1157)
Please indicate actions that have been achieved and feel free to add items in 
the Opening discussion Section.

Best,
ad_rien_

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

[openstack-dev] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

[Tobias Rydberg]

Hi everyone,

Don't forget todays meeting for the PublicCloudWorkingGroup.
1400 UTC  in IRC channel #openstack-meeting-3

Etherpad: https://etherpad.openstack.org/p/publiccloud-wg

Regards,
Tobias Rydberg


smime.p7s
Description: S/MIME Cryptographic 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