Re: [Openstack-operators] Ocata security groups don't work with LBaaS v2 ports

[Ignazio Cassano]

Hello Saverio,
neutron.lbaas.v2-agent should apply iptables rules but it does not work.
Also in redhat exixts the same issue reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=1500118

Regards

2018-03-26 9:32 GMT+02:00 Saverio Proto :

> Hello Ignazio,
>
> it would interesting to know how this works. For instances ports,
> those ports are created by openvswitch on the compute nodes, where the
> neutron-agent will take care of the security groups enforcement (via
> iptables or openvswitch rules).
>
> the LBaaS is a namespace that lives where the neutron-lbaasv2-agent is
> running.
>
> The question is if the neutron-lbaasv2-agent is capable for setting
> iptables rules. I would start to read the code there.
>
> Cheers,
>
> Saverio
>
>
> 2018-03-23 13:51 GMT+01:00 Ignazio Cassano :
> > Hi all,
> > following the ocata documentation, I am trying to apply security group
> to a
> > lbaas v2 port but
> > it seems not working because any filter is applyed.
> > The Port Security Enabled is True on lbaas port, so I expect applying
> > security group should work.
> > Is this a bug ?
> > Regards
> > Ignazio
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Ocata security groups don't work with LBaaS v2 ports

[Saverio Proto]

Hello Ignazio,

it would interesting to know how this works. For instances ports,
those ports are created by openvswitch on the compute nodes, where the
neutron-agent will take care of the security groups enforcement (via
iptables or openvswitch rules).

the LBaaS is a namespace that lives where the neutron-lbaasv2-agent is running.

The question is if the neutron-lbaasv2-agent is capable for setting
iptables rules. I would start to read the code there.

Cheers,

Saverio


2018-03-23 13:51 GMT+01:00 Ignazio Cassano :
> Hi all,
> following the ocata documentation, I am trying to apply security group to a
> lbaas v2 port but
> it seems not working because any filter is applyed.
> The Port Security Enabled is True on lbaas port, so I expect applying
> security group should work.
> Is this a bug ?
> Regards
> Ignazio
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

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

[Openstack-operators] Vancouver Forum - Topic submission tool is now open!

[Thierry Carrez]

Hi everyone,

The Forum in Vancouver is getting closer! As a reminder, the Forum is
where we take advantage of having a large community presence at the
Summit to discuss and get wide feedback on a variety of topics around
the future of OpenStack and adjacent projects.

Starting today, our submission tool is open for you to submit abstracts
for the most popular sessions that came out of your brainstorming.

All teams, work groups and SIGs should now submit their abstracts at:

http://forumtopics.openstack.org/

before 11:59PM UTC on Sunday April 15th!

We are looking for a good mix of project-specific, cross-project or
strategic/whole-of-community discussions, and sessions that emphasis
collaboration between our various types of contributors are most welcome!

We assume that anything submitted to the system has achieved a good
amount of discussion and consensus that it's a worthwhile topic. After
submissions close, a team of representatives from the User Committee,
the Technical Committee and Foundation staff will take the sessions
proposed by the community and fill out the schedule.

You can expect the draft schedule to be released around April 22nd.

Further details about the Forum can be found at:
https://wiki.openstack.org/wiki/Forum

Regards,

-- 
Thierry Carrez (ttx)

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

[Openstack-operators] Diskimage-builder lvm

[Ignazio Cassano]

Hi all,
I read diskimage-builder  documentatio but is not clear for me how I can
supply lvm configuration to the command.
Some yaml files are supplied but diskimage seems to expect json file.
Please, could anyone post an example?
Regards
Ignazio
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [all][oslo] Notice to users of the ZeroMQ transport in oslo.messaging

[Ken Giusti]

Folks,

It's been over a year since the last commit was made to the ZeroMQ
driver in oslo.messaging.  It is at the point where some of the
related unit tests are beginning to fail due to bit rot.  None of the
current oslo.messaging contributors have a good enough understanding
of the codebase to effectively fix it.

Personally I'm not sure the driver will work in production at all.

Given this it was decided in Dublin that the ZeroMQ driver no longer
meets the official policy for in tree driver support [0] and will be
deprecated in Rocky.  However it would be insincere for the team to
give the impression that the driver is maintained for the normal 2
cycle deprecation process.  Therefore the driver code will be removed
in 'S'.

The ZeroMQ driver is the largest body of code of any driver in the
oslo.messaging repo, weighing in at over 5k lines of code.  For
comparison, the rabbitmq kombu driver consists of only about 2K lines
of code.  If any individuals are willing to commit to ownership of
this codebase and keep the driver compliant with policy (see [0]),
please follow up with bnemec or myself (kgiusti) on #openstack-oslo.

Thanks,


[0] 
https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html


-- 
Ken Giusti  (kgiu...@gmail.com)

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

[Openstack-operators] Fwd: [openstack-dev] [nova][placement] Upgrade placement first!

[Matt Riedemann]

FYI


 Forwarded Message 
Subject: [openstack-dev] [nova][placement] Upgrade placement first!
Date: Mon, 26 Mar 2018 15:02:23 -0500
From: Eric Fried 
Reply-To: OpenStack Development Mailing List (not for usage questions) 


Organization: IBM
To: OpenStack Development Mailing List (not for usage questions) 



Since forever [0], nova has gently recommended [1] that the placement
service be upgraded first.

However, we've not made any serious effort to test scenarios where this
isn't done.  For example, we don't have grenade tests running placement
at earlier levels.

After a(nother) discussion [2] which touched on the impacts - real and
imagined - of running new nova against old placement, we finally decided
to turn the recommendation into a hard requirement [3].

This gives admins a crystal clear guideline, this lets us simplify our
support statement, and also means we don't have to do 406 fallback code
anymore.  So we can do stuff like [4], and also avoid having to write
(and subsequently remove) code like that in the future.

Please direct any questions to #openstack-nova

Your Faithful Scribe,
efried

[0] Like, since upgrading placement was a thing.
[1]
https://docs.openstack.org/nova/latest/user/upgrade.html#rolling-upgrade-process
(#2, first bullet)
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
[3] https://review.openstack.org/556631
[4] https://review.openstack.org/556633

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

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

Re: [Openstack-operators] How are you handling billing/chargeback?

[Andrew Ruthven]

On Wed, 2018-03-14 at 12:11 -0400, Lars Kellogg-Stedman wrote:
> On Mon, Mar 12, 2018 at 03:21:13PM -0400, Lars Kellogg-Stedman wrote:
> > I'm curious what folks out there are using for chargeback/billing
> > in
> > your OpenStack environment.
> 
> So far it looks like everyone is using a homegrown solution.  Is
> anyone using an existing product/project?

Hey,

We (Catalyst Cloud) wrote Distil which takes information out of
Ceilometer, and creates appropriate draft invoices in Odoo, the rating
information comes from products in Odoo. The accounting system is
module based, so should be easy enough to integrate with other systems.
We've added a number of other pollsters to Ceilometer to collect
various other items we want to bill, and we also have an sflow traffic
metering system which allows us to bill for different classes of
network traffic.

Source code for Distil is here: https://github.com/openstack/distil/
Traffic billing: https://github.com/catalyst/openstack-sflow-traffic-bi
lling
We've written an API for our customers to be able to retrieve their
invoices etc, example client is here:
https://github.com/catalyst-cloud/catalystcloud-billing

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  | linux.conf.au 2019, Christchurch, NZ
New Zealand's only real Cloud: |    https://lca2019.linux.org.au/
   https://catalystcloud.nz|

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