[openstack-dev] [mogan] Adds ability to create bare metal servers without an OS

[Zhenguo Niu]

Hi folks!

We plan to add a new no-OS option [1] for users who wants to run a
proprietary, externally licensed, or customized operating system on a bare
metal server.

A bare metal server with no operating system can be set up to boot and load
the OS from a PXE setup. For this to work properly, the PXE setup needs to
be in the same tenant network with the bare metal server, that is to say,
users need to create a VM or bare metal instance with existing OS for PXE
setup and maybe also some unique installation tools/scripts.

This new option streamlines the deployment process and eliminates
installation of the unnecessary operating system. A spec for this will be
proposed soon, if you are interested, please help to give some suggestions
there then, thanks!


[1] https://blueprints.launchpad.net/mogan/+spec/no-os-server

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

Re: [openstack-dev] [nova][neutron] How do you use the instance IP filter?

[Matt Riedemann]

On 10/26/2017 10:56 PM, Joshua Harlow wrote:
Just the paranoid person in me, but is it safe to say that the filter 
that you are showing here does not come from user text?


Ie these two lines don't come from a user input directly (without going 
through some filter) do they?


https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2458-L2459 



 From reading it seems like perhaps they do come at least partially from 
a user, so I am hoping that its not possible for a user to present a 
'ip' that is really a complicated regex that takes a long time to 
compile (and therefore can DOS the nova-api component); but I don't know 
the surrounding code so I might be wrong...


Just wondering :-/

-Josh


We have schema validation on the ip filter but it's just checking that 
it can actually compile it:


https://github.com/openstack/nova/blob/16.0.0/nova/api/validation/validators.py#L35

So yeah, probably a potential problem like you pointed out.

--

Thanks,

Matt

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

[openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

[James E. Blair]

Hi,

I'd like to draw your attention to some things that we're changing in
Zuul v3 that affect stable branches.

We found a couple of interrelated issues where Zuul's behavior did not
match our expectations, and we also had some incorrect advice in the
migration doc.

We're rolling out a new version of Zuul that corrects the issues, and
the migration doc has been updated.  The main things to know are:

* If your project has stable branches, we recommend backporting the Zuul
  config along with all the playbooks and roles that are in your repo to
  the stable branches.

That's because:

* Generally speaking, jobs defined in a branch of your project should
  only apply to changes to that branch.  So the copy of a job defined in
  'master' should be used for changes to 'master'.  And the copy defined
  in 'stable/pike' should be used for changes to 'stable/pike'.

* Backporting this now is a bit of extra work that needs to happen as
  part of this initial transition.  But going forward, the workflow will
  be *much* simpler.  The next stable branch will begin its life with
  all the content from master already in place, and the two branches can
  simply naturally diverge as you would expect.

The Zuul v3 migration docs have been updated to reflect this:

  https://docs.openstack.org/infra/manual/zuulv3.html#stable-branches

If something about the new arrangement isn't working out for you, there
are other options.  Let us know and we can work through them.

-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] [keystone] office hours report 2017-10-24

[Lance Bragstad]

Hey all,

Here is the recap of what we worked on during office hours [0] this week:

Bug #1726736 in OpenStack Identity (keystone): ""no auth token" debug
logs are confusing"
https://bugs.launchpad.net/keystone/+bug/1726736
discussed, proposed fix, reviewed, and merged

Outside of that, we spent the rest of the time reviewing specifications
for the Queens release.

Thanks!

[0]
http://eavesdrop.openstack.org/meetings/keystone_office_hours/2017/keystone_office_hours.2017-10-24-19.01.log.html




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

[openstack-dev] [tripleo] rh1 outage today

[Ben Nemec]

Hi all,

As you may or may not have noticed all ovb jobs on rh1 started failing 
sometime last night.  After some investigation today I found a few issues.


First, our nova db archiving wasn't working.  This was due to the 
auto-increment counter issue described by melwitt in 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122903.html 
 Deleting the problematic rows from the shadow table got us past that.


On another db-related note, we seem to have turned ceilometer back on at 
some point in rh1.  I think that was intentional to avoid notification 
queues backing up, but it led to a different problem.  We had 
approximately 400 GB of mongodb data from ceilometer that we don't 
actually care about.  I cleaned that up and set a TTL in ceilometer so 
hopefully this won't happen again.


Unfortunately neither of these things completely resolved the extreme 
slowness in the cloud that was causing every testenv to fail.  After 
trying a number of things that made no difference, the culprit seems to 
have been rabbitmq.  There was nothing obviously wrong with it according 
to the web interface, the queues were all short and messages seemed to 
be getting delivered.  However, when I ran rabbitmqctl status at the CLI 
it reported that the node was down.  Since something was clearly wrong I 
went ahead and restarted it.  After that everything seems to be back to 
normal.


