Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks for sharing this info , it make sense to leave a -2 here, I will
keep modifying follow on patches and get more reviews. thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Dan Smith 
To: "Chen CH Ji" 
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   04/30/2018 10:55 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



> According to requirements and comments, now we opened the CI runs with
> run_validation = True And according to [1] below, for example, [2]
> need the ssh validation passed the test
>
> And there are a couple of comments need some enhancement on the logs
> of CI such as format and legacy incorrect links of logs etc the newest
> logs sample can be found [3] (take n-cpu as example and those logs are
> with _white.html)
>
> Also, the blueprint [4] requested by previous discussion post here
> again for reference
>
> please let us know whether the procedure -2 can be removed in order to
> proceed . thanks for your help

The CI log format issues look fixed to me and validation is turned on
for the stuff supported, which is what was keeping it out of the
runway.

I still plan to leave the -2 on there until the next few patches have
agreement, just so we don't land an empty shell driver before we are
sure we're going to land spawn/destroy, etc. That's pretty normal
procedure and I'll be around to remove it when appropriate.

--Dan



__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Gilles Dubreuil]

Hi Jimmy,

Do you have an update about the API SIG slot?

Thanks,
Gilles


On 28/04/18 02:04, Jimmy McArthur wrote:

Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
Jimmy


__ 


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

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



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

Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live

[Emilien Macchi]

On Tue, May 1, 2018 at 7:18 AM, Jimmy McArthur  wrote:

> Apologies for the delay, Emilien!  I should be adding it today, but it's
> definitely yours.
>

Could we change the title of the slot and actually be a TripleO Project
Update session?
It would have been great to have the onboarding session but I guess we also
have 2 other sessions where we'll have occasions to meet:
TripleO Ops and User feedback and TripleO and Ansible integration

If it's possible to still have an onboarding session, awesome otherwise
it's ok I think we'll deal with it.

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

[openstack-dev] [tripleo] The Weekly Owl - 19th Edition

[Emilien Macchi]

Welcome to the nineteenth edition of a weekly update in TripleO world!
The goal is to provide a short reading (less than 5 minutes) to learn
what's new this week.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129800.html

+-+
| General announcements |
+-+

+--> Some efforts will be done during Rocky for splitting out controlplane,
see spec: https://review.openstack.org/#/c/523459
+--> We have 5 more weeks until milestone 2 ! Check-out the schedule:
https://releases.openstack.org/rocky/schedule.html

+--+
| Continuous Integration |
+--+

+--> Ruck is Wes and Rover is Gabriele. Please let them know any new CI
issue.
+--> Master promotion is 0 day, Queens is 0 day, Pike is 3 days and Ocata
is 1 days. Kudos folks!
+--> Still working on libvirt based multinode reproducer, see
https://goo.gl/DYCnkx
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

+-+
| Upgrades |
+-+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Containerized Undercloud upgrades has made good progress, non-voting
CI job almost ready
+--> Major efforts in tripleoclient for all-in-one (sorry for all the Merge
Conflict) but it was needed
+--> ansible-role-container-registry was imported in RDO, now moving
forward to consume it in THT.
+--> No progress on container updates before undercloud deployment.
+--> Still working on parity items between instack-undercloud and
containerized undercloud
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> config-download now the default with tripleo-heat-templates!
+--> Rewriting enable-ssh-admin.sh in python
+--> WIP around importing ansible role for keystone tasks.
+--> Progress on OpenStark operations Ansible role:
https://github.com/samdoran/ansible-role-openstack-operations
+--> Working on Skydive transition
+--> Working on improving performances when deploying Ceph with Ansible.
+--> More: https://etherpad.openstack.org/p/tripleo-config-download-
squad-status

+--+
| Integration |
+--+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Working on Network Wizard.
+--> Finishing config-download integration
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> Working on splitting workflows repository.
+--> Efforts around Workflow linting and unit testing.
+--> Discussions around usage of Zaqar.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> No updates, still focusing on Public TLS by default and Secret
Management.
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact  |
++

Keith Schincke suggested this weekly fact: you can observe owl's eyeball
through their ear:
https://www.livescience.com/61673-owl-eye-seen-through-ear.html


Thank you all for reading and stay tuned!
--
Your fellow reporter, Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun][k8s] AWS Fargate and OpenStack Zun

[Shuai Zhao]

Thanks Hongbin,

The article is really great!

On Mon, Apr 30, 2018 at 2:40 PM, Kumari, Madhuri 
wrote:

> Thank you Hongbin. The article is very helpful.
>
>
>
> Regards,
>
> Madhuri
>
>
>
> *From:* Hongbin Lu [mailto:hongbin...@gmail.com]
> *Sent:* Sunday, April 29, 2018 5:16 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [Zun][k8s] AWS Fargate and OpenStack Zun
>
>
>
> Hi folks,
>
>
>
> FYI. I wrote a blog post about a comparison between AWS Fargate and
> OpenStack Zun. It mainly covers the following:
>
>
>
> * The basic concepts of OpenStack Zun and AWS Fargate
>
> * The Kubernetes integration plan
>
>
>
> Here is the link: https://www.linkedin.com/pulse/aws-fargate-
> openstack-zun-comparing-serverless-container-hongbin-lu/
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] networking-vpp 18.04 for VPP 18.04 is now available

[Naveen Joy (najoy)]

Hello Everyone,

In conjunction with the release of VPP 18.04, we'd like to invite you all to 
try out networking-vpp 18.04 for VPP 18.04.
VPP is a fast userspace forwarder based on the DPDK toolkit, and uses vector 
packet processing algorithms to minimize the CPU time spent on each packet and 
maximize throughput.
networking-vpp is a ML2 mechanism driver that controls VPP on your control and 
compute hosts to provide fast L2 forwarding under Neutron.

This version has a few additional enhancements and several bug fixes, along 
with supporting the VPP 18.04 APIs:
- L3 HA is fully supported for VLAN, VXLAN-GPE and Flat Network Types
- IPv6 VM addressing supported for VXLAN-GPE
- Deadlock prevention in eventlet

