Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Marios Andreou]

+1 !



On Wed, Aug 1, 2018 at 2:31 PM, Giulio Fidente  wrote:

> Hi,
>
> I would like to propose Lukas Bezdicka core on TripleO.
>
> Lukas did a lot work in our tripleoclient, tripleo-common and
> tripleo-heat-templates repos to make FFU possible.
>
> FFU, which is meant to permit upgrades from Newton to Queens, requires
> in depth understanding of many TripleO components (for example Heat,
> Mistral and the TripleO client) but also of specific TripleO features
> which were added during the course of the three releases (for example
> config-download and upgrade tasks). I believe his FFU work to have been
> very challenging.
>
> Given his broad understanding, more recently Lukas started helping doing
> reviews in other areas.
>
> I am so sure he'll be a great addition to our group that I am not even
> looking for comments, just votes :D
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Joshua Harlow]

If I could, I would have something *like* the EXPLAIN syntax for looking 
at a sql query, but instead of telling me the query plan for a sql 
query, it would tell me the decisions (placement plan?) that resulted in 
a given resource being placed at a certain location.


And I would be able to say request the explanation for a given request 
id (historical even) so that analysis could be done post-change and 
pre-change (say I update the algorithm for selection) so that the 
effects of alternations to said decisions could be determined.


If it could also have a front-end like what is at http://sorting.at/ 
(press the play button) that'd be super sweet also (but not for sorting, 
but instead for placement, which if u squint at that webpage could have 
something similar built).


My 3 cents, ha

-Josh

Chris Friesen wrote:

On 08/01/2018 11:32 AM, melanie witt wrote:


I think it's definitely a significant issue that troubleshooting "No
allocation
candidates returned" from placement is so difficult. However, it's not
straightforward to log detail in placement when the request for
allocation
candidates is essentially "SELECT * FROM nodes WHERE cpu usage <
needed and disk
usage < needed and memory usage < needed" and the result is returned
from the API.


I think the only way to get useful info on a failure would be to break
down the huge SQL statement into subclauses and store the results of the
intermediate queries. So then if it failed placement could log something
like:

hosts with enough CPU: 
hosts that also have enough disk: 
hosts that also have enough memory: 
hosts that also meet extra spec host aggregate keys: 
hosts that also meet image properties host aggregate keys: 
hosts that also have requested PCI devices: 

And maybe we could optimize the above by only emitting logs where the
list has a length less than X (to avoid flooding the logs with hostnames
in large clusters).

This would let you zero in on the things that finally caused the list to
be whittled down to nothing.

Chris

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



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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Alex Xu]

2018-08-02 4:09 GMT+08:00 Jay Pipes :

> On 08/01/2018 02:02 PM, Chris Friesen wrote:
>
>> On 08/01/2018 11:32 AM, melanie witt wrote:
>>
>> I think it's definitely a significant issue that troubleshooting "No
>>> allocation
>>> candidates returned" from placement is so difficult. However, it's not
>>> straightforward to log detail in placement when the request for
>>> allocation
>>> candidates is essentially "SELECT * FROM nodes WHERE cpu usage < needed
>>> and disk
>>> usage < needed and memory usage < needed" and the result is returned
>>> from the API.
>>>
>>
>> I think the only way to get useful info on a failure would be to break
>> down the huge SQL statement into subclauses and store the results of the
>> intermediate queries.
>>
>
> This is a good idea and something that can be done.
>

That sounds like you need separate sql query for each resource to get
the intermediate,
will that be terrible performance than a single query to get the final
result?


>
> Unfortunately, it's refactoring work and as a community, we tend to
> prioritize fancy features like NUMA topology and CPU pinning over
> refactoring work.
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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 lagging behind 2 major python versions: we need a Python 3.7 gate

[Thomas Goirand]

On 07/12/2018 10:38 PM, Thomas Goirand wrote:
> Hi everyone!
> 
> [...]
Here's more examples that shows why we should be gating earlier with
newer Python versions:

Nova:
https://review.openstack.org/#/c/584365/

Glance:
https://review.openstack.org/#/c/586716/

Murano:
https://bugs.debian.org/904581

Pyghmi:
https://bugs.debian.org/905213

There's also some "raise StopIteration" issues in:
- ceilometer
- cinder
- designate
- glance
- glare
- heat
- karbor
- manila
- murano
- networking-ovn
- neutron-vpnaas
- nova
- rally
- zaqar

It'd be nice to have these addressed ASAP.

Cheers,

Thomas Goirand (zigo)

__
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] [tricircle] Tricircle or Trio2o

[linghucongsong]

HI  Andrea !

Yes, just as you said.The tricircle is now only work for network.Because the 
trio2o do not

as the openstack official project. so it is a long time nobody contribute to it.
But recently In the next openstack stein circle. we have plan to make tricircle 
and

trio2o work together in the tricircle stein plan. see below link:
https://etherpad.openstack.org/p/tricircle-stein-plan

After this fininsh we can play tricircle and tri2o2 together and make multisite 
openstack

solutions more effictive.









At 2018-08-02 00:55:30, "Andrea Franceschini" 
 wrote:
>Hello All,
>
>While I was looking for multisite openstack solutions I stumbled on
>Tricircle project which seemed fairly perfect for the job except that
>l it was split in two parts, tricircle itself for the network part and
>Trio2o for all the rest.
>
>Now it seems that the Trio2o project is no longer maintained  and I'm
>wondering what other options exist for multisite openstack, stated
>that tricircle seems more NFV oriented.
>
>Actually a heat multisite solution would work too, but I cannot find
>any  reference to this kind of solutions.
>
>Do you have any idea/advice?
>
>Thanks,
>
>Andrea
>
>__
>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] [Tacker] - TACKER + NETWORKING_SFC + NSH

[龚永生]

William,
tacker is just using network-sfc API, we have tested the ovs driver of it. 




regards,


yong sheng gong




--

龚永生
九州云信息科技有限公司 99CLOUD Co. Ltd.
邮箱（Email）：gong.yongsh...@99cloud.net
地址：北京市海淀区上地三街嘉华大厦B座806
Addr : Room 806, Tower B, Jiahua Building, No. 9 Shangdi 3rd Street, Haidian 
District, Beijing, China
手机（Mobile)：+86-18618199879
公司网址（WebSite）：http://99cloud.net 

At 2018-08-01 02:17:14, "william sales"  wrote:

Hello guys,



is there any version of Tacker that allows the use of networking_sfc with NSH?


Thankful.


William Sales__
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] [i18n] Edge and Containers whitepapers ready for translation

[Ian Y. Choi]

Hello Sebastian,

Korean has also currently 100% translation now.
About two weeks ago, there were a discussion how to include the list of 
translators per translated document.


My proposal is mentioned in [1] - do you think it is a good idea and it 
is under implementation,
or parsing the name of translators in header lines on po files (e.g., 
four lines on [2]) would be better idea?



With many thanks,

/Ian

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-i18n/%23openstack-i18n.2018-07-19.log.html#t2018-07-19T15:09:46
[2] 
http://git.openstack.org/cgit/openstack/i18n/tree/doc/source/locale/de/LC_MESSAGES/doc.po#n1


Frank Kloeker wrote on 7/31/2018 6:39 PM:

Hi Sebastian,

okay, it's translated now. In Edge whitepaper is the problem with 
XML-Parsing of the term AT&T. Don't know how to escape this. Maybe you 
will see the warning during import too.


kind regards

Frank

Am 2018-07-30 20:09, schrieb Sebastian Marcet:

Hi Frank,
i was double checking pot file and realized that original pot missed
some parts of the original paper (subsections of the paper) apologizes
on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  wrote:


Hi Jimmy,

from the GUI I'll get this link:

https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center 


[1]

paper version  are only in container whitepaper:


https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack 


[2]

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:
Frank,

We're getting a 404 when looking for the pot file on the Zanata API:

https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing 


[3]

As a result, we can't pull the po files.  Any idea what might be
happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

Korean and German version are now done on the new format. Can you
check publishing?

thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:
Hi all -

Follow up on the Edge paper specifically:

https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 


[4] This is now available. As I mentioned on IRC this morning, it
should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:
Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I indicated that we
would also be moving the Edge paper to HTML so that we could prevent
that additional design resource cost.
On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF,
which we unfortunately didn't have the resources to implement in the
same format.

I really appreciate Akihiro's work on RST-based support on
publishing translated edge computing whitepapers, since
translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on
the RST-based translation.  At the moment, it's just not usable for
the reasons mentioned above.
On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML
based translation is more difficult.

That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the
followings since *I18n-based tools*
would mean for translators that translators can test and publish
translated whitepapers locally:

- How to build translated container whitepaper using original
Silverstripe-based repository?
https://docs.openstack.org/i18n/latest/tools.html [5] describes
well how to build translated artifacts for RST-based OpenStack
repositories
but I could not find the way how to build translated container
whitepaper with translated resources on Zanata.
This is a little tric

Re: [openstack-dev] [all][election][tc] Lederless projects.

[赵超]

The trove team had our weekly meeting last night, all attended core members
and the new contributors from Samsung R&D Center in Krakow, Poland were
agreed on that we only have Dariusz Krol as an PTL candidate and hope he
could be accepted as a valid candidate [1].

Tony has pointed to me that the process for appointing PTL for leaderlesss
projects, thanks.

I talked about the situation about the current Trove team before([2] and
privately responded which resulted to a report as [3] to the TC project
healthy checking mail). I thought about continuing my role as the Trove
PTL, but it turns out it's better to have someone who could take more time
on the project, and happend that we just have a whole team joining us. I
think all of the current active team members will continue working on the
project, but it's sad none of us has much bandwith on the project now, so
we think it could be a good chance for the project to progress(though maybe
quite slowly ) to a whole team focusing on Trove.

There're always worries about the healthty about Trove and talks about
rearchitecturing, the project team has also been discussed these topics
many times internally, however it seems impossible for the time and
forseable future, until we have a bigger core team and more participation.
We all think there will be more opportunites to change this situation with
the join of a whole team(though it's may be small now) focusing on Trove.

Would love to hear more suggestions and participtions from whom are
interested in Trove.

Thanks.

[1]
http://eavesdrop.openstack.org/meetings/trove/2018/trove.2018-08-01-14.00.log.html#l-71

[2] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132475.html

[3] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Trove

On Wed, Aug 1, 2018 at 8:32 AM, Tony Breeds  wrote:

> On Wed, Aug 01, 2018 at 09:55:13AM +1000, Tony Breeds wrote:
> >
> > Hello all,
> > The PTL Nomination period is now over. The official candidate list
> > is available on the election website[0].
> >
> > There are 8 projects without candidates, so according to this
> > resolution[1], the TC will have to decide how the following
> > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,
> > RefStack, Searchlight, Trove and Winstackers.
>
> Hello TC,
> A few extra details[1]:
>
> ---
> Projects[1]   :65
> Projects with candidates  :57 ( 87.69%)
> Projects with election: 2 (  3.08%)
> ---
> Need election : 2 (Senlin Tacker)
> Need appointment  : 8 (Dragonflow Freezer Loci Packaging_Rpm
> RefStack
>Searchlight Trove Winstackers)
> ===
> Stats gathered@ 2018-08-01 00:11:59 UTC
>
> Of the 8 projects that can be considered leaderless, Trove did have a
> candidate[2] that doesn't meet the ATC criteria in that they do not
> have a merged change.
>
> I also excluded Security due to the governance review[3] to remove it as
> a project and the companion email discussion[4]
>
> Yours Tony.
>
> [1] http://paste.openstack.org/show/727002
> [2] https://review.openstack.org/587333
> [3] https://review.openstack.org/586896
> [4] http://lists.openstack.org/pipermail/openstack-dev/2018-
> July/132595.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
>
>


-- 
To be free as in freedom.
__
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] Candidacy to continue my work as the Senlin PTL for theStein cycle

[liu.xuefeng1]

Hi all,





This is my candidacy to continue my work as the Senlin PTL for the

Stein cycle.




In Rocky cycle, we finished many features, testing and bug fixing works.

For example:

 * Kubernetes: Added dependency relationship between the master cluster and the

   worker cluster created for Kubernetes.

 * Docker driver: Supported update name operation for docker profile.

 * Nova server: Added operation support to migrate a nova server node.

 * Health check improve: Added a new detection type that actively pools the node

   health using a URL specified in the health policy.

 * Dashboard:adds "Resize" action for cluster panel.

 * Testing: API/Function/Integration test were moved to senlin-tempest-plugin.




At the same time, in Rocky cycle I found and added two devlopers to the Senlin 
team, both of

them given a great work for the team.




As a PTL in Stein cycle, I'd like to continue to focus on the tasks as follows:

 * Grow the Senlin team of contributors and core reviewers.

 * Continue to improve k8s on Senlin feature implementation.

 * Collaborate with other OpenStack projects with joint blueprints.

 * Actively monitor incoming bug reports and assigned to fix them.

 * Acknowledgment of OpenStack-wide Goals.




Thanks for taking the time to read through this roadmap and to consider my

candidacy.




Best Regards,

XueFeng Liu

(Irc:XueFeng)__
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] easily identifying how services are configured

[Alex Schultz]

On Mon, Jul 9, 2018 at 6:28 AM, Bogdan Dobrelya  wrote:
> On 7/6/18 7:02 PM, Ben Nemec wrote:
>>
>>
>>
>> On 07/05/2018 01:23 PM, Dan Prince wrote:
>>>
>>> On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:


 I would almost rather see us organize the directories by service
 name/project instead of implementation.

 Instead of:

 puppet/services/nova-api.yaml
 puppet/services/nova-conductor.yaml
 docker/services/nova-api.yaml
 docker/services/nova-conductor.yaml

 We'd have:

 services/nova/nova-api-puppet.yaml
 services/nova/nova-conductor-puppet.yaml
 services/nova/nova-api-docker.yaml
 services/nova/nova-conductor-docker.yaml

 (or perhaps even another level of directories to indicate
 puppet/docker/ansible?)
>>>
>>>
>>> I'd be open to this but doing changes on this scale is a much larger
>>> developer and user impact than what I was thinking we would be willing
>>> to entertain for the issue that caused me to bring this up (i.e. how to
>>> identify services which get configured by Ansible).
>>>
>>> Its also worth noting that many projects keep these sorts of things in
>>> different repos too. Like Kolla fully separates kolla-ansible and
>>> kolla-kubernetes as they are quite divergent. We have been able to
>>> preserve some of our common service architectures but as things move
>>> towards kubernetes we may which to change things structurally a bit
>>> too.
>>
>>
>> True, but the current directory layout was from back when we intended to
>> support multiple deployment tools in parallel (originally
>> tripleo-image-elements and puppet).  Since I think it has become clear that
>> it's impractical to maintain two different technologies to do essentially
>> the same thing I'm not sure there's a need for it now.  It's also worth
>> noting that kolla-kubernetes basically died because there wasn't enough
>> people to maintain both deployment methods, so we're not the only ones who
>> have found that to be true.  If/when we move to kubernetes I would
>> anticipate it going like the initial containers work did - development for a
>> couple of cycles, then a switch to the new thing and deprecation of the old
>> thing, then removal of support for the old thing.
>>
>> That being said, because of the fact that the service yamls are
>> essentially an API for TripleO because they're referenced in user
>
>
> this ^^
>
>> resource registries, I'm not sure it's worth the churn to move everything
>> either.  I think that's going to be an issue either way though, it's just a
>> question of the scope.  _Something_ is going to move around no matter how we
>> reorganize so it's a problem that needs to be addressed anyway.
>
>
> [tl;dr] I can foresee reorganizing that API becomes a nightmare for
> maintainers doing backports for queens (and the LTS downstream release based
> on it). Now imagine kubernetes support comes within those next a few years,
> before we can let the old API just go...
>
> I have an example [0] to share all that pain brought by a simple move of
> 'API defaults' from environments/services-docker to environments/services
> plus environments/services-baremetal. Each time a file changes contents by
> its old location, like here [1], I had to run a lot of sanity checks to
> rebase it properly. Like checking for the updated paths in resource
> registries are still valid or had to/been moved as well, then picking the
> source of truth for diverged old vs changes locations - all that to loose
> nothing important in progress.
>
> So I'd say please let's do *not* change services' paths/namespaces in t-h-t
> "API" w/o real need to do that, when there is no more alternatives left to
> that.
>