I'm not sure exactly what the cause of all this was.  We did get kind of 
inundated with jobs yesterday after a zuul restart which I think is what 
probably pushed us over the edge, but that has happened before without 
bringing the cloud down.  It was probably a combination of some 
previously unnoticed issues stacking up over time and the large number 
of testenvs requested all at once.


In any case, testenvs are creating successfully again and the jobs in 
the queue look good so far.  If you notice any problems please let me 
know though.  I'm hoping this will help with the job timeouts, but that 
remains to be seen.


-Ben

__
OpenStack Development Mailing 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] [Magnum] Docker Swarm Mode Support

[Vahric MUHTARYAN]

Hello All , 

 

I found some blueprint about supporting Docker Swarm Mode 
https://blueprints.launchpad.net/magnum/+spec/swarm-mode-support 

 

I understood that related development is not over yet and no any Openstack 
version or Magnum version to test it also looks like some more thing to do.

 

Could you pls inform when we should expect support of Docker Swarm Mode ?

 

Another question is fedora atomic is good but looks like its not up2date for 
docker , instead of use Fedora Atomic , why you do not use Ubuntu, or some 
other OS and directly install docker with requested version ? 

 

And last, to help to over waiting items “Next working items: ”  how we could 
help ? 

 

Regards

Vahric Muhtaryan

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

Re: [openstack-dev] [nova][neutron] How do you use the instance IP filter?

[Jeremy Stanley]

On 2017-10-27 14:26:06 -0400 (-0400), Mohammed Naser wrote:
[...]
> in our experience, malicious VMs are not short lived but they are
> long lived.  We'll generally find them running before we received
> the report which means that the abuse report came for that user
> indeed.
[...]

I guess the Infra use case where we cycle through thousands of
instances an hour just winds up being a magnet for misdirected
complaints in those less-frequent incidents where the abused
instance was already deleted, as we have a higher chance of being
the most recent tenant reassigned the offending IP address.
-- 
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] [nova][neutron] How do you use the instance IP filter?

[Mohammed Naser]

On Fri, Oct 27, 2017 at 12:48 PM, Jeremy Stanley  wrote:

> On 2017-10-26 22:26:59 -0400 (-0400), Mohammed Naser wrote:
> [...]
> > The use-case for us is that it helps us easily identify or find VMs which
> > we get any abuse reports for (or anything we see malicious traffic going
> > to/from).  We usually search for an *exact* match of the IP address as we
> > are simply trying to perform a lookup of instance ID based on the IP
> > address.  Regex matching isn't important in our case.
> [...]
>
> Does it allow you to identify which instance had that IP address
> over a specific timeframe? One problem we encounter is that we get
> abuse reports forwarded from our service providers telling us that
> our instance with some particular IP address was performing port
> scans or participating in a denial of service attack, and invariably
> when we check our logs we did not have an instance with that IP
> address at the timeframe indicated by the original abuse reporter
> (we had an instance with that IP address at some point for an hour
> or two maybe, but not until days later when the abuse team went
> checking to see who was responsible, and yet they tend to just
> assume everyone has long-lived instances and that IP addresses don't
> bounce around from tenant to tenant with great frequency).
>

Unfortunately, it does not, which means if the VM is gone, it is much
harder at finding the exact source of the abuse at the time.  However,
generally, in our experience, malicious VMs are not short lived but they
are long lived.  We'll generally find them running before we received the
report which means that the abuse report came for that user indeed.

The other nice thing which I noticed is that Neutron generally doesn't
re-use IPs until it cycles the entire subnet/CIDR, so if you have a large
number of IPs and you don't have a big churn in VMs, it's unlikely that a
VM will get the same IP in a short period of time.


> It seems like OpenStack could generally benefit from a mechanism for
> correlating abuse complaints to specific instances/tenants in a way
> that allows performing time-based lookups as well. Compute instances
> are ephemeral, so treating abuse complaints the same as you would in
> a dedicated hosting environment doesn't really work so well.
> --
> 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
>
>
__
OpenStack Development Mailing 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] [security] Security SIG

[Luke Hinds]

On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley  wrote:

> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > I think the Security project team would benefit from becoming a
> > proper SIG.
> [...]
>
> I tend to agree, though it's worth also considering what the
> implications are for vulnerability management under the new model.
> The VMT tended to act as an independent task force in the
> beforetime, until the big t^W^Wproject reform of 2014, and then
> allied itself with the newly-formed Security Team while continuing
> operation autonomously under a fairly independent mandate. Does this
> still make sense in a Security SIG context, or should we be
> considering alternative (perhaps more formal?) governance for the
> VMT in that scenario? I don't have especially cogent thoughts around
> this yet, so interested to hear what others in the community think.
> --
> 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
>
>

