date:20171023

Re: [openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

2017-10-23 Thread Dave McCowan (dmccowan)

We're working on the Barbican Onboarding session now.  I don't think our Boston 
session went very well, and the results borne out; we were unable to convert 
any attendee to active contributor.  It was a much bigger group than I was 
expecting and everyone was at a different starting point .  I was unprepared 
for both of those situations.

I'd like to hear some success stories from Boston to learn from.

For projects that were successful, what topics did you cover?
For prospective Sydney Onboarders, what do you want to learn at these sessions?

Thanks!
dave-mccowan

From: Kendall Nelson >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, October 23, 2017 at 7:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

Hello Everyone :)

Everyone that has requested a slot has been added to the official schedule[1].

If conflicts arise with other talks you have or you want to add more 
presenters, please contact 
speakersupp...@openstack.org. They can get 
any issues with the schedule resolved.

We do still have spots available. If you have not yet signed up, please let me 
know immediately and I can add you to one of the available slots.

Thank you everyone! I hope you all get a good group of new contributors!

-Kendall Nelson (diablo_rojo)

[1] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/global-search?t=project+onboarding
__
OpenStack Development Mailing 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] Gertty dashboards

2017-10-23 Thread James E. Blair

Sławek Kapłoński  writes:

>>> "(NOT owner:self) status:open label:Code-Review-0,self
>>> label:Workflow=0 (project:openstack/neutron OR
>>> project:openstack/neutron-lib OR project:openstack/shade)
>>> branch:master”
>> 
>> If you haven't already, make sure you are subscribed to those three
>> projects in Gertty.  That will cause it to keep up with all of the
>> changes in those projects.  It also will also enable a per-project view
>> of open unreviewed changes for each project, very similar to your
>> dashboard.
>
> Yes, I am subscribed to all those projects and all is synced.
> I’m also using those „project views” there but I was thinking if it’s
> possible to have one view for all interesting projects for me :)

Oh, if you were already subscribed to those, then I don't know why
Gertty would be missing changes from that dashboard..  If you are able
to determine a commonality between the changes that are missing, that
may be useful.

-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

[openstack-dev] [ceilometer] the workload partition will cause consumer disappeared

2017-10-23 Thread 李田清

Hello,
 We test ceilometer workload partition, and find even with one rabbitmq 
server, the ceilometer-pipe
 will lost its consumers. Does anyone know this?
 I configure, batch_size =1, batch_timeout =1, and 
pipeline_processing_queues = 1.
 If anyone know this, please point it out. 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] [all] [elections] Technical Committee Election Results

2017-10-23 Thread Tony Breeds

On Mon, Oct 23, 2017 at 09:35:34AM +0100, Jean-Philippe Evrard wrote:

> I agree, we should care about not repeating this Pike trend. It looks
> like Queens is better in terms of turnout (see the amazing positive
> delta!). However, I can't help but noticing that the trend for
> turnouts is slowly reducing (excluding some outliers) since the
> beginning of these stats.

Yup, the table makes that pretty visible.

> Any idea on how to improve that?

Me? No ;P  I do think we need to work out *why* turnout is attending
before determining how to correct it.  I don't really think that we can
get that information though.  Community member that aren't engaged
enough to participate in the election(s) are also unlikely to
participate in a survey askign why they didn't participate ;P

I think things like the regular updates from the TC are part of the
solution.

Yours Tony.

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

[openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

2017-10-23 Thread Kendall Nelson

Hello Everyone :)

Everyone that has requested a slot has been added to the official
schedule[1].

If conflicts arise with other talks you have or you want to add more
presenters, please contact speakersupp...@openstack.org. They can get any
issues with the schedule resolved.

*We do still have spots available.* If you have not yet signed up, please
let me know immediately and I can add you to one of the available slots.

Thank you everyone! I hope you all get a good group of new contributors!

-Kendall Nelson (diablo_rojo)

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/global-search?t=project+onboarding
__
OpenStack Development Mailing 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] control_virtual_ip and corosync

2017-10-23 Thread Mark Hamzy

I am seeing "Can't connect to MySQL server on '9.114.118.250' ([Errno 113] 
EHOSTUNREACH)" when installing tripleo

Debugging it further, it seems that corosync will not start and returns an 
error code of 8.  This seems like not an error according to:

http://www.linux-ha.org/doc/dev-guides/_literal_ocf_running_master_literal_8.html

"The resource was found to be running in the Master role. This applies 
only to stateful (Master/Slave) resources, and only to their monitor 
action."

There is only one control baremetal node.

Further details are found in:

https://fedoraproject.org/wiki/User:Hamzy/TripleO_mixed_undercloud_overcloud_try8

-- 
Mark

You must be the change you wish to see in the world. -- Mahatma Gandhi
Never let the future disturb you. You will meet it, if you have to, with 
the same weapons of reason which today arm you against the present. -- 
Marcus Aurelius

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

2017-10-23 Thread Sławek Kapłoński

Hello,

> Wiadomość napisana przez James E. Blair  w dniu 
> 23.10.2017, o godz. 18:04:
> 
> Sławek Kapłoński  writes:
> 
>> Hello,
>> 
>> Recently I started using Getty and I think it’s good tool.
>> I have one problem which I don’t know how to solve. On web based
>> gerrit page (review.openstack.org) I have defined page with own query:
>> 
>> "(NOT owner:self) status:open label:Code-Review-0,self
>> label:Workflow=0 (project:openstack/neutron OR
>> project:openstack/neutron-lib OR project:openstack/shade)
>> branch:master”
> 
> If you haven't already, make sure you are subscribed to those three
> projects in Gertty.  That will cause it to keep up with all of the
> changes in those projects.  It also will also enable a per-project view
> of open unreviewed changes for each project, very similar to your
> dashboard.

Yes, I am subscribed to all those projects and all is synced.
I’m also using those „project views” there but I was thinking if it’s possible 
to have one view for all interesting projects for me :)

> 
> -Jim

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Gertty dashboards

2017-10-23 Thread Sławek Kapłoński

Hello,

> Wiadomość napisana przez Jeremy Stanley  w dniu 
> 23.10.2017, o godz. 15:02:
> 
> On 2017-10-22 11:56:06 +0200 (+0200), Sławek Kapłoński wrote:
> [...]
>> I suppose that gertty is looking only for patches which are
>> already in local database. Is it true?
> 
> Basically, yes. As far as I've seen it syncs status for any changes
> on projects to which you've explicitly subscribed, as well as any
> for which your account is the owner in Gerrit. I believe it will
> also include changes which are in its DB because you've directly
> loaded them, but does not automatically sync/update status changes
> for those unless you view and refresh them manually. I tend to work
> around this by subscribing Gertty to all the projects in which I
> regularly participate.

I am subscribed to all of projects listed in this query which I asked for. And 
still result of this query in gertty is different than result in Gerrit webpage.
Also gertty shows me that all projects are synced.

> 
>> And is there any possibility to change it?
> 
> It's software, so probably. That said, I expect Gertty would need
> some sort of first-class dashboard support where it knows (beyond
> simple keybindings for arbitrary queries, maybe similar to how it
> treats owner:self changes?) that you want all changes for dashboards
> pulled into the local DB and kept in sync so that it has them
> available for offline operation... not sure what impact that may
> have on performance either.

Yes, I know that it’s software and that it’s open source so it’s possible to 
patch it but my question was more about if it’s possible with some config 
options currently :)

> 
> And of course you'd need to convince its author this is a worthwhile
> behavior change, since there may be good reasons it was designed to
> work this way from the outset. I'll bring this thread to Jim's
> attention once he's around today; he will doubtless have more
> accurate details and concrete suggestions than I.

Thx.

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

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Gertty dashboards

2017-10-23 Thread Sławek Kapłoński

Thx for pointing those typos but it doesn’t fix „main problem” :)

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Jeremy Freudberg  w dniu 
> 23.10.2017, o godz. 02:17:
> 
> I know nothing about Gertty, but it looks like you have two typos:
> 
> - Code-Review-0 should be Code-Review=0
> - openstack/shade should openstack-infra/shade
> 
> 
> That being said, there could still be other Gertty-specific things to discuss 
> here. Hope you get the answers you need!
> 
> On Sun, Oct 22, 2017 at 5:56 AM, Sławek Kapłoński  wrote:
> Hello,
> 
> Recently I started using Getty and I think it’s good tool.
> I have one problem which I don’t know how to solve. On web based gerrit page 
> (review.openstack.org) I have defined page with own query:
> 
> "(NOT owner:self) status:open label:Code-Review-0,self label:Workflow=0 
> (project:openstack/neutron OR project:openstack/neutron-lib OR 
> project:openstack/shade) branch:master”
> 
> And it gives me list of many patches (more than 100 I think). Problem is that 
> when I configured own dashboard with exactly same query in gertty.yml file I 
> had only 22 patches displayed.
> I suppose that gertty is looking only for patches which are already in local 
> database. Is it true? And is there any possibility to change it?
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] this week's priorities and subteam reports