Along with this, there have been the usual upkeep as Neutron versions change, 
bug fixes, code and test improvements.

The README [1] explains how you can try out VPP and networking-vpp using 
devstack: the devstack plugin will deploy the mechanism driver and VPP itself 
and should give you a working system with a minimum of hassle.
It will use the etcd version deployed by newer versions of devstack.

We will be continuing our development between now and VPP's 18.07 release.
There are several features we're planning to work on (you'll find a list in our 
RFE bugs at [2]), and we welcome anyone who would like to come help us.

Everyone is welcome to join our biweekly IRC meetings, held every other Monday, 
0800 PST = 1600 GMT.
--
Naveen & Ian

[1]https://github.com/openstack/networking-vpp/blob/master/README.rst
[2]http://goo.gl/i3TzAt

__
OpenStack Development Mailing 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] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Arvind N]

Reminder for Operators, Please provide feedback either way.

In cases of rebuilding of an instance using a different image where the
image traits have changed between the original launch and the rebuild, is
it reasonable to ask to just re-launch a new instance with the new image?

The argument for this approach is that given that the requirements have
changed, we want the scheduler to pick and allocate the appropriate host
for the instance.

The approach above also gives you consistent results vs the other
approaches where the rebuild may or may not succeed depending on how the
original allocation of resources went.

For example(from Alex Xu) ,if you launched an instance on a host which has
two SRIOV nic. One is normal SRIOV nic(A), another one with some kind of
offload feature(B).

So, the original request is: resources=SRIOV_VF:1 The instance gets a VF
from the normal SRIOV nic(A).

But with a new image, the new request is: resources=SRIOV_VF:1
traits=HW_NIC_OFFLOAD_XX
With all the solutions discussed in the thread, a rebuild request like
above may or may not succeed depending on whether during the initial launch
whether nic A or nic B was allocated.

Remember that in rebuild new allocation don't happen, we have to reuse the
existing allocations.

Given the above background, there seems to be 2 competing options.

1. Fail in the API saying you can't rebuild with a new image with new
required traits.

2. Look at the current allocations for the instance and try to match the
new requirement from the image with the allocations.

With #1, we get consistent results in regards to how rebuilds are treated
when the image traits changed.

With #2, the rebuild may or may not succeed, depending on how well the
original allocations match up with the new requirements.

#2 will also need to need to account for handling preferred traits or
granular resource traits if we decide to implement them for images at some
point...


[1]
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html
[2] https://review.openstack.org/#/c/560718/

On Tue, Apr 24, 2018 at 6:26 AM, Sylvain Bauza  wrote:

> Sorry folks for the late reply, I'll try to also weigh in the Gerrit
> change.
>
> On Tue, Apr 24, 2018 at 2:55 PM, Jay Pipes  wrote:
>
>> On 04/23/2018 05:51 PM, Arvind N wrote:
>>
>>> Thanks for the detailed options Matt/eric/jay.
>>>
>>> Just few of my thoughts,
>>>
>>> For #1, we can make the explanation very clear that we rejected the
>>> request because the original traits specified in the original image and the
>>> new traits specified in the new image do not match and hence rebuild is not
>>> supported.
>>>
>>
>> I believe I had suggested that on the spec amendment patch. Matt had
>> concerns about an error message being a poor user experience (I don't
>> necessarily disagree with that) and I had suggested a clearer error message
>> to try and make that user experience slightly less sucky.
>>
>> For #3,
>>>
>>> Even though it handles the nested provider, there is a potential issue.
>>>
>>> Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1),
>>> another one with some kind of offload feature(VF2).(Described by alex)
>>>
>>> Initial instance launch happens with VF:1 allocated, rebuild launches
>>> with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want
>>> the instance to be allocated VF2.
>>>
>>> But the original allocation happens against VF1 and since in rebuild the
>>> original allocations are not changed, we have wrong allocations.
>>>
>>
>> Yep, that is certainly an issue. The only solution to this that I can see
>> would be to have the conductor ask the compute node to do the pre-flight
>> check. The compute node already has the entire tree of providers, their
>> inventories and traits, along with information about providers that share
>> resources with the compute node. It has this information in the
>> ProviderTree object in the reportclient that is contained in the compute
>> node resource tracker.
>>
>> The pre-flight check, if run on the compute node, would be able to grab
>> the allocation records for the instance and determine if the required
>> traits for the new image are present on the actual resource providers
>> allocated against for the instance (and not including any child providers
>> not allocated against).
>>
>>
> Yup, that. We also have pre-flight checks for move operations like live
> and cold migrations, and I'd really like to keep all the conditionals in
> the conductor, because it knows better than the scheduler which operation
> is asked.
> I'm not really happy with adding more in the scheduler about "yeah, it's a
> rebuild, so please do something exceptional", and I'm also not happy with
> having a filter (that can be disabled) calling the Placement API.
>
>
>> Or... we chalk this up as a "too bad" situation and just either go with
>> option #1 or simply don't care about it.
>
>
> Also, that too. 

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Ok, here are my two cents regarding GraphQL integration within Openstack
and some thoughts around this topic.

1°/- Openstack SDK should still exist and should be in my humble opinion a
critical focus as it allow following benefits for large and medium
companies :

• It provide a common and clean structure for Openstack developments and
should be used either by projects or tools willing to integrate Openstack
as it will then create some sort of standard.

For instance, here in my job we have A LOT (More than 10 000 peoples
working within around 130 teams) of teams developing over Openstack using
the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those
teams are spread around the world and so need to have clean guidelines as
it avoid them reinventing the wheel, they’re not stuck with someone else
obscure code created by another persons on the other side of the world or
within a different timezone.
Additionally it streamline our support and debug processes.

• We should get a common consensus before all projects start to implement
it.

This point is for me the most important one as it will fix flaws we get
currently with the rest APIs development within Openstack.

First it will avoid a fresh developer to be confused by too many options.
Honestly, I know we are open etc, but this point really need to be
addressed as it is the main issue that I face with Openstack advocacy since
many years now.

