Re: [Openstack-operators] How are you handling billing/chargeback?
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
[Openstack-operators] Fwd: [openstack-dev] [nova][placement] Upgrade placement first!
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
[Openstack-operators] [all][oslo] Notice to users of the ZeroMQ transport in oslo.messaging
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] Diskimage-builder lvm
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] Vancouver Forum - Topic submission tool is now open!
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
Re: [Openstack-operators] Ocata security groups don't work with LBaaS v2 ports
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
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