[openstack-dev] What's Up, Doc? 15 July

[Lana Brindley]

Hi everyone,

CFP for the Barcelona Summit closed this week, so I've been caught up in the 
flurry of talk submissions. I hope you got yours in on time! We have more 
Installation Tutorials going up all the time, with Swift up and Designate now 
in progress. I'd also like to remind you all that we have instructions for 
creating your team's Install Tutorial in our Contributor Guide here: 
http://docs.openstack.org/contributor-guide/project-install-guide.html We'd 
love to get your feedback on that content!

== Progress towards Newton ==

82 days to go!

Bugs closed so far: 280

Newton deliverables: 
https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
Feel free to add more detail and cross things off as they are achieved 
throughout the release.

The CFP for Barcelona is now closed. Best of luck to everyone who submitted a 
talk :)

== Speciality Team Reports ==

'''HA Guide: Bogdan Dobrelya'''
No report this week.

'''Install Tutorials: Lana Brindley'''
Continued to publish new guides, Swift is now up, Designate is on review. 
Submitted Summit talk on this topic. Don't miss our instructions for creating a 
new Install Tutorial: 
http://docs.openstack.org/contributor-guide/project-install-guide.html  Next 
meeting: 19 July 0600 UTC

'''Networking Guide: Edgar Magana'''
No meeting this week.

'''Security Guide: Nathaniel Dillon'''
No report this week.

'''User Guides: Joseph Robinson'''
No report this week.

'''Ops Guide: Shilla Saebi'''
OpenStack ops guide reorg in progress & documented here: 
https://etherpad.openstack.org/p/ops-guide-reorg
Added enterprise docs troubleshooting information to the Ops Guide

'''API Guide: Anne Gentle'''
Keystone API sprint this week, details are here: 
https://etherpad.openstack.org/p/keystone-api-sprint Lance Bragstad is on FIRE!
Review these api-ref patchsets in progress: 
https://review.openstack.org/#/q/status:open+file:api-ref
Working on a plan for how to merge HTTP Status Code tables and Graham Hayes's 
patch to use the openstackdocstheme and Karen Bradshaw's overall API navigation 
in time for release, stay tuned.

'''Config/CLI Ref: Tomoyuki Kato'''
Got feedbacks from Dolph Matthews, thank you! Closed a few bugs. Updated some 
CLI reference.

'''Training labs: Pranav Salunke, Roger Luethi'''
Many minor improvements to training-labs library scripts
Finalizing PXE feature, still more work is required but the current patch 
should be in a state to be merged soon.
Finalizing parser POC to parse install-guides to BASH for testing install 
guides and also auto-creation of guest side scripts for training-labs