We discussed the SIG proposal on the security meeting and I planned to
invite you in for a session to discuss Thierry (apologies for being late
for getting this together).

Overall folks thought it an idea worth while enough to explore further.

My own view is that if its leads to getting more eyes on security, then its
a good thing. With that in mind, I had the idea that we could run a
"Security SIG" in parallel to the security project and see if it gains
traction and security minded people from the wider community do actually
come forward to get involved and merit the change worth while (and it's not
just the Security Project rearranging the furniture). We could then review
how its gone at the end of the Queens cycle and if a success (not sure how
we would define that as yet), then implement the change at the juncture of
a new release.
Luke
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [docs] Docs meeting time? (was: Documentation meeting Thursday)

[Petr Kovar]

Thanks for voting, everybody. There is a strong preference to move the
meeting time to 16:00 UTC Mon or Wed, which seems to work for everybody
who voted.

http://whenisgood.net/qtqbz52/results/ptgfrap

Let's have our next week's docs meeting on Wednesday, 1st November, 16:00
UTC and see how that goes. If you have any objections, please let me know.

Cheers,
pk


On Fri, 20 Oct 2017 18:33:46 +0200
Petr Kovar  wrote:

> Chason, 
> 
> Thanks for bringing this up. I definitely don't want contributors from Asia
> to feel excluded. We discussed it in the docs meeting yesterday and it's
> clear that finding a meeting time that would work for Asia, Europe and
> America is a bit difficult, to say the least. 
> 
> Anyhow, I went ahead and I set up a poll to better understand what are
> people's preferences wrt meeting time:
> 
> http://whenisgood.net/qtqbz52
> 
> All, if you could indicate your time preference, that would be appreciated.
> 
> Results will appear here:
> 
> http://whenisgood.net/qtqbz52/results/ptgfrap
> 
> Thanks,
> pk
> 
> 
> On Thu, 19 Oct 2017 20:47:12 +0800
> Chason  wrote:
> 
> > Hi Petr,
> > 
> > Is there any chance the meeting could be moved earlier one so Asian can 
> > make it?
> > Thursday at 16:00 UTC is Friday at 1:00 here.
> > 
> > Thanks,
> > 
> > Chason
> > 
> > > 在 2017年10月19日，下午8:00，openstack-docs-requ...@lists.openstack.org 写道：
> > > 
> > > Send OpenStack-docs mailing list submissions to
> > >   openstack-d...@lists.openstack.org
> > > 
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> > > or, via email, send a message with subject or body 'help' to
> > >   openstack-docs-requ...@lists.openstack.org
> > > 
> > > You can reach the person managing the list at
> > >   openstack-docs-ow...@lists.openstack.org
> > > 
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of OpenStack-docs digest..."
> > > 
> > > 
> > > Today's Topics:
> > > 
> > >   1. [docs] Documentation meeting Thursday (Petr Kovar)
> > > 
> > > 
> > > --
> > > 
> > > Message: 1
> > > Date: Wed, 18 Oct 2017 15:07:39 +0200
> > > From: Petr Kovar 
> > > To: openstack-d...@lists.openstack.org
> > > Cc: openstack-dev@lists.openstack.org
> > > Subject: [OpenStack-docs] [docs] Documentation meeting Thursday
> > > Message-ID: <20171018150739.28a243fd1691f243c3002...@redhat.com>
> > > Content-Type: text/plain; charset=US-ASCII
> > > 
> > > Hi all,
> > > 
> > > The docs meeting will continue tomorrow, Thursday at 16:00 UTC in
> > > #openstack-meeting, as scheduled. For more details, and the agenda, see 
> > > the meeting page:
> > > 
> > > https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
> > > 
> > > Cheers,
> > > pk
> > > 
> > > 
> > > 
> > > --
> > > 
> > > Subject: Digest Footer
> > > 
> > > ___
> > > OpenStack-docs mailing list
> > > openstack-d...@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> > > 
> > > 
> > > --
> > > 
> > > End of OpenStack-docs Digest, Vol 64, Issue 9
> > > *
> > 
> > 
> > 
> > 
> > ___
> > OpenStack-docs mailing list
> > openstack-d...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


-- 
Petr Kovar
Sr. Technical Writer | Customer Content Services
Red Hat Czech, Brno

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

Re: [openstack-dev] [docs] Evidence of Success

[Petr Kovar]

On Tue, 17 Oct 2017 17:27:10 +0200
Petr Kovar  wrote:

> Thanks for your feedback, everybody. I made some more edits to the
> document and tried to address the remaining comments left in the etherpad.
> 
> I think the current revision of the doc provides enough details on
> the metrics and goals, so it should be ready to be added to
> https://docs.openstack.org/doc-contrib-guide/ as an official project doc.
> Let us know if you have more comments. 