Having too many options even if explained within the documentation daunt a
lot of people to quickly give a hand with projects.

For instance I have a workmate that is currently working on an internal
tool which ask me how should he implement its project REST interfaces.

I told him TO NOT use WSME and to stick with what have been done by a major
project. Unfortunately he choose to copy what have been done by Octavia
which is actually using... WSME...

GraphQL gives us the opportunity and ability to fix Openstack development
inconsistencies by providing and enforcing a clean guideline regarding
which library should be used and in which way.

That would also have the side effect to easy the entry level for a new
Openstack developer.

• New architecture opportunities.

For sure that will bring new architecture opportunities, but the broker
thing is not a good idea as each project should be able to be autonomous.

I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use a
RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much
debugging/investigation hell that we now plan to have a serious benchmark
and test of ZMQ.

One thing that I would love to see with GraphQL is a better distributed and
traceable model.

Anyway, I’m glad someone started this discussion as I feel it is a really
important topic that would highly help Openstack on more than just
interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil  a écrit :

>
>
> On 01/05/18 11:31, Flint WALRUS wrote:
>
> Yes, that’s was indeed the sens of my point.
>
>
> I was just enforcing it, no worries! ;)
>
>
>
> Openstack have to provide both endpoints type for a while for backward
> compatibility in order to smooth the transition.
>
> For instance, that would be a good idea to contact postman devteam once
> GraphQL will start to be integrated as it will allow a lot of ops to keep
> their day to day tools by just having to convert their existing collections
> of handful requests.
>
>
> Shouldn't we have a common consensus before any project start pushing its
> own GraphQL wheel?
>
> Also I wonder how GraphQL could open new architecture avenues for
> OpenStack.
> For example, would that make sense to also have a GraphQL broker linking
> OpenStack services?
>
>
>
>
> Or alternatively to provide a tool with similar features at least.
> Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a
> écrit :
>
>>
>>
>> On 30/04/18 20:16, Flint WALRUS wrote:
>>
>> I would very much second that question! Indeed it have been one of my own
>> wondering since many times.
>>
>> Of course GraphQL is not intended to replace REST as is and have to live
>> in parallel
>>
>>
>> Effectively a standard initial architecture is to have GraphQL sitting
>> aside (in parallel) and wrapping REST and along the way develop GrapgQL
>> Schema.
>>
>> It's seems too early to tell but GraphQL being the next step in API
>> evolution it might ultimately replace REST.
>>
>>
>> but it would likely and highly accelerate all requests within heavily
>> loaded environments
>>
>>
>> +1
>>
>>
>> .
>>
>> So +1 for this question.
>> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
>> écrit :
>>
>>> Hi,
>>>
>>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>>> addresses REST limitations.

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Ian Y. Choi]

> >> > So, is the documentation team willing to add the new "constellations"
> >> > repository under their umbrella? Or should we keep it as a TC-owned
> >> > repository for now?
> >>
> >> I'm fine having it as parts of the docs team. The docs PTL should be
> >> part of the review team for sure,
> >>
> >> Andreas
> >
> > Yeah, I wasn't really clear there: I intend to set up the documentation
> > and TC teams as members of the new team, so that all members of both
> > groups can be reviewers of the new repository.
>
> +1 Doug
>
>
I think a new specialty team in Docs team structure would fit well into
this purpose
: https://docs.openstack.org/doc-contrib-guide/team-structure.html

Note that the purpose of including docs core members is mentioned in:
http://lists.openstack.org/pipermail/openstack-docs/2016-June/008760.html .


With many thanks,

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

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Davanum Srinivas]

On Tue, May 1, 2018 at 4:21 PM, Doug Hellmann  wrote:
> Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
>> On 05/01/2018 04:08 PM, Doug Hellmann wrote:
>> > The TC has had an item on our backlog for a while (a year?) to
>> > document "constellations" of OpenStack components to make it easier
>> > for deployers and users to understand which parts they need to have
>> > the features they want [1].
>> >
>> > John Garbutt has started writing the first such document [2], but
>> > as we talked about the content we agreed the TC governance repository
>> > is not the best home for it, so I have proposed creating a new
>> > repository [3].
>> >
>> > In order to set up the publishing jobs for that repo so the content
>> > goes to docs.openstack.org, we need to settle the ownership of the
>> > repository.
>> >
>> > I think it makes sense for the documentation team to "own" it, but
>> > I also think it makes sense for it to have its own review team
>> > because it's a bit different from the rest of the docs and we may
>> > be able to recruit folks to help who might not want to commit to
>> > being core reviewers for all of the documentation repositories. The
>> > TC members would also like to be reviewers, to get things going.
>> >
>> > So, is the documentation team willing to add the new "constellations"
>> > repository under their umbrella? Or should we keep it as a TC-owned
>> > repository for now?
>>
>> I'm fine having it as parts of the docs team. The docs PTL should be
>> part of the review team for sure,
>>
>> Andreas
>
> Yeah, I wasn't really clear there: I intend to set up the documentation
> and TC teams as members of the new team, so that all members of both
> groups can be reviewers of the new repository.

+1 Doug

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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200:
> On 05/01/2018 04:08 PM, Doug Hellmann wrote:
> > The TC has had an item on our backlog for a while (a year?) to
> > document "constellations" of OpenStack components to make it easier
> > for deployers and users to understand which parts they need to have
> > the features they want [1].
> > 
> > John Garbutt has started writing the first such document [2], but
> > as we talked about the content we agreed the TC governance repository
> > is not the best home for it, so I have proposed creating a new
> > repository [3].
> > 
> > In order to set up the publishing jobs for that repo so the content
> > goes to docs.openstack.org, we need to settle the ownership of the
> > repository.
> > 
> > I think it makes sense for the documentation team to "own" it, but
> > I also think it makes sense for it to have its own review team
> > because it's a bit different from the rest of the docs and we may
> > be able to recruit folks to help who might not want to commit to
> > being core reviewers for all of the documentation repositories. The
> > TC members would also like to be reviewers, to get things going.
> > 
> > So, is the documentation team willing to add the new "constellations"
> > repository under their umbrella? Or should we keep it as a TC-owned
> > repository for now?
> 
> I'm fine having it as parts of the docs team. The docs PTL should be 
> part of the review team for sure,
> 
> Andreas

