- openstack-discuss - lists.openstack.org

Re: [Openstack-sigs] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley _______________________________________________ openstack-sigs mailing list openstack-sigs(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

1 0

Re: [openstack-dev] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Re: [Openstack] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[Openstack-operators] Nova hypervisor uuid
by Ignazio Cassano 27 Nov '18

27 Nov '18

Hi All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

2 1

Re: [OCTAVIA] How to monitor amphora
by Bedyk, Witold 27 Nov '18

27 Nov '18

Hi everyone, Monasca is the service which offers centralized monitoring and logging. As Joseph has written, you can probably use the monasca-agent and configure the existing system[1] and process[2] checks. If you need Octavia specific metrics, you can instrument your code using monasca-statsd library [3]. Best greetings Witek [1] https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md#syst… [2] https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md#proc… [3] https://github.com/openstack/monasca-statsd

1 0

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 27 Nov '18

27 Nov '18

Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC

1 0

Re: [OCTAVIA] How to monitor amphora
by Joseph Davis 26 Nov '18

26 Nov '18

Hello Sa Pham and others, Just to throw another option in to your discussion, the monasca-agent would also be able to monitor the cpu, memory, etc. on an amphora. Similar to how the Ceilometer agent -> Gnocchi publishing would work, you could then use Monasca services to track usage and set alarms. And Monasca handles storage in a time series database (Cassandra or InfluxDB). https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md has some details, an you can always ask questions in #openstack-monasca. joseph Adam Harwell wrote: I would also note (though I'm guessing you've heard this from Michael already) that logging and metrics for internal amphora data (like Haproxy logs, agent logs, etc) is on our roadmap to officially expose via some mechanism. We discussed possible ways to do this at the last PTG, but we were just waiting on someone to have time to do a blueprint for review. If you'd like to help get support for this upstream, you're welcome (actually, highly encouraged!) to hop into our IRC channel #openstack-lbaas and we can even help you get started. Hope to see you there! --Adam Harwell (rm_work) On Mon, Nov 26, 2018, 10:19 Michael Johnson <johnsomor(a)gmail.com> wrote: > This is an area we have been talking about recently at the PTGs. > > Adding connection log offloading is on our short term road map. > Someone had signed up for that, but has pivoted to work on other > items. > Due to that I can't say if it will make it for Stein or not. If > someone is interested in picking this up, I can help point you to the > documentation of our discussions at the PTGs. If not, I would expect > it to land late in Stein or early in Train. > > As for other monitoring, CPU, etc. this is area we currently leave to > the operator, but would like to do some work on. As mentioned above > gnocchi appears to be a nice time-series database for metrics > collection. We would need to have some design discussions on what and > how to collect the data. As you mentioned, monitoring agents can be > added to the amphora image at build time if the operator would like to > add a local tool set. > > As with most parts of Octavia, we try to make things "plug-able" so > that operators have a choice of tools. Both the log offloading and > metrics should follow that design principle. > > Michael > > On Sun, Nov 25, 2018 at 10:49 PM Gaël THEROND<gael.therond(a)gmail.com> > wrote: >> Hi! >> >> I’ve taken some time to read your presentation and I have to say thank > you for your wonderful work ! It’s pretty much complete and with code > example which is really cool. >> It’s exactly what I was looking for. >> If I could just suggest one thing, it would be to give operators freedom > to choose which logging and which metrics clients they want to use. >> Doing so would avoid having to rely on gnocchi as you would be able to > choose the clients type at amphora build time and specify clients target at > runtime using the amphora-agent. >> On another hand, it might we’ll be tricky to do so as everything is > namespaced into the amphora instance. >> As suggested using gnocchi to store HAProxy logs may well be the easiest > short path actually, I’m wondering if it would be possible for searchlight > to use that logs at some point. >> Anyway, thanks for the awesome job. >> For now I’ll keep it simple and just use the API for basic status. >> >> Kind regards, >> G. >> >> Le lun. 26 nov. 2018 à 04:23, Sa Pham<saphi070(a)gmail.com> a écrit : >>> yes. I have discussed with the Octavia team. PTL Johnson has suggested > me to use gnocchi to store octavia amphora metric. >>> >>> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND<gael.therond(a)gmail.com> > wrote: >>>> Hi! Thanks for this material, I’ll have a look at it. >>>> >>>> As our philosophy at work is to always push upstream all our > patchs/features or bug fixes, I won’t modify and keep the source code on > our own and if we need further features like that I think we will rather > push for a Blueprint with all required commits. >>>> Did you already discussed that topic with the Octavia team? >>>> >>>> Thanks a lot. >>>> >>>> Le mer. 21 nov. 2018 à 09:12, Sa Pham<saphi070(a)gmail.com> a écrit : >>>>> Hi, >>>>> >>>>> In Vietnam Openinfra Days 2018, I have a presentation about > monitoring and logging for Octavia Amphora. We have to customize octavia > source code to do this. I send you my presentation slide: > https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=… >>>>> Best, >>>>> >>>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND<gael.therond(a)gmail.com> > wrote: >>>>>> Hi guys, >>>>>> >>>>>> As already discussed I had to test Octavia as our corporate > LoadBalancer solution and it was a success. >>>>>> Thank to everyone on this list that assisted me and especially > Michael Octavia is fully working and without weird nightmare glitches. >>>>>> Now that I validated the technical part of my project, I need to > enter more operationals questions such as what’s the best way to monitor > and log amphora? >>>>>> I would like to be able to get a monitoring and logging agent > installed on the amphora in order to get proper metrics about what’s going > on with the LoadBalancer, is it fully cpu loaded? Is it using all network > resources available, are the file descriptors near the initial limits? How > much xxx HTTP return code the loadBalancer is facing and send those logs to > an ELK or something similar. >>>>>> Do you know if that something that I could achieve by adding more > elements to the image at DIB time or are there any other better > best-practices that I should be aware of ? >>>>>> As Octavia is creating a namespace for each HAProxy process, I am > wandering if it’s even possible. >>>>>> Thanks a lot for your hard work guys. >>>>>> >>>>>> Kind regards, >>>>>> >>>>> -- >>>>> Sa Pham Dang >>>>> Cloud RnD Team - VCCloud >>>>> Phone/Telegram: 0986.849.582 >>>>> Skype: great_bn >>>>> >>>>> >>> -- >>> Sa Pham Dang >>> Cloud RnD Team - VCCloud >>> Phone/Telegram: 0986.849.582 >>> Skype: great_bn >>> >>>

1 0

[openstack-dev] [cyborg] New time for Cyborg weekly IRC meetings
by Nadathur, Sundar 26 Nov '18

26 Nov '18

Hi, The current time for the weekly Cyborg IRC meeting is 1400 UTC, which is 6 am Pacific and 10pm China time. That is a bad time for most people in the call. Please vote in this doodle for what time you prefer. If you need more options, please respond in this thread. [1] https://doodle.com/poll/eqy3hp8hfqtf2qyn Thanks & Regards, Sundar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

[Openstack] Way to see VMs under all tenants by non-admin?
by Ken D'Ambrosio 26 Nov '18

26 Nov '18

Hey, all. I've had a request for a non-admin user to see all the VMs currently running, irrespective of project. I've gone through the policy.json file (this is Juno) and enabled everything I could think of that seemed appropriate, to no avail. Is there any way to do this without granting him flat-out admin? Thanks! -Ken _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

3 3

[all] maintainers/reviewers/committers wanted for tiny projects
by Chris Dent 26 Nov '18

26 Nov '18

I was recently going through the list of things to which I'm trying to pay attention and realized there are quite a few small software projects that are OpenStack-related that could do with additional attention because I'm either the sole or one of few maintainers. Some of these are hosted on OpenStack^wOpendev infra, some not. If you're interested in helping out, please have a look and feel free to ask me questions. Many are in some state of either disrepair or incompleteness because they were adopted from absentee owners. Paste: WSGI middleware management framework https://github.com/cdent/paste This was recently adopted because it had issues with Python 3.7 and there were concerns that OpenStack's continued use might present problems. I've also just inherited the pastedeploy package, and will be migrating it over to github too. It will also need some help. Use Flask instead. WSME: Web Service Made Easy (ha!) http://git.openstack.org/cgit/openstack/wsme For a brief period back in the day, this was the recommended way to make a web service in OpenStack. Soon after that it was abandoned by its maintainers and Lucas Gomez and I were press-ganged into maintaining it. It still gets the occasional patch to fix testing or Python 3 -related bugs. Does anyone still use this? Use Flask instead. microversion-parse: Library and WSGI middleware for parsing microversion headers http://git.openstack.org/cgit/openstack/microversion-parse This was extracted from placement's implementation for handling microversions. It tries to be framework agnostic, but is biased somewhat towards WebOb. It's nominally under the management of the API-SIG but it would be good to see it getting more use and thus more fixes. It's also used in Nova, not sure where else. wsgi-intercept: Intercept socket connection to wsgi applications for testing https://github.com/cdent/wsgi-intercept A convenient way to do functional testing of WSGI applications without needing to run a separate process but while still doing legit HTTP. Is used in nova and placement, and may still be used in the telemetry projects. It's old but very useful. It's at the core of gabbi. gabbi: Declarative HTTP Testing for Python and anything else https://github.com/cdent/gabbi YAML-driven testing of HTTP APIs that makes live _so_ _much_ _easier_. Was developed when I was working on telemetry, and is now central to the functional testing of placement. gabbi-tempest: A tempest plugin for using gabbi https://git.openstack.org/cgit/openstack/gabbi-tempest A tempest plugin + zuul job to make it super easy to use gabbi tests for driving integration tests in OpenStack, by mostly adding some YAML. If you're interested, great! Please let me know or simply start fixing things. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 5