Just a quick update that a final review of the vision document can be found
here:

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

Would be good to get move votes from the docs team and the community,
so please have a look.

Thanks,
pk

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

[openstack-dev] [security] Security SIG

[Thierry Carrez]

Hi everyone,

Once upon a time we only had one governance construct to recognize
activity in OpenStack, and that was the upstream project teams. As a
result, we created teams for everything.

However with the introduction of SIGs, we have a new construct for
activities that are not mainly about producing OpenStack software bits
(for which we should continue to use project teams) or directly related
to a specific governance body (for which we should continue to use
"working groups").

SIGs are especially good when the activity is centered around a topic or
practice that spans all our community (developers, operators, end
users...), forming a guild of people with a shared interest.

Security IMHO is a great example of such a topic. The Security team's
raison-d'être is the production of software, but more generally the
improvement of the state of security in all aspects of OpenStack. It can
gather all security-conscious people in all our community.

So I think the Security project team would benefit from becoming a
proper SIG.

You might say, but it also produces software (anchor, bandit,
syntribos...). You would be right, but (1) SIGs can totally have
software by-products and own git repositories, and (2) that software is
more about security in general than a piece of OpenStack itself.

You might wonder, will that result in losing ATC status (TC voting
rights) ? Well no, the plan being to consider SIGs in the same way as
project teams as far as voting rights are concerned.

What do you think ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [nova] [placement] resource providers update 40

[Chris Dent]

Update 40 will be the last one before a short gap unless someone else
wants to fill the gap. Next week I'll be travelling to Sydney. The
week after that I'll be taking a break in Sydney after the summit. The
week after that I'll be lost in a fog of jetlag and travel fatigue.
So, the next one of these I write will be a (US) Thanksgiving edition.

# Most Important

Reviewing and responding to review suggestions on the patches
identified in the "Main Themes" section.

If you're going to summit there's a forum session on placement:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20491/placement-update-and-direction

# What's Changed

The Selection object changed form again, slightly, to use the
SchedulerLimits object. Reviewers are happy with the patch that adds the
object but have pinned it with a -2 in case patches above it reveal
bad mojo. This is probably wise as the shape of the object has changed
several times over the course of its existence. See below for links.

# Main Themes

The main bits for resource providers is getting very close at

https://review.openstack.org/#/q/topic:bp/nested-resource-providers

Trait support is very relevant for nested providers, that work is at


https://review.openstack.org/#/q/bp/add-trait-support-in-allocation-candidates

And there's emerging work for expressing the relationship between a
particular provider and its traits:

https://review.openstack.org/#/q/topic:bp/granular-resource-requests

## Migration allocations

The migration allocations work is a hair's breadth away from fully
merged:

 https://review.openstack.org/#/q/topic:bp/migration-allocations

Management of those allocations currently involves some raciness,
birthing the idea to allow POST /allocations, which causes a cascade
of required changes to bring that about. The code stack for that
starts at:

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

## Alternate Hosts

We want to be able to do retries within cells, so we need some
alternate hosts when returning a destination that are structured
nicely for RPC (this is the Selection object stuff mentioned above):

 https://review.openstack.org/#/q/topic:bp/return-alternate-hosts

# Other

* https://review.openstack.org/#/c/508555/
   Re-use existing ComputeNode on ironic rebalance

* https://review.openstack.org/#/c/512553/
   Reproduce bug 1724172 in the functional test env
   (this is an allocations related bug)

* https://review.openstack.org/#/c/493865/
   cover migration cases with functional tests

* https://review.openstack.org/#/c/513041/
   Extract instance allocation removal code

* https://review.openstack.org/#/c/495159/
   Test resource allocation during soft delete

* https://review.openstack.org/#/c/499539/
   Moving more utils to ServerResourceAllocationTestBase

* https://review.openstack.org/#/c/503037/
   factor out compute service start in ServerMovingTest

* https://review.openstack.org/#/c/505202/
   Change live_migrate tests to use fakedriver

* https://review.openstack.org/#/c/497399/
   Extend ServerMovingTests with custom resources

* https://review.openstack.org/#/c/506175/
  get_inventory in vmware driver

* https://review.openstack.org/#/c/339204/
  get_inventory in xenapi driver

* https://review.openstack.org/#/q/topic:bug/1702420
Fixes for shared providers map being incorrect

* https://review.openstack.org/#/c/499826/
Include /resource_providers/uuid/allocations link

* https://review.openstack.org/#/c/492247/
Use ksa adapter for placement conf & requests

* https://review.openstack.org/#/q/topic:bp/placement-osc-plugin
Placement plugin for osc

* https://review.openstack.org/#/c/492571/
Make compute log less verbose with allocs autocorrection