Yeah, I wasn't really clear there: I intend to set up the documentation
and TC teams as members of the new team, so that all members of both
groups can be reviewers of the new repository.

Doug

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

[openstack-dev] OpenStack PTG Update

[Jimmy McArthur]

Hey everyone,

Good news! We have extended the early bird registration for the upcoming 
PTG in Denver to May 18, 6:59 UTC. After that time, the price will 
increase from USD $199 to USD $399.


Please keep in mind that the OpenStack Foundation doesn’t profit on 
these events. Our goal is to provide the absolute best community 
experience/opportunity/value for the money.


If you are concerned about cost and your organization will not fund your 
travel, you can apply for Travel Support 
.  
If we can answer any further questions about the cost or cost increase, 
just let us know.


Thank you and we look forward to seeing you in Denver!
Jimmy
__
OpenStack Development Mailing 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] [mistral] Help with test run

[András Kövi]

Thanks Clark,

I’m pretty sure the UTs would conflict with each other so raising the 
concurrency is probably a big undertaking. Though it’s definitely worth looking 
into in the future. Shifting the job timeout a little bit maybe a the simplest 
solution.

Thanks again,
Andras

_
From: Clark Boylan 
Sent: Tuesday, May 1, 2018 6:12 PM
Subject: Re: [openstack-dev] [mistral] Help with test run
To: 


On Fri, Apr 27, 2018, at 2:22 AM, András Kövi wrote:
> Hi,
>
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/

Reading the job log the job setup only took a few minutes. Then the unittests 
start and are running continuously until the timeout happens at 30 minutes. 
Chances are that the default 30 minute timeout is not sufficient for this job. 
Runtime may vary based on cloud region and presence of noisy neighbors.

As for making this more reliable you can increase the timeout in the job 
configuration for that job. Another approach would be to make the unittests run 
more quickly. I notice the job is hard coded to use concurrency=1 when invoking 
the test runner so you are only using ~1/8 of the available cpus. You might try 
increasing this value though will likely need to make sure the tests don't 
conflict with each other.

Clark

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


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

Re: [openstack-dev] [mistral] Help with test run

[András Kövi]

Thanks Brad for the check. Yes it’s quite consistent.

_
From: Brad P. Crochet 
Sent: Tuesday, May 1, 2018 5:13 PM
Subject: Re: [openstack-dev] [mistral] Help with test run
To: OpenStack Development Mailing List (not for usage questions) 





On Fri, Apr 27, 2018 at 5:23 AM András Kövi 
> wrote:
Hi,

Can someone please help me with why this build ended with TIMED_OUT?
http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/


I'm not seeing any particular reason for it. Is it happening consistently?

Thanks,
Andras

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385



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

[openstack-dev] [nova] Virtuozzo CI status

[melanie witt]

Hi Stackers,

Lately, I noticed the Virtuozzo CI has been having some problems, for 
example on a recent example run [0], the job link is broken:


"The requested URL 
/22/563722/4/check/check-dsvm-tempest-vz7-exe-minimal/d1d1707 was not 
found on this server."


Prior to that, I noticed that the image the job was using wasn't passing 
the ImagePropertiesFilter and failing to have a successful run because 
of it.


Can anyone from the Virtuozzo subteam comment on the status of the third 
party CI?


Thanks,
-melanie

[0] https://review.openstack.org/563722

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

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Andreas Jaeger]

On 05/01/2018 04:08 PM, Doug Hellmann wrote:

The TC has had an item on our backlog for a while (a year?) to
document "constellations" of OpenStack components to make it easier
for deployers and users to understand which parts they need to have
the features they want [1].

John Garbutt has started writing the first such document [2], but
as we talked about the content we agreed the TC governance repository
is not the best home for it, so I have proposed creating a new
repository [3].

In order to set up the publishing jobs for that repo so the content
goes to docs.openstack.org, we need to settle the ownership of the
repository.

I think it makes sense for the documentation team to "own" it, but
I also think it makes sense for it to have its own review team
because it's a bit different from the rest of the docs and we may
be able to recruit folks to help who might not want to commit to
being core reviewers for all of the documentation repositories. The
TC members would also like to be reviewers, to get things going.

So, is the documentation team willing to add the new "constellations"
repository under their umbrella? Or should we keep it as a TC-owned
repository for now?


I'm fine having it as parts of the docs team. The docs PTL should be 
part of the review team for sure,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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] Overriding project-templates in Zuul

[Wesley Hayutin]

On Tue, May 1, 2018 at 1:23 PM Emilien Macchi  wrote:

> On Tue, May 1, 2018 at 10:02 AM, James E. Blair 
> wrote:
> [...]
>
> Okay, let's summarize:
>>
>> Proposal 1: All project-template and project-local job variants matching
>> the item's branch must also match the item.
>>
>> * Files and irrelevant-files on project-template and project stanzas are
>>   essentially combined in a set intersection.
>> * It's possible to further reduce the scope of jobs, but not expand.
>> * Files and irrelevant-files are still independent matchers, and if both
>>   are present, both must match.
>> * It's not possible to alter a job attribute by adding a project-local
>>   variant with only a files matcher (it would cause the whole job to run
>>   or not run).  But it's still possible to do that in the main job
>>   definition itself.
>>
>> Proposal 2: Files and irrelevant-files are treated as overwriteable
>> attributes and evaluated after branch-matching variants are combined.
>>
>> * Files and irrelevant-files are overwritten, so the last value
>>   encountered when combining all the matching variants (looking only at
>>   branches) wins.
>> * Files and irrelevant-files will be treated as a pair, so that if
>>   "irrelevant-files" appears, it will erase a previous "files"
>>   attribute.
>> * It's possible to both reduce and expand the scope of jobs, but the
>>   user may need to manually copy values from a parent or other variant
>>   in order to do so.
>> * It will no longer be possible to alter a job attribute by adding a
>>   variant with only a files matcher -- in all cases files and
>>   irrelevant-files are used solely to determine whether the job is run,
>>   not to determine whether to apply a variant.
>>
>> I think both would be good solutions to the problem.  The key points for
>> me are whether we want to keep the "alter a job attribute with variant
>> with a files matcher" functionality (the "rebuild_index" example from
>> above), and whether the additional control of overwriting the matchers
>> (at the cost of redundancy in configuration) is preferable to combining
>> the matchers.
>>
>
> In the case of TripleO, I think proposal 2 is what we want.
> We have stanzas defined in the templates definitions in
> openstack-infra/tripleo-ci repo, but really want to override the file rules
> per repo (openstack/tripleo-quickstart for example) and I don't think we
> want to have them both matching but so the last value encountered would win.
> I'll let TripleO CI squad to give more thoughts though.
>
> Thanks,
> --
> Emilien Macchi
>