2017-10-23 Thread Yeleswarapu, Ramamani

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. CI migration to Zuul v3: take legacy jobs in tree
2. BIOS interface spec: https://review.openstack.org/#/c/496481/
3. Rolling upgrades: check object versions in dbsync tool: 
https://review.openstack.org/#/c/497703/
4. Finish and land switching ironicclient to "latest" 
https://review.openstack.org/#/c/512989/
5. Ref arch: common bits https://review.openstack.org/487410
6. Nova spec for migrate/resize: https://review.openstack.org/#/c/449155/

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
ilo:
irmc:
Nothing to be review this week.
oneview:
Migrate python-oneviewclient validations to Ironic OneView Drivers - 
https://review.openstack.org/#/c/468428/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
folks might consider trying the test patch to experiment manually with this 
https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 16 Oct 2017 and 23 Oct 2017)
- Ironic: 253 bugs (-8) + 258 wishlist items (+1). 19 new (+2), 195 in progress 
(-13), 0 critical, 32 high (-6) and 34 incomplete (-1)
- Inspector: 17 bugs + 29 wishlist items (-1). 2 new (-1), 15 in progress (-1), 
0 critical, 5 high and 3 incomplete
- Nova bugs with Ironic tag: 12 (-2). 0 new, 0 critical, 1 high (-1)
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Queens: what's left for rolling upgrades 
https://bugs.launchpad.net/ironic/+bug/1708243: ironic-dbsync: check object 
versions https://review.openstack.org/#/c/497703/
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- Zuul v3 jobs in-tree migration tracking 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking
- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- local boot with partition images: TODO 
https://bugs.launchpad.net/ironic/+bug/1531149
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1671145
- status as of 23 Oct 2017:
- patches on review:
- correct "latest" logic https://review.openstack.org/#/c/512986/ MERGED
- make the switch https://review.openstack.org/#/c/512989/
- missing: make --os-baremetal-api-version=1 equal to 
--os-baremetal-api-version=latest

External

[openstack-dev] [os-upstream-institute] Meeting reminder

2017-10-23 Thread Ildiko Vancsa

HI Training Team,

Our next meeting is in less than an hour at 2000 UTC on #openstack-meeting-3.

The meeting agenda is here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you on IRC in a bit! :)

Best Regards,
Ildikó



__
OpenStack Development Mailing 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] Looking for help in properly configuring a TripleO environment

2017-10-23 Thread Mark Hamzy

Joe Talerico  wrote on 10/09/2017 11:26:14 AM:

> If you ssh to your compute node can you ping 172.16.0.14?

Just a quick note to let everyone know that I am no longer seeing this 
problem.
I had to wait a while for lab services to update the firmware and then I 
was
seeing IP conflicts with rogue boxes on my DHCP range.

It seems that recent checkins to THT fixed this issue...


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

2017-10-23 Thread James E. Blair

Jeremy Stanley  writes:

> It's software, so probably. That said, I expect Gertty would need
> some sort of first-class dashboard support where it knows (beyond
> simple keybindings for arbitrary queries, maybe similar to how it
> treats owner:self changes?) that you want all changes for dashboards
> pulled into the local DB and kept in sync so that it has them
> available for offline operation... not sure what impact that may
> have on performance either.
>
> And of course you'd need to convince its author this is a worthwhile
> behavior change, since there may be good reasons it was designed to
> work this way from the outset. I'll bring this thread to Jim's
> attention once he's around today; he will doubtless have more
> accurate details and concrete suggestions than I.

We could perhaps parse the dashboard queries for project names, and
either automatically subscribe to those projects, or silently add them
to the list of projects to sync.

Or we could emit a warning: "dashboard references unsubscribed project:
...".

-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] Gertty dashboards

2017-10-23 Thread James E. Blair

Sławek Kapłoński  writes:

> Hello,
>
> Recently I started using Getty and I think it’s good tool.
> I have one problem which I don’t know how to solve. On web based
> gerrit page (review.openstack.org) I have defined page with own query:
>
> "(NOT owner:self) status:open label:Code-Review-0,self
> label:Workflow=0 (project:openstack/neutron OR
> project:openstack/neutron-lib OR project:openstack/shade)
> branch:master”

If you haven't already, make sure you are subscribed to those three
projects in Gertty.  That will cause it to keep up with all of the
changes in those projects.  It also will also enable a per-project view
of open unreviewed changes for each project, very similar to your
dashboard.

-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] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

2017-10-23 Thread Sam Matzek

The Keystone v2 removal also broke Trove's gate.  Trove's functional
and scenario tests had Keystone v2 hard codings and also relied on a >
4 year old 'compat' client package in the python-troveclient that did
not have V3 support.

Both cases required a lot of scrambling find all the v2 hard codings
and add in v3 support.

I'm completely behind the V2 removal and am glad we've finally crossed
that bridge. The one thing that I think could have been handled better
was a longer amount of time between making devstack use V3 by default
and the actual removal of the V2 auth APIs.  There were 8 days between
these two commits.  It may have been better to switch devstack to use
v3 a half cycle or full cycle before removing the v2 APIs to allow
teams that had impacts more time to react.

On Sun, Oct 22, 2017 at 1:01 PM, Clint Byrum  wrote:
> Excerpts from Jeremy Stanley's message of 2017-10-21 13:37:01 +:
>> On 2017-10-20 22:50:53 + (+), Fox, Kevin M wrote:
>> [...]
>> > Ideally, there should be an OpenStack overarching architecture
>> > team of some sort to handle this kind of thing I think.
>>
>> There was one for a while, but it dissolved due to lack of community
>> participation. If you'd like to help reboot it, Clint B. can
>> probably provide you with background on the previous attempt.
>>
>
> I'd be in support of reviving the Architecture Working Group (SIG?).
>
> Would need to see more people commit to it though. It mostly felt like
> a place for Thierry and me to write down our ideas, and a title to put
> on a room at the PTG so we could have cross-project discussions about
> our ideas.
>
> That said, there is a cross-project process that works pretty well when
> one project needs to ask for changes from other projects:
>
> https://docs.openstack.org/project-team-guide/cross-project.html
>
> I believe the Keystone team followed this process despite some fumbles
> early in the v3 story.
>
>> > Without such an entity though, I think the TC is probably
>> > currently the best place to discuss it though?
>>
>> Contrary to the impression some people seem to have, the TC is not
>> primarily composed of cloud architects; it's an elected body of
>> community leaders who seek informed input from people like you. I've
>> personally found no fault in the process and timeline the Keystone
>> team followed in this situation but I'm also not the primary
>> audience for their software, so it's good to hear from those who are
>> about ways to improve similar cases in the future. However, I also
>> understand that no matter how widely and carefully changes are
>> communicated, there's only so much anyone can do to avoid surprising
>> the subset of users who simply don't pay attention.
>
> Right, the TC is more or less a legislative body. They can set policy
> but they don't actually make sure the vision is implemented directly.
>
> I made an argument that there's a need for an executive branch to get
> hard things done here:
>
> http://fewbar.com/2017/02/open-source-governance-needs-presidents/
>
> Without some kind of immediate executive that sits above project levels,
> we'll always be designing by committee and find our silos getting deeper.
>
> All of that said, I believe the Keystone team did a great job of getting
> something hard done. As Morgan states, it was a 100% necessary evolution
> and required delicate orchestration. Well done Keystone 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] [ironic] ironic and traits

2017-10-23 Thread Dmitry Tantsur

Your suggestions requires transparent passing of extra_specs to ironic,
which is something the nova team has objections for quite some time.

On Mon, Oct 23, 2017 at 4:09 PM, Eric Fried  wrote:

> We discussed this a little bit further in IRC [1].  We're all in
> agreement, but it's worth being precise on a couple of points:
>
> * We're distinguishing between a "feature" and the "trait" that
> represents it in placement.  For the sake of this discussion, a
> "feature" can (maybe) be switched on or off, but a "trait" can either be
> present or absent on a RP.
> * It matters *who* can turn a feature on/off.
>   * If it can be done by virt at spawn time, then it makes sense to have
> the trait on the RP, and you can switch the feature on/off via a
> separate extra_spec.
>   * But if it's e.g. an admin action, and spawn has no control, then the
> trait needs to be *added* whenever the feature is *on*, and *removed*
> whenever the feature is *off*.
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/
> %23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13
>
> On 10/23/2017 08:15 AM, Sylvain Bauza wrote:
> >
> >
> > On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried  > > wrote:
> >
> > I agree with Sean.  In general terms:
> >
> > * A resource provider should be marked with a trait if that feature
> >   * Can be turned on or off (whether it's currently on or not); or
> >   * Is always on and can't ever be turned off.
> >
> >
> > No, traits are not boolean. If a resource provider stops providing a
> > capability, then the existing related trait should just be removed,
> > that's it.
> > If you see a trait, that's just means that the related capability for
> > the Resource Provider is supported, that's it too.
> >
> > MHO.
> >
> > -Sylvain
> >
> >
> >
> > * A consumer wanting that feature present (doesn't matter whether
> it's
> > on or off) should specify it as a required *trait*.
> > * A consumer wanting that feature present and turned on should
> >   * Specify it as a required trait; AND
> >   * Indicate that it be turned on via some other mechanism (e.g. a
> > separate extra_spec).
> >
> > I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's
> drive
> > for placement purity.
> >
> > Please invite me to the hangout or whatever.
> >
> > Thanks,
> > Eric
> >
> > On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
> > >
> > >
> > >
> > >
> > > *From:*Jay Pipes [mailto:jaypi...@gmail.com
> > ]
> > > *Sent:* Monday, October 23, 2017 12:20 PM
> > > *To:* OpenStack Development Mailing List
> >  > >
> > > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
> > >
> > >
> > >
> > > Writing from my phone... May I ask that before you proceed with
> any plan
> > > that uses traits for state information that we have a hangout or
> > > videoconference to discuss this? Unfortunately today and tomorrow
> I'm
> > > not able to do a hangout but I can do one on Wednesday any time of
> the day.
> > >
> > >
> > >
> > > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
> > ptg that
> > > we wanted to standardizes tratis for “verified boot” /*
> > >
> > > */that included a trait for uefi secure boot enabled and to
> > indicated a
> > > hardware root of trust, e.g. intel boot guard or similar/*
> > >
> > > */we distinctly wanted to be able to tag nova compute hosts with
> those
> > > new traits so we could require that vms that request/*
> > >
> > > */a host with uefi secure boot enabled and a hardware root of
> > trust are
> > > scheduled only to those nodes. /*
> > >
> > > */ /*
> > >
> > > */There are many other examples that effect both vms and bare
> > metal such
> > > as, ecc/interleaved memory, cluster on die, /*
> > >
> > > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
> > > threading, power states … all of these feature may be present on
> the
> > > platform/*
> > >
> > > */but I also need to know if they are turned on. Ruling out state
> in
> > > traits means all of this logic will eventually get pushed to
> scheduler
> > > filters/*
> > >
> > > */which will be suboptimal long term as more state is tracked.
> > Software
> > > defined infrastructure may be the future but hardware defined
> > software/*
> > >
> > > */is sadly the present…/*
> > >
> > > */ /*
> > >
> > > */I do however think there should be a sperateion between asking
> for a
> > > host that provides x with a trait and  asking for x to be
> > configure via/*
> > >
> > > */A trait. The trait secure_boot_enabled should

[openstack-dev] [ironic] [nova] traits discussion call

2017-10-23 Thread Dmitry Tantsur

Hi all!

I'd like to invite you to the discussion of the way to implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.

Note that it's going to be a technical discussion - please make sure you
understand what traits are and why ironic cares about them. See below for more
context.

We'll probably use my bluejeans account, as it works without plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:
> We discussed this a little bit further in IRC [1].  We're all in
> agreement, but it's worth being precise on a couple of points:
>
> * We're distinguishing between a "feature" and the "trait" that
> represents it in placement.  For the sake of this discussion, a
> "feature" can (maybe) be switched on or off, but a "trait" can either be
> present or absent on a RP.
> * It matters *who* can turn a feature on/off.
>* If it can be done by virt at spawn time, then it makes sense to have
> the trait on the RP, and you can switch the feature on/off via a
> separate extra_spec.
>* But if it's e.g. an admin action, and spawn has no control, then the
> trait needs to be *added* whenever the feature is *on*, and *removed*
> whenever the feature is *off*.
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13
>
> On 10/23/2017 08:15 AM, Sylvain Bauza wrote:
>>
>>
>> On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried > > wrote:
>>
>>  I agree with Sean.  In general terms:
>>
>>  * A resource provider should be marked with a trait if that feature
>>* Can be turned on or off (whether it's currently on or not); or
>>* Is always on and can't ever be turned off.
>>
>>
>> No, traits are not boolean. If a resource provider stops providing a
>> capability, then the existing related trait should just be removed,
>> that's it.
>> If you see a trait, that's just means that the related capability for
>> the Resource Provider is supported, that's it too.
>>
>> MHO.
>>
>> -Sylvain
>>
>>
>>
>>  * A consumer wanting that feature present (doesn't matter whether it's
>>  on or off) should specify it as a required *trait*.
>>  * A consumer wanting that feature present and turned on should
>>* Specify it as a required trait; AND
>>* Indicate that it be turned on via some other mechanism (e.g. a
>>  separate extra_spec).
>>
>>  I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
>>  for placement purity.
>>
>>  Please invite me to the hangout or whatever.
>>
>>  Thanks,
>>  Eric
>>
>>  On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
>>  >
>>  >
>>  >
>>  >
>>  > *From:*Jay Pipes [mailto:jaypi...@gmail.com
>>  ]
>>  > *Sent:* Monday, October 23, 2017 12:20 PM
>>  > *To:* OpenStack Development Mailing List
>>  >  >
>>  > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
>>  >
>>  >
>>  >
>>  > Writing from my phone... May I ask that before you proceed with any 
>> plan
>>  > that uses traits for state information that we have a hangout or
>>  > videoconference to discuss this? Unfortunately today and tomorrow I'm
>>  > not able to do a hangout but I can do one on Wednesday any time of 
>> the day.
>>  >
>>  >
>>  >
>>  > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
>>  ptg that
>>  > we wanted to standardizes tratis for “verified boot” /*
>>  >
>>  > */that included a trait for uefi secure boot enabled and to
>>  indicated a
>>  > hardware root of trust, e.g. intel boot guard or similar/*
>>  >
>>  > */we distinctly wanted to be able to tag nova compute hosts with those
>>  > new traits so we could require that vms that request/*
>>  >
>>  > */a host with uefi secure boot enabled and a hardware root of
>>  trust are
>>  > scheduled only to those nodes. /*
>>  >
>>  > */ /*
>>  >
>>  > */There are many other examples that effect both vms and bare
>>  metal such
>>  > as, ecc/interleaved memory, cluster on die, /*
>>  >
>>  > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
>>  > threading, power states … all of these feature may be present on the
>>  > platform/*
>>  >
>>  > */but I also need to know if they are turned on. Ruling out state in
>>  > traits means all of this logic will eventually get pushed to scheduler
>>  > filters/*
>>  >
>>  > */which will be suboptimal long term as more state is tracked.
>>  Software
>>  > defined infrastructure may be the future but hardware defined
>>  software/*
>>  >
>>

[openstack-dev] [manila] Need Updated Driver Maintainers in DriverLog

2017-10-23 Thread Dustin Schoenbrun

Hey all,

I was going through the DriverLog [0] to have an idea of which drivers were
maintained by whom as I go through the backlog of bugs so that I know who
to assign a driver-specific bug to if it's not already assigned. If the
driver maintainers could update the relevant parts of the DriverLog that
would be fantastic. I've attached a PDF of the known Manila drivers and
their maintainers, but know that this information is out of date and is
compiled from an old sheet that Ben had and the information that is
currently in the DriverLog. Let me know if you have any questions. Thanks!

[0] -
https://github.com/openstack/driverlog/blob/master/etc/default_data.json

Dustin Schoenbrun
OpenStack Quality Engineer
Red Hat, Inc.
dscho...@redhat.com


Manila_Driver_Maintainers.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing 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] [neutron dvr tempest test problem]

2017-10-23 Thread Ning Yao

thanks, it works.
Regards
Ning Yao


2017-08-24 19:43 GMT+08:00 Jakub Libosvar :
> On 24/08/2017 12:47, Ning Yao wrote:
>> Hi, all
>>
>> I encounter a problem about neutron tempest test. I run the tempest
>> neutron plugin test against my self-build OpenStack, and I find that
>> tempest will run the dvr test and report NotImplementedERROR. I dig
>> into the test code and find that even if I do not enable dvr router
>> for my OpenStack, the dvr test runs and does not automatically skip.
>> This is because it only skip this logic when
>> network-feature-enabled.api_extensions does not support dvr.
>> ```
>>
>> class DvrRoutersTest(base_routers.BaseRouterTest):
>>
>>
>> @classmethod
>>
>> @test.requires_ext(extension="dvr", service="network")
>>
>> def skip_checks(cls):
>>
>> super(DvrRoutersTest, cls).skip_checks()
>>
>> ```
>>
>> Is any other way to skip the test?
>>
>> I can manually delete the 'dvr' in tempest.conf
>> network-feature-enabled.api_extensions, but it is not convenient for
>> integrating test. while the value
>> network-feature-enabled.api_extensions is automatically detected from
>> neutron ext-list.
>>
>> while neutron ext-list is describing whether the current version
>> supports dvr,  dvr can be still disabled in neutron.conf for a certain
>> openstack environment. So I think we need a method to find out whether
>> this feature is enabled for the current OpenStack cluster and skip
>> this test depending on this. Am I right or I still miss something.
>>
>>
>> Regards
>> Ning Yao
>
> Hi Ning,
>
> during the Pike cycle, there was a patch [1] merged for this specific
> problem ops were facing. If your build contains this change, you can set
> enable_dvr option to False in /etc/neutron/neutron.conf and then your
> ext-list won't be propagating dvr.
>
> I hope that helps.
>
> Jakub
>
> [1] https://review.openstack.org/#/c/454203/
>>
>> __
>> OpenStack Development Mailing 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] [ironic] ironic and traits

2017-10-23 Thread Eric Fried

We discussed this a little bit further in IRC [1].  We're all in
agreement, but it's worth being precise on a couple of points:

* We're distinguishing between a "feature" and the "trait" that
represents it in placement.  For the sake of this discussion, a
"feature" can (maybe) be switched on or off, but a "trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
  * If it can be done by virt at spawn time, then it makes sense to have
the trait on the RP, and you can switch the feature on/off via a
separate extra_spec.
  * But if it's e.g. an admin action, and spawn has no control, then the
trait needs to be *added* whenever the feature is *on*, and *removed*
whenever the feature is *off*.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13

On 10/23/2017 08:15 AM, Sylvain Bauza wrote:
> 
> 
> On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried  > wrote:
> 
> I agree with Sean.  In general terms:
> 
> * A resource provider should be marked with a trait if that feature
>   * Can be turned on or off (whether it's currently on or not); or
>   * Is always on and can't ever be turned off.
> 
> 
> No, traits are not boolean. If a resource provider stops providing a
> capability, then the existing related trait should just be removed,
> that's it.
> If you see a trait, that's just means that the related capability for
> the Resource Provider is supported, that's it too.
> 
> MHO.
> 
> -Sylvain
> 
>  
> 
> * A consumer wanting that feature present (doesn't matter whether it's
> on or off) should specify it as a required *trait*.
> * A consumer wanting that feature present and turned on should
>   * Specify it as a required trait; AND
>   * Indicate that it be turned on via some other mechanism (e.g. a
> separate extra_spec).
> 
> I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
> for placement purity.
> 
> Please invite me to the hangout or whatever.
> 
> Thanks,
> Eric
> 
> On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
> >  
> >
> >  
> >
> > *From:*Jay Pipes [mailto:jaypi...@gmail.com
> ]
> > *Sent:* Monday, October 23, 2017 12:20 PM
> > *To:* OpenStack Development Mailing List
>  >
> > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
> >
> >  
> >
> > Writing from my phone... May I ask that before you proceed with any plan
> > that uses traits for state information that we have a hangout or
> > videoconference to discuss this? Unfortunately today and tomorrow I'm
> > not able to do a hangout but I can do one on Wednesday any time of the 
> day.
> >
> >  
> >
> > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
> ptg that
> > we wanted to standardizes tratis for “verified boot” /*
> >
> > */that included a trait for uefi secure boot enabled and to
> indicated a
> > hardware root of trust, e.g. intel boot guard or similar/*
> >
> > */we distinctly wanted to be able to tag nova compute hosts with those
> > new traits so we could require that vms that request/*
> >
> > */a host with uefi secure boot enabled and a hardware root of
> trust are
> > scheduled only to those nodes. /*
> >
> > */ /*
> >
> > */There are many other examples that effect both vms and bare
> metal such
> > as, ecc/interleaved memory, cluster on die, /*
> >
> > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
> > threading, power states … all of these feature may be present on the
> > platform/*
> >
> > */but I also need to know if they are turned on. Ruling out state in
> > traits means all of this logic will eventually get pushed to scheduler
> > filters/*
> >
> > */which will be suboptimal long term as more state is tracked.
> Software
> > defined infrastructure may be the future but hardware defined
> software/*
> >
> > */is sadly the present…/*
> >
> > */ /*
> >
> > */I do however think there should be a sperateion between asking for a
> > host that provides x with a trait and  asking for x to be
> configure via/*
> >
> > */A trait. The trait secure_boot_enabled should never result in the
> > feature being enabled It should just find a host with it on. If
> you want/*
> >
> > */To request it to be turned on you would request a host with
> > secure_boot_capable as a trait and have a flavor extra spec or image
> > property to request/*
> >
> > */Ironic to enabled it.  these are two very different request and
> should
> > not be treated the same. /*
> >
> >  
> >
>

Re: [openstack-dev] [ironic] ironic and traits

2017-10-23 Thread Sylvain Bauza

On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried  wrote:

> I agree with Sean.  In general terms:
>
> * A resource provider should be marked with a trait if that feature
>   * Can be turned on or off (whether it's currently on or not); or
>   * Is always on and can't ever be turned off.
>

No, traits are not boolean. If a resource provider stops providing a
capability, then the existing related trait should just be removed, that's
it.
If you see a trait, that's just means that the related capability for the
Resource Provider is supported, that's it too.

MHO.

-Sylvain



> * A consumer wanting that feature present (doesn't matter whether it's
> on or off) should specify it as a required *trait*.
> * A consumer wanting that feature present and turned on should
>   * Specify it as a required trait; AND
>   * Indicate that it be turned on via some other mechanism (e.g. a
> separate extra_spec).
>
> I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
> for placement purity.
>
> Please invite me to the hangout or whatever.
>
> Thanks,
> Eric
>
> On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
> >
> >
> >
> >
> > *From:*Jay Pipes [mailto:jaypi...@gmail.com]
> > *Sent:* Monday, October 23, 2017 12:20 PM
> > *To:* OpenStack Development Mailing List  openstack.org>
> > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
> >
> >
> >
> > Writing from my phone... May I ask that before you proceed with any plan
> > that uses traits for state information that we have a hangout or
> > videoconference to discuss this? Unfortunately today and tomorrow I'm
> > not able to do a hangout but I can do one on Wednesday any time of the
> day.
> >
> >
> >
> > */[Mooney, Sean K] on the uefi boot topic I did bring up at the ptg that
> > we wanted to standardizes tratis for “verified boot” /*
> >
> > */that included a trait for uefi secure boot enabled and to indicated a
> > hardware root of trust, e.g. intel boot guard or similar/*
> >
> > */we distinctly wanted to be able to tag nova compute hosts with those
> > new traits so we could require that vms that request/*
> >
> > */a host with uefi secure boot enabled and a hardware root of trust are
> > scheduled only to those nodes. /*
> >
> > */ /*
> >
> > */There are many other examples that effect both vms and bare metal such
> > as, ecc/interleaved memory, cluster on die, /*
> >
> > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
> > threading, power states … all of these feature may be present on the
> > platform/*
> >
> > */but I also need to know if they are turned on. Ruling out state in
> > traits means all of this logic will eventually get pushed to scheduler
> > filters/*
> >
> > */which will be suboptimal long term as more state is tracked. Software
> > defined infrastructure may be the future but hardware defined software/*
> >
> > */is sadly the present…/*
> >
> > */ /*
> >
> > */I do however think there should be a sperateion between asking for a
> > host that provides x with a trait and  asking for x to be configure via/*
> >
> > */A trait. The trait secure_boot_enabled should never result in the
> > feature being enabled It should just find a host with it on. If you
> want/*
> >
> > */To request it to be turned on you would request a host with
> > secure_boot_capable as a trait and have a flavor extra spec or image
> > property to request/*
> >
> > */Ironic to enabled it.  these are two very different request and should
> > not be treated the same. /*
> >
> >
> >
> >
> >
> > Lemme know!
> >
> > -jay
> >
> >
> >
> > On Oct 23, 2017 5:01 AM, "Dmitry Tantsur"  > > wrote:
> >
> > Hi Jay!
> >
> > I appreciate your comments, but I think you're approaching the
> > problem from purely VM point of view. Things simply don't work the
> > same way in bare metal, at least not if we want to provide the same
> > user experience.
> >
> >
> >
> > On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes  > > wrote:
> >
> > Sorry for delay, took a week off before starting a new job.
> > Comments inline.
> >
> > On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
> >
> > Hi all,
> >
> > I promised John to dump my thoughts on traits to the ML, so
> > here we go :)
> >
> > I see two roles of traits (or kinds of traits) for bare
> metal:
> > 1. traits that say what the node can do already (e.g. "the
> > node is
> > doing UEFI boot")
> > 2. traits that say what the node can be *configured* to do
> > (e.g. "the node can
> > boot in UEFI mode")
> >
> >
> > There's only one role for traits. #2 above. #1 is state
> > information. Traits are not for state information. Traits are
> > only for communicating capabilities of a resource provider
> >

Re: [openstack-dev] Gertty dashboards

2017-10-23 Thread Jeremy Stanley

On 2017-10-22 11:56:06 +0200 (+0200), Sławek Kapłoński wrote:
[...]
> I suppose that gertty is looking only for patches which are
> already in local database. Is it true?

Basically, yes. As far as I've seen it syncs status for any changes
on projects to which you've explicitly subscribed, as well as any
for which your account is the owner in Gerrit. I believe it will
also include changes which are in its DB because you've directly
loaded them, but does not automatically sync/update status changes
for those unless you view and refresh them manually. I tend to work
around this by subscribing Gertty to all the projects in which I
regularly participate.

> And is there any possibility to change it?

It's software, so probably. That said, I expect Gertty would need
some sort of first-class dashboard support where it knows (beyond
simple keybindings for arbitrary queries, maybe similar to how it
treats owner:self changes?) that you want all changes for dashboards
pulled into the local DB and kept in sync so that it has them
available for offline operation... not sure what impact that may
have on performance either.

And of course you'd need to convince its author this is a worthwhile
behavior change, since there may be good reasons it was designed to
work this way from the outset. I'll bring this thread to Jim's
attention once he's around today; he will doubtless have more
accurate details and concrete suggestions than I.
-- 
Jeremy Stanley

signature.asc
Description: 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] [ironic] ironic and traits

2017-10-23 Thread Eric Fried

I agree with Sean.  In general terms:

* A resource provider should be marked with a trait if that feature
  * Can be turned on or off (whether it's currently on or not); or
  * Is always on and can't ever be turned off.
* A consumer wanting that feature present (doesn't matter whether it's
on or off) should specify it as a required *trait*.
* A consumer wanting that feature present and turned on should
  * Specify it as a required trait; AND
  * Indicate that it be turned on via some other mechanism (e.g. a
separate extra_spec).

I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
for placement purity.

Please invite me to the hangout or whatever.

Thanks,
Eric

On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
>  
> 
>  
> 
> *From:*Jay Pipes [mailto:jaypi...@gmail.com]
> *Sent:* Monday, October 23, 2017 12:20 PM
> *To:* OpenStack Development Mailing List 
> *Subject:* Re: [openstack-dev] [ironic] ironic and traits
> 
>  
> 
> Writing from my phone... May I ask that before you proceed with any plan
> that uses traits for state information that we have a hangout or
> videoconference to discuss this? Unfortunately today and tomorrow I'm
> not able to do a hangout but I can do one on Wednesday any time of the day.
> 
>  
> 
> */[Mooney, Sean K] on the uefi boot topic I did bring up at the ptg that
> we wanted to standardizes tratis for “verified boot” /*
> 
> */that included a trait for uefi secure boot enabled and to indicated a
> hardware root of trust, e.g. intel boot guard or similar/*
> 
> */we distinctly wanted to be able to tag nova compute hosts with those
> new traits so we could require that vms that request/*
> 
> */a host with uefi secure boot enabled and a hardware root of trust are
> scheduled only to those nodes. /*
> 
> */ /*
> 
> */There are many other examples that effect both vms and bare metal such
> as, ecc/interleaved memory, cluster on die, /*
> 
> */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
> threading, power states … all of these feature may be present on the
> platform/*
> 
> */but I also need to know if they are turned on. Ruling out state in
> traits means all of this logic will eventually get pushed to scheduler
> filters/*
> 
> */which will be suboptimal long term as more state is tracked. Software
> defined infrastructure may be the future but hardware defined software/*
> 
> */is sadly the present…/*
> 
> */ /*
> 
> */I do however think there should be a sperateion between asking for a
> host that provides x with a trait and  asking for x to be configure via/*
> 
> */A trait. The trait secure_boot_enabled should never result in the
> feature being enabled It should just find a host with it on. If you want/*
> 
> */To request it to be turned on you would request a host with
> secure_boot_capable as a trait and have a flavor extra spec or image
> property to request/*
> 
> */Ironic to enabled it.  these are two very different request and should
> not be treated the same. /*
> 
>  
> 
>  
> 
> Lemme know!
> 
> -jay
> 
>  
> 
> On Oct 23, 2017 5:01 AM, "Dmitry Tantsur"  > wrote:
> 
> Hi Jay!
> 
> I appreciate your comments, but I think you're approaching the
> problem from purely VM point of view. Things simply don't work the
> same way in bare metal, at least not if we want to provide the same
> user experience.
> 
>  
> 
> On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes  > wrote:
> 
> Sorry for delay, took a week off before starting a new job.
> Comments inline.
> 
> On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
> 
> Hi all,
> 
> I promised John to dump my thoughts on traits to the ML, so
> here we go :)
> 
> I see two roles of traits (or kinds of traits) for bare metal:
> 1. traits that say what the node can do already (e.g. "the
> node is
> doing UEFI boot")
> 2. traits that say what the node can be *configured* to do
> (e.g. "the node can
> boot in UEFI mode")
> 
> 
> There's only one role for traits. #2 above. #1 is state
> information. Traits are not for state information. Traits are
> only for communicating capabilities of a resource provider
> (baremetal node).
> 
>  
> 
> These are not different, that's what I'm talking about here. No
> users care about the difference between "this node was put in UEFI
> mode by an operator in advance", "this node was put in UEFI mode by
> an ironic driver on demand" and "this node is always in UEFI mode,
> because it's AARCH64 and it does not have BIOS". These situation
> produce the same result (the node is booted in UEFI mode), and thus
> it's up to ironic to hide this difference.
> 
>  
> 
> My suggestion with traits is one

[openstack-dev] [QA} No QA team meeting on 26/10

2017-10-23 Thread Andrea Frittoli

Deal all,

I'm cancelling the QA meeting next Thursday as I will be travelling.
For any urgent thing, please find us in the #openstack-qa room.

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

Re: [openstack-dev] [qa] Proposing changes to 17UTC team meeting

2017-10-23 Thread Andrea Frittoli

On Mon, Oct 23, 2017 at 2:22 AM Ghanshyam Mann 
wrote:

> 1 typo correction, All current meeting and office hours are on
> Thursday (not Tuesday).
>
> Week1:
> - *Thu* 9:00 UTC Office hours in #openstack-qa
> - *Thu* 17:00 UTC Meeting in #openstack-meeting
> Week2:
> - *Thu* 8:00 UTC Meeting in #openstack-meeting
>

Thanks! :)


>
> -gmann
>
>
> On Sat, Oct 21, 2017 at 5:43 AM, Andrea Frittoli
>  wrote:
> > Dear all,
> >
> > The current schedule for QA meetings and office hours is as follows
> > (alternating weeks):
> >
> > Week1:
> > - Tue 9:00 UTC Office hours in #openstack-qa
> > - Tue 17:00 UTC Meeting in #openstack-meeting
> > Week2:
> > - Tue 8:00 UTC Meeting in #openstack-meeting
> >
> > Since the 17:00 UTC as a rather low attendance, but not zero, I would
> > propose to drop that meeting in favour of a second office hours slot, so
> > that we have one slot every week and the meeting would be every
> > second week:
> >
> > Week1:
> > - Tue 9:00 UTC Office hours in #openstack-qa
> > Week2:
> > - Tue 8:00 UTC Meeting in #openstack-meeting
> > - [TBD] Office hours in #openstack-qa
> >
> > Proposals for the office hours schedule in the doodle [0]
> >
> > Let me know your thoughts on this proposal and please vote for the
> > time slot in the doodle.
> >
> > Thank you!
> >
> > Andrea Frittoli (andreaf)
> >
> > [0] https://doodle.com/poll/kf6b8847wa2s5mxv
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Migrating TripleO jobs to native Zuul v3

2017-10-23 Thread David Moreau Simard

Reminder that this session is taking place in ~1h20minutes from the time of
this email.

I sent out Bluejeans invites to the people who signed up, if you didn't get
one, please poke me on IRC (dmsimard).


David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

On Wed, Oct 18, 2017 at 5:26 PM, David Moreau Simard  wrote:

> It looks like the best slot for everyone [1] is monday October 23rd @
> 10:00AM EST (2:00PM UTC).
>
> I'll send invites out, don't forget to start writing down things
> you're interested in learning
> about in the etherpad [2].
>
> [1]: https://beta.doodle.com/poll/hfkcgrahwskm2ggv
> [2]: https://etherpad.openstack.org/p/migrating-tripleo-zuulv3
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Mon, Oct 16, 2017 at 11:08 AM, David Moreau Simard 
> wrote:
> > Hi,
> >
> > Unless you've been hiding under a rock (which is totally
> > understandable), you know that Zuul v3 is here.
> >
> > Zuul v3 can be seen as a hindrance as of late because it's been
> > messing up with the gate jobs or preventing your patches to merge,
> > etc.
> > Hopefully, the "legacy" Zuul v3 jobs are all fixed up now and things
> > are able to merge without too much troubles.
> > I'm here to tell you that Zuul v3 is in fact awesome and I'd like
> > TripleO to benefit from all it's glory ASAP.
> >
> > I encourage everyone, not just people typically involved in CI, to
> > take a read at the Zuul v3 migration guide [1].
> > Zuul v3 opens a lot of opportunities to streamline, improve and
> > simplify the CI of TripleO in upstream.
> >
> > I'd like to open up an informal "ask me anything" regarding what's
> > implied in properly migrating TripleO jobs to "native" Zuul v3 and
> > have set up an etherpad to start collecting questions [2].
> > We could do a recorded Bluejeans session sometime early next week.
> > I've set up a Doodle, please tell us what time would work best for you
> [3].
> >
> > Paul Belanger and I will be there to answer questions from a Zuul v3
> > and upstream infrastructure perspective.
> >
> > We might also have questions for you !
> > For example, how do we plan on keeping jobs "compatible" between
> > review.openstack.org and review.rdoproject.org ?
> >
> > Thanks !
> >
> > [1]: https://docs.openstack.org/infra/manual/zuulv3.html
> > [2]: https://etherpad.openstack.org/p/migrating-tripleo-zuulv3
> > [3]: https://doodle.com/poll/hfkcgrahwskm2ggv
> >
> > David Moreau Simard
> > Senior Software Engineer | OpenStack RDO
> >
> > dmsimard = [irc, github, twitter]
>
__
OpenStack Development Mailing 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] ironic and traits

2017-10-23 Thread Mooney, Sean K

From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, October 23, 2017 12:20 PM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [ironic] ironic and traits

Writing from my phone... May I ask that before you proceed with any plan that 
uses traits for state information that we have a hangout or videoconference to 
discuss this? Unfortunately today and tomorrow I'm not able to do a hangout but 
I can do one on Wednesday any time of the day.

[Mooney, Sean K] on the uefi boot topic I did bring up at the ptg that we 
wanted to standardizes tratis for “verified boot”
that included a trait for uefi secure boot enabled and to indicated a hardware 
root of trust, e.g. intel boot guard or similar
we distinctly wanted to be able to tag nova compute hosts with those new traits 
so we could require that vms that request
a host with uefi secure boot enabled and a hardware root of trust are scheduled 
only to those nodes.

There are many other examples that effect both vms and bare metal such as, 
ecc/interleaved memory, cluster on die,
l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper threading, power 
states … all of these feature may be present on the platform
but I also need to know if they are turned on. Ruling out state in traits means 
all of this logic will eventually get pushed to scheduler filters
which will be suboptimal long term as more state is tracked. Software defined 
infrastructure may be the future but hardware defined software
is sadly the present…

I do however think there should be a sperateion between asking for a host that 
provides x with a trait and  asking for x to be configure via
A trait. The trait secure_boot_enabled should never result in the feature being 
enabled It should just find a host with it on. If you want
To request it to be turned on you would request a host with secure_boot_capable 
as a trait and have a flavor extra spec or image property to request
Ironic to enabled it.  these are two very different request and should not be 
treated the same.

Lemme know!
-jay

On Oct 23, 2017 5:01 AM, "Dmitry Tantsur" 
> wrote:
Hi Jay!
I appreciate your comments, but I think you're approaching the problem from 
purely VM point of view. Things simply don't work the same way in bare metal, 
at least not if we want to provide the same user experience.

On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes 
> wrote:
Sorry for delay, took a week off before starting a new job. Comments inline.

On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
Hi all,

I promised John to dump my thoughts on traits to the ML, so here we go :)

I see two roles of traits (or kinds of traits) for bare metal:
1. traits that say what the node can do already (e.g. "the node is
doing UEFI boot")
2. traits that say what the node can be *configured* to do (e.g. "the node can
boot in UEFI mode")

There's only one role for traits. #2 above. #1 is state information. Traits are 
not for state information. Traits are only for communicating capabilities of a 
resource provider (baremetal node).

These are not different, that's what I'm talking about here. No users care 
about the difference between "this node was put in UEFI mode by an operator in 
advance", "this node was put in UEFI mode by an ironic driver on demand" and 
"this node is always in UEFI mode, because it's AARCH64 and it does not have 
BIOS". These situation produce the same result (the node is booted in UEFI 
mode), and thus it's up to ironic to hide this difference.

My suggestion with traits is one way to do it, I'm not sure what you suggest 
though.

For example, let's say we add the following to the os-traits library [1]

* STORAGE_RAID_0
* STORAGE_RAID_1
* STORAGE_RAID_5
* STORAGE_RAID_6
* STORAGE_RAID_10

The Ironic administrator would add all RAID-related traits to the baremetal 
nodes that had the *capability* of supporting that particular RAID setup [2]

When provisioned, the baremetal node would either have RAID configured in a 
certain level or not configured at all.

A very important note: the Placement API and Nova scheduler (or future Ironic 
scheduler) doesn't care about this. At all. I know it sounds like I'm being 
callous, but I'm not. Placement and scheduling doesn't care about the state of 
things. It only cares about the capabilities of target destinations. That's it.

Yes, because VMs always start with a clean state, and hypervisor is there to 
ensure that. We don't have this luxury in ironic :) E.g. our SNMP driver is not 
even aware of boot modes (or RAID, or BIOS configuration), which does not mean 
that a node using it cannot be in UEFI mode (have a RAID or BIOS 
pre-configured, etc, etc).

This seems confusing, but it's actually very useful. Say, I have a flavor that
requests UEFI boot via a trait. It will match both the nodes that are already in
UEFI mode, as well as nodes that

Re: [openstack-dev] [ironic] ironic and traits

2017-10-23 Thread Dmitry Tantsur

Actually, I was suggesting the same to John the other day :) I can throw a
doodle later today to pick the time.

On 10/23/2017 01:19 PM, Jay Pipes wrote:
> Writing from my phone... May I ask that before you proceed with any plan that
> uses traits for state information that we have a hangout or videoconference to
> discuss this? Unfortunately today and tomorrow I'm not able to do a hangout 
> but
> I can do one on Wednesday any time of the day.
>
> Lemme know!
> -jay
>
> On Oct 23, 2017 5:01 AM, "Dmitry Tantsur"  > wrote:
>
> Hi Jay!
>
> I appreciate your comments, but I think you're approaching the problem 
> from
> purely VM point of view. Things simply don't work the same way in bare
> metal, at least not if we want to provide the same user experience.
>
> On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes  > wrote:
>
> Sorry for delay, took a week off before starting a new job. Comments 
> inline.
>
> On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
>
> Hi all,
>
> I promised John to dump my thoughts on traits to the ML, so here 
> we
> go :)
>
> I see two roles of traits (or kinds of traits) for bare metal:
> 1. traits that say what the node can do already (e.g. "the node is
> doing UEFI boot")
> 2. traits that say what the node can be *configured* to do (e.g.
> "the node can
> boot in UEFI mode")
>
>
> There's only one role for traits. #2 above. #1 is state information.
> Traits are not for state information. Traits are only for 
> communicating
> capabilities of a resource provider (baremetal node).
>
>
> These are not different, that's what I'm talking about here. No users care
> about the difference between "this node was put in UEFI mode by an 
> operator
> in advance", "this node was put in UEFI mode by an ironic driver on 
> demand"
> and "this node is always in UEFI mode, because it's AARCH64 and it does 
> not
> have BIOS". These situation produce the same result (the node is booted in
> UEFI mode), and thus it's up to ironic to hide this difference.
>
> My suggestion with traits is one way to do it, I'm not sure what you 
> suggest
> though.
>
>
> For example, let's say we add the following to the os-traits library 
> [1]
>
> * STORAGE_RAID_0
> * STORAGE_RAID_1
> * STORAGE_RAID_5
> * STORAGE_RAID_6
> * STORAGE_RAID_10
>
> The Ironic administrator would add all RAID-related traits to the
> baremetal nodes that had the *capability* of supporting that 
> particular
> RAID setup [2]
>
> When provisioned, the baremetal node would either have RAID configured
> in a certain level or not configured at all.
>
>
> A very important note: the Placement API and Nova scheduler (or future
> Ironic scheduler) doesn't care about this. At all. I know it sounds 
> like
> I'm being callous, but I'm not. Placement and scheduling doesn't care
> about the state of things. It only cares about the capabilities of
> target destinations. That's it.
>
>
> Yes, because VMs always start with a clean state, and hypervisor is there 
> to
> ensure that. We don't have this luxury in ironic :) E.g. our SNMP driver 
> is
> not even aware of boot modes (or RAID, or BIOS configuration), which does
> not mean that a node using it cannot be in UEFI mode (have a RAID or BIOS
> pre-configured, etc, etc).
>
>
> This seems confusing, but it's actually very useful. Say, I have a
> flavor that
> requests UEFI boot via a trait. It will match both the nodes that
> are already in
> UEFI mode, as well as nodes that can be put in UEFI mode.
>
>
> No :) It will only match nodes that have the UEFI capability. The set 
> of
> providers that have the ability to be booted via UEFI is *always* a
> superset of the set of providers that *have been booted via UEFI*.
> Placement and scheduling decisions only care about that superset -- 
> the
> providers with a particular capability.
>
>
> Well, no, it will. Again, you're purely basing on the VM idea, where a VM 
> is
> always *put* in UEFI mode, no matter how the hypervisor looks like. It is
> simply not the case for us. You have to care what state the node is, 
> because
> many drivers cannot change this state.
>
>
> This idea goes further with deploy templates (new concept we've 
> been
> thinking
> about). A flavor can request something like CUSTOM_RAID_5, and it
> will match the
> nodes that already have RAID 5, or, more interestingly, the nodes 
> on
> which we
> can

Re: [openstack-dev] [ironic] ironic and traits

2017-10-23 Thread Jay Pipes

Writing from my phone... May I ask that before you proceed with any plan
that uses traits for state information that we have a hangout or
videoconference to discuss this? Unfortunately today and tomorrow I'm not
able to do a hangout but I can do one on Wednesday any time of the day.

Lemme know!
-jay

On Oct 23, 2017 5:01 AM, "Dmitry Tantsur"  wrote:

> Hi Jay!
>
> I appreciate your comments, but I think you're approaching the problem
> from purely VM point of view. Things simply don't work the same way in bare
> metal, at least not if we want to provide the same user experience.
>
> On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes  wrote:
>
>> Sorry for delay, took a week off before starting a new job. Comments
>> inline.
>>
>> On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
>>
>>> Hi all,
>>>
>>> I promised John to dump my thoughts on traits to the ML, so here we go :)
>>>
>>> I see two roles of traits (or kinds of traits) for bare metal:
>>> 1. traits that say what the node can do already (e.g. "the node is
>>> doing UEFI boot")
>>> 2. traits that say what the node can be *configured* to do (e.g. "the
>>> node can
>>> boot in UEFI mode")
>>>
>>
>> There's only one role for traits. #2 above. #1 is state information.
>> Traits are not for state information. Traits are only for communicating
>> capabilities of a resource provider (baremetal node).
>>
>
> These are not different, that's what I'm talking about here. No users care
> about the difference between "this node was put in UEFI mode by an operator
> in advance", "this node was put in UEFI mode by an ironic driver on demand"
> and "this node is always in UEFI mode, because it's AARCH64 and it does not
> have BIOS". These situation produce the same result (the node is booted in
> UEFI mode), and thus it's up to ironic to hide this difference.
>
> My suggestion with traits is one way to do it, I'm not sure what you
> suggest though.
>
>
>>
>> For example, let's say we add the following to the os-traits library [1]
>>
>> * STORAGE_RAID_0
>> * STORAGE_RAID_1
>> * STORAGE_RAID_5
>> * STORAGE_RAID_6
>> * STORAGE_RAID_10
>>
>> The Ironic administrator would add all RAID-related traits to the
>> baremetal nodes that had the *capability* of supporting that particular
>> RAID setup [2]
>>
>> When provisioned, the baremetal node would either have RAID configured in
>> a certain level or not configured at all.
>>
>
>> A very important note: the Placement API and Nova scheduler (or future
>> Ironic scheduler) doesn't care about this. At all. I know it sounds like
>> I'm being callous, but I'm not. Placement and scheduling doesn't care about
>> the state of things. It only cares about the capabilities of target
>> destinations. That's it.
>>
>
> Yes, because VMs always start with a clean state, and hypervisor is there
> to ensure that. We don't have this luxury in ironic :) E.g. our SNMP driver
> is not even aware of boot modes (or RAID, or BIOS configuration), which
> does not mean that a node using it cannot be in UEFI mode (have a RAID or
> BIOS pre-configured, etc, etc).
>
>
>>
>> This seems confusing, but it's actually very useful. Say, I have a flavor
>>> that
>>> requests UEFI boot via a trait. It will match both the nodes that are
>>> already in
>>> UEFI mode, as well as nodes that can be put in UEFI mode.
>>>
>>
>> No :) It will only match nodes that have the UEFI capability. The set of
>> providers that have the ability to be booted via UEFI is *always* a
>> superset of the set of providers that *have been booted via UEFI*.
>> Placement and scheduling decisions only care about that superset -- the
>> providers with a particular capability.
>>
>
> Well, no, it will. Again, you're purely basing on the VM idea, where a VM
> is always *put* in UEFI mode, no matter how the hypervisor looks like. It
> is simply not the case for us. You have to care what state the node is,
> because many drivers cannot change this state.
>
>
>>
>> This idea goes further with deploy templates (new concept we've been
>>> thinking
>>> about). A flavor can request something like CUSTOM_RAID_5, and it will
>>> match the
>>> nodes that already have RAID 5, or, more interestingly, the nodes on
>>> which we
>>> can build RAID 5 before deployment. The UEFI example above can be
>>> treated in a
>>> similar way.
>>>
>>> This ends up with two sources of knowledge about traits in ironic:
>>> 1. Operators setting something they know about hardware ("this node is
>>> in UEFI
>>> mode"),
>>> 2. Ironic drivers reporting something they
>>>2.1. know about hardware ("this node is in UEFI mode" - again)
>>>2.2. can do about hardware ("I can put this node in UEFI mode")
>>>
>>
>> You're correct that both pieces of information are important. However,
>> only the "can do about hardware" part is relevant to Placement and Nova.
>>
>> For case #1 we are planning on a new CRUD API to set/unset traits for a
>>> node.
>>>
>>
>> I would *strongly* advise against

[openstack-dev] [TripleO][infra][CI] Moving OVB jobs from RH1 cloud to RDO cloud, plan

2017-10-23 Thread Sagi Shnaidman

Hi,

as you know we prepare transition of all OVB jobs from RH1 cloud to RDO
cloud, also a few long multinode upgrades jobs as well. We prepared a
workflow of transition below, please feel free to comment.


1) We run one job (ovb-ha-oooq) on every patch in following repos: oooq,
oooq-extras, tripleo-ci. We run rest of ovb jobs (containers and fs024) as
experimental in rdo cloud for following repos: oooq, oooq-extras,
tripleo-ci, tht, tripleo-common. It should cover most of our testing. This
step is completed.

Currently it's blocked by newton bug in RDO cloud:
https://bugs.launchpad.net/heat/+bug/1626256 , where cloud release doesn't
contain its fix: https://review.openstack.org/#/c/501592/ . From other
side, the upgrade to Ocata release (which would solve this issue too) is
blocked by bug: https://bugs.launchpad.net/tripleo/+bug/1724328
So we are in blocked state right now with moving.

Next steps:

2) We solve all issues with running on every patch job (ovb-ha-oooq) so
that it's passing (or failing exactly for same results as on rh1) for a 2
regular working days. (not weekend).
3) We should trigger experimental jobs in this time on various patches in
tht and tripleo-common and solve all issues for experimental jobs so all
ovb jobs pass.
4) We need to monitor all this time resources in openstack-nodepool tenant
(with help of rhops maybe) and be sure that it has the capacity to run
configured jobs.
5) We set ovb-ha-oooq job as running for every patch in all places where
it's running in rh1 (in parallel with existing rh1 job). We monitor RDO
cloud that it doesn't fail and still have resources - 1.5 working days
6) We add featureset024 ovb job to run in every patch where it runs in rh1.
We continue to monitor RDO cloud - 1.5 working days
7) We add last containers ovb job to all patches where it runs on rh1. We
continue monitor RDO cloud - 2 days.
8) In case if everything is OK in all previous points and RDO cloud still
performs well, we remove ovb jobs from rh1 configuration and make them as
experimental.
9) During next few days we monitor ovb jobs and run rh1 ovb jobs as
experimental to check if we have the same results (or better :) )
10) OVB jobs on rh1 cloud stay in experimental pipeline in tripleo for a
next month or two.

-- 
Best regards
Sagi Shnaidman
__
OpenStack Development Mailing 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] undercloud containers with SELinux Enforcing

2017-10-23 Thread Bogdan Dobrelya

Hello folks.
I need your feedback please on SELinux fixes [0] (or rather workarounds)
for containerized undercloud feature, which is experimental in Pike.

[TL;DR] The problem I'm trying to solve is primarily allowing TripleO
users to follow the guide [1] w/o telling them "please disable SELinux".

Especially, given the note "The undercloud is intended to work correctly
with SELinux enforcing, and cannot be installed to a system with SELinux
disabled".

I understand that putting "chcon -Rt svirt_sandbox_file_t -l s0" (see
[2]) to all of the host paths bind-mounted into containers is not
secure, and from SELinux perspective allows everything to all
containers. That could be a first step for docker volumes working w/o
shutting down SELinux on *hosts* though.

I plan to use the same approach for the t-h-t docker/services host-prep
tasks as well. Why not using docker's :z :Z directly? IIUC, it doesn't
allow combine with other mount flags, like :ro:z won't work. I look
forward for better solutions and ideas!

[0] https://review.openstack.org/#/q/topic:bug/1682179
[1]
https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/undercloud.html
[2]
https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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-ovn] Error while running unit tests(master branch)

2017-10-23 Thread Lucas Alvares Gomes

Hi Pranab,

Thanks for the interest in OVN.

> # tox
> ..
> {9}networking_ovn.tests.unit.ovsdb.test_ovsdb_monitor.TestOvnConnection.test_connection_sb_start
> [0.015743s] ... ok
> Mechanism driver 'ovn' failed in create_port_precommit
> Traceback (most recent call last):
>   File 
> "networking-ovn-orig/networking-ovn/.tox/py27/src/neutron/neutron/plugins/ml2/managers.py",
> line 428, in _call_on_drivers
> getattr(driver.obj, method_name)(context)
>   File "networking_ovn/ml2/mech_driver.py", line 325, in create_port_precommit
> utils.validate_and_get_data_from_binding_profile(port)
>   File "networking_ovn/common/utils.py", line 162, in
> validate_and_get_data_from_binding_profile
> raise n_exc.InvalidInput(error_message=msg)
> InvalidInput: Invalid input for operation: Invalid binding:profile.
> vtep-logical-switch 1234 value invalid type.
>
> Is the test suite broken?.
>
> Any ideas on how to fix it?

So, not really sure what is going on there. I've just ran the
unit-tests (master branch) against a fresh environment using both
Python 2 and 3 interpreters and it finished successfully [0].

Could you please paste (at [1]) the whole output of the tests run for
us please ?

[0] http://paste.openstack.org/show/624353/
[1] http://paste.openstack.org/

Cheers,
Lucas

__
OpenStack Development Mailing 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] ironic and traits

2017-10-23 Thread Dmitry Tantsur

Hi Jay!

I appreciate your comments, but I think you're approaching the problem from
purely VM point of view. Things simply don't work the same way in bare
metal, at least not if we want to provide the same user experience.

On Sun, Oct 22, 2017 at 2:25 PM, Jay Pipes  wrote:

> Sorry for delay, took a week off before starting a new job. Comments
> inline.
>
> On 10/16/2017 12:24 PM, Dmitry Tantsur wrote:
>
>> Hi all,
>>
>> I promised John to dump my thoughts on traits to the ML, so here we go :)
>>
>> I see two roles of traits (or kinds of traits) for bare metal:
>> 1. traits that say what the node can do already (e.g. "the node is
>> doing UEFI boot")
>> 2. traits that say what the node can be *configured* to do (e.g. "the
>> node can
>> boot in UEFI mode")
>>
>
> There's only one role for traits. #2 above. #1 is state information.
> Traits are not for state information. Traits are only for communicating
> capabilities of a resource provider (baremetal node).
>

These are not different, that's what I'm talking about here. No users care
about the difference between "this node was put in UEFI mode by an operator
in advance", "this node was put in UEFI mode by an ironic driver on demand"
and "this node is always in UEFI mode, because it's AARCH64 and it does not
have BIOS". These situation produce the same result (the node is booted in
UEFI mode), and thus it's up to ironic to hide this difference.

My suggestion with traits is one way to do it, I'm not sure what you
suggest though.


>
> For example, let's say we add the following to the os-traits library [1]
>
> * STORAGE_RAID_0
> * STORAGE_RAID_1
> * STORAGE_RAID_5
> * STORAGE_RAID_6
> * STORAGE_RAID_10
>
> The Ironic administrator would add all RAID-related traits to the
> baremetal nodes that had the *capability* of supporting that particular
> RAID setup [2]
>
> When provisioned, the baremetal node would either have RAID configured in
> a certain level or not configured at all.
>

> A very important note: the Placement API and Nova scheduler (or future
> Ironic scheduler) doesn't care about this. At all. I know it sounds like
> I'm being callous, but I'm not. Placement and scheduling doesn't care about
> the state of things. It only cares about the capabilities of target
> destinations. That's it.
>

Yes, because VMs always start with a clean state, and hypervisor is there
to ensure that. We don't have this luxury in ironic :) E.g. our SNMP driver
is not even aware of boot modes (or RAID, or BIOS configuration), which
does not mean that a node using it cannot be in UEFI mode (have a RAID or
BIOS pre-configured, etc, etc).


>
> This seems confusing, but it's actually very useful. Say, I have a flavor
>> that
>> requests UEFI boot via a trait. It will match both the nodes that are
>> already in
>> UEFI mode, as well as nodes that can be put in UEFI mode.
>>
>
> No :) It will only match nodes that have the UEFI capability. The set of
> providers that have the ability to be booted via UEFI is *always* a
> superset of the set of providers that *have been booted via UEFI*.
> Placement and scheduling decisions only care about that superset -- the
> providers with a particular capability.
>

Well, no, it will. Again, you're purely basing on the VM idea, where a VM
is always *put* in UEFI mode, no matter how the hypervisor looks like. It
is simply not the case for us. You have to care what state the node is,
because many drivers cannot change this state.


>
> This idea goes further with deploy templates (new concept we've been
>> thinking
>> about). A flavor can request something like CUSTOM_RAID_5, and it will
>> match the
>> nodes that already have RAID 5, or, more interestingly, the nodes on
>> which we
>> can build RAID 5 before deployment. The UEFI example above can be treated
>> in a
>> similar way.
>>
>> This ends up with two sources of knowledge about traits in ironic:
>> 1. Operators setting something they know about hardware ("this node is in
>> UEFI
>> mode"),
>> 2. Ironic drivers reporting something they
>>2.1. know about hardware ("this node is in UEFI mode" - again)
>>2.2. can do about hardware ("I can put this node in UEFI mode")
>>
>
> You're correct that both pieces of information are important. However,
> only the "can do about hardware" part is relevant to Placement and Nova.
>
> For case #1 we are planning on a new CRUD API to set/unset traits for a
>> node.
>>
>
> I would *strongly* advise against this. Traits are not for state
> information.
>
> Instead, consider having a DB (or JSON) schema that lists state
> information in fields that are explicitly for that state information.
>
> For example, a schema that looks like this:
>
> {
>   "boot": {
> "mode": ,
> "params": 
>   },
>   "disk": {
> "raid": {
>   "level": ,
>   "controller": ,
>   "driver": ,
>   "params": 
> },  ...
>   },
>   "network": {
> ...
>   }
> }
>
> etc, etc.
>
> Don't use trait strings to represent

Re: [openstack-dev] [ironic] Support for single OpenStack system supporting VM and Baremetal Instances simultaneously ?

2017-10-23 Thread Dmitry Tantsur

Hi Greg!

Answers inline.

On 10/20/2017 09:25 PM, Waines, Greg wrote:
> Hey,
>
> We are in the process of integrating OpenStack Ironic into our own OpenStack
> Distribution.

Nice to hear :)

>
> Is there support for a single OpenStack system supporting VM and Baremetal
> Instances simultaneously ?  ( in NEWTON ?  in PIKE ? )
>
> I BELIEVE the answer is yes.
>
> BUT can someone confirm ?

Yes, we've been doing it with TripleO starting with Newton, but it was supported
even earlier. Here is what we do:
http://tripleo.org/install/advanced_deployment/baremetal_overcloud.html

>
> And then, if YES,
>
> THEN in such a system
>
> ·i know there is a nova-compute for each COMPUTE NODE, and
>
> ·i know there is a nova-compute for ALL the IRONIC NODEs

Not exactly - you can have many nova-compute instances for ironic, the nodes
will be spread over them via a hash ring.

>
> ·QUESTION:
>
> oIs there still ONLY A SINGLE nova-scheduler ?
>
> oi.e. which, based on the baremetal extraspec, schedules over the COMPUTE 
> NODES
> or the IRONIC NODES ?

Yes.

What we do in TripleO is placing nova-computes for ironic on controller nodes (3
of them usually). Virtual nova-computes, of course, go to compute nodes. Then we
can add them to different host aggregates, thus separating ironic from vms - see
http://tripleo.org/install/advanced_deployment/baremetal_overcloud.html#assigning-host-aggregates

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

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

Re: [openstack-dev] [All][Elections] Vote Vote Vote in the TC election!

2017-10-23 Thread Jean-Philippe Evrard

On 20 October 2017 at 22:25, Kendall Nelson  wrote:
>
> Hello!
>
> We are coming down to the last hours for voting in the TC election. Voting
> ends 23:45 October 20th, 2017.
>
> Search your gerrit preferred email address[0] for the following subject:
> Poll: Queens TC Election
>
> That is your ballot and links you to the voting application. Please vote. If
> you have voted, please encourage your colleagues to vote.
>
> Candidate statements are linked to the names of all confirmed candidates:
> http://governance.openstack.org/election/#pike-tc-candidates
>
> What to do if you don't see the email and have a commit in at least one of
> the official programs projects[1]:
>   * check the trash of your gerrit Preferred Email address[0], in case it
> went into trash or spam
>   * wait a bit and check again, in case your email server is a bit slow
>   * find the sha of at least one commit from the program project repos[1]
> and email the election officials[2]. If we can confirm that you are entitled
> to vote, we will add you to the voters list and you will be emailed a
> ballot.
>
> Please vote!
>
> Thank you,
>
> Kendall Nelson (diablo_rojo)
>
> [0] Sign into review.openstack.org: Go to Settings > Contact
> Information. Look at the email listed as your Preferred Email.
> That is where the ballot has been sent.
> [1]:https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections
> [2] http://governance.openstack.org/election/#election-officials
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Hello,

Thanks Kendall and the elections team.
It looks the reminders have paid off :)

Best regards,
Jean-Philippe Evrard (evrardjp)

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

2017-10-23 Thread Jean-Philippe Evrard

On 21 October 2017 at 01:20, Tony Breeds  wrote:
>
> Hi All,
> With the election behind us it's somewhat traditional to look at
> some simple stats from the elections:
>
> +--+---+---+---+
> | Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta 
> %) |
> +--+---+---+---+
> |  10/2013 |   1106  (nan) |   342   (nan) | 30.92   (
> nan) |
> |  04/2014 |   1510  (  36.53) |   448   (  30.99) | 29.67   (  
> -4.05) |
> |  10/2014 |   1893  (  25.36) |   506   (  12.95) | 26.73   (  
> -9.91) |
> |  04/2015 |   2169  (  14.58) |   548   (   8.30) | 25.27   (  
> -5.48) |
> |  10/2015 |   2759  (  27.20) |   619   (  12.96) | 22.44   ( 
> -11.20) |
> |  04/2016 |   3284  (  19.03) |   652   (   5.33) | 19.85   ( 
> -11.51) |
> |  10/2016 |   3517  (   7.10) |   801   (  22.85) | 22.78   (  
> 14.71) |
> |  04/2017 |   3191  (  -9.27) |   427   ( -46.69) | 13.38   ( 
> -41.25) |
> |  10/2017 |   2430  ( -23.85) |   420   (  -1.64) | 17.28   (  
> 29.16) |
> +--+---+---+---+
>
> Election CIVS links
>  10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
>  04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
>  10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
>  04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
>  10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
>  04/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5
>  10/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>
> I don't have a feel for with the Pike electorate decreased but my gut
> feel is that it was organic drop-off possibly in part to the shorter
> Ocata development cycle.  The Queens drop-off was due to a new[1]
> membership API being available that meant we could validate Foundation
> membership instead of using gerrit permission as a proxy.
>
> I'd like to call out that with Pike we had a very dramatic decrease in
> voter turnout both in absolute and relative terms.  As a community it's
> worth trying to understand whether this is a problem and/or a trend that
> needs to change.
>
> Yours Tony.
>
> [1] It wasn't that new it was also used during the PTL election[2]
> [2] See:
> http://lists.openstack.org/pipermail/openstack-dev/2017-July/119786.html 
> ; and
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120544.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Very interesting analysis.
I agree, we should care about not repeating this Pike trend. It looks
like Queens is better in terms of turnout (see the amazing positive
delta!). However, I can't help but noticing that the trend for
turnouts is slowly reducing (excluding some outliers) since the
beginning of these stats.

Any idea on how to improve that?

On top of that, thanks to all the candidates, and congratulations!

Best regards,
Jean-Philippe Evrard (evrardjp)

__
OpenStack Development Mailing 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] [ptls] MOAR UPDATES: Sydney Project Onboarding

Re: [openstack-dev] Gertty dashboards

[openstack-dev] [ceilometer] the workload partition will cause consumer disappeared

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

[openstack-dev] [tripleo] control_virtual_ip and corosync

Re: [openstack-dev] Gertty dashboards

Re: [openstack-dev] Gertty dashboards

Re: [openstack-dev] Gertty dashboards

[openstack-dev] [ironic] this week's priorities and subteam reports

[openstack-dev] [os-upstream-institute] Meeting reminder

Re: [openstack-dev] [tripleo] Looking for help in properly configuring a TripleO environment

Re: [openstack-dev] Gertty dashboards

Re: [openstack-dev] Gertty dashboards

Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Re: [openstack-dev] [ironic] ironic and traits

[openstack-dev] [ironic] [nova] traits discussion call

[openstack-dev] [manila] Need Updated Driver Maintainers in DriverLog

Re: [openstack-dev] [openstack-neutron] [neutron dvr tempest test problem]

Re: [openstack-dev] [ironic] ironic and traits

Re: [openstack-dev] [ironic] ironic and traits

Re: [openstack-dev] Gertty dashboards

Re: [openstack-dev] [ironic] ironic and traits

[openstack-dev] [QA} No QA team meeting on 26/10

Re: [openstack-dev] [qa] Proposing changes to 17UTC team meeting

Re: [openstack-dev] [TripleO] Migrating TripleO jobs to native Zuul v3

Re: [openstack-dev] [ironic] ironic and traits

Re: [openstack-dev] [ironic] ironic and traits

Re: [openstack-dev] [ironic] ironic and traits

[openstack-dev] [TripleO][infra][CI] Moving OVB jobs from RH1 cloud to RDO cloud, plan

[openstack-dev] [tripleo] undercloud containers with SELinux Enforcing

Re: [openstack-dev] [networking-ovn] Error while running unit tests(master branch)

Re: [openstack-dev] [ironic] ironic and traits

Re: [openstack-dev] [ironic] Support for single OpenStack system supporting VM and Baremetal Instances simultaneously ?

Re: [openstack-dev] [All][Elections] Vote Vote Vote in the TC election!

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

36 matches

Site Navigation

Mail list logo

Footer information