* https://review.openstack.org/#/c/499539/
Stack of functional test fixups

* https://review.openstack.org/#/c/495380/
[placement] manage cache headers for /resource_providers
(This needs some rebasing to get the microversion handling right)

* https://review.openstack.org/#/q/topic:bp/allocation-candidates-limit
   Enable limiting GET /allocation_candidates

* https://review.openstack.org/#/c/513057/
   [placement] Clean up TODOs in allocations.yaml gabbit

* https://review.openstack.org/#/q/topic:bug/1578989
   move placement client in neutron to neutron-lib and add
   functionality

* https://review.openstack.org/#/c/494206/
   Remove the Pike migration code for [Ironic] flavor migration

* https://review.openstack.org/#/c/511342/
   placement: add API reference for create inventory

* https://review.openstack.org/#/q/topic:bp/add-support-for-vgpu
  Add support for VGPU

* https://review.openstack.org/#/q/topic:bp/placement-test-enhancement
  Some functional test improvements for placement

* https://review.openstack.org/#/c/512497/
  refactor placement version check

* https://review.openstack.org/#/q/topic:bp/placement-doc-enhancement-queens
  placement api ref cleanups

* 

Re: [openstack-dev] [keystoneauth] [osc] [ironic] Usage of none loader in the CLI

[Vladyslav Drok]

On Wed, Oct 25, 2017 at 3:07 PM, Dmitry Tantsur  wrote:

> Hi!
>
> Thanks for raising this.
>
> On 10/19/2017 01:11 PM, Vladyslav Drok wrote:
>
>> Hi!
>>
>> I'd like to discuss the usage of the new noauth plugin to keystoneauth,
>> which was introduced in [1]. The docstring of the loader says it is
>> intended to be used during adapter initialization along with
>> endpoint_override. But what about the CLI usage in the OpenStack client? I
>> was trying to make the none loader work with baremetal plugin, as part of
>> testing [2], and encountered some problems, which are hacked around in [3].
>>
>> So, here are some questions:
>>
>> 1. Was it intended to be used in CLI at all, or should we still use the
>> token_endpoint?
>> 2. If it was intended, should we:
>>  2.1. do the hacks as in [3]?
>>
>
> I don't particularly like hardcoding an entrypoint name in the code here,
> to be honest.
>
>  2.2. introduce endpoint as an option for the none loader, making it a
>> bit similar to token_endpoint, with token hardcoded (and also get_endpoint
>> method to the auth plugin I think)?
>>
>
> I think that's the way to go, we should fix the none loader in
> keystoneauth.
>

I'll go with this option, Dean also suggested this in his review of [3]


>
>  2.3. leave it as-is, allowing the usage of none loader only by
>> specifying the parameters in the clouds.yaml, as in [4] for example?
>>
>
> That's not great. We're getting rid of the "ironic" command in favour of
> "openstack baremetal", but inability to properly use a no-auth mode hurts
> quite a few of our use cases (like Bifrost).
>
>
>> [1] https://review.openstack.org/469863 > 469863>
>> [2] https://review.openstack.org/359061
>> [3] https://review.openstack.org/512699
>> [4] https://github.com/openstack/bifrost/blob/21ca45937a9cb36c6f
>> 04073182bf2edea8acbd5d/playbooks/roles/bifrost-keystone-client-config/
>> templates/clouds.yaml.j2#L17-L19
>>
>> Thanks,
>> Vlad
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

[Vladyslav Drok]

On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes  wrote:

> On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
>
>> Hi,
>>
>> On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:
>>
>>> Hello ironic'ers,
>>>
>>> A while ago, we approved a spec to add node tag support to ironic [1].
>>> The
>>> feature itself did not land yet (although some of the code has). Now that
>>> the (nova) community has come up with traits, ironic wants to support
>>> node
>>> traits, and there is a spec proposing that [2]. At the ironic node level,
>>> this is VERY similar to the node tag support, so the thought is to drop
>>> (not
>>> implement) the node tagging feature, since the node traits feature could
>>> be
>>> used instead. There are a few differences between the tags and traits.
>>> "Traits" means something in OpenStack, and there are some restrictions
>>> about
>>> it:
>>>
>>> - max 50 per node
>>>
>>> - names must be one of those in os-traits library OR prefixed with
>>> 'CUSTOM_'
>>>
>>> For folks that wanted the node tagging feature, will this new node traits
>>> feature work for your use case? Should we support both tags and traits? I
>>> was wondering about e.g. using ironic standalone.
>>>
>>> Please feel free to comment in [2].
>>>
>>> Thanks in advance,
>>>
>>> --ruby
>>>
>>> [1]
>>> http://specs.openstack.org/openstack/ironic-specs/specs/appr
>>> oved/nodes-tagging.html
>>>
>>> [2] https://review.openstack.org/#/c/504531/
>>>
>>>
>> Are tags/traits serving a different purpose? One serves the purpose of
>> helping the scheduling/placement while the other is more or less aims
>> at grouping for the "end users"?
>> I understand that the code will be *very* similar but who/what will be
>> the consumers/users?
>> I fell they won't be the same and could artificially limit its use due
>> to technical/design "limitations". (must be in os-traits or be
>> prefixed by CUSTOM)
>>
>> For example which I personally foresee:
>> * I might want to populate Ironic inventory from an external system
>> which would also injects the appropriate traits.
>> * I might also want some technical people to use/query Ironic and
>> allow them to tag nodes based on their own needs while not messing
>> with the traits part (as it's managed by an external system and will
>> influence the scheduling later)
>>
>> Lets not assume traits/tags have the same purpose and same user.
>>
>
> I agree with Matthieu 100% here.
>
> Traits are structured, formalized, and set by the system or the operator
> against resource providers.
>
> Tags are for end-users to, well, tag their instances with whatever strings
> they want.
>
> Best,
> -jay