I agree,
Proposal #2 makes the most sense to me and seems more straight forward in
that you have the ability to override and that the project overriding would
need to handle both files and irrelevant-files from scratch.

Nice write up



> __
> OpenStack Development Mailing 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] Overriding project-templates in Zuul

[James E. Blair]

cor...@inaugust.com (James E. Blair) writes:

> So a job with "files: tests/" and "irrelevant-files: docs/" would
> never run because it's impossible to satisfy both.

Jeremy pointed out in IRC that that's not what would happen.  So... let
me rephrase that:

> So a job with "files: tests/" and "irrelevant-files: docs/" would do 
> whatever it is that happens when you specify both.

In this case, I'm pretty sure that would mean it reduces to just "files:
tests/", but I've never claimed to understand irrelevant-files and I
won't start now.

Anyway, the main point is that Proposal 1 doesn't change the current
behavior which is "everything must match" and Proposal 2 does, meaning
you only get one or the other.

-Jim

__
OpenStack Development Mailing 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] Overriding project-templates in Zuul

[Emilien Macchi]

On Tue, May 1, 2018 at 10:02 AM, James E. Blair  wrote:
[...]

> Okay, let's summarize:
>
> Proposal 1: All project-template and project-local job variants matching
> the item's branch must also match the item.
>
> * Files and irrelevant-files on project-template and project stanzas are
>   essentially combined in a set intersection.
> * It's possible to further reduce the scope of jobs, but not expand.
> * Files and irrelevant-files are still independent matchers, and if both
>   are present, both must match.
> * It's not possible to alter a job attribute by adding a project-local
>   variant with only a files matcher (it would cause the whole job to run
>   or not run).  But it's still possible to do that in the main job
>   definition itself.
>
> Proposal 2: Files and irrelevant-files are treated as overwriteable
> attributes and evaluated after branch-matching variants are combined.
>
> * Files and irrelevant-files are overwritten, so the last value
>   encountered when combining all the matching variants (looking only at
>   branches) wins.
> * Files and irrelevant-files will be treated as a pair, so that if
>   "irrelevant-files" appears, it will erase a previous "files"
>   attribute.
> * It's possible to both reduce and expand the scope of jobs, but the
>   user may need to manually copy values from a parent or other variant
>   in order to do so.
> * It will no longer be possible to alter a job attribute by adding a
>   variant with only a files matcher -- in all cases files and
>   irrelevant-files are used solely to determine whether the job is run,
>   not to determine whether to apply a variant.
>
> I think both would be good solutions to the problem.  The key points for
> me are whether we want to keep the "alter a job attribute with variant
> with a files matcher" functionality (the "rebuild_index" example from
> above), and whether the additional control of overwriting the matchers
> (at the cost of redundancy in configuration) is preferable to combining
> the matchers.
>

In the case of TripleO, I think proposal 2 is what we want.
We have stanzas defined in the templates definitions in
openstack-infra/tripleo-ci repo, but really want to override the file rules
per repo (openstack/tripleo-quickstart for example) and I don't think we
want to have them both matching but so the last value encountered would win.
I'll let TripleO CI squad to give more thoughts though.

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

Re: [openstack-dev] Overriding project-templates in Zuul

[James E. Blair]

Joshua Hesketh  writes:

> I might be misunderstanding at which point a job is chosen to be ran and
> therefore when it's too late to dissuade it. However, if possible, would it
> make more sense for the project-local copy of a job to overwrite the
> supplied files and irrelevant-files? This would allow a project to run a
> job when it otherwise doesn't match.

Imagine that a project with branches has a job added via a template.

project-config/zuul.yaml@master:
- job:
name: my-job
vars: {jobvar: true}

- project-template:
name: myjobs
check:
  jobs:
- my-job:
vars: {templatevar: true}

project/zuul.yaml@master:
- project:
templates:
  - myjobs
check:
  jobs:
- my-job:
vars: {projectvar: true}

project/zuul.yaml@stable:
- project:
templates:
  - myjobs
check:
  jobs:
- my-job:
vars: {projectvar: true}

The resulting project config is:

- project:
jobs:
  - my-job (branches: master; project-local job)
  - my-job (branches: master; project-template job)
  - my-job (branches: stable; project-local job)
  - my-job (branches: stable; project-template job)

When Zuul decides what to run, it goes through each of those in order,
evaluates their matchers, and pulls in parents and their variants for
each that matches.  So a change on the master branch would collect the
following variants to apply:

  my-job (branch: master; project-local job)
my-job (job)
  base (job)
  my-job (branch: master; project-template job)
my-job (job)
  base (job)

It would then apply them in this order:

  base (job)
  my-job (job)
  my-job (branch: master; project-template job)
  my-job (branch: master; project-local job)

To further restrict a project-local job with a "files:" matcher would
cause the project-local job not to match, but the project-template job
will still match, so the job gets run.

That's the situation we have today, which is what I meant by "it's too
late to dissuade it".

Regarding the suggestion to overwrite it, we would need to decide which
of the possible variants to overwrite.  Keep in mind that there are 3
independent matchers operating on all the variants (branches, files,
irrelevant-files).  Does a project-local job with a "files:" matcher
overwrite all of the variants?  Just the ones which match the same
branch?  That would probably be the most reasonable thing to do.