Ok so it's time to dig this thread back up. I'm currently looking at
the chrony support which will require a new service[0][1]. Rather than
add it under puppet, we'll likely want to leverage ansible. So I guess
the question is where do we put services going forward?  Additionally
as we look to truly removing the baremetal deployment options and
puppet service deployment, it seems like we need to consolidate under
a single structure.  Given that we don't want force too much churn,
does this mean that we should align to the docker/services/*.yaml
structure or should we be proposing a new structure that we can try to
align on.

There is outstanding tech-debt around the nested stacks and references
within these services when we added the container deployments so it's
something that would be beneficial to start tackling sooner rather
than later.  Personally I think we're always going to have the issue
when we rename files that could have been referenced by custom
templates, but I don't think we can continue to carry the outstanding
tech debt around these static locations.  Should we be investing in
coming up with some sort of mappings that we can use/warn a user on
when we move files?

Thanks,
-Alex

[0] https://review.openstack.org/#/c/586679/

[openstack-dev] [tripleo] Patches to speed up plan operations

[Ian Main]

Hey folks!

So I've been working on some patches to speed up plan operations in
TripleO.  This was originally driven by the UI needing to be able to
perform a 'plan upload' in something less than several minutes. :)

https://review.openstack.org/#/c/581153/
https://review.openstack.org/#/c/581141/

I have a functioning set of patches, and it actually cuts over 2 minutes
off the overcloud deployment time.

Without patch:
+ openstack overcloud plan create --templates
/home/stack/tripleo-heat-templates/ overcloud
Creating Swift container to store the plan
Creating plan from template files in: /home/stack/tripleo-heat-templates/
Plan created.
real3m3.415s

With patch:
+ openstack overcloud plan create --templates
/home/stack/tripleo-heat-templates/ overcloud
Creating Swift container to store the plan
Creating plan from template files in: /home/stack/tripleo-heat-templates/
Plan created.
real0m44.694s

This is on VMs.  On real hardware it now takes something like 15-20 seconds
to do the plan upload which is much more manageable from the UI standpoint.

Some things about what this patch does:

- It makes use of process-templates.py (written for the undercloud) to
process the jinjafied templates.  This reduces replication with the
existing version in the code base and is very fast as it's all done on
local disk.
- It stores the bulk of the templates as a tarball in swift.  Any
individual files in swift take precedence over the contents of the tarball
so it should be backwards compatible.  This is a great speed up as we're
not accessing a lot of individual files in swift.

There's still some work to do; cleaning up and fixing the unit tests,
testing upgrades etc.  I just wanted to get some feedback on the general
idea and hopefully some reviews and/or help - especially with the unit test
stuff.

Thanks everyone!

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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Matt Riedemann]

On 8/1/2018 3:55 PM, Ben Nemec wrote:
I changed disk_allocation_ratio to 2.0 in the config file and it had no 
effect on the existing resource provider.  I assume that is because I 
had initially deployed with it unset, so I got 1.0, and when I later 
wanted to change it the provider already existed with the default value. 


Yeah I think so, unless the inventory changes we don't mess with 
changing the allocation ratio.



  So in the past I could do the following:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler and/or nova-compute

Now it seems like I need to do:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler, nova-compute, and nova-placement (or some 
subset of those?)


Restarting the placement service wouldn't have any effect here.

3) Use osc-placement to fix up the ratios on any existing resource 
providers


Yeah that's what you'd need to do in this case.

I believe Jay Pipes might have somewhere between 3 and 10 specs for the 
allocation ratio / nova conf / placement inventory / aggregates problems 
floating around, so he's probably best to weigh in here. Like: 
https://review.openstack.org/#/c/552105/


--

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

Re: [openstack-dev] [tripleo] The Weekly Owl - 25th Edition

[Jill Rouleau]

On Tue, 2018-07-31 at 07:38 -0400, Pradeep Kilambi wrote:
> 
> 
> On Mon, Jul 30, 2018 at 2:17 PM Jill Rouleau  wrote:
> > On Mon, 2018-07-30 at 11:35 -0400, Pradeep Kilambi wrote:
> > > 
> > > 
> > > On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz  > >
> > > wrote:
> > > > On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr 
> > > > wrote:
> > > > >
> > > > >
> > > > > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi  > t.co
> > > > m> wrote:
> > > > >>
> > > > >> Your fellow reporter took a break from writing, but is now
> > back
> > > > on his
> > > > >> pen.
> > > > >>
> > > > >> Welcome to the twenty-fifth edition of a weekly update in
> > TripleO
> > > > world!
> > > > >> The goal is to provide a short reading (less than 5 minutes)
> > to
> > > > learn
> > > > >> what's new this week.
> > > > >> Any contributions and feedback are welcome.
> > > > >> Link to the previous version:
> > > > >> http://lists.openstack.org/pipermail/openstack-dev/2018-June/
> > 1314
> > > > 26.html
> > > > >>
> > > > >> +-+
> > > > >> | General announcements |
> > > > >> +-+
> > > > >>
> > > > >> +--> Rocky Milestone 3 is next week. After, any feature code
> > will
> > > > require
> > > > >> Feature Freeze Exception (FFE), asked on the mailing-list.
> > We'll
> > > > enter a
> > > > >> bug-fix only and stabilization period, until we can push the
> > > > first stable
> > > > >> version of Rocky.
> > > > >
> > > > >
> > > > > Hey guys,
> > > > >
> > > > >   I would like to ask for FFE for backup and restore, where we
> > > > ended up
> > > > > deciding where is the best place for the code base for this
> > > > project (please
> > > > > see [1] for details). We believe that B&R support for
> > overcloud
> > > > control
> > > > > plane will be good addition to a rocky release, but we started
> > > > with this
> > > > > initiative quite late indeed. The final result should the
> > support
> > > > in
> > > > > openstack client, where "openstack overcloud (backup|restore)"
> > > > would work as
> > > > > a charm. Thanks in advance for considering this feature.
> > > > >
> > > > 
> > > > Was there a blueprint/spec for this effort?  Additionally do we
> > have
> > > > a
> > > > list of the outstanding work required for this? If it's just
> > these
> > > > two
> > > > playbooks, it might be ok for an FFE. But if there's additional
> > > > tripleoclient related changes, I wouldn't necessarily feel
> > > > comfortable
> > > > with these unless we have a complete list of work.  Just as a
> > side
> > > > note, I'm not sure putting these in tripleo-common is going to
> > be
> > > > the
> > > > ideal place for this.
> > 
> > Was it this review? https://review.openstack.org/#/c/582453/
> > 
> > For Stein we'll have an ansible role[0] and playbook repo[1] where
> > these
> > types of tasks should live.
> > 
> > [0] https://github.com/openstack/ansible-role-openstack-operations 
> > [1] https://review.openstack.org/#/c/583415/
> Thanks Jill! The issue is, we want to be able to backport this to
> Queens once merged. With the new repos you're mentioning would this be
> possible? If no, then this wont work for us unfortunately.
> 

We wouldn't backport the new packages to Queens, however the repos will
be on github and available to clone and use.  This would be far
preferable than adding them to tripleo-common so late in the rocky cycle
then having to break them back out right away in stein.

> 
>  
> > 
> > 
> > > 
> > > Thanks Alex. For Rocky, if we can ship the playbooks with relevant
> > > docs we should be good. We will integrated with client in Stein
> > > release with restore logic included. Regarding putting tripleo-
> > common, 
> > > we're open to suggestions. I think Dan just submitted the review
> > so we
> > > can get some eyes on the playbooks. Where do you suggest is better
> > > place for these instead?
> > >  
> > > > 
> > > > Thanks,
> > > > -Alex
> > > > 
> > > > > Regards,
> > > > > Martin
> > > > >
> > > > > [1] https://review.openstack.org/#/c/582453/
> > > > >
> > > > >>
> > > > >> +--> Next PTG will be in Denver, please propose topics:
> > > > >> https://etherpad.openstack.org/p/tripleoci-ptg-stein
> > > > >> +--> Multiple squads are currently brainstorming a framework
> > to
> > > > provide
> > > > >> validations pre/post upgrades - stay in touch!
> > > > >>
> > > > >> +--+
> > > > >> | Continuous Integration |
> > > > >> +--+
> > > > >>
> > > > >> +--> Sprint theme: migration to Zuul v3 (More on
> > > > >> https://trello.com/c/vyWXcKOB/841-sprint-16-goals)
> > > > >> +--> Sagi is the rover and Chandan is the ruck. Please tell
> > them
> > > > any CI
> > > > >> issue.
> > > > >> +--> Promotion on master is 4 days, 0 days on Queens and Pike
> > and
> > > > 1 day on
> > > > >> Ocata.
> > > > >> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-
> > meet
> > > > ing
> > > > >>
> > > > >> +-+

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Ben Nemec]

On 08/01/2018 02:22 PM, Matt Riedemann wrote:

On 8/1/2018 12:06 PM, Ben Nemec wrote:
To close the loop on the problem I was having, it looks like the 
allocation_ratio config opts are now just defaults, and if you want to 
change ratios after the initial deployment you need to do so with the 
client.


You mean how 
https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio 
defaults to 0.0 and that's used in the ResourceTracker to set the 
inventory?


https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/compute/resource_tracker.py#L120 



That should get defaulted to 1.0 if you didn't change the config option:

https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/objects/compute_node.py#L207 



If you wanted 2.0, then you should set the disk_allocation_ratio config 
option to 2.0 on that host - I don't think that is a behavior change is it?


I changed disk_allocation_ratio to 2.0 in the config file and it had no 
effect on the existing resource provider.  I assume that is because I 
had initially deployed with it unset, so I got 1.0, and when I later 
wanted to change it the provider already existed with the default value. 
 So in the past I could do the following:


1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler and/or nova-compute

Now it seems like I need to do:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler, nova-compute, and nova-placement (or some 
subset of those?)

3) Use osc-placement to fix up the ratios on any existing resource providers





I will note that it's a little annoying that you have to specify all 
of the fields on this call.


I agree with you. The "openstack resource provider inventory set" 
command is similar in that it is a total overwrite of all inventory for 
the provider:


https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-set 



So if you want to add just one inventory class (or change one) then you 
have to repeat all of the existing inventory if you don't want to lose 
that. And I don't think "openstack resource provider inventory class 
set" lets you add new inventory classes, it only lets you update 
existing ones.


So we probably need something like an --amend option on both commands 
which are sort of meta commands to retain everything else about the 
inventory for the provider but only changes the fields that the user 
specifies.


We've mostly just been trying to get out *any* CLI support at all, so 
what is there now is basic functionality, warts and all, and we can 
iterate over time to make the tools more usable.


To track this, I've created an RFE bug in launchpad:

https://bugs.launchpad.net/placement-osc-plugin/+bug/1784932



Cool, 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] [nova] How to debug no valid host failures with placement

[Jay Pipes]

On 08/01/2018 02:02 PM, Chris Friesen wrote:

On 08/01/2018 11:32 AM, melanie witt wrote:

I think it's definitely a significant issue that troubleshooting "No 
allocation

candidates returned" from placement is so difficult. However, it's not
straightforward to log detail in placement when the request for 
allocation
candidates is essentially "SELECT * FROM nodes WHERE cpu usage < 
needed and disk
usage < needed and memory usage < needed" and the result is returned 
from the API.


I think the only way to get useful info on a failure would be to break 
down the huge SQL statement into subclauses and store the results of the 
intermediate queries.


This is a good idea and something that can be done.

Unfortunately, it's refactoring work and as a community, we tend to 
prioritize fancy features like NUMA topology and CPU pinning over 
refactoring work.


Best,
-jay

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

Re: [openstack-dev] [Nova] [Cyborg] Updates to os-acc proposal

[Eric Fried]

Sundar-

> On an unrelated note, thanks for the
> pointer to the GPU spec
> (https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst).
> I will review that.

Thanks. Please note that this is for nova-powervm, PowerVM's
*out-of-tree* compute driver. We hope to bring this into the in-tree
driver eventually (unless we skip straight to the cyborg model :) but it
should give a good idea of some of the requirements and use cases we're
looking to support.

> Fair enough. We had discussed that too. The Cyborg drivers can also
> invoke REST APIs etc. for Power.

Ack.

> Agreed. So, we could say:
> - The plugins do the instance half. They are hypervisor-specific and
> platform-specific. (The term 'platform' subsumes both the architecture
> (Power, x86) and the server/system type.) They are invoked by os-acc.
> - The drivers do the device half, device discovery/enumeration and
> anything not explicitly assigned to plugins. They contain
> device-specific and platform-specific code. They are invoked by Cyborg
> agent and os-acc.

Sounds good.

> Are you ok with the workflow in
> https://docs.google.com/drawings/d/1cX06edia_Pr7P5nOB08VsSMsgznyrz4Yy2u8nb596sU/edit?usp=sharing
> ?

Yes (but see below).

>> You mean for getVAN()?
> Yes -- BTW, I renamed it as prepareVANs() or prepareVAN(), because it is
> not just a query as the name getVAN implies, but has side effects.

Ack.

>> Because AFAIK, os_vif.plug(list_of_vif_objects,
>> InstanceInfo) is *not* how nova uses os-vif for plugging.
> 
> Yes, the os-acc will invoke the plug() once per VAN. IIUC, Nova calls
> Neutron once per instance for all networks, as seen in this code
> sequence in nova/nova/compute/manager.py:
> 
> _build_and_run_instance() --> _build_resources() -->
> 
>     _build_networks_for_instance() --> _allocate_network()
> 
> The _allocate_network() actually takes a list of requested_networks, and
> handles all networks for an instance [1].
> 
> Chasing this further down:
> 
> _allocate_network --> _allocate_network_async()
> 
> --> self.network_api.allocate_for_instance()
> 
>  == nova/network/rpcapi.py::allocate_for_instance()
> 
> So, even the RPC out of Nova seems to take a list of networks [2].

Yes yes, but by the time we get to os_vif.plug(), we're doing one VIF at
a time. That corresponds to what you've got in your flow diagram, so as
long as that's accurate, I'm fine with it.

That said, we could discuss os_acc.plug taking a list of VANs and
threading out the calls to the plugin's plug() method (which takes one
at a time). I think we've talked a bit about this before: the pros and
cons of having the threading managed by os-acc or by the plugin. We
could have the same discussion for prepareVANs() too.

> [1]
> https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1529
> [2]
> https://github.com/openstack/nova/blob/master/nova/network/rpcapi.py#L163
>> Thanks,
>> Eric
>> //lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Regards,
> Sundar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [all] Gerrit project renaming Friday August 3 at 16:00UTC

[Clark Boylan]

Hello everyone,

The infra team will be renaming a couple of projects in Gerrit on Friday 
starting at 16:00UTC. This requires us to restart Gerrit on 
review.openstack.org. The total noticeable downtime should be no more than 
about 10 minutes.

If you would like to follow along, the current process is laid out at 
https://etherpad.openstack.org/p/project-renames-2018-08-03.

Let us know if you have questions or concerns,
Clark

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

Re: [openstack-dev] [Nova] [Cyborg] Updates to os-acc proposal

[Nadathur, Sundar]

Hi Eric,
    Please see my responses inline. On an unrelated note, thanks for 
the pointer to the GPU spec 
(https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst). 
I will review that.


On 7/31/2018 10:42 AM, Eric Fried wrote:

Sundar-


   * Cyborg drivers deal with device-specific aspects, including
 discovery/enumeration of devices and handling the Device Half of the
 attach (preparing devices/accelerators for attach to an instance,
 post-attach cleanup (if any) after successful attach, releasing
 device/accelerator resources on instance termination or failed
 attach, etc.)
   * os-acc plugins deal with hypervisor/system/architecture-specific
 aspects, including handling the Instance Half of the attach (e.g.
 for libvirt with PCI, preparing the XML snippet to be included in
 the domain XML).

This sounds well and good, but discovery/enumeration will also be
hypervisor/system/architecture-specific. So...
Fair enough. We had discussed that too. The Cyborg drivers can also 
invoke REST APIs etc. for Power.

Thus, the drivers and plugins are expected to be complementary. For
example, for 2 devices of types T1 and T2, there shall be 2 separate
Cyborg drivers. Further, we would have separate plugins for, say,
x86+KVM systems and Power systems. We could then have four different
deployments -- T1 on x86+KVM, T2 on x86+KVM, T1 on Power, T2 on Power --
by suitable combinations of the drivers and plugins.

...the discovery/enumeration code for T1 on x86+KVM (lsdev? lspci?
walking the /dev file system?) will be totally different from the
discovery/enumeration code for T1 on Power
(pypowervm.wrappers.ManagedSystem.get(adapter)).

I don't mind saying "drivers do the device side; plugins do the instance
side" but I don't see getting around the fact that both "sides" will
need to have platform-specific code

Agreed. So, we could say:
- The plugins do the instance half. They are hypervisor-specific and 
platform-specific. (The term 'platform' subsumes both the architecture 
(Power, x86) and the server/system type.) They are invoked by os-acc.
- The drivers do the device half, device discovery/enumeration and 
anything not explicitly assigned to plugins. They contain 
device-specific and platform-specific code. They are invoked by Cyborg 
agent and os-acc.


Are you ok with the workflow in 
https://docs.google.com/drawings/d/1cX06edia_Pr7P5nOB08VsSMsgznyrz4Yy2u8nb596sU/edit?usp=sharing 
?

One secondary detail to note is that Nova compute calls os-acc per
instance for all accelerators for that instance, not once for each
accelerator.

You mean for getVAN()?
Yes -- BTW, I renamed it as prepareVANs() or prepareVAN(), because it is 
not just a query as the name getVAN implies, but has side effects.

Because AFAIK, os_vif.plug(list_of_vif_objects,
InstanceInfo) is *not* how nova uses os-vif for plugging.


Yes, the os-acc will invoke the plug() once per VAN. IIUC, Nova calls 
Neutron once per instance for all networks, as seen in this code 
sequence in nova/nova/compute/manager.py:


_build_and_run_instance() --> _build_resources() -->

    _build_networks_for_instance() --> _allocate_network()

The _allocate_network() actually takes a list of requested_networks, and 
handles all networks for an instance [1].


Chasing this further down:

_allocate_network --> _allocate_network_async()

--> self.network_api.allocate_for_instance()

 == nova/network/rpcapi.py::allocate_for_instance()

So, even the RPC out of Nova seems to take a list of networks [2].

[1] 
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1529
[2] 
https://github.com/openstack/nova/blob/master/nova/network/rpcapi.py#L163

Thanks,
Eric
//lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Regards,
Sundar

__
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 update for 1 Aug 2018

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Approved changes:

- python3-first goal: https://review.openstack.org/#/c/575933/

== Ongoing Discussions ==

Dims started porting the compute:starter-kit tag to be a constellation.
This highlighted an issue with the current definition of that set of
projects and their use of the tools in the base services list.

- https://review.openstack.org/#/c/586212/

We had 7 teams without any volunteers to serve as PTL for the Stein
cycle (Dragonflow, Freezer, Loci, Packaging-RPM, Refstack, Searchlight,
and Winstackers). The Trove team had a volunteer, but that person does
not qualify under our normal rules that say the PTL should be an ATC.
This triggered some discussion of what the PTL's role is, why we have
it, and whether we may need to make some changes in how it is defined
and used.

The TC will be reviewing what to do with those teams over the next week
or two.

- https://wiki.openstack.org/wiki/OpenStack_health_tracker#Status_updates

Thierry posted about the changes to the Summit & PTG and how they will
affect the Stein release cycle. tl;dr: Because the Summit and PTG will
be combined at the end of Stein, the cycle will be a little longer to
allow the release dates to sync with the event.

- http://lists.openstack.org/pipermail/openstack-dev/2018-July/132651.html

== TC member actions/focus/discussions for the coming week(s) ==

The TC members who are liaisons to one of the teams affected by a lack
of PTL candidates should contact the current PTL for those teams to
ensure that they are aware of the problem.

Please review the suggested topics for the TC to discuss at the PTG:

- https://etherpad.openstack.org/p/tc-stein-ptg

The PTG is approaching quickly. Please complete any remaining team
health checks.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


__
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] How to debug no valid host failures with placement

[Matt Riedemann]

On 8/1/2018 12:06 PM, Ben Nemec wrote:
To close the loop on the problem I was having, it looks like the 
allocation_ratio config opts are now just defaults, and if you want to 
change ratios after the initial deployment you need to do so with the 
client.


You mean how 
https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio 
defaults to 0.0 and that's used in the ResourceTracker to set the inventory?


https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/compute/resource_tracker.py#L120

That should get defaulted to 1.0 if you didn't change the config option:

https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/objects/compute_node.py#L207

If you wanted 2.0, then you should set the disk_allocation_ratio config 
option to 2.0 on that host - I don't think that is a behavior change is it?




I will note that it's a little annoying that you have to specify all of 
the fields on this call.


I agree with you. The "openstack resource provider inventory set" 
command is similar in that it is a total overwrite of all inventory for 
the provider:


https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-set

So if you want to add just one inventory class (or change one) then you 
have to repeat all of the existing inventory if you don't want to lose 
that. And I don't think "openstack resource provider inventory class 
set" lets you add new inventory classes, it only lets you update 
existing ones.


So we probably need something like an --amend option on both commands 
which are sort of meta commands to retain everything else about the 
inventory for the provider but only changes the fields that the user 
specifies.


We've mostly just been trying to get out *any* CLI support at all, so 
what is there now is basic functionality, warts and all, and we can 
iterate over time to make the tools more usable.


To track this, I've created an RFE bug in launchpad:

https://bugs.launchpad.net/placement-osc-plugin/+bug/1784932

--

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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Matt Riedemann]

On 8/1/2018 12:32 PM, melanie witt wrote:
I think it's definitely a significant issue that troubleshooting "No 
allocation candidates returned" from placement is so difficult. However, 
it's not straightforward to log detail in placement when the request for 
allocation candidates is essentially "SELECT * FROM nodes WHERE cpu 
usage < needed and disk usage < needed and memory usage < needed" and 
the result is returned from the API.


I think better logging is something we want to have, so if anyone has 
ideas around it, do share them.


I don't have any amazing ideas but I did put it on the PTG etherpad for 
discussion:


https://etherpad.openstack.org/p/nova-ptg-stein

--

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

Re: [openstack-dev] [sahara] Anti-Affinity Broke

[Telles Nobrega]

Thanks, that is what I did as well.

On Wed, Aug 1, 2018 at 3:50 PM Joe Topjian  wrote:

> Hello,
>
> Yes, those workarounds were able to get anti-affinity working. In my
> original email I noted the uninitialized key issue. We're getting around
> this by doing the following:
>
> properties[SERVER_GROUP_NAMES] = []
>
> Thanks,
> Joe
>
>
> On Wed, Aug 1, 2018 at 12:39 PM, Telles Nobrega 
> wrote:
>
>> Hi Joe,
>>
>> sorry for only replying to this now, but I just got time to work on it
>> today.
>>
>> When you did those workarounds, did it all work properly? I'm hitting an
>> issue with a KeyError whili trying to add the resource to the properties.
>>
>> properties[SERVER_GROUP_NAMES].insert(i,
>> server_group_resource)
>>
>> Thanks,
>>
>>
>> On Fri, Jun 22, 2018 at 5:03 AM Luigi Toscano 
>> wrote:
>>
>>> On Friday, 22 June 2018 05:00:16 CEST Joe Topjian wrote:
>>> > Hello,
>>> >
>>> > I originally posted this to the general openstack list to get a sanity
>>> > check on what I was seeing. Jeremy F reached out and confirmed that,
>>> so I'm
>>> > going to re-post the details here to begin a discussion.
>>>
>>> Hi,
>>>
>>> thanks for investigating the issue; it's not the most trivial thing to
>>> test
>>> without a real CI system based on baremetal, and we don't have one at
>>> this
>>> time.
>>>
>>> > I can also create something on StoryBoard for this, too.
>>>
>>> Yes, that would be preferred; could you please open it describing the
>>> symptoms
>>> that you found in addition to the workarounds?
>>>
>>> Ciao
>>> --
>>> Luigi
>>>
>>>
>>>
>>>
>>> __
>>> 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
>>>
>> --
>>
>> TELLES NOBREGA
>>
>> SOFTWARE ENGINEER
>>
>> Red Hat Brasil  
>>
>> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>>
>> tenob...@redhat.com
>> 
>> TRIED. TESTED. TRUSTED. 
>>  Red Hat é reconhecida entre as melhores empresas para trabalhar no
>> Brasil pelo Great Place to Work.
>>
>> __
>> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
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] [sahara] Anti-Affinity Broke

[Joe Topjian]

Hello,

Yes, those workarounds were able to get anti-affinity working. In my
original email I noted the uninitialized key issue. We're getting around
this by doing the following:

properties[SERVER_GROUP_NAMES] = []

Thanks,
Joe


On Wed, Aug 1, 2018 at 12:39 PM, Telles Nobrega  wrote:

> Hi Joe,
>
> sorry for only replying to this now, but I just got time to work on it
> today.
>
> When you did those workarounds, did it all work properly? I'm hitting an
> issue with a KeyError whili trying to add the resource to the properties.
>
> properties[SERVER_GROUP_NAMES].insert(i,
> server_group_resource)
>
> Thanks,
>
>
> On Fri, Jun 22, 2018 at 5:03 AM Luigi Toscano  wrote:
>
>> On Friday, 22 June 2018 05:00:16 CEST Joe Topjian wrote:
>> > Hello,
>> >
>> > I originally posted this to the general openstack list to get a sanity
>> > check on what I was seeing. Jeremy F reached out and confirmed that, so
>> I'm
>> > going to re-post the details here to begin a discussion.
>>
>> Hi,
>>
>> thanks for investigating the issue; it's not the most trivial thing to
>> test
>> without a real CI system based on baremetal, and we don't have one at
>> this
>> time.
>>
>> > I can also create something on StoryBoard for this, too.
>>
>> Yes, that would be preferred; could you please open it describing the
>> symptoms
>> that you found in addition to the workarounds?
>>
>> Ciao
>> --
>> Luigi
>>
>>
>>
>> 
>> __
>> 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
>>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil  
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>  Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
> pelo Great Place to Work.
>
> __
> 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] [sahara] Anti-Affinity Broke

[Telles Nobrega]

Hi Joe,

sorry for only replying to this now, but I just got time to work on it
today.

When you did those workarounds, did it all work properly? I'm hitting an
issue with a KeyError whili trying to add the resource to the properties.

properties[SERVER_GROUP_NAMES].insert(i,
server_group_resource)

Thanks,


On Fri, Jun 22, 2018 at 5:03 AM Luigi Toscano  wrote:

> On Friday, 22 June 2018 05:00:16 CEST Joe Topjian wrote:
> > Hello,
> >
> > I originally posted this to the general openstack list to get a sanity
> > check on what I was seeing. Jeremy F reached out and confirmed that, so
> I'm
> > going to re-post the details here to begin a discussion.
>
> Hi,
>
> thanks for investigating the issue; it's not the most trivial thing to
> test
> without a real CI system based on baremetal, and we don't have one at this
> time.
>
> > I can also create something on StoryBoard for this, too.
>
> Yes, that would be preferred; could you please open it describing the
> symptoms
> that you found in addition to the workarounds?
>
> Ciao
> --
> Luigi
>
>
>
> __
> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
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] How to debug no valid host failures with placement

[Chris Friesen]

On 08/01/2018 11:32 AM, melanie witt wrote:


I think it's definitely a significant issue that troubleshooting "No allocation
candidates returned" from placement is so difficult. However, it's not
straightforward to log detail in placement when the request for allocation
candidates is essentially "SELECT * FROM nodes WHERE cpu usage < needed and disk
usage < needed and memory usage < needed" and the result is returned from the 
API.


I think the only way to get useful info on a failure would be to break down the 
huge SQL statement into subclauses and store the results of the intermediate 
queries.  So then if it failed placement could log something like:


hosts with enough CPU: 
hosts that also have enough disk: 
hosts that also have enough memory: 
hosts that also meet extra spec host aggregate keys: 
hosts that also meet image properties host aggregate keys: 
hosts that also have requested PCI devices: 

And maybe we could optimize the above by only emitting logs where the list has a 
length less than X (to avoid flooding the logs with hostnames in large clusters).


This would let you zero in on the things that finally caused the list to be 
whittled down to nothing.


Chris

__
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] How to debug no valid host failures with placement

[melanie witt]

On Wed, 1 Aug 2018 12:17:36 -0500, Ben Nemec wrote:



On 08/01/2018 11:23 AM, Chris Friesen wrote:

On 08/01/2018 09:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources
of your cloud.
This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10

And you can explore placement state with other commands like openstack
resource
provider list, resource provider inventory list, resource provider
usage show.



Unfortunately this doesn't help figure out what the missing resources
were *at the time of the failure*.

The fact that there is no real way to get the equivalent of the old
detailed scheduler logs is a known shortcoming in placement, and will
become more of a problem if/when we move more complicated things like
CPU pinning, hugepages, and NUMA-awareness into placement.

The problem is that getting useful logs out of placement would require
significant development work.


Yeah, in my case I only had one compute node so it was obvious what the
problem was, but if I had a scheduling failure on a busy cloud with
hundreds of nodes I don't see how you would ever track it down.  Maybe
we need to have a discussion with operators about how often they do
post-mortem debugging of this sort of thing?


I think it's definitely a significant issue that troubleshooting "No 
allocation candidates returned" from placement is so difficult. However, 
it's not straightforward to log detail in placement when the request for 
allocation candidates is essentially "SELECT * FROM nodes WHERE cpu 
usage < needed and disk usage < needed and memory usage < needed" and 
the result is returned from the API.


I think better logging is something we want to have, so if anyone has 
ideas around it, do share them.


-melanie




__
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] Ongoing spam in Freenode IRC channels

[Jeremy Stanley]

On 2018-08-01 12:48:39 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Monty Taylor's message of 2018-08-01 09:58:03 -0500:
> > On 08/01/2018 08:38 AM, Jeremy Stanley wrote:
> > > On 2018-08-01 09:58:48 -0300 (-0300), Rafael Weingärtner wrote:
> > >> What about Rocket chat instead of Slack? It is open source.
> > >> https://github.com/RocketChat/Rocket.Chat
> > >>
> > >> Monty, what kind of evaluation would you guys need? I might be
> > >> able to help.
> > > 
> > > Consider reading and possibly resurrecting the infra spec for it:
> > > 
> > >  https://review.openstack.org/319506
> > > 
> > > My main concern is how we'll go about authenticating and policing
> > > whatever gateway we set up. As soon as spammers and other abusers
> > > find out there's an open (or nearly so) proxy to a major IRC
> > > network, they'll use it to hide their origins from the IRC server
> > > operators and put us in the middle of the problem.
> > 
> > To be clear -- I was not suggesting running matrix and IRC. I was 
> > suggesting investigating running a matrix home server and the 
> > permanently moving all openstack channels to it.
> > 
> > matrix synapse supports federated identity providers with saml and cas 
> > support implemented. I would imagine we'd want to configure it to 
> > federate to openstackid for logging in to the home server -so that might 
> > involve either adding saml support to openstackid or writing an 
> > openid-connect driver to synapse.
> 
> This matches my expectations. We did talk about supporting a temporary
> bridge to IRC, during the migration, but I don't think we need to run an
> "open" home server to have that.

Yes, I'm not concerned about Matrix specifically. My response was
triggered by Rafael's suggestion of running a Rocket.Chat interface
for users. Sorry if that wasn't clear.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Chris Friesen]

On 08/01/2018 11:17 AM, Ben Nemec wrote:



On 08/01/2018 11:23 AM, Chris Friesen wrote:



The fact that there is no real way to get the equivalent of the old detailed
scheduler logs is a known shortcoming in placement, and will become more of a
problem if/when we move more complicated things like CPU pinning, hugepages,
and NUMA-awareness into placement.

The problem is that getting useful logs out of placement would require
significant development work.


Yeah, in my case I only had one compute node so it was obvious what the problem
was, but if I had a scheduling failure on a busy cloud with hundreds of nodes I
don't see how you would ever track it down.  Maybe we need to have a discussion
with operators about how often they do post-mortem debugging of this sort of 
thing?


For Wind River's Titanium Cloud it was enough of an issue that we customized the 
scheduler to emit detailed logs on scheduler failure.


We started upstreaming it[1] but the effort stalled out when the upstream folks 
requested major implementation changes.


Chris


[1] https://blueprints.launchpad.net/nova/+spec/improve-sched-logging

__
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] How to debug no valid host failures with placement

[Ben Nemec]

On 08/01/2018 11:23 AM, Chris Friesen wrote:

On 08/01/2018 09:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources 
of your cloud.

This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10

And you can explore placement state with other commands like openstack 
resource
provider list, resource provider inventory list, resource provider 
usage show.




Unfortunately this doesn't help figure out what the missing resources 
were *at the time of the failure*.


The fact that there is no real way to get the equivalent of the old 
detailed scheduler logs is a known shortcoming in placement, and will 
become more of a problem if/when we move more complicated things like 
CPU pinning, hugepages, and NUMA-awareness into placement.


The problem is that getting useful logs out of placement would require 
significant development work.


Yeah, in my case I only had one compute node so it was obvious what the 
problem was, but if I had a scheduling failure on a busy cloud with 
hundreds of nodes I don't see how you would ever track it down.  Maybe 
we need to have a discussion with operators about how often they do 
post-mortem debugging of this sort of thing?


__
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] How to debug no valid host failures with placement

[Ben Nemec]

Aha, thanks!  That explains why I couldn't find any client commands for 
placement before.


To close the loop on the problem I was having, it looks like the 
allocation_ratio config opts are now just defaults, and if you want to 
change ratios after the initial deployment you need to do so with the 
client.  This is what I used:


openstack resource provider inventory class set 
f931b646-ce18-43f6-8c95-bd3ba82fb9a8 DISK_GB --total 111 
--allocation_ratio 2.0


I will note that it's a little annoying that you have to specify all of 
the fields on this call.  To change allocation_ratio I also had to pass 
total even though I didn't want to change total.  MEMORY_MB is even 
worse because not passing max_unit and reserved as well will cause those 
to revert to max_int and 0, which I can't imagine ever being right.  I 
guess this isn't something that users would do a lot, but it could be a 
nasty surprise if they tried to update something, had reserved go to 
zero but didn't notice, and suddenly find they're overcommitting more 
than they intended.


Anyway, thanks again for the help.  I hope this thread will be useful to 
other people who are learning placement too.


-Ben

On 08/01/2018 10:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources of 
your cloud.

This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource 
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10


And you can explore placement state with other commands like openstack 
resource provider list, resource provider inventory list, resource 
provider usage show.


[1] https://developer.openstack.org/api-ref/placement/
[2] https://docs.openstack.org/osc-placement/latest/index.html

On Wed, Aug 1, 2018 at 6:16 PM Ben Nemec > wrote:


Hi,

I'm having an issue with no valid host errors when starting instances
and I'm struggling to figure out why.  I thought the problem was disk
space, but I changed the disk_allocation_ratio and I'm still getting no
valid host.  The host does have plenty of disk space free, so that
shouldn't be a problem.

However, I'm not even sure it's disk that's causing the failures
because
I can't find any information in the logs about why the no valid host is
happening.  All I get from the scheduler is:

"Got no allocation candidates from the Placement API. This may be a
temporary occurrence as compute nodes start up and begin reporting
inventory to the Placement service."

While in placement I see:

2018-08-01 15:02:22.062 20 DEBUG
nova.api.openstack.placement.requestlog
[req-0a830ce9-e2af-413a-86cb-b47ae129b676
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
default default] Starting request: 10.2.2.201 "GET

/placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"

__call__

/usr/lib/python2.7/site-packages/nova/api/openstack/placement/requestlog.py:38
2018-08-01 15:02:22.103 20 INFO nova.api.openstack.placement.requestlog
[req-0a830ce9-e2af-413a-86cb-b47ae129b676
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
default default] 10.2.2.201 "GET

/placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"

status: 200 len: 53 microversion: 1.25

Basically it just seems to be logging that it got a request, but
there's
no information about what it did with that request.

So where do I go from here?  Is there somewhere else I can look to see
why placement returned no candidates?

Thanks.

-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



--
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.


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



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

[openstack-dev] [all][python3] approved python3-first goal for stein

[Doug Hellmann]

The goal to run jobs under python3 first has been approved for Stein
[1].

We are going to be using storyboard for tracking work on the goal,
so I have started creating the stories and tasks. Because of the
complexity of the work, I am setting up 1 story for each team, with
1 task for each repository. For repositories that haven't migrated
to storyboard, the tasks will be associated with the openstack/governance
repository. See [2] for the relevant stories.

The first phase of the work for this goal involves a lot of zuul
reconfiguration, so please do not start on it until after we have
completed the Rocky release.

As the goal document describes, the champions for this goal will
propose the patches to move the zuul settings (we have some nice
tools to do this in a consistent way).  I expect we will start with
that around the time of the PTG. Stand by for more details.

Doug

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://storyboard.openstack.org/#!/search?tags=goal-python3-first

__
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] [tricircle] Tricircle or Trio2o

[Andrea Franceschini]

Hello All,

While I was looking for multisite openstack solutions I stumbled on
Tricircle project which seemed fairly perfect for the job except that
l it was split in two parts, tricircle itself for the network part and
Trio2o for all the rest.

Now it seems that the Trio2o project is no longer maintained  and I'm
wondering what other options exist for multisite openstack, stated
that tricircle seems more NFV oriented.

Actually a heat multisite solution would work too, but I cannot find
any  reference to this kind of solutions.

Do you have any idea/advice?

Thanks,

Andrea

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

Re: [openstack-dev] [neutron] Port mirroring for SR-IOV VF to VF mirroring

[Bhatia, Manjeet S]

Hi,

Yes, we need to refine spec for sure, once a consensus is reached focus will be 
on implementation,
Here’s implementation patch (WIP) https://review.openstack.org/#/c/584892/ , we 
can’t really
review api part until spec if finalized but, other stuff like config and common 
issues can
still be pointed out and progress can be made until consensus on api is 
reached. Miguel, I think
this will be added to etherpad for PTG discussions as well ?

Thanks and Regards !
Manjeet




From: Miguel Lavalle [mailto:mig...@mlavalle.com]
Sent: Tuesday, July 31, 2018 10:26 AM
To: Zhao, Forrest 
Cc: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [neutron] Port mirroring for SR-IOV VF to VF 
mirroring

Hi Forrest,

Yes, in my email, I was precisely referring to the work around 
https://review.openstack.org/#/c/574477.
 Now that we are wrapping up Rocky, I wanted to raise the visibility of this 
spec. I am glad you noticed. This week we are going to cut our RC-1 and I don't 
anticipate that we will will have a RC-2 for Rocky. So starting next week, 
let's go back to the spec and refine it, so we can start implementing in Stein 
as soon as possible. Depending on how much progress we make in the spec, we may 
need to schedule a discussion during the PTG in Denver, September 10 - 14, in 
case face to face time is needed to reach an agreement. I know that Manjeet is 
going to attend the PTG and he has already talked to me about this spec in the 
recent past. So maybe Manjeet could be the conduit to represent this spec in 
Denver, in case we need to talk about it there

Best regards

Miguel

On Tue, Jul 31, 2018 at 4:12 AM, Zhao, Forrest 
mailto:forrest.z...@intel.com>> wrote:
Hi Miguel,

In your mail “PTL candidacy for the Stein cycle”, it mentioned that “port 
mirroring for SR-IOV VF to VF mirroring” is within Stein goal.

Could you tell where is the place to discuss the design for this feature? 
Mailing list, IRC channel, weekly meeting or others?

I was involved in its spec review at https://review.openstack.org/#/c/574477/; 
but it has not been updated for a while.

Thanks,
Forrest

__
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] Ongoing spam in Freenode IRC channels

[Doug Hellmann]

Excerpts from Monty Taylor's message of 2018-08-01 09:58:03 -0500:
> On 08/01/2018 08:38 AM, Jeremy Stanley wrote:
> > On 2018-08-01 09:58:48 -0300 (-0300), Rafael Weingärtner wrote:
> >> What about Rocket chat instead of Slack? It is open source.
> >> https://github.com/RocketChat/Rocket.Chat
> >>
> >> Monty, what kind of evaluation would you guys need? I might be
> >> able to help.
> > 
> > Consider reading and possibly resurrecting the infra spec for it:
> > 
> >  https://review.openstack.org/319506
> > 
> > My main concern is how we'll go about authenticating and policing
> > whatever gateway we set up. As soon as spammers and other abusers
> > find out there's an open (or nearly so) proxy to a major IRC
> > network, they'll use it to hide their origins from the IRC server
> > operators and put us in the middle of the problem.
> 
> To be clear -- I was not suggesting running matrix and IRC. I was 
> suggesting investigating running a matrix home server and the 
> permanently moving all openstack channels to it.
> 
> matrix synapse supports federated identity providers with saml and cas 
> support implemented. I would imagine we'd want to configure it to 
> federate to openstackid for logging in to the home server -so that might 
> involve either adding saml support to openstackid or writing an 
> openid-connect driver to synapse.
> 

This matches my expectations. We did talk about supporting a temporary
bridge to IRC, during the migration, but I don't think we need to run an
"open" home server to have that.

Doug

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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Samuel Cassiba]

On Wed, Aug 1, 2018 at 5:21 AM, Andrey Kurilin  wrote:
> I can make an assumption that for marketing reasons, Slack Inc can propose
> extended Free plan.
> But anyway, even with default one the only thing which can limit us is
> `10,000 searchable messages` which is bigger than 0 (freenode doesn't store
> messages).
>
>
> Why I like slack? because a lot of people are familar with it (a lot of
> companies use it as like some opensource communities, like k8s )
>
> PS: I realize that OpenStack Community will never go away from Freenode and
> IRC, but I do not want to stay silent.
>

My response wasn't intended to become a wall of text, but my
individual experience dovetails with the ongoing thread. The intent
here is not to focus on one thing or the other, but to highlight some
of the strengths and drawbacks.

This is a great proposal on-paper. As you said, lots of people are
already familiar with the technology and concept at this point. It
generally seems to make sense.

The unfortunate reality is that with something that has N searchable
messages -- that counts for the whole instance -- it will be exceeded
within the first few days due to the initial surge, requiring
tweaking, if possible. Ten thousand messages is not much for a large,
distributed, culturally diverse group heavily entrenched in IRC, even
if it is a nice looking number. There should not be a limit on
recorded history such as that, lest it be forgotten every few months.

From a technological perspective, that puts both such a proposal and
the existing solution at direct odds. Having a proprietary third-party
be the gatekeepers to chat-based outlets is not a good prospect over
the long-term. For recorded history, eavesdrop, by far, exceeds that
imposed value, by sheer virtue of it existing.

In freemium offerings, much knowledge gets blown to the aether in
exchange for gifs and emoji reactions. In these situations, of course,
the users are, by default, the product. The long-term effects which
can have lasting effects on a large, multicultural, open source
project already under siege on certain fronts.

Production OpenStack deployments have usually hitched their wagon to
OpenStack: The Project for a multi-year effort at a minimum, which can
and tends to involve some level of activity in parts of the community
over that time. People come and go, but the long-term goals have
generally remained the same.

While the long-term ramifications of large FLOSS communities being on
freemium proprietary platforms are just beginning to be felt, they're
not quite to the point of inertia yet. Short of paying obscene amounts
of money for chat, FLOSS alternatives need to be championed, far above
any proprietary options with a free welcome mat, no matter how awesome
and feature-rich they may be.

Making a change of this order, this far in, is a drastic undertaking.
I've been witness and participant in a similar migration, which took
place a few years ago. It was heralded with much fanfare, a new day
for engagement. It was full-on party parrot, until it wasn't.

To this day, there are still IRC stragglers, with one or two
experienced -- sometimes self-appointed -- individuals that
tirelessly, asynchronously, answer softball questions and redirect to
the other outlets for the more involved.

Extended community channels, like development channels, are just kind
of left to rot, with a topic that says "Go over here >". There is
very little moderation, which develops a certain narrative all on its
own.

Today, that community on the free offering is quieter, more vibrant
and immediately knowledgeable, albeit at the expense of recorded
history. Questions take on a recurring theme at times, requiring
one-to-one or one-to-many engagement for every question. The person
wanting some fish tonight doesn't have a clean lake or stream to catch
their dinner.

Unfortunately, some of those long-term effects are beginning to be
felt as of recent, after "everyone" is off of IRC. Fewer long-term
maintainers are sticking around, and even fewer are stepping up to
replace them. On the upshot, there are more new users always finding
their way to the slick proprietary chat group.

-scas

__
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] How to debug no valid host failures with placement

[Chris Friesen]

On 08/01/2018 09:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources of your 
cloud.
This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10

And you can explore placement state with other commands like openstack resource
provider list, resource provider inventory list, resource provider usage show.



Unfortunately this doesn't help figure out what the missing resources were *at 
the time of the failure*.


The fact that there is no real way to get the equivalent of the old detailed 
scheduler logs is a known shortcoming in placement, and will become more of a 
problem if/when we move more complicated things like CPU pinning, hugepages, and 
NUMA-awareness into placement.


The problem is that getting useful logs out of placement would require 
significant development work.


Chris

__
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] Ongoing spam in Freenode IRC channels

[Monty Taylor]

On 08/01/2018 08:17 AM, Andrey Kurilin wrote:



ср, 1 авг. 2018 г. в 15:37, Monty Taylor >:


On 08/01/2018 06:22 AM, Luigi Toscano wrote:
 > On Wednesday, 1 August 2018 12:49:13 CEST Andrey Kurilin wrote:
 >> Hey Ian and stackers!
 >>
 >> ср, 1 авг. 2018 г. в 8:45, Ian Wienand mailto:iwien...@redhat.com>>:
 >>> Hello,
 >>>
 >>> It seems freenode is currently receiving a lot of unsolicited
traffic
 >>> across all channels.  The freenode team are aware [1] and doing
their
 >>> best.
 >>>
 >>> There are not really a lot of options.  We can set "+r" on channels
 >>> which means only nickserv registered users can join channels. 
We have

 >>> traditionally avoided this, because it is yet one more barrier to
 >>> communication when many are already unfamiliar with IRC access.
 >>> However, having channels filled with irrelevant messages is
also not
 >>> very accessible.
 >>>
 >>> This is temporarily enabled in #openstack-infra for the time
being, so
 >>> we can co-ordinate without interruption.
 >>>
 >>> Thankfully AFAIK we have not needed an abuse policy on this before;
 >>> but I guess we are the point we need some sort of coordinated
 >>> response.
 >>>
 >>> I'd suggest to start, people with an interest in a channel can
request
 >>> +r from an IRC admin in #openstack-infra and we track it at [2] >>>
 >>> Longer term ... suggestions welcome? :)
 >>
 >> Move to Slack? We can provide auto-sending to emails invitations for
 >> joining by clicking the button on some page at openstack.org
. It will not
 >> add more berrier for new contributors and, at the same time,
this way will
 >> give some base filtering by emails at least.

slack is pretty unworkable for many reasons. The biggest of them is
that
it is not Open Source and we don't require OpenStack developers to use
proprietary software to work on OpenStack.

The quality of slack that makes it effective at fighting spam is also
the quality that makes it toxic as a community platform - the need for
an invitation and being structured as silos.

Even if we were to decide to abandon our Open Source principles and
leave behind those in our contributor base who believe that Free
Software Needs Free Tools [1] - moving to slack would be a GIANT
undertaking. As such, it would not be a very effective way to deal with
this current spam storm.

 > No, please no. If we need to move to another service, better go
to a FLOSS
 > one, like Matrix.org, or others.

We had some discussion in Vancouver about investigating the use of
Matrix. We are a VERY large community, so we need to do scale and
viability testing before it's even a worthy topic to raise with the TC
and the community for consideration. If we did, we'd aim to run our own
home server.


The last paragraph is the best answer why we never switch from IRC.
"we are a VERY large community"

Looking back at migration to Zuul V3: the project which is written by 
folks who
know potencial high-load and usage, the project which has a great 
background.
Some issues appeared only after launching it in production. Fortunately, 
Zuul-community

quickly fixed them and we have this great CI system now.

As for the FOSS alternatives for the Slack aka modern IRC, I did not 
heard anything
scalable for the size we need. Also, in case of any issues, they will 
not be fixed as

quickly as it was with Zull V3 (thank you folks!).


Yes. This is an excellent point. In fact, just trying to figure out how 
to properly test that a different choice can handle the scale is ... 
very hard at best.


Another issue, the alternative should be popular, modern and usable. IRC 
is the thing which

is used by a lot of communities (i.e. you do not need to install some
no-name tool to communicate for one more topic), the same for Slack and 
I suppose
some other tools havethe same popularity (but I do not have installed 
versions of them).
If the alternative doesn't feet these criteria, a lot of people will 
stay at Freenode and migration will fail.


Yup. Totally agree.


However, it's worth noting that matrix is not immune to spam. As an
open
federated protocol, it's a target as well. Running our own home server
might give us some additional tools - but it might not, and we might be
in the same scenario except now we're running another service and we
had
the pain of moving.

All that to say though, matrix seems like the best potential option
available that meets the largest number of desires from our user base.
Once we've checked it out for viability it might be worth discussing.

As above, any effort there is a pretty giant one that will require a
large amount of planning, a pretty sizeable amount of technical
   

Re: [openstack-dev] [requirements][ffe] Critical bug found in python-cinderclient

[Matthew Thode]

On 18-07-31 15:50:42, Doug Hellmann wrote:
> Excerpts from Sean McGinnis's message of 2018-07-31 14:15:08 -0500:
> > A critical bug has been found in python-cinderclient that is impacting both
> > horizon and python-openstackclient (at least).
> > 
> > https://bugs.launchpad.net/cinder/+bug/1784703
> > 
> > tl;dr is, something new was added with a microversion, but support for that 
> > was
> > done incorrectly such that nothing less than that new microversion would be
> > allowed. This patch addresses the issue:
> > 
> > https://review.openstack.org/587601
> > 
> > Once that lands we will need a new python-cinderclient release to unbreak
> > clients. We may want to blacklist python-cinderclient 4.0.0, but I think at
> > least just raising the upper-constraints should get things working again.
> > 
> > Sean
> > 
> 
> Both adding the exclusion and changing the upper constraint makes sense,
> since it will ensure that bad version never makes it back into the
> constraints list.
> 
> We don't need to sync the exclusion setting into all of the projects
> that depend on the client, so we won't need a new release of any of the
> downstream consumers.
> 
> We could add the exclusion to OSC on master, just for accuracy's sake.
> 

Ya, it sounds like this is a valid FFE

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Andrey Volkov]

Hi,

It seems you need first to check what placement knows about resources of
your cloud.
This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10

And you can explore placement state with other commands like openstack
resource provider list, resource provider inventory list, resource provider
usage show.

[1] https://developer.openstack.org/api-ref/placement/
[2] https://docs.openstack.org/osc-placement/latest/index.html

On Wed, Aug 1, 2018 at 6:16 PM Ben Nemec  wrote:

> Hi,
>
> I'm having an issue with no valid host errors when starting instances
> and I'm struggling to figure out why.  I thought the problem was disk
> space, but I changed the disk_allocation_ratio and I'm still getting no
> valid host.  The host does have plenty of disk space free, so that
> shouldn't be a problem.
>
> However, I'm not even sure it's disk that's causing the failures because
> I can't find any information in the logs about why the no valid host is
> happening.  All I get from the scheduler is:
>
> "Got no allocation candidates from the Placement API. This may be a
> temporary occurrence as compute nodes start up and begin reporting
> inventory to the Placement service."
>
> While in placement I see:
>
> 2018-08-01 15:02:22.062 20 DEBUG nova.api.openstack.placement.requestlog
> [req-0a830ce9-e2af-413a-86cb-b47ae129b676
> fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
> default default] Starting request: 10.2.2.201 "GET
> /placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"
>
> __call__
>
> /usr/lib/python2.7/site-packages/nova/api/openstack/placement/requestlog.py:38
> 2018-08-01 15:02:22.103 20 INFO nova.api.openstack.placement.requestlog
> [req-0a830ce9-e2af-413a-86cb-b47ae129b676
> fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
> default default] 10.2.2.201 "GET
> /placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"
>
> status: 200 len: 53 microversion: 1.25
>
> Basically it just seems to be logging that it got a request, but there's
> no information about what it did with that request.
>
> So where do I go from here?  Is there somewhere else I can look to see
> why placement returned no candidates?
>
> Thanks.
>
> -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
>


-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.
__
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] [requirements][ffe] Critical bug found in python-cinderclient

[Ivan Kolodyazhny]

Hi,

I'm OK with this release both from Cinder and Horizon perspective.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Tue, Jul 31, 2018 at 10:50 PM, Doug Hellmann 
wrote:

> Excerpts from Sean McGinnis's message of 2018-07-31 14:15:08 -0500:
> > A critical bug has been found in python-cinderclient that is impacting
> both
> > horizon and python-openstackclient (at least).
> >
> > https://bugs.launchpad.net/cinder/+bug/1784703
> >
> > tl;dr is, something new was added with a microversion, but support for
> that was
> > done incorrectly such that nothing less than that new microversion would
> be
> > allowed. This patch addresses the issue:
> >
> > https://review.openstack.org/587601
> >
> > Once that lands we will need a new python-cinderclient release to unbreak
> > clients. We may want to blacklist python-cinderclient 4.0.0, but I think
> at
> > least just raising the upper-constraints should get things working again.
> >
> > Sean
> >
>
> Both adding the exclusion and changing the upper constraint makes sense,
> since it will ensure that bad version never makes it back into the
> constraints list.
>
> We don't need to sync the exclusion setting into all of the projects
> that depend on the client, so we won't need a new release of any of the
> downstream consumers.
>
> We could add the exclusion to OSC on master, just for accuracy's sake.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] Ongoing spam in Freenode IRC channels

[James E. Blair]

Monty Taylor  writes:

> On 08/01/2018 12:45 AM, Ian Wienand wrote:
>> Hello,
>> I'd suggest to start, people with an interest in a channel can request
>> +r from an IRC admin in #openstack-infra and we track it at [2]
>
> To mitigate the pain caused by +r - we have created a channel called
> #openstack-unregistered and have configured the channels with the +r
> flag to forward people to it. We have also set an entrymsg on
> #openstack-unregistered to:
>
> "Due to a prolonged SPAM attack on freenode, we had to configure
> OpenStack channels to require users to be registered. If you are here,
> you tried to join a channel without being logged in. Please see
> https://freenode.net/kb/answer/registration for instructions on
> registration with NickServ, and make sure you are logged in."
>
> So anyone attempting to join a channel with +r should get that message.

It turns out this was a very popular option, so we've gone ahead and
performed this for all channels registered with accessbot.  If you're in
a channel that still needs this, please add it to the accessbot channel
list[1] and let us know in #openstack-infra.

Also, if folks would be willing to lurk in #openstack-unregistered to
help anyone who ends up there by surprise and is unfamiliar with how to
register with nickserv, that would be great.

-Jim

[1] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/accessbot/channels.yaml

__
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] [oslo] proposing Moisés Guimarães for oslo.config core

[John Dennis]

On 08/01/2018 09:27 AM, Doug Hellmann wrote:

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.


+1


--
John Dennis

__
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] [horizon] PTL on vacation: what to do with meeting and RC1?

[Ivan Kolodyazhny]

Hi team,

I'll be on PTO next week. Are we OK to cancel the next meeting?

I remember that next week is a deadline for RC1, so I'm going to propose a
patch to release it
a bit later next week: Tuesday or Wednesday.

In an emergency case, please, reach me via e-mail because I'll have a
limited internet access
so I'll be mostly offline in IRC.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
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] How to debug no valid host failures with placement

[Ben Nemec]

Hi,

I'm having an issue with no valid host errors when starting instances 
and I'm struggling to figure out why.  I thought the problem was disk 
space, but I changed the disk_allocation_ratio and I'm still getting no 
valid host.  The host does have plenty of disk space free, so that 
shouldn't be a problem.


However, I'm not even sure it's disk that's causing the failures because 
I can't find any information in the logs about why the no valid host is 
happening.  All I get from the scheduler is:


"Got no allocation candidates from the Placement API. This may be a 
temporary occurrence as compute nodes start up and begin reporting 
inventory to the Placement service."


While in placement I see:

2018-08-01 15:02:22.062 20 DEBUG nova.api.openstack.placement.requestlog 
[req-0a830ce9-e2af-413a-86cb-b47ae129b676 
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e - 
default default] Starting request: 10.2.2.201 "GET 
/placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1" 
__call__ 
/usr/lib/python2.7/site-packages/nova/api/openstack/placement/requestlog.py:38
2018-08-01 15:02:22.103 20 INFO nova.api.openstack.placement.requestlog 
[req-0a830ce9-e2af-413a-86cb-b47ae129b676 
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e - 
default default] 10.2.2.201 "GET 
/placement/allocation_candidates?limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1" 
status: 200 len: 53 microversion: 1.25


Basically it just seems to be logging that it got a request, but there's 
no information about what it did with that request.


So where do I go from here?  Is there somewhere else I can look to see 
why placement returned no candidates?


Thanks.

-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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Anita Kuno]

On 2018-08-01 09:24 AM, Monty Taylor wrote:

On 08/01/2018 12:45 AM, Ian Wienand wrote:

Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2]


To mitigate the pain caused by +r - we have created a channel called 
#openstack-unregistered and have configured the channels with the +r 
flag to forward people to it. We have also set an entrymsg on 
#openstack-unregistered to:


"Due to a prolonged SPAM attack on freenode, we had to configure 
OpenStack channels to require users to be registered. If you are here, 
you tried to join a channel without being logged in. Please see 
https://freenode.net/kb/answer/registration for instructions on 
registration with NickServ, and make sure you are logged in."


So anyone attempting to join a channel with +r should get that message.


I can confirm this worked for me as advertised with my nick unregistered.

Thank you,
Anita



__
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] Ongoing spam in Freenode IRC channels

[Monty Taylor]

On 08/01/2018 08:38 AM, Jeremy Stanley wrote:

On 2018-08-01 09:58:48 -0300 (-0300), Rafael Weingärtner wrote:

What about Rocket chat instead of Slack? It is open source.
https://github.com/RocketChat/Rocket.Chat

Monty, what kind of evaluation would you guys need? I might be
able to help.


Consider reading and possibly resurrecting the infra spec for it:

 https://review.openstack.org/319506

My main concern is how we'll go about authenticating and policing
whatever gateway we set up. As soon as spammers and other abusers
find out there's an open (or nearly so) proxy to a major IRC
network, they'll use it to hide their origins from the IRC server
operators and put us in the middle of the problem.


To be clear -- I was not suggesting running matrix and IRC. I was 
suggesting investigating running a matrix home server and the 
permanently moving all openstack channels to it.


matrix synapse supports federated identity providers with saml and cas 
support implemented. I would imagine we'd want to configure it to 
federate to openstackid for logging in to the home server -so that might 
involve either adding saml support to openstackid or writing an 
openid-connect driver to synapse.


__
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] [oslo] proposing Moisés Guimarães for oslo.config core

[Raildo Mascena de Sousa Filho]

+1

On Wed, Aug 1, 2018 at 11:49 AM Ben Nemec  wrote:

> +1
>
> On 08/01/2018 08:27 AM, Doug Hellmann wrote:
> > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> > during the Rocky cycle to add driver support. Based on that work,
> > and a discussion we have had since then about general cleanup needed
> > in oslo.config, I think he would make a good addition to the
> > oslo.config review team.
> >
> > Please indicate your approval or concerns with +1/-1.
> >
> > Doug
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack 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
>
-- 

Raildo mascena

Software Engineer, Identity Managment

Red Hat



TRIED. TESTED. TRUSTED. 
__
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] [oslo] proposing Moisés Guimarães for oslo.config core

[Ben Nemec]

+1

On 08/01/2018 08:27 AM, Doug Hellmann wrote:

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

Doug

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



__
OpenStack 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] [oslo] proposing Moisés Guimarães for oslo.config core

[Davanum Srinivas]

+1 from me!
On Wed, Aug 1, 2018 at 6:27 AM Doug Hellmann  wrote:
>
> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
>
> Please indicate your approval or concerns with +1/-1.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core

[Juan Antonio Osorio]

Yeah! +1 Moisés has been doing a great job there

On Wed, 1 Aug 2018, 16:27 Doug Hellmann,  wrote:

> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
>
> Please indicate your approval or concerns with +1/-1.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [cinder] about block device driver

[John Griffith]

On Fri, Jul 27, 2018 at 8:44 AM Matt Riedemann  wrote:

> On 7/16/2018 4:20 AM, Gorka Eguileor wrote:
> > If I remember correctly the driver was deprecated because it had no
> > maintainer or CI.  In Cinder we require our drivers to have both,
> > otherwise we can't guarantee that they actually work or that anyone will
> > fix it if it gets broken.
>
> Would this really require 3rd party CI if it's just local block storage
> on the compute node (in devstack)? We could do that with an upstream CI
> job right? We already have upstream CI jobs for things like rbd and nfs.
> The 3rd party CI requirements generally are for proprietary storage
> backends.
>
> I'm only asking about the CI side of this, the other notes from Sean
> about tweaking the LVM volume backend and feature parity are good
> reasons for removal of the unmaintained driver.
>
> Another option is using the nova + libvirt + lvm image backend for local
> (to the VM) ephemeral disk:
>
>
> https://github.com/openstack/nova/blob/6be7f7248fb1c2bbb890a0a48a424e205e173c9c/nova/virt/libvirt/imagebackend.py#L653
>
> --
>
> 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


We've had this conversation multiple times, here were the results from past
conversations and the reasons we deprecated:
1. Driver was not being tested at all (no CI, no upstream tests etc)
2. We sent out numerous requests trying to determine if anybody was using
the driver, didn't receive much feedback
3. The driver didn't work for an entire release, this indicated that
perhaps it wasn't that valuable
4. The driver is unable to implement a number of the required features for
a Cinder Block Device
5. Digging deeper into performance tests most comparisons were doing things
like
a. Using the shared single nic that's used for all of the cluster
communications (ie DB, APIs, Rabbit etc)
b. Misconfigured deployment, ie using a 1Gig Nic for iSCSI connections
(also see above)

The decision was that raw-block was not by definition a "Cinder Device",
and given that it wasn't really tested or
maintained that it should be removed.  LVM is actually quite good, we did
some pretty extensive testing and even
presented it as a session in Barcelona that showed perf within
approximately 10%.  I'm skeptical any time I see
dramatic comparisons of 1/2 performance, but I could be completely wrong.

I would be much more interested in putting efforts towards trying to figure
out why you have such a large perf
delta and see if we can address that as opposed to trying to bring back and
maintain a driver that only half
works.

Or as Jay Pipes mentioned, don't use Cinder in your case.

Thanks,
John
__
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] August bug day tomorrow! (August 2nd 13:00 UTC to 14:00 UTC)

[Michael Turek]

Hey all,

Welcome to August! Tomorrow is the first Thursday of the month so bug 
day is once again upon us. For details please see the etherpad [0].


If you have ideas for how we can improve Bug Day, or how the agenda 
should be structured, let me know! I hope to see you there tomorrow


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-2018


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

Re: [openstack-dev] [neutron] Credentials for a Keystone DB lookup from Neutron

[Neil Jerram]

Hoping I can leverage the wisdom of the ML for a follow-up point on this
topic...

I've coded this up now following Aditya's suggestion, but the issue now is
about the Neutron user (or more generally, whatever is configured in
neutron.conf's [keystone_authtoken] section) being authorized to do a
keystone.projects.list().

IIUC that is considered to be an admin operation, and the Neutron user is
not normally authorized to do it.  However, it seems reasonable to me that
the operator of a particular deployment can choose to allow that if they
want to, and I see two approaches to doing that:

1. Add the "admin" role to the "neutron" user.  I have code for this that
seems to work, and append it below for interest and review [1].

2. Modify Keystone's RBAC specifically to allow "neutron" to do
"get_projects".  I don't yet know how to do this, though.

My questions are:  Am I in the right ballpark here?  Are there any other
approaches to allowing this access, ideally as specifically as possible?
And in case (2) is the preferred approach, can you point me to how to
modify that RBAC?

Many thanks,
 Neil


[1] Apparently working code for adding the "admin" role to the "neutron"
user:

# Admin client setup:
>>> auth_url="http://controller:35357/v3";
>>> name = "admin"
>>> password = "abcdef"
>>> from keystoneauth1 import identity
>>> auth = identity.Password(auth_url=auth_url,
...  username=name,
...  password=password,
...  project_name=name,
...  project_domain_id="default",
...  user_domain_id="default")
>>> from keystoneauth1 import session
>>> session = session.Session(auth=auth)
>>> from keystoneclient.v3.client import Client as KeystoneClient
>>> keystone_client = KeystoneClient(session=session)

# Identify which role is the "admin" one:
>>> roles=keystone_client.roles.list()
>>> roles[0]
http://controller:35357/v3/roles/9fe2ff9ee4384b1894a90878d3e92bab'},
name=_member_>
>>> roles[1]
http://controller:35357/v3/roles/d0a84ecdad284fecb9b215126b5fbe05'},
name=admin>

# Identify which project is the "service" one:
>>> projects=keystone_client.projects.list()
>>> projects[0]
http://controller:35357/v3/projects/6274ae6b92634389a4a5eda4093035c3'},
name=admin, parent_id=default, tags=[]>
>>> projects[1]
http://controller:35357/v3/projects/7837dbe6b5294ce89342dec823fea106'},
name=service, parent_id=default, tags=[]>

# Identify which user is the "neutron" one:
>>> users=keystone_client.users.list()
>>> users[0]
http://controller:35357/v3/users/113dc98e751d4720b4573044df6eb870'},
name=neutron, options={}, password_expires_at=None>

# Grant "admin" role to "neutron":
>>> keystone_client.roles.grant(roles[1], user=users[0],
project=projects[1])

# And to revoke that again:
>>> keystone_client.roles.revoke(roles[1], user=users[0],
project=projects[1])




On Tue, Jul 17, 2018 at 7:17 PM Neil Jerram  wrote:

> Thanks Aditya, that looks like just what I need.
>
> Best wishes,
> Neil
>
>
> On Tue, Jul 17, 2018 at 5:48 PM Aditya Vaja 
> wrote:
>
>> hey neil,
>>
>> neutron.conf has a section called '[keystone_authtoken]’ which has
>> credentials to query keystone as neutron. you can read the config as you’d
>> typically do from the mechanism driver for any other property using
>> oslo.config.
>>
>> you could then use python-keystoneclient with those creds to query the
>> mapping. a sample is given in the keystoneclient repo [1].
>>
>> via telegram
>>
>> [1]
>> https://github.com/openstack/python-keystoneclient/blob/650716d0dd30a73ccabe3f0ec20eb722ca0d70d4/keystoneclient/v3/client.py#L102-L116
>> On Tue, Jul 17, 2018 at 9:58 PM, Neil Jerram  wrote:
>>
>> On Tue, Jul 17, 2018 at 3:55 PM Jay Pipes  wrote:
>>
>>> On 07/17/2018 03:36 AM, Neil Jerram wrote:
>>> > Can someone help me with how to look up a project name (aka tenant
>>> name)
>>> > for a known project/tenant ID, from code (specifically a mechanism
>>> > driver) running in the Neutron server?
>>> >
>>> > I believe that means I need to make a GET REST call as here:
>>> >
>>> https://developer.openstack.org/api-ref/identity/v3/index.html#projects.
>>> But
>>> > I don't yet understand how a piece of Neutron server code can ensure
>>> > that it has the right credentials to do that. If someone happens to
>>> > have actual code for doing this, I'm sure that would be very helpful.
>>> >
>>> > (I'm aware that whenever the Neutron server processes an API request,
>>> > the project name for the project that generated that request is added
>>> > into the request context. That is great when my code is running in an
>>> > API request context. But there are other times when the code isn't in
>>> a
>>> > request context and still needs to map from a project ID to project
>>> > name; hence the question here.)
>>>
>>> Hi Neil,
>>>
>>> You basically answered your own question above :) The neutron request
>>> context gets built from oslo.context's Context.from_envi

Re: [openstack-dev] [tripleo][ci][metrics] Stucked in the middle of work because of RDO CI

[Ben Nemec]

On 07/31/2018 04:51 PM, Wesley Hayutin wrote:



On Tue, Jul 31, 2018 at 7:41 AM Sagi Shnaidman > wrote:


Hi, Martin

I see master OVB jobs are passing now [1], please recheck.

[1] http://cistatus.tripleo.org/


Things have improved and I see a lot of jobs passing however at the same 
time I see too many jobs failing due to node_failures.  We are tracking 
the data from [1].  Certainly the issue is NOT ideal for development and 
we need to remain focused on improving the situation.


I assume you're aware, but just to update the thread it looks like the 
OVB jobs are failing at a 50%+ rate again today (mostly unknown failures 
according to the tracking app).  Even with only two jobs that means your 
odds of getting them both to pass are pretty bad.




Thanks

[1] https://softwarefactory-project.io/zuul/api/tenant/rdoproject.org/builds



On Tue, Jul 31, 2018 at 12:24 PM, Martin Magr mailto:mm...@redhat.com>> wrote:

Greetings guys,

   it is pretty obvious that RDO CI jobs in TripleO projects are
broken [0]. Once Zuul CI jobs will pass would it be possible to
have AMQP/collectd patches ([1],[2],[3]) merged please even
though the negative result of RDO CI jobs? Half of the patches
for this feature is merged and the other half is stucked in this
situation, were nobody reviews these patches, because there is
red -1. Those patches passed Zuul jobs several times already and
were manually tested too.

Thanks in advance for consideration of this situation,
Martin

[0]

https://trello.com/c/hkvfxAdX/667-cixtripleoci-rdo-software-factory-3rd-party-jobs-failing-due-to-instance-nodefailure
[1] https://review.openstack.org/#/c/578749
[2] https://review.openstack.org/#/c/576057/
[3] https://review.openstack.org/#/c/572312/

-- 
Martin Mágr

Senior Software Engineer
Red Hat Czech


__
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

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

--

Wes Hayutin

Associate MANAGER

Red Hat



w hayu...@redhat.com 
  T: +1919 4232509     IRC: 
weshay





Viewmycalendar and check my availability for meetings HERE 




__
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] [oslo] proposing Moisés Guimarães for oslo.config core

[Harry Rybacki]

On Wed, Aug 1, 2018 at 9:28 AM Doug Hellmann  wrote:
>
> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
>
> Please indicate your approval or concerns with +1/-1.
>
+1!

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

__
OpenStack 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] Ongoing spam in Freenode IRC channels

[Thierry Carrez]

Monty Taylor wrote:

[...]
However, it's worth noting that matrix is not immune to spam. As an open 
federated protocol, it's a target as well. Running our own home server 
might give us some additional tools - but it might not, and we might be 
in the same scenario except now we're running another service and we had 
the pain of moving.

[...]


Any open communication platform is subject to spam. As long as you let 
anonymous users join and post stuff, it will happen as soon as the 
platform reaches a certain critical mass. Slack is not immune to this: 
it has spam too, and the platform being outside of your control 
limits[1] your options.


Freenode/IRC is a bit bad because it does not make it easy to /deal/ 
with spam. The protocol being designed at a time where it was costly to 
switch IPs, you can ignore people/hosts, but not messages based on key 
words. As we look into alternatives, we should evaluate their 
spam-filtering abilities...


[1] 
https://www.reddit.com/r/Slack/comments/71bd1h/need_help_preventing_pm_spam/


--
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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Jeremy Stanley]

On 2018-08-01 16:17:47 +0300 (+0300), Andrey Kurilin wrote:
[...]
> If the alternative doesn't feet these criteria, a lot of people
> will stay at Freenode and migration will fail.
[...]

We've had discussions off and on for years about moving from
Freenode to OFTC (whose ideals more closely reflect those of our
community), but even with that our biggest fear was disruption and
fracturing with some people holding conversations in one network and
some in the other.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Jeremy Stanley]

On 2018-08-01 09:58:48 -0300 (-0300), Rafael Weingärtner wrote:
> What about Rocket chat instead of Slack? It is open source.
> https://github.com/RocketChat/Rocket.Chat
> 
> Monty, what kind of evaluation would you guys need? I might be
> able to help.

Consider reading and possibly resurrecting the infra spec for it:

https://review.openstack.org/319506

My main concern is how we'll go about authenticating and policing
whatever gateway we set up. As soon as spammers and other abusers
find out there's an open (or nearly so) proxy to a major IRC
network, they'll use it to hide their origins from the IRC server
operators and put us in the middle of the problem.
-- 
Jeremy Stanley


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] [oslo] proposing Moisés Guimarães for oslo.config core

[Doug Hellmann]

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

Doug

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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Monty Taylor]

On 08/01/2018 12:45 AM, Ian Wienand wrote:

Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2]


To mitigate the pain caused by +r - we have created a channel called 
#openstack-unregistered and have configured the channels with the +r 
flag to forward people to it. We have also set an entrymsg on 
#openstack-unregistered to:


"Due to a prolonged SPAM attack on freenode, we had to configure 
OpenStack channels to require users to be registered. If you are here, 
you tried to join a channel without being logged in. Please see 
https://freenode.net/kb/answer/registration for instructions on 
registration with NickServ, and make sure you are logged in."


So anyone attempting to join a channel with +r should get that message.

__
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] Ongoing spam in Freenode IRC channels

[Andrey Kurilin]

ср, 1 авг. 2018 г. в 15:37, Monty Taylor :

> On 08/01/2018 06:22 AM, Luigi Toscano wrote:
> > On Wednesday, 1 August 2018 12:49:13 CEST Andrey Kurilin wrote:
> >> Hey Ian and stackers!
> >>
> >> ср, 1 авг. 2018 г. в 8:45, Ian Wienand :
> >>> Hello,
> >>>
> >>> It seems freenode is currently receiving a lot of unsolicited traffic
> >>> across all channels.  The freenode team are aware [1] and doing their
> >>> best.
> >>>
> >>> There are not really a lot of options.  We can set "+r" on channels
> >>> which means only nickserv registered users can join channels.  We have
> >>> traditionally avoided this, because it is yet one more barrier to
> >>> communication when many are already unfamiliar with IRC access.
> >>> However, having channels filled with irrelevant messages is also not
> >>> very accessible.
> >>>
> >>> This is temporarily enabled in #openstack-infra for the time being, so
> >>> we can co-ordinate without interruption.
> >>>
> >>> Thankfully AFAIK we have not needed an abuse policy on this before;
> >>> but I guess we are the point we need some sort of coordinated
> >>> response.
> >>>
> >>> I'd suggest to start, people with an interest in a channel can request
> >>> +r from an IRC admin in #openstack-infra and we track it at [2] >>>
> >>> Longer term ... suggestions welcome? :)
> >>
> >> Move to Slack? We can provide auto-sending to emails invitations for
> >> joining by clicking the button on some page at openstack.org. It will
> not
> >> add more berrier for new contributors and, at the same time, this way
> will
> >> give some base filtering by emails at least.
>
> slack is pretty unworkable for many reasons. The biggest of them is that
> it is not Open Source and we don't require OpenStack developers to use
> proprietary software to work on OpenStack.
>
> The quality of slack that makes it effective at fighting spam is also
> the quality that makes it toxic as a community platform - the need for
> an invitation and being structured as silos.
>
> Even if we were to decide to abandon our Open Source principles and
> leave behind those in our contributor base who believe that Free
> Software Needs Free Tools [1] - moving to slack would be a GIANT
> undertaking. As such, it would not be a very effective way to deal with
> this current spam storm.
>
> > No, please no. If we need to move to another service, better go to a
> FLOSS
> > one, like Matrix.org, or others.
>
> We had some discussion in Vancouver about investigating the use of
> Matrix. We are a VERY large community, so we need to do scale and
> viability testing before it's even a worthy topic to raise with the TC
> and the community for consideration. If we did, we'd aim to run our own
> home server.
>

The last paragraph is the best answer why we never switch from IRC.
"we are a VERY large community"

Looking back at migration to Zuul V3: the project which is written by folks
who
know potencial high-load and usage, the project which has a great
background.
Some issues appeared only after launching it in production. Fortunately,
Zuul-community
quickly fixed them and we have this great CI system now.

As for the FOSS alternatives for the Slack aka modern IRC, I did not heard
anything
scalable for the size we need. Also, in case of any issues, they will not
be fixed as
quickly as it was with Zull V3 (thank you folks!).

Another issue, the alternative should be popular, modern and usable. IRC is
the thing which
is used by a lot of communities (i.e. you do not need to install some
no-name tool to communicate for one more topic), the same for Slack and I
suppose
some other tools havethe same popularity (but I do not have installed
versions of them).
If the alternative doesn't feet these criteria, a lot of people will stay
at Freenode and migration will fail.


> However, it's worth noting that matrix is not immune to spam. As an open
> federated protocol, it's a target as well. Running our own home server
> might give us some additional tools - but it might not, and we might be
> in the same scenario except now we're running another service and we had
> the pain of moving.
>
> All that to say though, matrix seems like the best potential option
> available that meets the largest number of desires from our user base.
> Once we've checked it out for viability it might be worth discussing.
>
> As above, any effort there is a pretty giant one that will require a
> large amount of planning, a pretty sizeable amount of technical
> preparation and would be disruptive at the least, I don't think that'll
> help us with the current spam storm though.
>
> Monty
>
> [1] https://mako.cc/writing/hill-free_tools.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
>


-- 
Best regards,
Andrey Kurilin.
_

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Rafael Weingärtner]

What about Rocket chat instead of Slack? It is open source.
https://github.com/RocketChat/Rocket.Chat

Monty, what kind of evaluation would you guys need? I might be able to help.


On Wed, Aug 1, 2018 at 9:54 AM, Monty Taylor  wrote:

> On 08/01/2018 07:44 AM, Doug Hellmann wrote:
>
>> Excerpts from Andrey Kurilin's message of 2018-08-01 15:21:37 +0300:
>>
>>> ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur :
>>>
>>> On 08/01/2018 12:49 PM, Andrey Kurilin wrote:

> Hey Ian and stackers!
>
> ср, 1 авг. 2018 г. в 8:45, Ian Wienand  >:
>
>  Hello,
>
>  It seems freenode is currently receiving a lot of unsolicited
> traffic
>  across all channels.  The freenode team are aware [1] and doing
> their
>  best.
>
>  There are not really a lot of options.  We can set "+r" on
> channels
>  which means only nickserv registered users can join channels.  We
>
 have

>  traditionally avoided this, because it is yet one more barrier to
>  communication when many are already unfamiliar with IRC access.
>  However, having channels filled with irrelevant messages is also
> not
>  very accessible.
>
>  This is temporarily enabled in #openstack-infra for the time
> being,
>
 so

>  we can co-ordinate without interruption.
>
>  Thankfully AFAIK we have not needed an abuse policy on this
> before;
>  but I guess we are the point we need some sort of coordinated
>  response.
>
>  I'd suggest to start, people with an interest in a channel can
>
 request

>  +r from an IRC admin in #openstack-infra and we track it at [2]
>
>  Longer term ... suggestions welcome? :)
>
>
> Move to Slack? We can provide auto-sending to emails invitations for
>
 joining by

> clicking the button on some page at openstack.org <
> http://openstack.org>.
>
 It

> will not add more berrier for new contributors and, at the same time,
>
 this way

> will give some base filtering by emails at least.
>

 A few potential barriers with slack or similar solutions: lack of FOSS
 desktop
 clients (correct me if I'm wrong),

>>>
>>>
>>> The second link from google search gives an opensource client written in
>>> python https://github.com/raelgc/scudcloud . Also, there is something
>>> which
>>> is written in golang.
>>>
>>> complete lack of any console clients (ditto),


>>> Again, google gives several ones as first results -
>>> https://github.com/evanyeung/terminal-slack
>>> https://github.com/erroneousboat/slack-term
>>>
>>> serious limits on free (as in beer) tariff plans.
>>>


 I can make an assumption that for marketing reasons, Slack Inc can
>>> propose
>>> extended Free plan.
>>> But anyway, even with default one the only thing which can limit us is
>>> `10,000 searchable messages` which is bigger than 0 (freenode doesn't
>>> store
>>> messages).
>>>
>>>
>>> Why I like slack? because a lot of people are familar with it (a lot of
>>> companies use it as like some opensource communities, like k8s )
>>>
>>> PS: I realize that OpenStack Community will never go away from Freenode
>>> and
>>> IRC, but I do not want to stay silent.
>>>
>>
>> We are unlikely to select slack because the platform itself is
>> proprietary, even if there are OSS clients. That said, there have
>> been some discussions about platforms such as Matrix, which is
>> similar to slack and also OSS.
>>
>> I think the main thing that is blocking any such move right now is
>> the fact that we're lacking someone with time to evaluate the tool
>> to see what it would take for us to run it. If you're interested in
>> this, maybe you can work with the infrastructure team to plan and
>> implement that evaluation?
>>
>
> In Vancouver I signed up to work on this - but so far it has been lower in
> priority than other tasks. I'll circle around with people today and see
> what we think about relative priorities.
>
> That said - Doug's invitation is quite valid - help would be welcome and
> I'd be happy to connect with someone who has time to help with this.
>
>
> __
> 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
>



-- 
Rafael Weingärtner
__
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] Ongoing spam in Freenode IRC channels

[Monty Taylor]

On 08/01/2018 07:44 AM, Doug Hellmann wrote:

Excerpts from Andrey Kurilin's message of 2018-08-01 15:21:37 +0300:

ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur :


On 08/01/2018 12:49 PM, Andrey Kurilin wrote:

Hey Ian and stackers!

ср, 1 авг. 2018 г. в 8:45, Ian Wienand mailto:iwien...@redhat.com>>:

 Hello,

 It seems freenode is currently receiving a lot of unsolicited traffic
 across all channels.  The freenode team are aware [1] and doing their
 best.

 There are not really a lot of options.  We can set "+r" on channels
 which means only nickserv registered users can join channels.  We

have

 traditionally avoided this, because it is yet one more barrier to
 communication when many are already unfamiliar with IRC access.
 However, having channels filled with irrelevant messages is also not
 very accessible.

 This is temporarily enabled in #openstack-infra for the time being,

so

 we can co-ordinate without interruption.

 Thankfully AFAIK we have not needed an abuse policy on this before;
 but I guess we are the point we need some sort of coordinated
 response.

 I'd suggest to start, people with an interest in a channel can

request

 +r from an IRC admin in #openstack-infra and we track it at [2]

 Longer term ... suggestions welcome? :)


Move to Slack? We can provide auto-sending to emails invitations for

joining by

clicking the button on some page at openstack.org .

It

will not add more berrier for new contributors and, at the same time,

this way

will give some base filtering by emails at least.


A few potential barriers with slack or similar solutions: lack of FOSS
desktop
clients (correct me if I'm wrong),



The second link from google search gives an opensource client written in
python https://github.com/raelgc/scudcloud . Also, there is something which
is written in golang.


complete lack of any console clients (ditto),



Again, google gives several ones as first results -
https://github.com/evanyeung/terminal-slack
https://github.com/erroneousboat/slack-term

serious limits on free (as in beer) tariff plans.




I can make an assumption that for marketing reasons, Slack Inc can propose
extended Free plan.
But anyway, even with default one the only thing which can limit us is
`10,000 searchable messages` which is bigger than 0 (freenode doesn't store
messages).


Why I like slack? because a lot of people are familar with it (a lot of
companies use it as like some opensource communities, like k8s )

PS: I realize that OpenStack Community will never go away from Freenode and
IRC, but I do not want to stay silent.


We are unlikely to select slack because the platform itself is
proprietary, even if there are OSS clients. That said, there have
been some discussions about platforms such as Matrix, which is
similar to slack and also OSS.

I think the main thing that is blocking any such move right now is
the fact that we're lacking someone with time to evaluate the tool
to see what it would take for us to run it. If you're interested in
this, maybe you can work with the infrastructure team to plan and
implement that evaluation?


In Vancouver I signed up to work on this - but so far it has been lower 
in priority than other tasks. I'll circle around with people today and 
see what we think about relative priorities.


That said - Doug's invitation is quite valid - help would be welcome and 
I'd be happy to connect with someone who has time to help with this.


__
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] Ongoing spam in Freenode IRC channels

[Graham Hayes]

On 01/08/2018 13:21, Andrey Kurilin wrote:
> 



> 
> The second link from google search gives an opensource client written in
> python https://github.com/raelgc/scudcloud . Also, there is something
> which is written in golang.
>  
> 
> complete lack of any console clients (ditto),
> 
> 
> Again, google gives several ones as first results -
> https://github.com/evanyeung/terminal-slack
> https://github.com/erroneousboat/slack-term
> 



Any unoffical slack client needs to use "Legacy Tokens"[1]

> You're reading this because you're looking for info on legacy
> custom integrations - an outdated way for teams to integrate with
> Slack. These integrations lack newer features and they will be
> deprecated and possibly removed in the future. *We do not recommend
> their use.*

Legacy tokens can go away (just like the XMPP and IRC gateway did) at
any point, and we will be back in the same situation.

1 - https://api.slack.com/custom-integrations/legacy-tokens



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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Dmitry Tantsur]

On 08/01/2018 02:21 PM, Andrey Kurilin wrote:



ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur >:


On 08/01/2018 12:49 PM, Andrey Kurilin wrote:
 > Hey Ian and stackers!
 >
 > ср, 1 авг. 2018 г. в 8:45, Ian Wienand mailto:iwien...@redhat.com>
 > >>:
 >
 >     Hello,
 >
 >     It seems freenode is currently receiving a lot of unsolicited traffic
 >     across all channels.  The freenode team are aware [1] and doing their
 >     best.
 >
 >     There are not really a lot of options.  We can set "+r" on channels
 >     which means only nickserv registered users can join channels.  We 
have
 >     traditionally avoided this, because it is yet one more barrier to
 >     communication when many are already unfamiliar with IRC access.
 >     However, having channels filled with irrelevant messages is also not
 >     very accessible.
 >
 >     This is temporarily enabled in #openstack-infra for the time being, 
so
 >     we can co-ordinate without interruption.
 >
 >     Thankfully AFAIK we have not needed an abuse policy on this before;
 >     but I guess we are the point we need some sort of coordinated
 >     response.
 >
 >     I'd suggest to start, people with an interest in a channel can 
request
 >     +r from an IRC admin in #openstack-infra and we track it at [2]
 >
 >     Longer term ... suggestions welcome? :)
 >
 >
 > Move to Slack? We can provide auto-sending to emails invitations for
joining by
 > clicking the button on some page at openstack.org 
. It
 > will not add more berrier for new contributors and, at the same time,
this way
 > will give some base filtering by emails at least.

A few potential barriers with slack or similar solutions: lack of FOSS 
desktop
clients (correct me if I'm wrong), 



The second link from google search gives an opensource client written in python 
https://github.com/raelgc/scudcloud . Also, there is something which is written 
in golang.


The bad thing about non-official clients is that they come and go. An even worse 
thing is that Slack can (in theory) prevent them from operating or make it 
illegal (remember ICQ's attempts to ban unofficial clients?).


And I agree with Doug that non-free server part can be an issue as well. As the 
very least, we end being locked into their service.




complete lack of any console clients (ditto),


Again, google gives several ones as first results - 
https://github.com/evanyeung/terminal-slack 
https://github.com/erroneousboat/slack-term


Okay, I stand corrected here.



serious limits on free (as in beer) tariff plans.


I can make an assumption that for marketing reasons, Slack Inc can propose 
extended Free plan.


Are there precedents of them doing such a thing? Otherwise I would not count on 
it. Especially if they don't commit to providing it for free forever.


But anyway, even with default one the only thing which can limit us is `10,000 
searchable messages` which is bigger than 0 (freenode doesn't store messages).


Well, my IRC bouncer has messages for years :) I understand it's not a 
comparable solution, but I do have a way to find a message that happened a year 
ago. Not with slack.




Why I like slack? because a lot of people are familar with it (a lot of 
companies use it as like some opensource communities, like k8s )


PS: I realize that OpenStack Community will never go away from Freenode and IRC, 
but I do not want to stay silent.


I'd not mind at all to move to a more modern *FOSS* system. If we consider 
paying for Slack, we can consider hosting Matrix/Rocket/whatever as well.


Dmitry



 >
 >     -i
 >
 >     [1] https://freenode.net/news/spambot-attack
 >     [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018
 >
 >   
  __

 >     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,
 > Andrey Kurilin.
 >
 >
 > 
__
 > 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] Proposing Lukas Bezdicka core on TripleO

[Michele Baldessari]

+1 
On Wed, Aug 01, 2018 at 01:31:40PM +0200, Giulio Fidente wrote:
> Hi,
> 
> I would like to propose Lukas Bezdicka core on TripleO.
> 
> Lukas did a lot work in our tripleoclient, tripleo-common and
> tripleo-heat-templates repos to make FFU possible.
> 
> FFU, which is meant to permit upgrades from Newton to Queens, requires
> in depth understanding of many TripleO components (for example Heat,
> Mistral and the TripleO client) but also of specific TripleO features
> which were added during the course of the three releases (for example
> config-download and upgrade tasks). I believe his FFU work to have been
> very challenging.
> 
> Given his broad understanding, more recently Lukas started helping doing
> reviews in other areas.
> 
> I am so sure he'll be a great addition to our group that I am not even
> looking for comments, just votes :D
> -- 
> Giulio Fidente
> GPG KEY: 08D733BA
> 
> __
> 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

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] Ongoing spam in Freenode IRC channels

[Doug Hellmann]

Excerpts from Andrey Kurilin's message of 2018-08-01 15:21:37 +0300:
> ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur :
> 
> > On 08/01/2018 12:49 PM, Andrey Kurilin wrote:
> > > Hey Ian and stackers!
> > >
> > > ср, 1 авг. 2018 г. в 8:45, Ian Wienand  > > >:
> > >
> > > Hello,
> > >
> > > It seems freenode is currently receiving a lot of unsolicited traffic
> > > across all channels.  The freenode team are aware [1] and doing their
> > > best.
> > >
> > > There are not really a lot of options.  We can set "+r" on channels
> > > which means only nickserv registered users can join channels.  We
> > have
> > > traditionally avoided this, because it is yet one more barrier to
> > > communication when many are already unfamiliar with IRC access.
> > > However, having channels filled with irrelevant messages is also not
> > > very accessible.
> > >
> > > This is temporarily enabled in #openstack-infra for the time being,
> > so
> > > we can co-ordinate without interruption.
> > >
> > > Thankfully AFAIK we have not needed an abuse policy on this before;
> > > but I guess we are the point we need some sort of coordinated
> > > response.
> > >
> > > I'd suggest to start, people with an interest in a channel can
> > request
> > > +r from an IRC admin in #openstack-infra and we track it at [2]
> > >
> > > Longer term ... suggestions welcome? :)
> > >
> > >
> > > Move to Slack? We can provide auto-sending to emails invitations for
> > joining by
> > > clicking the button on some page at openstack.org .
> > It
> > > will not add more berrier for new contributors and, at the same time,
> > this way
> > > will give some base filtering by emails at least.
> >
> > A few potential barriers with slack or similar solutions: lack of FOSS
> > desktop
> > clients (correct me if I'm wrong),
> 
> 
> The second link from google search gives an opensource client written in
> python https://github.com/raelgc/scudcloud . Also, there is something which
> is written in golang.
> 
> > complete lack of any console clients (ditto),
> >
> 
> Again, google gives several ones as first results -
> https://github.com/evanyeung/terminal-slack
> https://github.com/erroneousboat/slack-term
> 
> serious limits on free (as in beer) tariff plans.
> >
> >
> I can make an assumption that for marketing reasons, Slack Inc can propose
> extended Free plan.
> But anyway, even with default one the only thing which can limit us is
> `10,000 searchable messages` which is bigger than 0 (freenode doesn't store
> messages).
> 
> 
> Why I like slack? because a lot of people are familar with it (a lot of
> companies use it as like some opensource communities, like k8s )
> 
> PS: I realize that OpenStack Community will never go away from Freenode and
> IRC, but I do not want to stay silent.

We are unlikely to select slack because the platform itself is
proprietary, even if there are OSS clients. That said, there have
been some discussions about platforms such as Matrix, which is
similar to slack and also OSS.

I think the main thing that is blocking any such move right now is
the fact that we're lacking someone with time to evaluate the tool
to see what it would take for us to run it. If you're interested in
this, maybe you can work with the infrastructure team to plan and
implement that evaluation?

Doug

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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Monty Taylor]

On 08/01/2018 06:22 AM, Luigi Toscano wrote:

On Wednesday, 1 August 2018 12:49:13 CEST Andrey Kurilin wrote:

Hey Ian and stackers!

ср, 1 авг. 2018 г. в 8:45, Ian Wienand :

Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2] >>>
Longer term ... suggestions welcome? :)


Move to Slack? We can provide auto-sending to emails invitations for
joining by clicking the button on some page at openstack.org. It will not
add more berrier for new contributors and, at the same time, this way will
give some base filtering by emails at least.


slack is pretty unworkable for many reasons. The biggest of them is that 
it is not Open Source and we don't require OpenStack developers to use 
proprietary software to work on OpenStack.


The quality of slack that makes it effective at fighting spam is also 
the quality that makes it toxic as a community platform - the need for 
an invitation and being structured as silos.


Even if we were to decide to abandon our Open Source principles and 
leave behind those in our contributor base who believe that Free 
Software Needs Free Tools [1] - moving to slack would be a GIANT 
undertaking. As such, it would not be a very effective way to deal with 
this current spam storm.



No, please no. If we need to move to another service, better go to a FLOSS
one, like Matrix.org, or others.


We had some discussion in Vancouver about investigating the use of 
Matrix. We are a VERY large community, so we need to do scale and 
viability testing before it's even a worthy topic to raise with the TC 
and the community for consideration. If we did, we'd aim to run our own 
home server.


However, it's worth noting that matrix is not immune to spam. As an open 
federated protocol, it's a target as well. Running our own home server 
might give us some additional tools - but it might not, and we might be 
in the same scenario except now we're running another service and we had 
the pain of moving.


All that to say though, matrix seems like the best potential option 
available that meets the largest number of desires from our user base. 
Once we've checked it out for viability it might be worth discussing.


As above, any effort there is a pretty giant one that will require a 
large amount of planning, a pretty sizeable amount of technical 
preparation and would be disruptive at the least, I don't think that'll 
help us with the current spam storm though.


Monty

[1] https://mako.cc/writing/hill-free_tools.html

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

Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Emilien Macchi]

On Wed, Aug 1, 2018 at 7:33 AM Giulio Fidente  wrote:

> I would like to propose Lukas Bezdicka core on TripleO.
>

Thanks Giulio for proposing him.
I agree Lukas's technical level has been quite impactful in the
Fast-Forward-Upgrades effort, and upgrades in general.
Also his strong experience with TripleO testing over the last years will
make him a great core reviewer, careful to not break upgrades and maintain
code consistency across the project.

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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Andrey Kurilin]

ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur :

> On 08/01/2018 12:49 PM, Andrey Kurilin wrote:
> > Hey Ian and stackers!
> >
> > ср, 1 авг. 2018 г. в 8:45, Ian Wienand  > >:
> >
> > Hello,
> >
> > It seems freenode is currently receiving a lot of unsolicited traffic
> > across all channels.  The freenode team are aware [1] and doing their
> > best.
> >
> > There are not really a lot of options.  We can set "+r" on channels
> > which means only nickserv registered users can join channels.  We
> have
> > traditionally avoided this, because it is yet one more barrier to
> > communication when many are already unfamiliar with IRC access.
> > However, having channels filled with irrelevant messages is also not
> > very accessible.
> >
> > This is temporarily enabled in #openstack-infra for the time being,
> so
> > we can co-ordinate without interruption.
> >
> > Thankfully AFAIK we have not needed an abuse policy on this before;
> > but I guess we are the point we need some sort of coordinated
> > response.
> >
> > I'd suggest to start, people with an interest in a channel can
> request
> > +r from an IRC admin in #openstack-infra and we track it at [2]
> >
> > Longer term ... suggestions welcome? :)
> >
> >
> > Move to Slack? We can provide auto-sending to emails invitations for
> joining by
> > clicking the button on some page at openstack.org .
> It
> > will not add more berrier for new contributors and, at the same time,
> this way
> > will give some base filtering by emails at least.
>
> A few potential barriers with slack or similar solutions: lack of FOSS
> desktop
> clients (correct me if I'm wrong),


The second link from google search gives an opensource client written in
python https://github.com/raelgc/scudcloud . Also, there is something which
is written in golang.


> complete lack of any console clients (ditto),
>

Again, google gives several ones as first results -
https://github.com/evanyeung/terminal-slack
https://github.com/erroneousboat/slack-term

serious limits on free (as in beer) tariff plans.
>
>
I can make an assumption that for marketing reasons, Slack Inc can propose
extended Free plan.
But anyway, even with default one the only thing which can limit us is
`10,000 searchable messages` which is bigger than 0 (freenode doesn't store
messages).


Why I like slack? because a lot of people are familar with it (a lot of
companies use it as like some opensource communities, like k8s )

PS: I realize that OpenStack Community will never go away from Freenode and
IRC, but I do not want to stay silent.

>
> > -i
> >
> > [1] https://freenode.net/news/spambot-attack
> > [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> >
> __
> > 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
>


-- 
Best regards,
Andrey Kurilin.
__
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] Ongoing spam in Freenode IRC channels

[Luigi Toscano]

On Wednesday, 1 August 2018 13:12:49 CEST András Kövi wrote:
> These are not just spam messages. At least the ones hitting Mistral are
> pedophile content. This must be reported. Can someone help me where?
> THX,
> A

They are already known:

https://freenode.net/news/spambot-attack

-- 
Luigi




__
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] Proposing Lukas Bezdicka core on TripleO

[Jiří Stránský]

+1!

On 1.8.2018 13:31, Giulio Fidente wrote:

Hi,

I would like to propose Lukas Bezdicka core on TripleO.

Lukas did a lot work in our tripleoclient, tripleo-common and
tripleo-heat-templates repos to make FFU possible.

FFU, which is meant to permit upgrades from Newton to Queens, requires
in depth understanding of many TripleO components (for example Heat,
Mistral and the TripleO client) but also of specific TripleO features
which were added during the course of the three releases (for example
config-download and upgrade tasks). I believe his FFU work to have been
very challenging.

Given his broad understanding, more recently Lukas started helping doing
reviews in other areas.

I am so sure he'll be a great addition to our group that I am not even
looking for comments, just votes :D




__
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] [Tacker] - TACKER + NETWORKING_SFC + NSH

[super user]

Currently, Tacker does not support NSH.

This feature will implement in the future.

On Wed, Aug 1, 2018 at 3:17 AM william sales 
wrote:

> Hello guys,
>
> is there any version of Tacker that allows the use of networking_sfc with
> NSH?
>
> Thankful.
>
> William Sales
> __
> 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] Proposing Lukas Bezdicka core on TripleO

[John Fulton]

+1 I thought he was already core.
On Wed, Aug 1, 2018 at 7:33 AM Giulio Fidente  wrote:
>
> Hi,
>
> I would like to propose Lukas Bezdicka core on TripleO.
>
> Lukas did a lot work in our tripleoclient, tripleo-common and
> tripleo-heat-templates repos to make FFU possible.
>
> FFU, which is meant to permit upgrades from Newton to Queens, requires
> in depth understanding of many TripleO components (for example Heat,
> Mistral and the TripleO client) but also of specific TripleO features
> which were added during the course of the three releases (for example
> config-download and upgrade tasks). I believe his FFU work to have been
> very challenging.
>
> Given his broad understanding, more recently Lukas started helping doing
> reviews in other areas.
>
> I am so sure he'll be a great addition to our group that I am not even
> looking for comments, just votes :D
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> 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] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Giulio Fidente]

Hi,

I would like to propose Lukas Bezdicka core on TripleO.

Lukas did a lot work in our tripleoclient, tripleo-common and
tripleo-heat-templates repos to make FFU possible.

FFU, which is meant to permit upgrades from Newton to Queens, requires
in depth understanding of many TripleO components (for example Heat,
Mistral and the TripleO client) but also of specific TripleO features
which were added during the course of the three releases (for example
config-download and upgrade tasks). I believe his FFU work to have been
very challenging.

Given his broad understanding, more recently Lukas started helping doing
reviews in other areas.

I am so sure he'll be a great addition to our group that I am not even
looking for comments, just votes :D
-- 
Giulio Fidente
GPG KEY: 08D733BA

__
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] Ongoing spam in Freenode IRC channels

[Luigi Toscano]

On Wednesday, 1 August 2018 12:49:13 CEST Andrey Kurilin wrote:
> Hey Ian and stackers!
> 
> ср, 1 авг. 2018 г. в 8:45, Ian Wienand :
> > Hello,
> > 
> > It seems freenode is currently receiving a lot of unsolicited traffic
> > across all channels.  The freenode team are aware [1] and doing their
> > best.
> > 
> > There are not really a lot of options.  We can set "+r" on channels
> > which means only nickserv registered users can join channels.  We have
> > traditionally avoided this, because it is yet one more barrier to
> > communication when many are already unfamiliar with IRC access.
> > However, having channels filled with irrelevant messages is also not
> > very accessible.
> > 
> > This is temporarily enabled in #openstack-infra for the time being, so
> > we can co-ordinate without interruption.
> > 
> > Thankfully AFAIK we have not needed an abuse policy on this before;
> > but I guess we are the point we need some sort of coordinated
> > response.
> > 
> > I'd suggest to start, people with an interest in a channel can request
> > +r from an IRC admin in #openstack-infra and we track it at [2]
> > 
> > Longer term ... suggestions welcome? :)
> 
> Move to Slack? We can provide auto-sending to emails invitations for
> joining by clicking the button on some page at openstack.org. It will not
> add more berrier for new contributors and, at the same time, this way will
> give some base filtering by emails at least.

No, please no. If we need to move to another service, better go to a FLOSS 
one, like Matrix.org, or others.

Ciao
-- 
Luigi




__
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] Ongoing spam in Freenode IRC channels

[András Kövi]

These are not just spam messages. At least the ones hitting Mistral are
pedophile content. This must be reported. Can someone help me where?
THX,
A

Andrey Kurilin  ezt írta (időpont: 2018. aug. 1.,
Sze, 12:49):

> Hey Ian and stackers!
>
> ср, 1 авг. 2018 г. в 8:45, Ian Wienand :
>
>> Hello,
>>
>> It seems freenode is currently receiving a lot of unsolicited traffic
>> across all channels.  The freenode team are aware [1] and doing their
>> best.
>>
>> There are not really a lot of options.  We can set "+r" on channels
>> which means only nickserv registered users can join channels.  We have
>> traditionally avoided this, because it is yet one more barrier to
>> communication when many are already unfamiliar with IRC access.
>> However, having channels filled with irrelevant messages is also not
>> very accessible.
>>
>> This is temporarily enabled in #openstack-infra for the time being, so
>> we can co-ordinate without interruption.
>>
>> Thankfully AFAIK we have not needed an abuse policy on this before;
>> but I guess we are the point we need some sort of coordinated
>> response.
>>
>> I'd suggest to start, people with an interest in a channel can request
>> +r from an IRC admin in #openstack-infra and we track it at [2]
>>
>> Longer term ... suggestions welcome? :)
>>
>>
> Move to Slack? We can provide auto-sending to emails invitations for
> joining by clicking the button on some page at openstack.org. It will not
> add more berrier for new contributors and, at the same time, this way will
> give some base filtering by emails at least.
>
>
>> -i
>>
>> [1] https://freenode.net/news/spambot-attack
>> [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018
>>
>> __
>> 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,
> Andrey Kurilin.
> __
> 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] Ongoing spam in Freenode IRC channels

[Dmitry Tantsur]

On 08/01/2018 12:49 PM, Andrey Kurilin wrote:

Hey Ian and stackers!

ср, 1 авг. 2018 г. в 8:45, Ian Wienand >:


Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2]

Longer term ... suggestions welcome? :)


Move to Slack? We can provide auto-sending to emails invitations for joining by 
clicking the button on some page at openstack.org . It 
will not add more berrier for new contributors and, at the same time, this way 
will give some base filtering by emails at least.


A few potential barriers with slack or similar solutions: lack of FOSS desktop 
clients (correct me if I'm wrong), complete lack of any console clients (ditto), 
serious limits on free (as in beer) tariff plans.




-i

[1] https://freenode.net/news/spambot-attack
[2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018

__
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,
Andrey Kurilin.


__
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] Ongoing spam in Freenode IRC channels

[Andrey Kurilin]

Hey Ian and stackers!

ср, 1 авг. 2018 г. в 8:45, Ian Wienand :

> Hello,
>
> It seems freenode is currently receiving a lot of unsolicited traffic
> across all channels.  The freenode team are aware [1] and doing their
> best.
>
> There are not really a lot of options.  We can set "+r" on channels
> which means only nickserv registered users can join channels.  We have
> traditionally avoided this, because it is yet one more barrier to
> communication when many are already unfamiliar with IRC access.
> However, having channels filled with irrelevant messages is also not
> very accessible.
>
> This is temporarily enabled in #openstack-infra for the time being, so
> we can co-ordinate without interruption.
>
> Thankfully AFAIK we have not needed an abuse policy on this before;
> but I guess we are the point we need some sort of coordinated
> response.
>
> I'd suggest to start, people with an interest in a channel can request
> +r from an IRC admin in #openstack-infra and we track it at [2]
>
> Longer term ... suggestions welcome? :)
>
>
Move to Slack? We can provide auto-sending to emails invitations for
joining by clicking the button on some page at openstack.org. It will not
add more berrier for new contributors and, at the same time, this way will
give some base filtering by emails at least.


> -i
>
> [1] https://freenode.net/news/spambot-attack
> [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018
>
> __
> 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,
Andrey Kurilin.
__
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] Ongoing spam in Freenode IRC channels

[Dmitry Tantsur]

Is it possible to ignore message or kick users by keywords? It seems that most 
messages are more or less the same and include a few URLs that are unlikely to 
appear in a normal conversation.


On 08/01/2018 07:45 AM, Ian Wienand wrote:

Hello,

It seems freenode is currently receiving a lot of unsolicited traffic
across all channels.  The freenode team are aware [1] and doing their
best.

There are not really a lot of options.  We can set "+r" on channels
which means only nickserv registered users can join channels.  We have
traditionally avoided this, because it is yet one more barrier to
communication when many are already unfamiliar with IRC access.
However, having channels filled with irrelevant messages is also not
very accessible.

This is temporarily enabled in #openstack-infra for the time being, so
we can co-ordinate without interruption.

Thankfully AFAIK we have not needed an abuse policy on this before;
but I guess we are the point we need some sort of coordinated
response.

I'd suggest to start, people with an interest in a channel can request
+r from an IRC admin in #openstack-infra and we track it at [2]

Longer term ... suggestions welcome? :)

-i

[1] https://freenode.net/news/spambot-attack
[2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018

__
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] [mistral] Mistral Monthly August 2018

[Dougal Matthews]

Hey everyone!

It is time to wrap-up the last month and have a look and see what has
happened.


# General News

We are now close to the end of the Rocky release cycle! It has been a
pleasure serving at the PTL and it looks like you are stuck with me for
Stein :)

- https://governance.openstack.org/election/

I would be interested to hear about high levels goals and themes for Stein.
What do you think the project should do and focus on? Let me know!


# Releases

- The finaly Rocky releases were made for mistral-lib and
python-mistralclient
- https://docs.openstack.org/releasenotes/python-mistralclient/rocky.html
- Next week we will release the RC1 for mistral, mistral-dashboard and
mistral-extra
- We skipped RC3 for the above repos, due to CI issues and other delays.
The changes can wait for the RC1 release


# Notable Changes and Additions

- 17 new actions for OpenStack Tacker were added
- A new policy was added to control which users can create and update
actions and workflows
- A new configuration option (oslo_rpc_executor) was added to change the
oslo RPC executor. It can now be eventlet, blocking or threading
- A new keystone configuration group was added, replacing the
keystone_authtoken group (which is now deprecated, but not removed)
- 166 new actions were added for OpenStack Manila
- Workbooks now support namespaces, previously only Workflows had support
- The Mistral development container now supports Keycloak

Lots of other small changes and bug fixes! It has been a busy month :)


# Milestones, Reviews, Bugs and Blueprints

- 55 commits and 251 reviews
- 100 Open bugs (Down from 105, yay!)
- Rocky-3 numbers:
Blueprints: 1 Unknown, 4 Not started, 3 Started, 1 Slow progress, 2
Implemented
Bugs: 1 Incomplete, 3 Invalid, 20 Confirmed, 7 Triaged, 8 In Progress,
21 Fix Released

Lots of bug fixes landed, good work!

Thanks all,
Dougal
__
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-ansible] Change in our IRC channel

[Slawomir Kaplonski]

Maybe such change should be considered to be done globally on all OpenStack 
channels?

> Wiadomość napisana przez jean-phili...@evrard.me w dniu 01.08.2018, o godz. 
> 10:13:
> 
> Hello everyone,
> 
> Due to a continuously increasing spam [0] on our IRC channels, I have decided 
> to make our channel (#openstack-ansible on freenode) only joinable by 
> Freenode's nickserv registered users.
> 
> I am sorry for the inconvenience, as it will now be harder to reach us (but 
> it's not that hard to register! [1]). The conversations will be easier to 
> follow though.
> 
> You can still contact us on the mailing lists too.
> 
> Regards,
> Jean-Philippe Evrard (evrardjp)
> 
> [0]: https://freenode.net/news/spambot-attack
> [1]: https://freenode.net/kb/answer/registration
> 
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Ongoing spam in Freenode IRC channels

[Luigi Toscano]

On Wednesday, 1 August 2018 07:45:02 CEST Ian Wienand wrote:
> Hello,
> 
> It seems freenode is currently receiving a lot of unsolicited traffic
> across all channels.  The freenode team are aware [1] and doing their
> best.
> 
> There are not really a lot of options.  We can set "+r" on channels
> which means only nickserv registered users can join channels.  We have
> traditionally avoided this, because it is yet one more barrier to
> communication when many are already unfamiliar with IRC access.
> However, having channels filled with irrelevant messages is also not
> very accessible.

What about inviting Sigyn, the anti-spam bot of the freenode admins, to all 
channels? Unless it does not trigger some global limit in Sigyn, but people on 
#freenode should be able to help.


Ciao
-- 
Luigi



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

[openstack-dev] [openstack-ansible] Change in our IRC channel

[jean-philippe]

Hello everyone,

Due to a continuously increasing spam [0] on our IRC channels, I have decided 
to make our channel (#openstack-ansible on freenode) only joinable by 
Freenode's nickserv registered users.

I am sorry for the inconvenience, as it will now be harder to reach us (but 
it's not that hard to register! [1]). The conversations will be easier to 
follow though.

You can still contact us on the mailing lists too.

Regards,
Jean-Philippe Evrard (evrardjp)

[0]: https://freenode.net/news/spambot-attack
[1]: https://freenode.net/kb/answer/registration


__
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] [watcher] no weekly meeting today

[Чадин Александр Сергеевич]

Hi folks,

I’m not able to run weekly meeting today because of vacation. Let’s meet in the 
next week on Wednesday.

Best regards,

Alex
__
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