I'd also vote for having them separate. We can refactor the common bits of
code instead.

-Vlad


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

[openstack-dev] [tc] Technical Committee Status update, October 27th

[Thierry Carrez]

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker

If you are working on something (or plan to work on something) that is
not on the tracker, feel free to add to it !


== Welcome new membership ! ==

The election concluded and we now have the 13 members of the Technical
Committee for the coming 6 months. You can find the list here:

https://governance.openstack.org/tc/


== Recently-approved changes ==

* PTI updates: documentation jobs [1] and releasenotes [2]
* Nova and Cinder assert supports-accessible-upgrade tag [3]
* Goal updates: magnum, dragonflow, horizon, ironic-inspector, congress,
tricircle
* New repos: ansible-role-k8s-cookiecutter

[1] https://review.openstack.org/#/c/508694/
[2] https://review.openstack.org/#/c/509868/
[3] https://review.openstack.org/#/c/509170/

Calm week as we on-boarded new members and focused on administrative
details. Next week is also expected to be calm as most TC members are
departing for Sydney.


== Voting in progress ==

The TC chair designation process is under way. So far only myself has
proposed to fill the chair duties, and that proposal reached majority on
Oct 24. It will be approved on Oct 31 unless the situation changes:

https://review.openstack.org/514553

Colleen spotted that our house rules were still mentioning meetings, and
proposed a catchup. We are still short of a few votes to merge it:

https://review.openstack.org/514582


== Under review ==

Late to the Queens project team additions party, but probably worth
adding, the LOCI team (packaging OCI container images for OpenStack
deliverables) is being proposed here:

https://review.openstack.org/513851

Kendall Nelson kicked off the Rocky goal proposal season with a proposal
around Storyboard Migration. Please review it at:

https://review.openstack.org/513875

Our latest top-5 "help wanted" list proposed addition, "champions
and stewards" will soon be refreshed with a new patchset. Please review
it at:

https://review.openstack.org/510656


== TC member actions for the coming week(s) ==

TC members should prepare for Sydney activities (see below).

Monty should answer the feedback on the supported database version
resolution (https://review.openstack.org/493932) so that we can make
progress there -- or abandon it.

Doug will update the "champions and stewards" top-5 help wanted addition
(https://review.openstack.org/510656), as soon as we manage to get the
release jobs situation under control.


== Sydney Summit ==

A number of meetings and sessions are directly involving the Technical
Committee during the OpenStack Summit in Sydney.

First, there will be a "leadership meeting" with the Board, UC and
Foundation staff on Sunday, Nov 5, starting at 1pm after lunch (ICC
Level 3 in Room E3.1/E3.2). This will be followed up by a dinner (please
RSVP using the link posted to openstack-tc).

Then a number of Forum sessions are directly of interest to TC members:

We'll hold an in-person TC "office hour" at the end of the event
(Wednesday, 5:20pm-6:00pm). It will be the occasion for a retrospective
of what was recently achieved and kicking off the next 6 months. Please
join if you can:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20576/technical-committee-in-person-office-hour

The TC vision mentions "constellations" but we are still a bit fuzzy
about what they are. Join Dean to brainstorm about them:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20477/constellation-brainstorming

Mogan's complementarity with Nova/ironic (or lack thereof) will be
discussed on Wednesday (11:00am-11:40am), which may inform your decision
on that project addition:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20501/bare-metal-as-a-service-ironic-vs-mogan-vs-nova

The question of a specific stable policy (and accompanying tag) for
deployment projects will be covered in this session:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20456/what-do-operators-want-from-the-stable-policy

A number of other sessions are directly linked to the TC vision or
strategic areas and might be interesting to you:

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20464/making-openstack-more-palatable-to-part-time-contributors

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20500/first-contact-sig-formation-discussion

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20461/sigs-ii-to-infinity-and-beyond

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20466/openstack-sig-k8s-and-k8s-sig-openstack-collaborations

I certainly missed others -- feel free to reply to this to flag them!


== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical 

Re: [openstack-dev] Update on Zuul v3 Migration - and what to do about issues

[Rikimaru Honjo]

Hello,

(Can I still use this thread?)

Excuse me, I'm trying to run Zuul v3 in my environment, and I have three
question about it.
I'd appreciate it if anyone helps.

My environment)
I use feature/zuulv3 branch, and version is 2.5.3.dev1374.

Q1)
"Unknown option --die-with-parent" error was occurred when zuul ran job.
Is there requirement of bubblewrap version?