In my mind, that effectively splits the matchers into two categories:
branch matchers, and file matchers.  And they would behave differently.

Zuul could collect the variants as above, considering only the branch
matchers.  It could then apply all of the variants in the normal manner,
treating files and irrelevant-files as normal attributes which can be
overwritten.  Then, once it has composed the job to run based on all the
matching variants, it would only *then* evaluate the files matchers.  If
they don't match, then it would not run the job after all.

I think that's a very reasonable way to solve the issue as well, and I
believe it would match people's expectations.  Ultimately, the outcome
will be very similar to the proposal I made except that rather than
being combined, the matchers will be overwritten.  That means that if
you want to expand the set of irrelevant-files for a job, you would have
to copy the set from the parent.

There's one other aspect to consider -- it's possible to create a job
like this:

- job:
name: doc-job

- jobs:
name: doc-job
files: docs/index.rst
  vars: {rebuild_index: true}

Which means: there's a normal docs job with no variables, but if
docs/index.rst is changed, set the rebuild_index variable to true.
Either approach (combine vs overwrite) eliminates the ability to do this
within a project or project-template stanza.  But the "combine" approach
still lets us do this at the job level.  We could still support this in
the overwrite approach, however, I think it might be simpler to work
with if we eliminated it as well and just always treated files and
irrelevant-files matchers as overwriteable attributes.  It would no
longer be possible to implement the above example, but I'm not sure it's
that useful anyway?

> What happens when something is in both files and irrelevant-files? If the
> project-template is trying to say A is in 'files', but the project-local
> says A is in 'irrelevant-files', should that overwrite it?

I think my statement and table below was erroneous:

>> This effectively causes the "files" and "irrelevant-files" attributes on
>> all of the project-local job definitions matching a given branch to be
>> combined.  The combination of multiple files matchers behaves as a
>> union, and irrelevant-files matchers as an intersection.
>>
>>     ===  ===
>> Matcher   Template  Project  Result
>>     ===  ===
>> files 

Re: [openstack-dev] [mistral] Help with test run

[Clark Boylan]

On Fri, Apr 27, 2018, at 2:22 AM, András Kövi wrote:
> Hi,
> 
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/

Reading the job log the job setup only took a few minutes. Then the unittests 
start and are running continuously until the timeout happens at 30 minutes. 
Chances are that the default 30 minute timeout is not sufficient for this job. 
Runtime may vary based on cloud region and presence of noisy neighbors.

As for making this more reliable you can increase the timeout in the job 
configuration for that job. Another approach would be to make the unittests run 
more quickly. I notice the job is hard coded to use concurrency=1 when invoking 
the test runner so you are only using ~1/8 of the available cpus. You might try 
increasing this value though will likely need to make sure the tests don't 
conflict with each other.

Clark

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

Re: [openstack-dev] [mistral] Help with test run

[Brad P. Crochet]

On Fri, Apr 27, 2018 at 5:23 AM András Kövi  wrote:

> Hi,
>
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/
>
>
I'm not seeing any particular reason for it. Is it happening consistently?


> Thanks,
> Andras
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] Mistral Monthly May 2018

[Dougal Matthews]

Hey Folks!

Welcome to the first Mistral Monthly newsletter!

# Intro

I am going to try sending out a monthly newsletter summarising what is
going on in the world of Mistral. This is an experiment, so feedback would
be very welcome! If you have something you want me to share for next time,
please let me know (or if I missed something this round please reply here).
There is no fixed structure, but that may happen over time. I'll aim to
send it on the 1st of each month.


# Releases

There were quite a few releases in April. I expect there will be a bugfix
release for Queens and Pike this month.

- Rocky
  - Rocky-1 Milestone
https://docs.openstack.org/releasenotes/mistral/unreleased.html
  - mistral-lib 0.5.0 [We don't publish the release notes, we need to fix
that]
  - python-mistralclient 3.4.0
https://docs.openstack.org/releasenotes/python-mistralclient/unreleased.html
- Queens
  - Mistral 6.0.2
https://docs.openstack.org/releasenotes/mistral/queens.html
- Pike
  - Mistral 5.2.3 https://docs.openstack.org/releasenotes/mistral/pike.html

Rocky-2 is due to be released by June 8th.


# Office Hours - https://etherpad.openstack.org/p/mistral-office-hours

The Mistral office hours have been happening regularly on Mondays and
Fridays now. Participation has been good and it has seen a wider and more
varied attendance than the weekly Mistral meetings.

We usually chat about bugs and features that people are interested in. if
there is nothing specific we take the time to do some bug triage. Please
bring yourself and topics to discuss! If none of the current time slots
suit you, please propose an additional one.


# Notable changes and additions

- In Rocky we will have support for Swiftservice and Vitrage actions.
- Workflow executions can no longer be deleted while they are still running
unless the force parameter is provided. This is a backwards incompatible
change, but makes the default behaviour much safer.
- Support for py_mini_racer, a easier to install JavaScript implementation,
was added. Users now have the choice of pyv8, v8eval or py_mini_racer.

# Milestones, Reviews, Bugs and Blueprints