'''Training Guides: Matjaz Pancur'''
Removed unused images for Training guides, improvements on Getting Started 
(core and optional services, link updates).

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Rodrigo Caballero'''
No report this week.

== Core Team Review ==

Regretfully, Diane Fleming is no longer a core team member. I'd like to thank 
Diane for all her contributions to our team. She's been a powerhouse core team 
member since well before I did my very first OpenStack patch, and I think it's 
fair to say that many of us wouldn't be here without Diane's support and 
guidance.

== Site Stats ==

The number of people browsing the site using Opera has dropped by 5% over the 
past 30 days, but nearly 20% more people are using Edge (which I'm told is the 
new Windows browser that's replacing IE). Oddly, IE users have increased 
slightly as well, though, by 7%. Are people abandoning their Macs?!

== Doc team meeting ==

Next meetings:

The APAC meeting was held this week (big thanks to Joseph for chairing that 
meeting in my absence!), you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-07-13

Next meetings:
US: Wednesday 20 July, 19:00 UTC
APAC: Wednesday 27 July, 00:30 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#15_July_2016

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



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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Cheng, Yingxin]

On 7/14/16, 12:18, "Edward Leafe"  wrote:
On Jul 13, 2016, at 9:38 PM, Cheng, Yingxin  wrote:
>>Thinking about that a bit, it would seem that a host aggregate could 
also be represented as a namespace:name tag. That makes sense, since the fact 
that a host belongs to a particular aggregate is a qualitative aspect of that 
host.
>> 
> 
> Thanks for the feedback!
> 
> We’ve thought about the relationship between capability tags and host 
aggregates carefully. And we decide not to blend it with host aggregates, for 
several reasons below:
> 1. We want to manage capabilities in only ONE place, either in host 
aggregates, compute_node records or with resource_provider records.
> 2. Compute services may need to attach discovered capabilities to its 
host. It is inconvenient if we store caps with host aggregates, because 
nova-compute needs to create/search host aggregates first, it can’t directly 
attach caps.
> 3. Other services may need to attach discovered capabilities to its 
resources. So the best place is to its related resource pool, not aggregates, 
nor compute_node records. Note the relationship between resource pools and host 
aggregates are N:N.
> 4. It’s logically correct to store caps with resource_providers, because 
caps are actually owned by nodes or resource pools.
> 5. Scheduling will be faster if resource-providers are directly attached 
with caps.
> 
> However, for user-defined caps, it still seems easier to manage them with 
aggregates. We may want to manage them in a way different from pre-defined 
caps. Or we can indirectly manage them through aggregates, but they are 
actually stored with compute-node resource-providers in placement db.

Oh, I think you misunderstood me. Capabilities definitely belong with 
resource providers, not host aggregates, because not all RPs are hosts.
I'm thinking that host aggregates themselves are equivalent to capabilities 
for hosts. Imagine we have 10 hosts, and put 3 of them in an aggregate. How is 
that different than if we give those three a tag with the 'host_agg' namespace, 
and with tag named for the agg?
I'm just thinking out loud here. There might be opportunities to simplify a 
lot of the code between capability tags and host aggregates in the future, 
since it looks like host aggs are a structural subset of RP capability tags.

-- Ed Leafe


Your concerns are correct. The major goal of “Capability Tags” series is to 
*replace* existing capability-like functionalities in Nova and Scheduler with a 
more generic and extensible implementation.

As you said, host aggregates themselves are equivalent to capabilities for 
hosts. We should continue support this way with the new “Capability Tags” 
implementation. Currently users can write free-formed metadata to host 
aggregates, then scheduler can process them through 
“AggregateImagePropertiesIsolation” and “AggregateInstanceExtraSpecsFilter”, 
when users can specify those caps in image-props and flavor extra-specs. This 
means we need to support capability tags in group granularity, i.e. to tag caps 
to host aggregates. It can be in a separate implementation called “Aggregate 
Capability Tags”, replacing current implementation with the two mentioned 
aggregate filters.

As for “Resource Provider Capability Tags”, we are managing capabilities in a 
finer granularity: host and resource pool level. Currently users can only use 
pre-defined caps such as “architecture”, “hypervisor-types”, 
“hypervisor-versions” and “vm-mode” in host states, which can be processed by 
“ImagePropertiesFilter” and “ComputeCapabilitiesFilter” and “JsonFilter”, when 
users can specify them in image-props, flavor extra-specs and scheduler hints. 
We are designing “Resource Provider Capability Tags” to replace them and 
providing extensibility to add more service-defined and user-defined caps in a 
generic way.

The above also means we may want to manage caps in a separate table, and 
maintain their relationship with resource providers and host aggregates. So we 
can query existing caps, validate them in image-props, flavor extra-specs and 
scheduler hints, and manage them in a consistent way.


---
Regards
Yingxin





__
OpenStack Development Mailing 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] Naming polls - and some issues

[Jamie Lennox]

Partially because its name is Circular Quay, so it would be like calling
the S release Street for  Street.

Having said that there are not that many of them and Sydney people know
what you mean when you are going to the Quay.


On 14 July 2016 at 21:35, Neil Jerram  wrote:

> Not sure what the problem would be with 'Quay' or 'Street' - they both
> sound like good options to me.
>
>
> On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn  wrote:
>
>>
>>
>> > >> Hey all!
>> > >>
>> > >> The poll emails for the P and Q naming have started to go out - and
>> > >> we're experiencing some difficulties. Not sure at the moment what's
>> > >> going on ... but we'll keep working on the issues and get ballots to
>> > >> everyone as soon as we can.
>> > >
>> > > You'll need to re-send at least some emails, because the link I
>> received
>> > > is wrong - the site just reports
>> > >
>> > >   "Your voter key is invalid. You should have received a correct URL
>> by
>> > >   email."
>> >
>> > Yup. That would be a key symptom of the problems. One of the others is
>> > that I just uploaded 3000 of the emails to the Q poll and it shows 0
>> > active voters.
>> >
>> > I think maybe it needs a nap...
>>
>> Any chance we could remove "Quay" from the Q release naming poll before
>> the links are fixed and the real voting starts?
>>
>> Otherwise we risk looking a bit silly, since "Quay" for the Q release
>> would be somewhat akin to choosing "Street" for the S release ;)
>>
>> Cheers,
>> Eoghan
>>
>> __
>> OpenStack Development Mailing 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] [kolla] our mascot - input needed

[Britt Houser (bhouser)]

Koala is the best by a long shot. These ideas are all total stretches:
  Bee on a honeycomb – Its kinda like the bee is orchestrating containers of 
honey.
  Armadillo – It rolls up into a ball and is "immutable"

Thx,
britt

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 14, 2016 at 4:08 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] our mascot - input needed

Hey folks,

The OpenStack foundation is putting together mascots for every project with a 
proper artist doing the work.  The cool thing about this is we a) get stickers 
b) have consistent look and feel among mascots in OpenStack.

The downside is we have to make a decision.  The foundation wants 3-5 choices.

The mascot must be an animal and it can't involve glue or other inc007 inspired 
ideas :)

Obviously Koala bear is probably everyone's first choice since we have sort of 
been using that as a mascot since day one.  Anyone else have anything else for 
me to provide the foundation with a choices 2-5?

Please respond quickly, the foundation needs the information shortly.  I'd like 
to offer up two alternatives just in case.

Regards
-steve


__
OpenStack Development Mailing 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][qa] When do we need tests for microversions in Tempest?

[Matt Riedemann]

On 7/13/2016 10:18 PM, Ken'ichi Ohmichi wrote:

Hi Matt,


2016-07-14 11:55 GMT+09:00 Matt Riedemann :

There are several changes in Tempest right now trying to add response schema
validation for the 2.26 microversion which added server tags to the server
GET response. This is needed for anything testing a microversion >=2.26,
which several people are trying to add.

We have a similar issue with the 2.3 microversion which is really a bug, but
only exposed in jobs that have run_validation=True which is only in a
non-voting job right now.

I've mostly been debating this in this change:

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

I've added an item to the nova midcycle meetup agenda to talk about the plan
for handling microversion testing in tempest for nova changes, specifically
around API response validation.

I agree that nova doesn't test response schema validation in tree, so doing
it in tempest is good.

But I'm not sure that we need a new set of tempest tests for every
microversion change in nova, e.g. if it's only touching the API and
database, like server tags, we can test that in nova.


I think it is nice to implement every microversion tests in Tempest
for preparing the base/minimum microversion bump in the future.
On API microversions mechanism, we have defined the minimum
microversion(now version 2.1) can be increased.
Every microversion test will provide an option when we want to bump it
to verify a new minimum microversion is stable by Tempest as an
integrated test.


We're pretty far out from raising the minimum required microversion in 
Nova I think, like several releases at least.


The issue I have really is a few releases ago there was a push to pair 
down how much is tested in Tempest in the integrated gate, and if tests 
only hit the API for a single service, those tests should live in the 
project/service that's being tested. This is why the CLI tests moved out 
and a bunch of things that only hit the API and database.


We'd be going back on that now if we need to implement a test for every 
microversion that shows up.


Maybe Nova needs to think about a Tempest plugin for stuff like that?




It's also not great having several changes in flight at the same time to
tempest trying to add the same 2.26 response schema because it wasn't added
the at the same time the 2.26 API merged.

I also wonder what it means if someone configures max_microversion in
tempest.conf to something we don't test, like say 2.11, what blows up? For
example, we know that we don't have response validation for 2.3 so some
tests are broken when you run with ssh validation and microversion>=2.3.


Ideally, the response schema also should be implemented on Tempest.
but it is difficult to catch up because the microversion bumping is
fast on Nova side.
The max_microversion option is useful to operate the same Tempest to
master/stable branches which are different microversions.

Thanks
Ken Ohmichi

---


So I'm thinking we should:

1. Always add a schema change to Tempest if a microversion changes a
response.

2. Only add tests to Tempest for a microversion change if it can't be tested
within nova, e.g. you actually need to create a server, or use other
services like glance/cinder/neutron.

mtreinish and sdague will be at the nova midcycle so hopefully they can
represent for the QA team.

--

Thanks,

Matt Riedemann


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


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




--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [TripleO] 3rd party CI

[Wesley Hayutin]

On Thu, Jul 14, 2016 at 5:13 PM, Emilien Macchi  wrote:

> On Thu, Jul 14, 2016 at 4:45 PM, Wesley Hayutin 
> wrote:
> > Greetings,
> >
> > Just wanted to let folks know we're bringing up two 3rd party gates for
> > TripleO CI atm.
> >
> > 1. The first gate will be for upgrading from mitaka -> newton/master
> > 2. The second gate will be for running TripleO CI on RHEL 7.2
> >
> > We're working out the logging for #2.  ATM we're going to try and store
> the
> > logs on an openshift gear as we don't have a public file server
> available.
> > If anyone has a public server where we can store logs and would like to
> > help, please let us know.
> >
> > If you have any questions please let us know.
>
> Great, this is a cool news.
> Can you provide the link of git repos that execute the jobs?
> So anyone can contribute to it and also see what it's actually testing
> (what scenario, etc).
>
> Thanks,
> --
> Emilien Macchi
>

TripleO RHEL will run w/ the normal TripleO-Quickstart playbook w/ RHEL
images [1]

Upgrades, will run a liberty deployment using [4], but is the functional
equivalent of [1] on CentOS, then execute the upgrade w/ [2]
Example [4] adds some additional inventory steps required to reach out to
all the nodes in the deployment and is an example of composable roles.

Let us know if you need more information.
Thanks

[1]
https://github.com/openstack/tripleo-quickstart/blob/master/playbooks/quickstart.yml
[2]
https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-upgrade/blob/master/playbooks/upgrade.yml

[3]
https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-upgrade
[4]
https://github.com/openstack/tripleo-quickstart/blob/master/playbooks/tripleo-roles.yml



>
> __
> OpenStack Development Mailing 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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Not sure why the URL is wrong. Please use this 
https://etherpad.openstack.org/p/zaqar-project-mascot  Thanks.


On 15/07/16 11:25, Fei Long Wang wrote:

Hi team,

I've created an etherpad [1] to discuss mascots for Zaqar project. 
Please input and vote. Thanks.


[1] https://etherpad.openstack.org/p/zaqar-project-mascot
--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email:flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
OpenStack Development Mailing 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] [zaqar] Mascot for Zaqar

[Fei Long Wang]

Hi team,

I've created an etherpad [1] to discuss mascots for Zaqar project. 
Please input and vote. Thanks.


[1] https://etherpad.openstack.org/p/zaqar-project-mascot 



--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
OpenStack Development Mailing 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] Naming polls - and some issues

[Mike Carden]

On Thu, Jul 14, 2016 at 9:35 PM, Neil Jerram  wrote:

> Not sure what the problem would be with 'Quay' or 'Street' - they both
> sound like good options to me.
>

A possible issue with 'Quay' is that it's pronounced 'Key' which may case
phonetic confusion wherein it's mistaken for a 'K' release.

Then again, I may be biased because I'm an Australian and I live 15km from
'Queanbeyan' (which by the way is never pronounced anything like 'Queen
Bean' as is suggested in the wiki).

-- 
MC
__
OpenStack Development Mailing 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Brent Troge]

dont you have to set something like the below in your flavor ?

 aggregate_instance_extra_specs:volume_type=ZOL

On Thu, Jul 14, 2016 at 4:07 PM, Turbo Fredriksson  wrote:

> On Jul 14, 2016, at 5:44 PM, Turbo Fredriksson wrote:
>
> > EXCEPT, I get Subj. when trying to create an instance.
>
>
> Do I need to set some configuration on the Compute host
> as well?
> --
> God gave man both a penis and a brain,
> but unfortunately not enough blood supply
> to run both at the same time.
> - R. Williams
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
__
OpenStack Development Mailing 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][qa] When do we need tests for microversions in Tempest?

[Matt Riedemann]

On 7/14/2016 3:11 AM, GHANSHYAM MANN wrote:

1. Always add a schema change to Tempest if a microversion changes a
response.


The problem with this is we shouldn't land a schema change by itself in tempest.
Until we have something using the schema we have no verification that they
actually work. We can and will land incorrect schemas if we did this. That's why
there is a pretty strong policy of only landing code that is run in CI somewhere
for Tempest.


+1, yes we should not add those without testing.



OK, good point on not landing changes that aren't tested. That's pretty 
obvious.


For something like this though:

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

The gate-tempest-dsvm-neutron-full-ssh is testing it indirectly, so I'm 
assuming that's OK even though we don't have an explicit test for the 
2.3 microversion?


I know the patch needs to be updated for the other extended server 
attributes in that microversion, but it's the immediate thing I want to 
get fixed so we can get on with making the 
gate-tempest-dsvm-neutron-full-ssh job voting.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [TripleO] 3rd party CI

[Emilien Macchi]

On Thu, Jul 14, 2016 at 4:45 PM, Wesley Hayutin  wrote:
> Greetings,
>
> Just wanted to let folks know we're bringing up two 3rd party gates for
> TripleO CI atm.
>
> 1. The first gate will be for upgrading from mitaka -> newton/master
> 2. The second gate will be for running TripleO CI on RHEL 7.2
>
> We're working out the logging for #2.  ATM we're going to try and store the
> logs on an openshift gear as we don't have a public file server available.
> If anyone has a public server where we can store logs and would like to
> help, please let us know.
>
> If you have any questions please let us know.

Great, this is a cool news.
Can you provide the link of git repos that execute the jobs?
So anyone can contribute to it and also see what it's actually testing
(what scenario, etc).

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] [ironic] v2 API meeting cancelled for July 19

[Jim Rollenhagen]

Hey all,

Just a reminder the v2 API meeting will be cancelled for July 19, as
both Deva and I will be at the Nova midcycle. We'll resume on July 26.

// 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

On Jul 14, 2016, at 5:44 PM, Turbo Fredriksson wrote:

> EXCEPT, I get Subj. when trying to create an instance.


Do I need to set some configuration on the Compute host
as well?
--
God gave man both a penis and a brain,
but unfortunately not enough blood supply
to run both at the same time.
- R. Williams


__
OpenStack Development Mailing 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

On Jul 14, 2016, at 8:39 PM, Brent Troge wrote:

> Do you see anything in your nova scheduler logs ?
> What about your nova compute logs ?

None. Nothing other than the section I posted.

> How big is the image you are trying to boot ? I see you have a 10G boot
> disk, but can your boot image fit on this size disk ?

The image require 8.8GB or something like that. It's well
within the 10GB image I'm trying to create..
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson


__
OpenStack Development Mailing 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] 3rd party CI

[Wesley Hayutin]

Greetings,

Just wanted to let folks know we're bringing up two 3rd party gates for
TripleO CI atm.

1. The first gate will be for upgrading from mitaka -> newton/master
2. The second gate will be for running TripleO CI on RHEL 7.2

We're working out the logging for #2.  ATM we're going to try and store the
logs on an openshift gear as we don't have a public file server available.
If anyone has a public server where we can store logs and would like to
help, please let us know.

If you have any questions please let us know.

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] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

Henry Gessau  wrote:
> In accordance with the Blueprint [1] and the spec [2], we are in the process
> of deprecating the use of the term 'tenant' in favor of 'project'.
> 
> The code change [3] with the biggest impact on Neutron developers is currently
> out for review and will merge quite soon (shortly after N-2). This change
> renames all 'tenant_id' columns in the database to 'project_id'.
> 
> If you have any changes in flight that touch a tenant_id field, you will be
> affected. Please familiarize yourself with [3], rebase on it, and comply with
> the changes.
> 
> One patch known to be affected is [4].
> 
> The column rename change has been designed to have minimal impact on the usage
> of 'tenant_id' fields. For now 'tenant_id' is still available as a
> key/property in resource dicts and objects, and as an attribute in request
> contexts.
> 
> In the long run (Ocata or beyond) we want to end up with no usages of the term
> 'tenant', except in the API for backwards compatibility. Existing usages of
> 'tenant' in the codebase will be converted to 'project' on a case-by-case
> basis. Although the conversion has not yet commenced, any *new* fields,
> arguments, variables, etc. with 'tenant' in the name will no longer be 
> accepted.
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
> [3] https://review.openstack.org/335786
> [4] https://review.openstack.org/244680

This work also affects repos that integrate with neutron and have tables in
the Neutron database. We have started to submit patches for the neutron-fwaas,
-lbaas, and -vpnaas repos, and we are keeping track of the progress with an
etherpad [5].

I have listed all the Neutron Stadium projects there, as well as all the
projects that I could find hosted on git.openstack.org that integrate with the
Neutron DB. Please help by signing up for a project.

If you encounter any problem or issues, please ask us for help. Either reply
to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron IRC
channel.

[5] https://etherpad.openstack.org/p/neutron-stadium-tenant2project


__
OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

[Fox, Kevin M]

I'm going to go ahead and ask the difficult question now as the answer is 
relevant to the attached proposal...

Should we reconsider whether the big tent is the right approach going forward?

There have been some major downsides I think to the Big Tent approach, such as:
 * Projects not working together because of fear of adding extra dependencies 
Ops don't already have
 * Reimplementing features, badly, over and over again in different projects 
instead of standardizing something.
 * More projects being created due to politics and not technical reasons.
 * Less cross project communication
 * Greater Operator pain at trying to assemble a more loose confederation of 
projects into something useful.
 * General pushing off more and more work to Operators/Users to deal with.
 * Worse User experience as cross project issues aren't being addressed.
 * Previously incubated projects such as Nova, Swift, etc getting a 
disproportionate say in things as they have a greater current user base, and 
its increasingly hard now for new projects to gain any traction.
 * Much less community pressure on projects to work together to elevate 
everyone. Architectural decisions are now made at individual project level with 
little done at the OpenStack level.
 * etc...

The overall goal of the Big Tent was to make the community more inclusive. That 
I think has mostly happened. Which is good. But It also seems to have fractured 
the community more into insular islands and made the system harder for our 
operators/users. Which is bad.

Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its 
probably time to consider if it has been a net positive and should be further 
refined to try and address some of these problems, or a net negative and 
different approaches be explored.

Thanks,
Kevin

From: Hayes, Graham [graham.ha...@hpe.com]
Sent: Thursday, July 14, 2016 12:21 PM
To: OpenStack Development Mailing List (not for usage questions); 
openstack...@lists.openstack.org
Subject: [openstack-dev] [tc][all] Plugins for all

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Matt Riedemann]

On 7/14/2016 11:34 AM, Paul Bourke wrote:

Hi Matt,

Here is the failure from nova_compute on trying to start an instance:

2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
-] Error starting thread.
2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service Traceback (most recent call last):
2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py",
line 708, in run_service
2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service service.start()
2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py",
line 117, in start
2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.manager.init_host()
2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py",
line 1122, in init_host
2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.driver.init_host(host=self.host)
2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 467, in init_host
2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self._parse_migration_flags()
2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 689, in _parse_migration_flags
2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service live_migration_flags, live_config_name)
2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 644, in _handle_live_migration_auto_converge
2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service migration_flags &=
~libvirt.VIR_MIGRATE_AUTO_CONVERGE
2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service AttributeError: 'module' object has no attribute
'VIR_MIGRATE_AUTO_CONVERGE'

The full log can be viewed at
http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704


-Paul

On 14/07/16 17:13, Matt Riedemann wrote:

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C&P isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278



If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
get these values from libvirt:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633



Could be something patched out of the versions you're using from the
distro maybe?

The actual failure paste/trace would help.



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



Looks like you have the minimum versions of libvirt and qemu required 
for VIR_MIGRATE_AUTO_CONVERGE but for whatever reason it's not actually 
in libvirt in the image you're testing against.


I'm not sure it would matter, but what version of libvirt-python is 
being used?


I'd probably ping danpb or kashyap about this in #openstack-nova in IRC.

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [tc][all] Plugins for all

[Matt Riedemann]

On 7/14/2016 2:21 PM, Hayes, Graham wrote:

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

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



Just for my own understanding, are you suggesting that something like 
nova, cinder or neutron become optional for an openstack cloud?


And does this also include plugins within projects, like storage 
backends in cinder and hypervisor drivers in nova?


Nova has been pushing for a few releases now on getting rid of plug 
points since they are barriers to interoperability.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [kolla] our mascot - input needed

[Steven Dake (stdake)]

Hey folks,

The OpenStack foundation is putting together mascots for every project with a 
proper artist doing the work.  The cool thing about this is we a) get stickers 
b) have consistent look and feel among mascots in OpenStack.

The downside is we have to make a decision.  The foundation wants 3-5 choices.

The mascot must be an animal and it can't involve glue or other inc007 inspired 
ideas :)

Obviously Koala bear is probably everyone's first choice since we have sort of 
been using that as a mascot since day one.  Anyone else have anything else for 
me to provide the foundation with a choices 2-5?

Please respond quickly, the foundation needs the information shortly.  I'd like 
to offer up two alternatives just in case.

Regards
-steve


__
OpenStack Development Mailing 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Brent Troge]

Do you see anything in your nova scheduler logs ?
What about your nova compute logs ?

How big is the image you are trying to boot ? I see you have a 10G boot
disk, but can your boot image fit on this size disk ?



On Thu, Jul 14, 2016 at 2:13 PM, Turbo Fredriksson  wrote:

> On Jul 14, 2016, at 6:53 PM, Brent Troge wrote:
>
> > can you send output of the below..
> >
> > nova service-list
> > nova flavor-show z1.3small
> > nova aggregate-details zfs
>
>
> I've never got "nova" to work, but here's the corresponding
> info from "openstack":
>
> - s n i p -
> bladeA01:~# openstack compute service list
>
> ++--+--+--+-+---++
> | Id | Binary   | Host | Zone | Status  | State | Updated
> At |
>
> ++--+--+--+-+---++
> |  6 | nova-conductor   | bladeA01 | internal | enabled | up|
> 2016-07-14T19:12:38.00 |
> |  7 | nova-scheduler   | bladeA01 | internal | enabled | up|
> 2016-07-14T19:12:36.00 |
> | 10 | nova-compute | bladeA03 | nova | enabled | up|
> 2016-07-14T19:12:29.00 |
> | 11 | nova-console | bladeA03 | internal | enabled | up|
> 2016-07-14T19:12:49.00 |
> | 12 | nova-consoleauth | bladeA03 | internal | enabled | up|
> 2016-07-14T19:12:48.00 |
>
> ++--+--+--+-+---++
> bladeA01:~# openstack flavor show z1.3small
> ++--+
> | Field  | Value|
> ++--+
> | OS-FLV-DISABLED:disabled   | False|
> | OS-FLV-EXT-DATA:ephemeral  | 0|
> | disk   | 10   |
> | id | fea57bb6-0c85-454a-b5b7-1169f3e42a49 |
> | name   | z1.3small|
> | os-flavor-access:is_public | True |
> | properties | volume_type='ZOL'|
> | ram| 2048 |
> | rxtx_factor| 1.0  |
> | swap   |  |
> | vcpus  | 1|
> ++--+
> bladeA01:~# openstack aggregate show zfs
> +---++
> | Field | Value  |
> +---++
> | availability_zone | nova   |
> | created_at| 2016-07-14T12:16:05.00 |
> | deleted   | False  |
> | deleted_at| None   |
> | hosts | [u'bladeA03']  |
> | id| 10 |
> | name  | zfs|
> | properties| volume_type='ZOL'  |
> | updated_at| None   |
> +---++
> - s n i p -
> --
> Att inse sin egen betydelse är som att få ett kvalster att
> fatta att han bara syns i mikroskop
> - Arne Anka
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
__
OpenStack Development Mailing 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][all] Plugins for all

[Hayes, Graham]

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova, 
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things 
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

__
OpenStack Development Mailing 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

On Jul 14, 2016, at 6:53 PM, Brent Troge wrote:

> can you send output of the below..
> 
> nova service-list
> nova flavor-show z1.3small
> nova aggregate-details zfs


I've never got "nova" to work, but here's the corresponding
info from "openstack":

- s n i p -
bladeA01:~# openstack compute service list
++--+--+--+-+---++
| Id | Binary   | Host | Zone | Status  | State | Updated At
 |
++--+--+--+-+---++
|  6 | nova-conductor   | bladeA01 | internal | enabled | up| 
2016-07-14T19:12:38.00 |
|  7 | nova-scheduler   | bladeA01 | internal | enabled | up| 
2016-07-14T19:12:36.00 |
| 10 | nova-compute | bladeA03 | nova | enabled | up| 
2016-07-14T19:12:29.00 |
| 11 | nova-console | bladeA03 | internal | enabled | up| 
2016-07-14T19:12:49.00 |
| 12 | nova-consoleauth | bladeA03 | internal | enabled | up| 
2016-07-14T19:12:48.00 |
++--+--+--+-+---++
bladeA01:~# openstack flavor show z1.3small
++--+
| Field  | Value|
++--+
| OS-FLV-DISABLED:disabled   | False|
| OS-FLV-EXT-DATA:ephemeral  | 0|
| disk   | 10   |
| id | fea57bb6-0c85-454a-b5b7-1169f3e42a49 |
| name   | z1.3small|
| os-flavor-access:is_public | True |
| properties | volume_type='ZOL'|
| ram| 2048 |
| rxtx_factor| 1.0  |
| swap   |  |
| vcpus  | 1|
++--+
bladeA01:~# openstack aggregate show zfs
+---++
| Field | Value  |
+---++
| availability_zone | nova   |
| created_at| 2016-07-14T12:16:05.00 |
| deleted   | False  |
| deleted_at| None   |
| hosts | [u'bladeA03']  |
| id| 10 |
| name  | zfs|
| properties| volume_type='ZOL'  |
| updated_at| None   |
+---++
- s n i p -
--
Att inse sin egen betydelse är som att få ett kvalster att
fatta att han bara syns i mikroskop
- Arne Anka


__
OpenStack Development Mailing 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] [app-catalog] App Catalog mascot

[Christopher Aedo]

Today we decided to set up an etherpad for picking a mascot for the
Community App Catalog.  If you'd like to propose an idea or vote on
one of the ones already up there, please check out the etherpad -
thanks!

https://etherpad.openstack.org/p/app-catalog-mascot

-Christopher

__
OpenStack Development Mailing 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] Filter ComputeCapabilitiesFilter returned 0 hosts

[Brent Troge]

can you send output of the below..

nova service-list
nova flavor-show z1.3small
nova aggregate-details zfs



On Thu, Jul 14, 2016 at 11:44 AM, Turbo Fredriksson 
wrote:

> I've been working on "porting" the Openstack-ZFS driver
> (https://github.com/FransUrbo/Openstack-ZFS) to Mitaka
> and most works now.
>
> EXCEPT, I get Subj. when trying to create an instance.
>
> - s n i p -
> 2016-07-14 13:18:30.955 21554 DEBUG nova.filters
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filter ComputeFilter returned 1
> host(s) get_filtered_objects
> /usr/lib/python2.7/dist-packages/nova/filters.py:104
> 2016-07-14 13:18:30.956 21554 DEBUG
> nova.scheduler.filters.compute_capabilities_filter
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] (bladeA03, bladeA03.domain.tld)
> ram: 15046MB disk: 116736MB io_ops: 0 instances: 1 fails. There are no
> capabilities to retrieve. _get_capabilities
> /usr/lib/python2.7/dist-packages/nova/scheduler/filters/compute_capabilities_filter.py:63
> 2016-07-14 13:18:30.957 21554 DEBUG
> nova.scheduler.filters.compute_capabilities_filter
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] (bladeA03, bladeA03.domain.tld)
> ram: 15046MB disk: 116736MB io_ops: 0 instances: 1 fails instance_type
> extra_specs requirements host_passes
> /usr/lib/python2.7/dist-packages/nova/scheduler/filters/compute_capabilities_filter.py:101
> 2016-07-14 13:18:30.957 21554 INFO nova.filters
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filter ComputeCapabilitiesFilter
> returned 0 hosts
> 2016-07-14 13:18:30.958 21554 DEBUG nova.filters
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filtering removed all hosts for the
> request with instance ID 'e46864b7-468e-439a-8374-bd5af32b6f4f'. Filter
> results: [('RetryFilter', [(u'bladeA03', u'bladeA03.domain.tld')]),
> ('AvailabilityZoneFilter', [(u'bladeA03', u'bladeA03.domain.tld')]),
> ('RamFilter', [(u'bladeA03', u'bladeA03.domain.tld')]), ('DiskFilter',
> [(u'bladeA03', u'bladeA03.domain.tld')]), ('ComputeFilter', [(u'bladeA03',
> u'bladeA03.domain.tld')]), ('ComputeCapabilitiesFilter', None)]
> get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:129
> 2016-07-14 13:18:30.959 21554 INFO nova.filters
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filtering removed all hosts for the
> request with instance ID 'e46864b7-468e-439a-8374-bd5af32b6f4f'. Filter
> results: ['RetryFilter: (start: 1, end: 1)', 'AvailabilityZoneFilter:
> (start: 1, end: 1)', 'RamFilter: (start: 1, end: 1)', 'DiskFilter: (start:
> 1, end: 1)', 'ComputeFilter: (start: 1, end: 1)',
> 'ComputeCapabilitiesFilter: (start: 1, end: 0)']
> 2016-07-14 13:18:30.960 21554 DEBUG nova.scheduler.filter_scheduler
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] There are 0 hosts available but 1
> instances requested to build. select_destinations
> /usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py:71
>
> ==> /var/log/nova/nova-conductor.log <==
> 2016-07-14 13:18:30.965 21686 WARNING nova.scheduler.utils
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Failed to
> compute_task_build_instances: No valid host was found. There are not enough
> hosts available.
> Traceback (most recent call last):
>
>   File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py",
> line 150, in inner
> return func(*args, **kwargs)
>
>   File "/usr/lib/python2.7/dist-packages/nova/scheduler/manager.py", line
> 104, in select_destinations
> dests = self.driver.select_destinations(ctxt, spec_obj)
>
>   File
> "/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py", line
> 74, in select_destinations
> raise exception.NoValidHost(reason=reason)
>
> NoValidHost: No valid host was found. There are not enough hosts available.
>
> 2016-07-14 13:18:30.966 21686 WARNING nova.scheduler.utils
> [req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b
> 04ee0e71babe4fd7aa16c3f64a8fca89 - - -] [instance:
> e46864b7-468e-439a-8374-bd5af32b6f4f] Setting instance to ERROR state.
> - s n i p -
>
>
> I've created both a flavor and a host aggregate for this, but
> still nothing..
>
> - s n i p -
> # openstack aggregate create --zone nova --property volume_type=ZOL zfs
> # openstack volume type create --description "ZFS volumes" --public zfs
> # openstack volume type set --property volume_backend_name=ZOL zfs
> # openstack flavor create --ram  2048 --disk 20 --vcpus 1 --disk 10
> z

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Paul Bourke]

>> What version of libvirt/qemu do you have in the image/job you're 
running?


$ dpkg -l | grep -e libvirt -e qemu
ii  libvirt-dev:amd64 1.3.1-1ubuntu10.1~cloud0 
amd64development files for the libvirt library
ii  libvirt0:amd641.3.1-1ubuntu10.1~cloud0 
amd64library for interfacing with different virtualization systems
ii  python-libvirt1.3.1-1ubuntu1~cloud0 
amd64libvirt Python bindings
ii  qemu-block-extra:amd641:2.5+dfsg-5ubuntu10.2~cloud0 
amd64extra block backend modules for qemu-system and qemu-utils
ii  qemu-utils1:2.5+dfsg-5ubuntu10.2~cloud0 
amd64QEMU utilities


Thanks,
-Paul

On 14/07/16 17:34, Paul Bourke wrote:

Hi Matt,

Here is the failure from nova_compute on trying to start an instance:

2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
-] Error starting thread.
2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service Traceback (most recent call last):
2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py",
line 708, in run_service
2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service service.start()
2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py",
line 117, in start
2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.manager.init_host()
2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py",
line 1122, in init_host
2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.driver.init_host(host=self.host)
2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 467, in init_host
2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self._parse_migration_flags()
2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 689, in _parse_migration_flags
2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service live_migration_flags, live_config_name)
2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 644, in _handle_live_migration_auto_converge
2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service migration_flags &=
~libvirt.VIR_MIGRATE_AUTO_CONVERGE
2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service AttributeError: 'module' object has no attribute
'VIR_MIGRATE_AUTO_CONVERGE'

The full log can be viewed at
http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704


-Paul

On 14/07/16 17:13, Matt Riedemann wrote:

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C&P isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278



If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
get these values from libvirt:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633



Could be something patched out of the versions you're using from the
distro maybe?

The actual failure paste/trace would help.



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

[openstack-dev] [Neutron] Project mascot - propose your choice/cast your vote

[Armando M.]

Hi Neutrinos,

Based on proposal [1], I prepared an etherpad to allow us to choose
collaboratively a set of candidates for our mascot. Propose/vote away on
[2]. You have time until Friday, July 22nd.

After the deadline the most voted ones (depending on the number) will be
sent to Heidi Joy @Foundation for the next step in the selection process.

Feel free to reach out if you have any questions/suggestions.

Happy hacking!
Armando

[1] http://www.openstack.org/project-mascots
[2] https://etherpad.openstack.org/p/neutron-project-mascot
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

I've been working on "porting" the Openstack-ZFS driver
(https://github.com/FransUrbo/Openstack-ZFS) to Mitaka
and most works now.

EXCEPT, I get Subj. when trying to create an instance.

- s n i p -
2016-07-14 13:18:30.955 21554 DEBUG nova.filters 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filter ComputeFilter returned 1 host(s) 
get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:104
2016-07-14 13:18:30.956 21554 DEBUG 
nova.scheduler.filters.compute_capabilities_filter 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] (bladeA03, bladeA03.domain.tld) ram: 
15046MB disk: 116736MB io_ops: 0 instances: 1 fails. There are no capabilities 
to retrieve. _get_capabilities 
/usr/lib/python2.7/dist-packages/nova/scheduler/filters/compute_capabilities_filter.py:63
2016-07-14 13:18:30.957 21554 DEBUG 
nova.scheduler.filters.compute_capabilities_filter 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] (bladeA03, bladeA03.domain.tld) ram: 
15046MB disk: 116736MB io_ops: 0 instances: 1 fails instance_type extra_specs 
requirements host_passes 
/usr/lib/python2.7/dist-packages/nova/scheduler/filters/compute_capabilities_filter.py:101
2016-07-14 13:18:30.957 21554 INFO nova.filters 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filter ComputeCapabilitiesFilter 
returned 0 hosts
2016-07-14 13:18:30.958 21554 DEBUG nova.filters 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filtering removed all hosts for the 
request with instance ID 'e46864b7-468e-439a-8374-bd5af32b6f4f'. Filter 
results: [('RetryFilter', [(u'bladeA03', u'bladeA03.domain.tld')]), 
('AvailabilityZoneFilter', [(u'bladeA03', u'bladeA03.domain.tld')]), 
('RamFilter', [(u'bladeA03', u'bladeA03.domain.tld')]), ('DiskFilter', 
[(u'bladeA03', u'bladeA03.domain.tld')]), ('ComputeFilter', [(u'bladeA03', 
u'bladeA03.domain.tld')]), ('ComputeCapabilitiesFilter', None)] 
get_filtered_objects /usr/lib/python2.7/dist-packages/nova/filters.py:129
2016-07-14 13:18:30.959 21554 INFO nova.filters 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Filtering removed all hosts for the 
request with instance ID 'e46864b7-468e-439a-8374-bd5af32b6f4f'. Filter 
results: ['RetryFilter: (start: 1, end: 1)', 'AvailabilityZoneFilter: (start: 
1, end: 1)', 'RamFilter: (start: 1, end: 1)', 'DiskFilter: (start: 1, end: 1)', 
'ComputeFilter: (start: 1, end: 1)', 'ComputeCapabilitiesFilter: (start: 1, 
end: 0)']
2016-07-14 13:18:30.960 21554 DEBUG nova.scheduler.filter_scheduler 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] There are 0 hosts available but 1 
instances requested to build. select_destinations 
/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py:71

==> /var/log/nova/nova-conductor.log <==
2016-07-14 13:18:30.965 21686 WARNING nova.scheduler.utils 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Failed to compute_task_build_instances: 
No valid host was found. There are not enough hosts available.
Traceback (most recent call last):

  File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 
150, in inner
return func(*args, **kwargs)

  File "/usr/lib/python2.7/dist-packages/nova/scheduler/manager.py", line 104, 
in select_destinations
dests = self.driver.select_destinations(ctxt, spec_obj)

  File "/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py", 
line 74, in select_destinations
raise exception.NoValidHost(reason=reason)

NoValidHost: No valid host was found. There are not enough hosts available.

2016-07-14 13:18:30.966 21686 WARNING nova.scheduler.utils 
[req-88443e97-1486-4cdf-a15f-21e78b1ee3a1 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] [instance: 
e46864b7-468e-439a-8374-bd5af32b6f4f] Setting instance to ERROR state.
- s n i p -


I've created both a flavor and a host aggregate for this, but
still nothing..

- s n i p -
# openstack aggregate create --zone nova --property volume_type=ZOL zfs
# openstack volume type create --description "ZFS volumes" --public zfs
# openstack volume type set --property volume_backend_name=ZOL zfs
# openstack flavor create --ram  2048 --disk 20 --vcpus 1 --disk 10 z1.3small
# openstack flavor set --property volume_type=ZOL z1.3small
- s n i p -

Config file: 
https://github.com/FransUrbo/openstack_bladecenter/blob/master/configs-control/etc/cinder/cinder.conf#L78-L89
-- 
Try not. Do. Or do not. There is no try!
- Yoda

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Matt,

I'd like to add our CentOS / Oracle Linux gates work great with Red Hat's
feature-reduced version (not totally sure on the feature reduced part - I
saw it in a Red Hat summit slidedeck) of QEMU 2.3.0 shipped with RDO (not
sure on version of libvirt).

On 7/14/16, 9:34 AM, "Paul Bourke"  wrote:

>Hi Matt,
>
>Here is the failure from nova_compute on trying to start an instance:
>
>2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
>-] Error starting thread.
>2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service Traceback (most recent call last):
>2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/servic
>e.py", 
>line 708, in run_service
>2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service service.start()
>2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py",
>line 117, in start
>2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self.manager.init_host()
>2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manage
>r.py", 
>line 1122, in init_host
>2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self.driver.init_host(host=self.host)
>2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 467, in init_host
>2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self._parse_migration_flags()
>2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 689, in _parse_migration_flags
>2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service live_migration_flags, live_config_name)
>2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 644, in _handle_live_migration_auto_converge
>2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service migration_flags &=
>~libvirt.VIR_MIGRATE_AUTO_CONVERGE
>2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service AttributeError: 'module' object has no attribute
>'VIR_MIGRATE_AUTO_CONVERGE'
>
>The full log can be viewed at
>http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-
>source/0849a74/console.html#_2016-07-13_18_04_12_526704
>
>-Paul
>
>On 14/07/16 17:13, Matt Riedemann wrote:
>> On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:
>>>
>>> We are not making the deploy gates voting at this time, although the
>>> plan is to do so once we stablize the last of the gate issues.  I think
>>> we are just down to one issue now, and that is that ubuntu source fails
>>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>> bug.  If the nova community has any bones to throw us on how to fix
>>> this, it would be appreciated.  I'd cut and paste the log, but for some
>>> reason C&P isn't working in my email client at present.
>>>
>>
>> What version of libvirt/qemu do you have in the image/job you're
>>running?
>>
>> See:
>>
>> 
>>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff02
>>9495a6/nova/virt/libvirt/driver.py#L278
>>
>>
>> If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
>> get these values from libvirt:
>>
>> 
>>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff02
>>9495a6/nova/virt/libvirt/driver.py#L633
>>
>>
>> Could be something patched out of the versions you're using from the
>> distro maybe?
>>
>> The actual failure paste/trace would help.
>>
>
>__
>OpenStack Development Mailing 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] [all] [api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

No new guidelines have been merged or proposed for freeze this week.

There are 19 outstanding issues in the launchpad bug tracker for the 
working group[4], and we are always looking for more help from the 
community. A few hot issues currently are the need for an acceptable 
guideline on pagination, and some history and advice on why extensions 
have not worked and should not be used. If you are interested in helping 
the effort, please take a look at the issues and reach out to the group.


# Recently merged guidelines

No new guidelines in the last two weeks but the following fixes were merged:

* Get rid of the DRAFT warning at the top of guidelines
  https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
  https://review.openstack.org/#/c/330876/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg


__
OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Paul Bourke]

Hi Matt,

Here is the failure from nova_compute on trying to start an instance:

2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - - 
-] Error starting thread.
2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service Traceback (most recent call last):
2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py", 
line 708, in run_service
2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service service.start()
2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py", 
line 117, in start
2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self.manager.init_host()
2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py", 
line 1122, in init_host
2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self.driver.init_host(host=self.host)
2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 467, in init_host
2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self._parse_migration_flags()
2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 689, in _parse_migration_flags
2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service live_migration_flags, live_config_name)
2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 644, in _handle_live_migration_auto_converge
2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service migration_flags &= 
~libvirt.VIR_MIGRATE_AUTO_CONVERGE
2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service AttributeError: 'module' object has no attribute 
'VIR_MIGRATE_AUTO_CONVERGE'


The full log can be viewed at 
http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704


-Paul

On 14/07/16 17:13, Matt Riedemann wrote:

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C&P isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278


If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
get these values from libvirt:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633


Could be something patched out of the versions you're using from the
distro maybe?

The actual failure paste/trace would help.



__
OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Matt,

My computer is bust, but I've asked Paul and Serguei to get back to you
with answers to your questions in the next 30 minutes.

Regards
-steve

On 7/14/16, 9:13 AM, "Matt Riedemann"  wrote:

>On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:
>>
>> We are not making the deploy gates voting at this time, although the
>> plan is to do so once we stablize the last of the gate issues.  I think
>> we are just down to one issue now, and that is that ubuntu source fails
>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>> bug.  If the nova community has any bones to throw us on how to fix
>> this, it would be appreciated.  I'd cut and paste the log, but for some
>> reason C&P isn't working in my email client at present.
>>
>
>What version of libvirt/qemu do you have in the image/job you're running?
>
>See:
>
>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029
>495a6/nova/virt/libvirt/driver.py#L278
>
>If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
>get these values from libvirt:
>
>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029
>495a6/nova/virt/libvirt/driver.py#L633
>
>Could be something patched out of the versions you're using from the
>distro maybe?
>
>The actual failure paste/trace would help.
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Matt Riedemann]

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C&P isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278

If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and 
get these values from libvirt:


https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633

Could be something patched out of the versions you're using from the 
distro maybe?


The actual failure paste/trace would help.

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Anita Kuno]

On 07/14/2016 11:55 AM, Steven Dake (stdake) wrote:
> Antia,
> 
> Thanks for the correction.  I've been at this about 5 years, and agree -
> things are muddy :)
> 
> Kolla cores - when reading this email, please keep Anita's comments in
> mind.
> 
> Regards
> -steve

Thank you Steve,
Anita.

> 
> On 7/14/16, 7:37 AM, "Anita Kuno"  wrote:
> 
>> On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
>>> Hey folks,
>>>
>>> At the midcycle, we had a session on gating.
>>>
>>> Out of that session came the decision to make the build gates voting
>>
>> Jobs, you have voting jobs, gates do not vote.
>>
>> We have an overload of technical terms as it is. Newcomers look to
>> existing members to understand terminology and culture. Someone
>> continuing to call a term a slang version perpetuates and creates
>> confusion and frustration for people who believed they were using the
>> correct term.
>>
>> http://docs.openstack.org/project-team-guide/testing.html#project-gating
>>
>> Thank you,
>> Anita.
>>
>>
>>> as soon as the mirroring is finished for ubuntu first (because that is
>>> closer for us to get mirroring sorted out) followed by CentOS/Oracle
>>> Linux.  I am taking this work on (mirroring specifically) and expect it
>>> to finish in the next 1-2 weeks (ubuntu only).  After that I will sort
>>> out the centos mirroring.  I'm not sure who got the mirroring work
>>> kicked off in infrastructure - I think it was Jessie Pretorious - if the
>>> credit is wrong apologies, but whoever it was, - huge thanks from me
>>> personally :)
>>>
>>> We are not making the deploy gates voting at this time, although the
>>> plan is to do so once we stablize the last of the gate issues.  I think
>>> we are just down to one issue now, and that is that ubuntu source fails
>>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>> bug.  If the nova community has any bones to throw us on how to fix
>>> this, it would be appreciated.  I'd cut and paste the log, but for some
>>> reason C&P isn't working in my email client at present.
>>>
>>> If folks know of other consistent deploy gate failures, can you please
>>> respond on this thread with either a bug link or a link to a log of the
>>> failure in question.
>>>
>>> The review where it fails is 339776.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>>
>>>
>>> _
>>> _
>>> OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Swapnil Kulkarni (coolsvap)]

On Thu, Jul 14, 2016 at 7:51 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> At the midcycle, we had a session on gating.
>
> Out of that session came the decision to make the build gates voting as soon
> as the mirroring is finished for ubuntu first (because that is closer for us
> to get mirroring sorted out) followed by CentOS/Oracle Linux.  I am taking
> this work on (mirroring specifically) and expect it to finish in the next
> 1-2 weeks (ubuntu only).  After that I will sort out the centos mirroring.
> I'm not sure who got the mirroring work kicked off in infrastructure – I
> think it was Jessie Pretorious – if the credit is wrong apologies, but
> whoever it was, - huge thanks from me personally :)
>
> We are not making the deploy gates voting at this time, although the plan is
> to do so once we stablize the last of the gate issues.  I think we are just
> down to one issue now, and that is that ubuntu source fails with an error
> about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova
> community has any bones to throw us on how to fix this, it would be
> appreciated.  I'd cut and paste the log, but for some reason C&P isn't
> working in my email client at present.
>
> If folks know of other consistent deploy gate failures, can you please
> respond on this thread with either a bug link or a link to a log of the
> failure in question.
>
> The review where it fails is 339776.
>
> Regards
> -steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


+1 I think its good idea to finally move towards voting build jobs.

__
OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Antia,

Thanks for the correction.  I've been at this about 5 years, and agree -
things are muddy :)

Kolla cores - when reading this email, please keep Anita's comments in
mind.

Regards
-steve

On 7/14/16, 7:37 AM, "Anita Kuno"  wrote:

>On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
>> Hey folks,
>> 
>> At the midcycle, we had a session on gating.
>> 
>> Out of that session came the decision to make the build gates voting
>
>Jobs, you have voting jobs, gates do not vote.
>
>We have an overload of technical terms as it is. Newcomers look to
>existing members to understand terminology and culture. Someone
>continuing to call a term a slang version perpetuates and creates
>confusion and frustration for people who believed they were using the
>correct term.
>
>http://docs.openstack.org/project-team-guide/testing.html#project-gating
>
>Thank you,
>Anita.
>
>
>> as soon as the mirroring is finished for ubuntu first (because that is
>>closer for us to get mirroring sorted out) followed by CentOS/Oracle
>>Linux.  I am taking this work on (mirroring specifically) and expect it
>>to finish in the next 1-2 weeks (ubuntu only).  After that I will sort
>>out the centos mirroring.  I'm not sure who got the mirroring work
>>kicked off in infrastructure - I think it was Jessie Pretorious - if the
>>credit is wrong apologies, but whoever it was, - huge thanks from me
>>personally :)
>> 
>> We are not making the deploy gates voting at this time, although the
>>plan is to do so once we stablize the last of the gate issues.  I think
>>we are just down to one issue now, and that is that ubuntu source fails
>>with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>bug.  If the nova community has any bones to throw us on how to fix
>>this, it would be appreciated.  I'd cut and paste the log, but for some
>>reason C&P isn't working in my email client at present.
>> 
>> If folks know of other consistent deploy gate failures, can you please
>>respond on this thread with either a bug link or a link to a log of the
>>failure in question.
>> 
>> The review where it fails is 339776.
>> 
>> Regards
>> -steve
>> 
>> 
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing 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] [nova] Let's kill quota classes (again)

[Kevin L. Mitchell]

The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant.  That is,
say you have a tiered setup, where you have gold-, silver-, and
bronze-level customers, with gold having lots of free quota and bronze
having a small amount of quota.  Rather than having to set the quotas
individually for each tenant you created, the idea is that you set the
_class_ of the tenant, and have quotas associated with the classes.
This also has the advantage that, if someone levels up (or down) to
another class of service, all you do is change the tenant's class, and
the new quotas apply immediately.

(By the way, the turnstile integration was not part of turnstile itself;
there's a turnstile plugin to allow it to integrate with nova that's
quota_class-aware, so you could also apply rate limits this way.)

Personally, it wouldn't break my heart if quota classes went away; I
think this level of functionality, if it seems reasonable to include,
should become part of a more unified quota API (which we're still
struggling to come up with anyway) so that everyone gets the benefit…or
perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this
functionality, though it might be worth asking about on the operators
list—for curiosity's sake, if nothing else.  It would be interesting to
see if anyone would be interested in the original idea, even if the
current implementation doesn't make sense :)

On Wed, 2016-07-13 at 14:47 -0500, Matt Riedemann wrote:
> We got a bug that the os-quota-class-sets API isn't documented:
> 
> https://bugs.launchpad.net/nova/+bug/1602400
> 
> That's probably because we hate it and no one understands it.
> 
> See this previous thread about trying to sort this out from the long 
> long ago:
> 
> https://lists.launchpad.net/openstack/msg12200.html
> 
> We tried killing it before, but it turns out, it's actually used by 
> something!
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-May/036031.html
> 
> But we didn't have integration testing in Tempest for default quotas at 
> that time (we added those tests in when we reverted the delete of the 
> API back in Juno).
> 
> I got looking at this because of the quota_class attribute in the nova 
> RequestContext:
> 
> https://github.com/openstack/nova/blob/93cc5e3ffd2867bdb39a707a230c1efc6ed2f5f4/nova/context.py#L138-L141
> 
> That led me to markmc's thread about that only being there for the 
> turnstile project and some old API rate limiting stuff that Rackspace 
> was doing out of tree (it appears to set a type of middleware for a 
> quota class for rate limiting).
> 
> Anyway, super duper out of tree stuff that is probably not even used 
> anymore (Vek - if you're reading, please speak up).
> 
> I'll also point out that API rate limiting as a paste config was only in 
> the v2 API and that code was all dropped and the API rate limiting stuff 
> wasn't carried over for the v2.1 API, for good reason, see:
> 
> http://lists.openstack.org/pipermail/openstack-operators/2016-June/010692.html
> 
> You can still create unique quota classes via the os-quota-class-sets 
> API (it does a create if the update operation fails), but as far as I 
> can tell you can't really use those in any meaningful way.
> 
> We really just have the 'default' quota class with a buttload of code 
> and plumbing to use that, which sucks, because it's all very complicated.
> 
> So I think I'm going to start a pet project of rooting this stuff out 
> again, starting with nova.context.RequestContext.quota_class, unless 
> anyone has a good reason we should keep this in tree.
> 
> I think we should also add a microversion to the API in Ocata to disable 
> the ability to create new quota classes, so that update is only update, 
> and a 404 for anything else.
> 

-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Anita Kuno]

On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
> Hey folks,
> 
> At the midcycle, we had a session on gating.
> 
> Out of that session came the decision to make the build gates voting

Jobs, you have voting jobs, gates do not vote.

We have an overload of technical terms as it is. Newcomers look to
existing members to understand terminology and culture. Someone
continuing to call a term a slang version perpetuates and creates
confusion and frustration for people who believed they were using the
correct term.

http://docs.openstack.org/project-team-guide/testing.html#project-gating

Thank you,
Anita.


> as soon as the mirroring is finished for ubuntu first (because that is closer 
> for us to get mirroring sorted out) followed by CentOS/Oracle Linux.  I am 
> taking this work on (mirroring specifically) and expect it to finish in the 
> next 1-2 weeks (ubuntu only).  After that I will sort out the centos 
> mirroring.  I'm not sure who got the mirroring work kicked off in 
> infrastructure - I think it was Jessie Pretorious - if the credit is wrong 
> apologies, but whoever it was, - huge thanks from me personally :)
> 
> We are not making the deploy gates voting at this time, although the plan is 
> to do so once we stablize the last of the gate issues.  I think we are just 
> down to one issue now, and that is that ubuntu source fails with an error 
> about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova 
> community has any bones to throw us on how to fix this, it would be 
> appreciated.  I'd cut and paste the log, but for some reason C&P isn't 
> working in my email client at present.
> 
> If folks know of other consistent deploy gate failures, can you please 
> respond on this thread with either a bug link or a link to a log of the 
> failure in question.
> 
> The review where it fails is 339776.
> 
> Regards
> -steve
> 
> 
> 
> __
> OpenStack Development Mailing 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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Hey folks,

At the midcycle, we had a session on gating.

Out of that session came the decision to make the build gates voting as soon as 
the mirroring is finished for ubuntu first (because that is closer for us to 
get mirroring sorted out) followed by CentOS/Oracle Linux.  I am taking this 
work on (mirroring specifically) and expect it to finish in the next 1-2 weeks 
(ubuntu only).  After that I will sort out the centos mirroring.  I'm not sure 
who got the mirroring work kicked off in infrastructure - I think it was Jessie 
Pretorious - if the credit is wrong apologies, but whoever it was, - huge 
thanks from me personally :)

We are not making the deploy gates voting at this time, although the plan is to 
do so once we stablize the last of the gate issues.  I think we are just down 
to one issue now, and that is that ubuntu source fails with an error about VIR 
MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova community has 
any bones to throw us on how to fix this, it would be appreciated.  I'd cut and 
paste the log, but for some reason C&P isn't working in my email client at 
present.

If folks know of other consistent deploy gate failures, can you please respond 
on this thread with either a bug link or a link to a log of the failure in 
question.

The review where it fails is 339776.

Regards
-steve
__
OpenStack Development Mailing 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] [charms] 16.07 release feature freeze today

[James Page]

Hi All

A (somewhat) late reminder that the feature freeze for the 16.07 charm
release at the end of the month is today; any outstanding feature reviews
need to be fully tested, reviewed and landed by 0800 UTC on the 15th July
(which is the end of the day for those on the west coast of the US).

This has been discussed a-lot in channel (#openstack-charms) - however need
to remember to notify the world as well!

Bug fixes only from tomorrow until the 28th please!

Cheers

James
__
OpenStack Development Mailing 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] [fuel] IRC meeting for Jul - 14

[Andrew Woodward]

The meeting agenda is again empty, so I'm calling the meeting canceled.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing 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] [Networking-vSphere]

[Igor Gajsin]

Thanks for quick reply.

Let's restore the context. I develop plugin for Fuel that uses
Networking-vSphere as the network driver. Next release of Fuel, 9.1 and
maybe 9.X will based on mitaka.

For me it means that I have to have a place for commit my changes to
driver. Now I'm working on changing of devstack/plugin.sh to make possible
to install either OVSvApp or VMware DVS driver. But my ambitions are spread
much further.

I have several ideas how to improve vmware dvs and my question is can I
full-fledged develop it or not?

On Thu, Jul 14, 2016 at 3:21 PM, Jay Pipes  wrote:

> On 07/14/2016 02:41 AM, Igor Gajsin wrote:
>
>> Hi all.
>>
>> I'm going to add some improvement to Networking-vSphere. There is the
>> problem because I'm working with mitaka which already released. But I
>> see some commits in the stable/mitaka branch that were made after
>> release date.
>>
>> Does it mean, that I can commit new functionality to stable/mitaka
>> branch and work with it as usual?
>>
>
> Hello Igor!
>
> Generally, no patches should land in a stable branch that provide a new
> feature or change existing behaviour. Only bug fixes should be applied to a
> stable branch. Can you point to specific patches that you are referring to?
>
> Thanks!
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] ended up with extra 85watt magsafe power supply

[Steven Dake (stdake)]

Hey folks,

I ended up with an extra power supply for a mac.  I'm not sure if it is from 
someone at the midcycle or from the Ansible HQ offices.  If its from the 
Ansible HQ offices, I'll have my wife take it with her next time she visits.  
If it was a midcycle attendee, please contact me off list with your address and 
I'll ship it to you.

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

[openstack-dev] [new][oslo] oslo.utils 3.16.0 release (newton)

[no-reply]

We are psyched to announce the release of:

oslo.utils 3.16.0: Oslo Utility library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.utils

With package available at:

https://pypi.python.org/pypi/oslo.utils

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

For more details, please see below.

Changes in oslo.utils 3.15.0..3.16.0


878f570 Fix mask_dict_password for non string/dict type key in dict
5434726 More unit tests for specs matcher
1d1c983 Imported Translations from Zanata
103a322 Add Python 3.5 classifier and venv
7699788 Use an actual well defined parser for spec matching
9981276 Remove unused LOG to keep code clean
b9e9f17 Updated from global requirements
e97f08b Move nova extra_specs_ops to oslo.utils


Diffstat (except docs and test files)
-

oslo_utils/fileutils.py|   2 -
.../locale/es/LC_MESSAGES/oslo_utils-log-error.po  |  13 +-
.../pt_BR/LC_MESSAGES/oslo_utils-log-error.po  |  13 +-
oslo_utils/specs_matcher.py|  86 ++
oslo_utils/strutils.py |   3 +-
oslo_utils/versionutils.py |   4 -
requirements.txt   |   1 +
setup.cfg  |   1 +
test-requirements.txt  |   2 +-
tox.ini|   2 +-
12 files changed, 433 insertions(+), 21 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7cac05d..af47d66 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -19,0 +20 @@ debtcollector>=1.2.0 # Apache-2.0
+pyparsing>=2.0.1 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index 6562796..80a559c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -28 +28 @@ mock>=2.0 # BSD
-oslo.config>=3.10.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0



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

Re: [openstack-dev] [Neutron][infra] Switch to xenial and Neutron unit tests

[Boden Russell]

>From a vmware-nsx perspective, we have added some temp gate jobs that
run pep8, py27 and py35 on Xenial (check-xenial-epep8,
check-xenial-epy27 and check-xenial-epy35 respectively). Everything (on
Xenial) is passing as indicated in recent job results [1].

That said, please feel free to create vmware-nsx defects [2] as needed
for any such failures and/or reach out to me on IRC ('boden').

Thanks

[1] https://review.openstack.org/#/c/342128
[2] https://bugs.launchpad.net/vmware-nsx


On 7/12/16 6:18 PM, Armando M. wrote:
> Hi Neutrinos,
> 
> OpenStack infra is in the process of testing OpenStack tests on ubuntu
> Xenial so that it can be adopted as default platform for testing in the
> Gate. It is likely that the switch is going to happen sometime next week.
> 
> It was noted in the channel at [1] that some unit tests are not
> currently passing for the following repos: vmware-nsx, networking-cisco
> and group-based-policy.
> 
> For those of you who may be affected, please make sure to read IRC logs
> and stay on top of this issue.
> 
> Cheers,
> Armando
> 
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-12.log.html#t2016-07-12T21:39:32
> 
> 
> 
> __
> OpenStack Development Mailing 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] [Networking-vSphere]

[Jay Pipes]

On 07/14/2016 02:41 AM, Igor Gajsin wrote:

Hi all.

I'm going to add some improvement to Networking-vSphere. There is the
problem because I'm working with mitaka which already released. But I
see some commits in the stable/mitaka branch that were made after
release date.

Does it mean, that I can commit new functionality to stable/mitaka
branch and work with it as usual?


Hello Igor!

Generally, no patches should land in a stable branch that provide a new 
feature or change existing behaviour. Only bug fixes should be applied 
to a stable branch. Can you point to specific patches that you are 
referring to?


Thanks!
-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] kick-off meeting of openstack stewardship working group (SWG)

[Amrith Kumar]

Today (July 14th) at 1800UTC in #openstack-meeting-cp, we will hold the 
kick-off meeting of the OpenStack Stewardship Working Group (SWG)[1].

The SWG was setup by the TC[2] with the stated purpose that this small group 
would review the leadership, communication, and decision making processes of 
the TC and OpenStack projects as a whole, and propose a set of improvements to 
the TC. Anyone interested in leadership, stewardship, and OpenStack is welcome 
to join the working group. Final decisions about any changes proposed by the 
SWG will be made by the TC.

The agenda for today's meeting is posted on the meetings wiki[3].

Today's meeting is being held in #openstack-meeting-cp as that meeting space is 
available at the proposed time. This is not going to be the time for the 
regular weekly meeting; an item on the agenda today is to figure out when we 
want to meet on a regular basis. Once we decide that, I'll find an available 
meeting channel.

Thanks,

-amrith

[1] I don't plan to send reminders every week to the ML about the meeting; I'm 
only sending this one out because this is the kick-off meeting.
[2] https://review.openstack.org/#/c/337895/
[3] https://wiki.openstack.org/wiki/Meetings/SWGMeeting


__
OpenStack Development Mailing 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] Naming polls - and some issues

[Neil Jerram]

Not sure what the problem would be with 'Quay' or 'Street' - they both
sound like good options to me.


On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn  wrote:

>
>
> > >> Hey all!
> > >>
> > >> The poll emails for the P and Q naming have started to go out - and
> > >> we're experiencing some difficulties. Not sure at the moment what's
> > >> going on ... but we'll keep working on the issues and get ballots to
> > >> everyone as soon as we can.
> > >
> > > You'll need to re-send at least some emails, because the link I
> received
> > > is wrong - the site just reports
> > >
> > >   "Your voter key is invalid. You should have received a correct URL by
> > >   email."
> >
> > Yup. That would be a key symptom of the problems. One of the others is
> > that I just uploaded 3000 of the emails to the Q poll and it shows 0
> > active voters.
> >
> > I think maybe it needs a nap...
>
> Any chance we could remove "Quay" from the Q release naming poll before
> the links are fixed and the real voting starts?
>
> Otherwise we risk looking a bit silly, since "Quay" for the Q release
> would be somewhat akin to choosing "Street" for the S release ;)
>
> Cheers,
> Eoghan
>
> __
> OpenStack Development Mailing 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] [ironic] How to handle defaults in driver composition reform?

[Dmitry Tantsur]

On 07/14/2016 12:52 PM, Sam Betts (sambetts) wrote:

There have been several discussions brought about by new interface types
and how they fit into the existing driver composition spec. Network and
Volume connector interfaces are examples of two interfaces who’s
implementations can depend highly on the environment they are being used
in, as well as the piece of hardware they are being used with. For
example the neutron network interface requires neutron to exist to operate.





After considering several different ways to handle hardware_type
interfaces so that we can ensure that deployers maintain fine control
over which interfaces are enabled in their environment, but continue to
provide sane defaults for all the different types of interfaces for
convenience of the user when enrolling nodes and also have all interface
types defined in a consistent way for developers of hardware types. I
would like to propose this solution:

- Remove single hardware_type default for all interface types
- Make hardware_type supported_FOO_interfaces a list of supported
implementations in order of preference by that hardware type’s vendor
- Have Ironic resolve the possible_FOO_interfaces by intersecting
enabled_FOO_interfaces with supported_FOO_interfaces maintaining the
order of preference
- Use the first possible_FOO_interface as the default this hardware_type


I haven't thought much about the idea, but at first glance I like it. 
It's somewhat less explicit, but we still can return the calculated 
default interface in /v1/drivers API, so it might be OK.




An example of this in operation:

In the deployer’s environment, implementation RAR, HAH and GAR will
work, BAR will not.
The deployer wants to enable two different hardware_types X and Y.

hardware_type X:
# BAR is recomended over RAR and RAR over GAR if available in
this deployment
supported_FOO_interface: [BAR, RAR, GAR]

hardware_type Y:
supported_FOO_interface: [HAH]


The deployer knowing that BAR will not work, does not include BAR in the
list of enabled_FOO_interfaces.

Deployers config file:
enabled_FOO_interfaces = RAR, HAH, GAR

The Ironic user creates a node using hardware_type X, but doesn’t
specify any interfaces.

ironic node-create -d X


Ironic calculates prioritied list of possible interfaces:

possible_FOO_interfaces = [BAR, RAR, GAR] intersect [RAR, HAH, GAR]
  = [RAR, GAR]

Ironic creates node with the first interface out of ordered list of
possible interfaces.

Node:

hardware_type: X
FOO_interfaces: RAR


The user now has a node with interfaces that are guaranteed by the
deployer to work in this environment.

This solution does mean that based on which environment you enroll a
node in you might get a different set of interfaces. So in order to find
out which interface is going to be the default FOO_interface for this
hardware_type in this environment, you can use the discovery API, which
returns a default_FOO_interface field, and also the
possible_FOO_interfaces, if you want to know which other interfaces
are available to you.

I believe this is a good fit for treating all interfaces in a
standardised way, please let me know your opinions so we can solve this
issue in a way that is convenient for our users as well as keeps
things consistent for developing core Ironic code, and hardware_types
both in and out of tree.

Sam


__
OpenStack Development Mailing 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] [ironic] How to handle defaults in driver composition reform?

[Sam Betts (sambetts)]

There have been several discussions brought about by new interface types and 
how they fit into the existing driver composition spec. Network and Volume 
connector interfaces are examples of two interfaces who’s implementations can 
depend highly on the environment they are being used in, as well as the piece 
of hardware they are being used with. For example the neutron network interface 
requires neutron to exist to operate.

The current solution for handling defaults with hardware_types removes much of 
the control from the deployer over which interfaces are enabled in their 
environment. For example:

- A deployer wants to use a hardware_type that specifies neutron as the default 
network_interface in a Ironic standalone deployment.
- As a deployer they know that the neutron network interface is not going to 
work but they can’t disable it because its a hardware_type default which are 
automatically enabled.
- This means that nodes can be created using that hardware_type with a known 
not to work interface implementation, and if not overridden during node 
creation the network_interface for that node will be automatically configured 
to use the neutron interface because its the default, resulting in a broken 
node by default.

To address this issue meetings and discussions on IRC considered several 
different solutions but all more or less resulted in either removing special 
case interfaces like network from the hardware_type, or treating these 
interfaces as special cases in some form or other with no default, or new 
config options to manage them.

After considering several different ways to handle hardware_type interfaces so 
that we can ensure that deployers maintain fine control over which interfaces 
are enabled in their environment, but continue to provide sane defaults for all 
the different types of interfaces for convenience of the user when enrolling 
nodes and also have all interface types defined in a consistent way for 
developers of hardware types. I would like to propose this solution:

- Remove single hardware_type default for all interface types
- Make hardware_type supported_FOO_interfaces a list of supported 
implementations in order of preference by that hardware type’s vendor
- Have Ironic resolve the possible_FOO_interfaces by intersecting 
enabled_FOO_interfaces with supported_FOO_interfaces maintaining the order of 
preference
- Use the first possible_FOO_interface as the default this hardware_type

An example of this in operation:

In the deployer’s environment, implementation RAR, HAH and GAR will work, BAR 
will not.
The deployer wants to enable two different hardware_types X and Y.

hardware_type X:
# BAR is recomended over RAR and RAR over GAR if available in this 
deployment
supported_FOO_interface: [BAR, RAR, GAR]

hardware_type Y:
supported_FOO_interface: [HAH]

The deployer knowing that BAR will not work, does not include BAR in the list 
of enabled_FOO_interfaces.

Deployers config file:
enabled_FOO_interfaces = RAR, HAH, GAR

The Ironic user creates a node using hardware_type X, but doesn’t specify any 
interfaces.

ironic node-create -d X

Ironic calculates prioritied list of possible interfaces:

possible_FOO_interfaces = [BAR, RAR, GAR] intersect [RAR, HAH, GAR]
  = [RAR, GAR]

Ironic creates node with the first interface out of ordered list of possible 
interfaces.

Node:
hardware_type: X
FOO_interfaces: RAR

The user now has a node with interfaces that are guaranteed by the deployer to 
work in this environment.

This solution does mean that based on which environment you enroll a node in 
you might get a different set of interfaces. So in order to find out which 
interface is going to be the default FOO_interface for this hardware_type in 
this environment, you can use the discovery API, which returns a 
default_FOO_interface field, and also the possible_FOO_interfaces, if you want 
to know which other interfaces are available to you.

I believe this is a good fit for treating all interfaces in a standardised way, 
please let me know your opinions so we can solve this issue in a way that is 
convenient for our users as well as keeps things consistent for developing core 
Ironic code, and hardware_types both in and out of tree.

Sam
__
OpenStack Development Mailing 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] Naming polls - and some issues

[Eoghan Glynn]

> >> Hey all!
> >>
> >> The poll emails for the P and Q naming have started to go out - and
> >> we're experiencing some difficulties. Not sure at the moment what's
> >> going on ... but we'll keep working on the issues and get ballots to
> >> everyone as soon as we can.
> > 
> > You'll need to re-send at least some emails, because the link I received
> > is wrong - the site just reports
> > 
> >   "Your voter key is invalid. You should have received a correct URL by
> >   email."
> 
> Yup. That would be a key symptom of the problems. One of the others is
> that I just uploaded 3000 of the emails to the Q poll and it shows 0
> active voters.
> 
> I think maybe it needs a nap...

Any chance we could remove "Quay" from the Q release naming poll before
the links are fixed and the real voting starts?

Otherwise we risk looking a bit silly, since "Quay" for the Q release
would be somewhat akin to choosing "Street" for the S release ;)

Cheers,
Eoghan

__
OpenStack Development Mailing 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][neutron]adding and parsing new configuration option in neutron.conf

[Ihar Hrachyshka]

Megan Liu  wrote:


Hi

I am new to Openstack neutron. I have problem of parsing new added option  
in neutron.conf. Do I have to register the new added option in code to be  
able to read the option value from neutron.conf or not.


Yes, you should register it with oslo.config:  
http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options






After adding new option in neutron.conf,  in the code , I try to use


neutron.conf
...
remote_ipam_ip= XXX

...

In the code

**

from oslo_config import cfg

ipam_ip_val=cfg.CONF.remote_ipam_ip

**
I got error :
File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 1906, in  
__getattr__
2016-07-14 11:34:11.085 12001 ERROR neutron.api.v2.resource raise  
NoSuchOptError(name)
2016-07-14 11:34:11.085 12001 ERROR neutron.api.v2.resource  
NoSuchOptError: no such option: remote_ipam_ip



Thanks.

Meirong


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




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

Re: [openstack-dev] [all][oslo] pbr potential breaking change coming

[Markus Zoeller]

On 13.07.2016 19:11, Jeremy Stanley wrote:
> On 2016-07-13 13:25:44 +0200 (+0200), Markus Zoeller wrote:
>> For some reason the gate docs job didn't find the issue (wrong json
>> format) which got fixed with change [1]. It doesn't even emit a warning.
>> Locally, the execution of "tox -e docs" does find the issue. Can we make
>> the gate docs job aware of such json format issues?
> [...]
> 
> It looks like your "docs" tox env is doing some additional checks[1]
> with the json.tool module. The gate-{name}-docs CI jobs don't call
> `tox -e docs` but `tox -evenv -- python setup.py build_sphinx`
> directly[2]. Changing that has been discussed[3][4] (and
> rejected/withdrawn) by the TC in the past.
> 
> I agree with Andreas that if you want additional checking of this
> you probably need it in a different job. The same goes for tests of
> your config/policy generation and API guide/reference builds. The
> goal of gate-{name}-docs is to make sure that the setup.py
> build_sphinx entrypoint works across all covered projects (per the
> CTI[5]) without requiring any extra nonstandard magic.
> 
> [1] http://git.openstack.org/cgit/openstack/nova/tree/tox.ini?id=df0aa8a#n97
> [2] 
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh
> [3] 
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-30-20.01.log.html#l-27
> [4] https://review.openstack.org/119875
> [5] 
> http://governance.openstack.org/reference/cti/python_cti.html#documentation
> 

I understand the reasoning now, thanks. Luckily, Andreas pushed a patch
to change that for Nova: https://review.openstack.org/#/c/341444/1

-- 
Regards, Markus Zoeller (markus_z)


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

[Igor Gajsin]

Hi all.

I'm going to add some improvement to Networking-vSphere. There is the
problem because I'm working with mitaka which already released. But I see
some commits in the stable/mitaka branch that were made after release date.

Does it mean, that I can commit new functionality to stable/mitaka branch
and work with it as usual?
__
OpenStack Development Mailing 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] [new][oslo] mox3 0.17.0 release (newton)

[Markus Zoeller]

On 13.07.2016 21:51, Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2016-07-13 17:22:32 +:
>> On 2016-07-13 17:10:20 +0200 (+0200), Markus Zoeller wrote:
>>> Whoever chooses the wording in these announcements, you're a genius!
>>
>> You too can be a genius--add some more--there's only ~20 at the
>> moment so they repeat pretty often:
>>
>> > http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py?id=da89264#n33
>>  >
> 
> Indeed, I've worn out my thesaurus. Please send synonyms.
> 
> 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
> 

So be it: https://review.openstack.org/342053 :)

https://www.youtube.com/watch?v=KrDcAzD6cWM

-- 
Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing 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][neutron]adding and parsing new configuration option in neutron.conf

[Megan Liu]

Hi

I am new to Openstack neutron. I have problem of parsing new added option
in neutron.conf. Do I have to register the new added option in code to be
able to read the option value from neutron.conf or not.

After adding new option in neutron.conf,  in the code , I try to use


neutron.conf
...
remote_ipam_ip= XXX

...

In the code

**

from oslo_config import cfg

ipam_ip_val=cfg.CONF.remote_ipam_ip

**
I got error :
File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 1906, in
__getattr__
2016-07-14 11:34:11.085 12001 ERROR neutron.api.v2.resource raise
NoSuchOptError(name)
2016-07-14 11:34:11.085 12001 ERROR neutron.api.v2.resource NoSuchOptError:
no such option: remote_ipam_ip


Thanks.

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

[openstack-dev] [QA] Cancel QA meeting today

[Ken'ichi Ohmichi]

Hi

Sorry for notifying this too lately.
We don't have enough attendees of QA meeting today and it is difficult
to run that.
So we cancel this week QA meeting.

Thanks
Ken Omichi

__
OpenStack Development Mailing 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][qa] When do we need tests for microversions in Tempest?

[GHANSHYAM MANN]

On Thu, Jul 14, 2016 at 12:08 PM, Matthew Treinish  wrote:
> On Wed, Jul 13, 2016 at 09:55:33PM -0500, Matt Riedemann wrote:
>> There are several changes in Tempest right now trying to add response schema
>> validation for the 2.26 microversion which added server tags to the server
>> GET response. This is needed for anything testing a microversion >=2.26,
>> which several people are trying to add.
>>
>> We have a similar issue with the 2.3 microversion which is really a bug, but
>> only exposed in jobs that have run_validation=True which is only in a
>> non-voting job right now.
>>
>> I've mostly been debating this in this change:
>>
>> https://review.openstack.org/#/c/233176/
>>
>> I've added an item to the nova midcycle meetup agenda to talk about the plan
>> for handling microversion testing in tempest for nova changes, specifically
>> around API response validation.
>>
>> I agree that nova doesn't test response schema validation in tree, so doing
>> it in tempest is good.
>>
>> But I'm not sure that we need a new set of tempest tests for every
>> microversion change in nova, e.g. if it's only touching the API and
>> database, like server tags, we can test that in nova.
>
> I largely agree with this, we don't need 100% coverage of every microversion.
> Especially if it's just an API that's just extra metadata in the DB.
>
>>
>> It's also not great having several changes in flight at the same time to
>> tempest trying to add the same 2.26 response schema because it wasn't added
>> the at the same time the 2.26 API merged.
>
> I agree it's not ideal, but it's not like there is a huge burden on rebasing,
> no more than for developers having to bump their microversions because another
> bp landed and took the microversion they were using.
>
>
>>
>> I also wonder what it means if someone configures max_microversion in
>> tempest.conf to something we don't test, like say 2.11, what blows up? For
>> example, we know that we don't have response validation for 2.3 so some
>> tests are broken when you run with ssh validation and microversion>=2.3.
>
> We can easily add a job that changes the min microversion config flag in 
> tempest
> to something higher than 2.1. This will ensure we send a higher microversion
> everywhere and will catch these issues sooner. But, I'm not sure we want to do
> that on a normal check/gate job.

Yes, there will be lot of tests failure not with schema thing only but
we do tests some bit
in tests which might got changed in versions.

But we have plan for that. to detect those tests and modify/cap with
appropriate boundary. But not sure when :)


>
>>
>> So I'm thinking we should:
>>
>> 1. Always add a schema change to Tempest if a microversion changes a
>> response.
>
> The problem with this is we shouldn't land a schema change by itself in 
> tempest.
> Until we have something using the schema we have no verification that they
> actually work. We can and will land incorrect schemas if we did this. That's 
> why
> there is a pretty strong policy of only landing code that is run in CI 
> somewhere
> for Tempest.

+1, yes we should not add those without testing.

>
>>
>> 2. Only add tests to Tempest for a microversion change if it can't be tested
>> within nova, e.g. you actually need to create a server, or use other
>> services like glance/cinder/neutron.
>
> +1
>
> -Matt Treinish
>
>>
>> mtreinish and sdague will be at the nova midcycle so hopefully they can
>> represent for the QA team.
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [nova][qa] When do we need tests for microversions in Tempest?

[GHANSHYAM MANN]

Thanks Matt for bringing this up.


On Thu, Jul 14, 2016 at 11:55 AM, Matt Riedemann
 wrote:
> There are several changes in Tempest right now trying to add response schema
> validation for the 2.26 microversion which added server tags to the server
> GET response. This is needed for anything testing a microversion >=2.26,
> which several people are trying to add.
>
> We have a similar issue with the 2.3 microversion which is really a bug, but
> only exposed in jobs that have run_validation=True which is only in a
> non-voting job right now.
>
> I've mostly been debating this in this change:
>
> https://review.openstack.org/#/c/233176/
>
> I've added an item to the nova midcycle meetup agenda to talk about the plan
> for handling microversion testing in tempest for nova changes, specifically
> around API response validation.
>
> I agree that nova doesn't test response schema validation in tree, so doing
> it in tempest is good.
>
> But I'm not sure that we need a new set of tempest tests for every
> microversion change in nova, e.g. if it's only touching the API and
> database, like server tags, we can test that in nova.
>
> It's also not great having several changes in flight at the same time to
> tempest trying to add the same 2.26 response schema because it wasn't added
> the at the same time the 2.26 API merged.
>
> I also wonder what it means if someone configures max_microversion in
> tempest.conf to something we don't test, like say 2.11, what blows up? For
> example, we know that we don't have response validation for 2.3 so some
> tests are broken when you run with ssh validation and microversion>=2.3.

you mean if we increase min_microversion? For max_microversion
capping, It should just skip the tests which are going
out of configured boundary.

But yes there will be failure if we increase the min_microversion to
some higher version which schema is missing (as tests is not added).

2.3 schema was missed as this tests was not added yet in tempest. So
we might have same case in future also.

I am trying to add all version schema needed till Mitaka max supported
version which is 2.25 in https://review.openstack.org/#/c/287605/
After that, we should have all lower version schema available for
other version tests(<2.25). This should make things easy for other new
tests.

>
> So I'm thinking we should:
>
> 1. Always add a schema change to Tempest if a microversion changes a
> response.

We should not actually. Schema are more error prone if we add
manually. We have to be very careful on all attributes, their type and
range etc
which can be verified with tests only. Adding schema in Tempest may
end up adding wrong schema in Tempest.

>
> 2. Only add tests to Tempest for a microversion change if it can't be tested
> within nova, e.g. you actually need to create a server, or use other
> services like glance/cinder/neutron.

Almost +1.
Actually This is fine till we do not increase the min_microversion.
Any new version tests coming in Tempest should add lower version
schema also if needed. This is mentioned very clearly in doc [1] also.
But if anytime we increase the minimum version (which is almost
impossible) then yes, we should have tests for all microversion so
that no failure with schema things. Honestly saying, I would like to
ignore this case as of now as very rare to rare that nova will bump
minimum version.

I am agree on this But also want to tests each microversion changes
through schema which does not mean we need to add tests for each
microversion. Higher microversion tests(which are valid for Tempest
like interacting with other services etc) can verify same API's lower
version changes through schema automatically.

Tempest testing which does schema validation are very useful to find
API bugs. We have found many in past and recently also [2].  How about
this:
- Do not add tests for changes which can be tested in Nova as
mentioned by you in 2nd point with below exception:
- Exception- If that version need schema change and those schema
changes are not covered by any higher version tests then add tests in
Tempest.

And this we can done at end of each cycle to make sure each version
changes in this cycle are tested thorough schema validation (is change
in schema) in Tempest.



>
> mtreinish and sdague will be at the nova midcycle so hopefully they can
> represent for the QA team.

..[1] 
http://docs.openstack.org/developer/tempest/microversion_testing.html#notes-about-compute-microversion-tests
..[2]  https://bugs.launchpad.net/nova/+bug/1602044
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage que

[openstack-dev] [Nova] About deleting keypairs

[Zhenyu Zheng]

Hi All,

We have meet some problems when trying to cleanup resources, keypairs in
particular.

The scenario is like this, we have several projects in our public cloud,
each project have their own admin, they can create and delete users, and
their users may create keypairs; As keypairs are only related to
users(user_id), when project admin delete it's users, they may forget to
delete the related keypairs and also they might tried to delete keypairs
but some thing happened and it didn't work.

Now, when we, as public cloud admin, we want to delete this project and
cleanup its' resources, we can't delete the keypairs because when delete
keypairs we have to provide the related user_id, if this user has already
been deleted(keystone uses hard delete and we cannot find deleted users
their), we won't able to delete the keypairs forever.

Does anyone have any comments or thoughts about the above problem?

Thanks

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