I used bubblewrap 0.1.7-1~16.04~ansible.
If I removed "--die-with-parent" from zuul/driver/bubblewrap/__init__.py,
above error wouldn't occurred.

Q2)
When I specified "zuul_return" in playbook, the below error was occurred
on remote host.

KeyError: 'ZUUL_JOBDIR'

Should I write a playbook to set a environment variable "ZUUL_JOBDIR"?

Q3)
Setup module of ansible took long time when zuul ran jobs.
My job was succeeded if I extended timeout from 60 to 120 by modifying
runAnsibleSetup() in zuul/executor/server.py.

But, if I run same job directly(by own), it was finished soon.
Do you have any knowledge about it?


P.S.
Is there a constructed VM image or ansible for running zuul v3...?

Best regards,

On 2017/09/29 23:58, Monty Taylor wrote:

Hey everybody!

tl;dr - If you're having issues with your jobs, check the FAQ, this email and 
followups on this thread for mentions of them. If it's an issue with your job 
and you can spot it (bad config) just submit a patch with topic 'zuulv3'. If 
it's bigger/weirder/you don't know - we'd like to ask that you send a follow up 
email to this thread so that we can ensure we've got them all and so that 
others can see it too.

** Zuul v3 Migration Status **

If you haven't noticed the Zuul v3 migration - awesome, that means it's working 
perfectly for you.

If you have - sorry for the disruption. It turns out we have a REALLY 
complicated array of job content you've all created. Hopefully the pain of the 
moment will be offset by the ability for you to all take direct ownership of 
your awesome content... so bear with us, your patience is appreciated.

If you find yourself with some extra time on your hands while you wait on 
something, you may find it helpful to read:

   https://docs.openstack.org/infra/manual/zuulv3.html

We're adding content to it as issues arise. Unfortunately, one of the issues is 
that the infra manual publication job stopped working.

While the infra manual publication is being fixed, we're collecting FAQ content 
for it in an etherpad:

   https://etherpad.openstack.org/p/zuulv3-migration-faq

If you have a job issue, check it first to see if we've got an entry for it. 
Once manual publication is fixed, we'll update the etherpad to point to the FAQ 
section of the manual.

** Global Issues **

There are a number of outstanding issues that are being worked. As of right 
now, there are a few major/systemic ones that we're looking in to that are 
worth noting:

* Zuul Stalls

If you say to yourself "zuul doesn't seem to be doing anything, did I do something 
wrong?", we're having an issue that jeblair and Shrews are currently tracking down 
with intermittent connection issues in the backend plumbing.

When it happens it's an across the board issue, so fixing it is our number one 
priority.

* Incorrect node type

We've got reports of things running on trusty that should be running on xenial. 
The job definitions look correct, so this is also under investigation.

* Multinode jobs having POST FAILURE

There is a bug in the log collection trying to collect from all nodes while the 
old jobs were designed to only collect from the 'primary'. Patches are up to 
fix this and should be fixed soon.

* Branch Exclusions being ignored

This has been reported and its cause is currently unknown.

Thank you all again for your patience! This is a giant rollout with a bunch of 
changes in it, so we really do appreciate everyone's understanding as we work 
through it all.

Monty

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




--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru s Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



__
OpenStack Development Mailing 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][oslo_messaging] Random Connection reset by peer

[李田清]

Hello,
I test ceilometer agent notification workload partition. I found it is too 
fragile. 
The load is 1k cirrors vm. I make processing queue to 4 and workers to 1. 
I can sure the network is ok. But in the ceilometer agent notification log 
i see this
http://paste.openstack.org/show/624795/ 


   I am sure rabbitmq resource is enough. the status is here
http://paste.openstack.org/show/624796/


   And after some dig in i found this.
https://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu


Can someone join me to test it? Or is there someone know this why and how 
to fix this?
Thanks a lot a lot.__
OpenStack Development Mailing 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] [vitrage] some error in Aodh datasource