(This will be more interesting in the next edition, when we can see what
changes. Stackalytics is also down, so I can't grab all the stats I wanted)

- We currently have 109 open bugs
  - We now have zero untriaged bugs! This is largely due to the
collaboration during office hours.
  - Two bugs are "critical"
  - The number of open bugs reduced from around 180 a month ago
- 44 bugs are targeted towards Rocky-2 - that is ambitious to say the
least. During Rocky-1 we fixed 23 bugs
- 8 blueprints are targeted for Rocky-2 (3 were implemented in Rocky-1)


That's all for this time. See you next month!

Dougal

[If you get this far, please ping d0ugal on freenode and let me know. I am
just curious to know roughly how many folks are reading. Thanks!]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

Hi Dave,

On Tue, May 1, 2018 at 4:30 AM, Dave Holland  wrote:
> On Mon, Apr 30, 2018 at 12:41:21PM -0400, Mathieu Gagné wrote:
>> Weighers for baremetal cells:
>> * ReservedHostForTenantWeigher [7]
> ...
>> [7] Used to favor reserved host over non-reserved ones based on project.
>
> Hello Mathieu,
>
> we are considering writing something like this, for virtual machines not
> for baremetal. Our use case is that a project buying some compute
> hardware is happy for others to use it, but when the compute "owner"
> wants sole use of it, other projects' instances must be migrated off or
> killed; a scheduler weigher like this might help us to minimise the
> number of instances needing migration or termination at that point.
> Would you be willing to share your source code please?
>

I'm not sure how battle-tested this code is to be honest but here it is:
https://gist.github.com/mgagne/659ca02e63779802de6f7aec8cda612a

I had to merge 2 files in one (the weigher and the conf) so I'm not
sure if it still works but I think you will get the idea.

To use it, you need to define the "reserved_for_tenant_id" Ironic node
property with the project ID to reserve it. (through Ironic API)

This code also assumes you already filtered out hosts which are
reserved for a different tenant. I included that code in the gist too.

On a side note, our technicians generally use the forced host feature
of Nova to target specific Ironic nodes:
https://docs.openstack.org/nova/pike/admin/availability-zones.html

But if the customer buys and reserves some machines, he should get
them first before the ones in the "public pool".

--
Mathieu

__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Jimmy McArthur]

Apologies for the delay, Emilien!  I should be adding it today, but it's 
definitely yours.



Emilien Macchi 
May 1, 2018 at 9:03 AM

Jimmy, could you please confirm we have the TripleO Project Updates 
slot? I don't see it in the schedule.


Thanks,
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Emilien Macchi 
April 30, 2018 at 12:25 PM

This slot is perfect, and I'll run it with one of my tripleo 
co-workers (Alex won't be here).


Thanks,
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 12:05 PM
Alex,

It looks like we have a spot held for you, but did not receive 
confirmation that TripleO would be moving forward with Project 
Update.  If you all will be recording this, we have you down for 
Wednesday from 11:25 - 11:45am.  Just let me know and I'll get it up 
on the schedule.


Thanks!
Jimmy


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Alex Schultz 
April 30, 2018 at 11:52 AM
On Mon, Apr 30, 2018 at 9:47 AM, Jimmy McArthur  wrote:

Project Updates are in their own track:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223



TripleO is still missing?

Thanks,
-Alex


As are SIG, BoF and Working Groups:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218

Amy Marrich
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know I saw
some in the schedule before the Forum submittals were even closed. Maybe
contact speaker support or Jimmy will answer here.

Thanks,

Amy (spotz)


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Emilien Macchi
April 30, 2018 at 10:33 AM



Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
You should also see it update on your Summit App.

Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed but it
would be great to have it advertised as a project update!

Thanks,
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
You should also see it update on your Summit App.

Thank you and see you in Vancouver!
Jimmy


__
OpenStack Development Mailing 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
Jimmy McArthur 
April 30, 2018 at 10:47 AM
Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



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

[openstack-dev] [tc][docs] documenting openstack "constellations"

[Doug Hellmann]

The TC has had an item on our backlog for a while (a year?) to
document "constellations" of OpenStack components to make it easier
for deployers and users to understand which parts they need to have
the features they want [1].

John Garbutt has started writing the first such document [2], but
as we talked about the content we agreed the TC governance repository
is not the best home for it, so I have proposed creating a new
repository [3].

In order to set up the publishing jobs for that repo so the content
goes to docs.openstack.org, we need to settle the ownership of the
repository.

I think it makes sense for the documentation team to "own" it, but
I also think it makes sense for it to have its own review team
because it's a bit different from the rest of the docs and we may
be able to recruit folks to help who might not want to commit to
being core reviewers for all of the documentation repositories. The
TC members would also like to be reviewers, to get things going.

So, is the documentation team willing to add the new "constellations"
repository under their umbrella? Or should we keep it as a TC-owned
repository for now?

Doug

[1] https://storyboard.openstack.org/#!/story/2001702
[2] https://review.openstack.org/565466
[3] https://review.openstack.org/565498

__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Emilien Macchi]

On Mon, Apr 30, 2018 at 10:25 AM, Emilien Macchi  wrote:

> On Mon, Apr 30, 2018 at 10:05 AM, Jimmy McArthur 
> wrote:
>>
>> It looks like we have a spot held for you, but did not receive
>> confirmation that TripleO would be moving forward with Project Update.  If
>> you all will be recording this, we have you down for Wednesday from 11:25 -
>> 11:45am.  Just let me know and I'll get it up on the schedule.
>>
>
> This slot is perfect, and I'll run it with one of my tripleo co-workers
> (Alex won't be here).
>

Jimmy, could you please confirm we have the TripleO Project Updates slot? I
don't see it in the schedule.

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

Re: [openstack-dev] [All] [Elections] Rocky TC Election Results

[Doug Hellmann]

Excerpts from Kendall Nelson's message of 2018-05-01 00:02:36 +:
> Hello Everyone :)
> 
> Please join me in congratulating the 7 newly elected members of the
> Technical Committee (TC)!
> 
> 
>- Thierry Carrez (ttx)]
>- Chris Dent (cdent)
>- Sean McGinnis (smcginnis)
>- Davanum Srinivas (dims)
>- Zane Bitter (zaneb)
>- Graham Hayes (mugsie)
>- Mohammed Naser (mnaser)
> 
> 
> Full results:
> https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d
> 
> Election process details and results are also available here:
> https://governance.openstack.org/election/
> 
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
> 
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voices are heard!
> 
> Thank you for another great round.
> 
> -Kendall Nelson (diablo_rojo)
> 
> [1] https://review.openstack.org/#/c/565368/
> 

Congratulations to the new and returning TC members!

I hope that some of the folks who ran this time but did not make
the cut will join us in discussions and help with initiatives they
would have participated in if they were elected. It is always good
for us to have more perspectives.

Doug

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

Re: [openstack-dev] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate

[Steven Dake (stdake)]

Mark,

The major constraint here is gate memory (which is maxed at 8gb).  This is 
barely enough to run compute-kit (which is tested).  Now that multiple nodes 
are a thing, it may be possible to run computekit on one node, and other 
services on other nodes.  (IOW the environment has changed, and may be more 
conducive to adding more gating).

Cheers
-steve

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

Date: Monday, April 30, 2018 at 4:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Zun][Kolla][Kolla-ansible] Verify Zun deployment 
in Kolla gate

Hi,

This is something I've been thinking about recently. In particular, I noticed a 
patch go by to fix the same issue in the magnum role that has been broken and 
fixed previously. Kolla needs to up its game in terms of CI testing.

At the very least, we need tests that verify that services can be deployed. 
Even if we don't verify that the deployed service is functional, this will be 
an improvement from where we are today.

As with many things, we won't get there in a single leap, but should look to 
incrementally improve test coverage, perhaps with a set of milestones spanning 
multiple releases.

I suggest our first step should be to add a set of experimental jobs for 
testing particular services. These would not run against every patch, but could 
be invoked on demand by commenting 'check experimental' on a patch in Gerrit. 
For many services this could be done simply by setting 'enable_=true' 
in config.

There are many paths we could take from there, but perhaps this would be best 
discussed at the next PTG?

Cheers,
Mark

On Mon, 30 Apr 2018, 14:07 Jeffrey Zhang, 
> wrote:
Thanks hongbin

In Kolla, one job is used to test multi OpenStack services. there are already 
two test scenarios.

1. without ceph
2. with ceph

each scenario test a serial of OpenStack services. like nova, neutron, cinder 
etc.
Zun or kuryr is not tested now.  But i think it is OK to add a new scenario to 
test network related
service, like zun and kuryr.

for tempest testing, there is a WIP bp for this[0]

[0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate

On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu 
> wrote:
Hi Kolla team,

Recently, I saw there are users who tried to install Zun by using Kolla-ansible 
and reported bugs to us whenever they ran into issues (e.g. 
https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of this 
usage pattern (Kolla + Zun) made me think that we need to have CI coverage to 
verify the Zun deployment setup by Kolla.

IMHO, the ideal CI workflow should be:

* Create a VM with different distros (i.e. Ubuntu, CentOS).
* Use Kolla-ansible to stand up a Zun deployment.
* Run Zun's tempest test suit [1] against the deployment.

My question for Kolla team is if it is reasonable to setup a Zuul job as 
described above? or such CI jobs already exist? If not, how to create one?

[1] https://github.com/openstack/zun-tempest-plugin

Best regards,
Hongbin

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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] Default scheduler filters survey

[Tim Bell]

You may also need something like pre-emptible instances to arrange the clean up 
of opportunistic VMs when the owner needs his resources back. Some details on 
the early implementation at 
http://openstack-in-production.blogspot.fr/2018/02/maximizing-resource-utilization-with.html.

If you're in Vancouver, we'll be having a Forum session on this 
(https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21787/pre-emptible-instances-the-way-forward)
 and notes welcome on the etherpad 
(https://etherpad.openstack.org/p/YVR18-pre-emptible-instances)

It would be good to find common implementations since this is a common scenario 
in the academic and research communities.

Tim

-Original Message-
From: Dave Holland 
Date: Tuesday, 1 May 2018 at 10:40
To: Mathieu Gagné 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, openstack-operators 

Subject: Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler 
filters survey

On Mon, Apr 30, 2018 at 12:41:21PM -0400, Mathieu Gagné wrote:
> Weighers for baremetal cells:
> * ReservedHostForTenantWeigher [7]
...
> [7] Used to favor reserved host over non-reserved ones based on project.

Hello Mathieu,

we are considering writing something like this, for virtual machines not
for baremetal. Our use case is that a project buying some compute
hardware is happy for others to use it, but when the compute "owner"
wants sole use of it, other projects' instances must be migrated off or
killed; a scheduler weigher like this might help us to minimise the
number of instances needing migration or termination at that point.
Would you be willing to share your source code please?

thanks,
Dave
-- 
** Dave Holland ** Systems Support -- Informatics Systems Group **
** 01223 496923 **Wellcome Sanger Institute, Hinxton, UK**


-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

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


__
OpenStack Development Mailing 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] Default scheduler filters survey

[Simon Leinen]

[Resending for a colleague who's not on openstack-dev-- SL.]

Yeap, because of the bug [#1677217] in the standard
AggregateImagePropertiesIsolation filter, we have written a custom
Nova scheduler filter.

The filter AggregateImageOsDistroIsolation is a simplified version the
AggregateImagePropertiesIsolation, based only on the 'os_distro' image
property.
https://github.com/valerytschopp/nova/blob/aggregate_image_isolation/nova/scheduler/filters/aggregate_image_os_distro_isolation.py

[#1677217] https://bugs.launchpad.net/nova/+bug/1677217

Cheers,
Valery

On 29/04/18, 23:29 , "Ed Leafe"  wrote:

> On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:
>> 
>> Based on that, we can definitely say that SameHostFilter and
>> DifferentHostFilter do *not* belong in the defaults. In fact, we got
>> our defaults pretty spot on, based on this admittedly very limited
>> dataset. The only frequently occurring filter that's not in our
>> defaults is AggregateInstanceExtraSpecsFilter.

> Another data point that might be illuminating is: how many sites
> use a custom (i.e., not in-tree) filter or weigher? One of the
> original design tenets of the scheduler was that we did not want to
> artificially limit what people could use to control their deployments,
> but inside of Nova there is a lot of confusion as to whether anyone is
> using anything but the included filters.

> So - does anyone out there rely on a filter and/or weigher that they 
> wrote themselves, and maintain outside of OpenStack?

> -- Ed Leafe





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


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

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

[Slawomir Kaplonski]

Hi,

I have to cancel today’s Neutron CI meeting because of Public holidays in many 
countries. 
Next meeting will be on 8th May.

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com




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