[dong.wenjuan]

Hi Idan Kinory,






I deploy Vitrage with devstack using master branch.


Currently I found a error in Aodh datasource when I change the Aodh alarm 
state(alarm_state_transition notification).






The error log is as follows:


Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:30:50.429 
9880 DEBUG vitrage.datasources.listener_service [-] EVENT ENQUEUED:
Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: {'description': u'Alarm 
when * event occurred.', 'resource_id': None, 'vitrage_entity_type': 'aodh', 
'timestamp': u'2017-10-26T06:37:41.353447', 'state_timestamp': 
u'2017-10-27T07:09:06.636137', 'name': u'dwj', 'vitrage_datasource_action': 
'update', 'severity': u'low', 'vitrage_sample_date': '2017-10-27 
07:30:50.382730+00:00', 'vitrage_event_type': u'alarm.deletion', 'enabled': 
True, 'alarm_id': u'9578d0eb-5d09-49a2-80e9-fb1a6c7ce7e9', 'state': u'alarm', 
'repeat_actions': False, 'event_type': (u'*',), 'project_id': 
u'378f268c64fc42c28226704dd71f37fe', 'type': u'event'} _enqueue_events 
/opt/stack/vitrage/vitrage/datasources/listener_service.py:106
Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.327 
10104 DEBUG vitrage.datasources.services [-] start get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:119
Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.331 
10104 DEBUG vitrage.datasources.services [-] end get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:126
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver [-] Failed to Convert alarm state 
transition event - 'dict' object has no attribute 'encode': AttributeError: 
'dict' object has no attribute 'encode'
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver Traceback (most recent call last):
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver   File 
"/opt/stack/vitrage/vitrage/datasources/aodh/driver.py", line 352, in 
_convert_alarm_state_transition_event
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver unicode_to_str = 
state.encode("ascii")
Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver AttributeError: 'dict' object has no 
attribute 'encode'



I noticed that you fix the code in this patch(Line 352-368): 
https://review.openstack.org/#/c/501701/4/vitrage/datasources/aodh/driver.py


Can you please explain why? Thanks.




BR,

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

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Steven Dake (stdake)]

Dims,

This was just a fella in the kolla community experimenting without attempting 
to cause harm.  IOW he didn’t know exactly what he was doing which is helpful 
when messing with the meeting bots (.

No harm done anyway, so no need to take any corrective action in implementation.

Cheers
-steve

On 10/11/17, 11:15 AM, "Davanum Srinivas"  wrote:

Swapnil,

Dunno if it was malicious or someone just trying to understand how things 
work.

Worth reaching out to jinke [1]

[1] 
http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=e2593c113d64868b44f27a9fba15a564855236c6

Thanks,
Dims

On Wed, Oct 11, 2017 at 12:35 PM, Swapnil Kulkarni  
wrote:
> On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski  
wrote:
>> I haven't seen "malicious" meeting starters yet, let's hope that won't
>> happen:) On the other hand, ad-hoc chair change can, and did, happen,
>> so I agree with fungi - I don't think we need to put restrictions on
>> that.
>>
>> On 11 October 2017 at 09:11, Jeremy Stanley  wrote:
>>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
>>> [...]
 The problem here is if we know who are most likely to chair the
 meeting e.g. [1] we can allow them to start the meeting.
>>> [...]
>>>
>>> I'm pretty certain I wouldn't want to have to propose a patch to
>>> update that every time I needed someone to chair a meeting in my
>>> absence. This doesn't seem like a common enough issue to warrant the
>>> added complexity and red tape of access controls on our meeting
>>> automation.
>>> --
>>> 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
>>>
>>
>> 
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Michal,
>
> I just gave one instance of malicious meeting attempt [1] happened
> today and it happened to be kolla meeting so I noticed its not correct
> timing for the same. I would put it as permission-ed access rather
> than restriction, because as much as we want to keep it open we need
> to maintain the genuineness of meeting. I would not want to stumble
> into a junk log file while I am reading it later looking for
> something.
>
>
> [1] 
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.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



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

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


__
OpenStack Development Mailing 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] [masakari]py35 unit tests are failed

[Rikimaru Honjo]

Hello,

py35 unit tests of masakari are failed by same errors on gerrit.

e.g.
* https://review.openstack.org/#/c/441796/
  
=>http://logs.openstack.org/96/441796/3/check/openstack-tox-py35/d958f3f/testr_results.html.gz

* https://review.openstack.org/#/c/509782/
  
=>http://logs.openstack.org/82/509782/23/check/openstack-tox-py35/9612809/testr_results.html.gz

It seems to have been caused by sqlalchemy, but I haven't analyzed it enough 
yet.
Please tell in this ML or submit a patch if you can solve it.

Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



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