Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
On 11/06/2017 08:36 AM, Juan Antonio Osorio wrote: > Giving this a bit more thought; I'm slightly more inclined on merely adding > the JSON formatter option to the standard oslo.log configuration options. Fine for me. > > This is because we right now have the ability to pass oslo.cfg options via > the CLI, and we would loose that with the advanced logging configuration > file. The aforementioned option is something that we're using for > containerized openstack services. OK - I'll check on my own if I can get something nice with the logging.conf file. But that won't be for "tomorrow", as I'm not full-time on openstack (unfortunately :(). Both solutions have their pros and cons in the end. > > I'll look into adding the ability to turn that handler on/off from oslo.log. Ping me if I can help :). And big thanks for that coming change! > > > > On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio > wrote: > >> >> >> On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret < >> cedric.jeanne...@camptocamp.com> wrote: >> >>> On 11/04/2017 07:08 AM, Doug Hellmann wrote: Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 >>> +0200: >> On 3 Nov 2017 19:59, "Doug Hellmann" wrote: >> >> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100: >>> Dear Stackers, >>> >>> While working on my locally deployed Openstack (Pike using TripleO), >>> I >>> was a bit struggling with the logging part. Currently, all logs are >>> pushed to per-service files, in the standard format "one line per >>> entry", plain flat text. >>> >>> It's nice, but if one is wanting to push and index those logs in an >>> ELK, >>> the current, default format isn't really good. >>> >>> After some discussions about oslo.log, it appears it provides a nice >>> JSONFormatter handler¹ one might want to use for each (python) >>> service >>> using oslo central library. >>> >>> A JSON format is really cool, as it's easy to parse for machines, >>> and it >>> can be on a multi-line without any bit issue - this is especially >>> important for stack traces, as their output is multi-line without >>> real >>> way to have a common delimiter so that we can re-format it and feed >>> it >>> to any log parser (logstash, fluentd, …). >>> >>> After some more talks, olso.log will not provide a unified interface >>> in >>> order to output all received logs as JSON - this makes sens, as that >>> would mean "rewrite almost all the python logging management >>> interface"², and that's pretty useless, since (all?) services have >>> their >>> own "logging.conf" file. >>> >>> That said… to the main purpose of that mail: >>> >>> - Default format for logs >>> A first question would be "are we all OK with the default output >>> format" >>> - I'm pretty sure "humans" are happy with that, as it's really >>> convenient to read and grep. But on a "standard" Openstack deploy, >>> I'm >>> pretty sure one does not have only one controller, one ceph node and >>> one >>> compute. Hence comes the log centralization, and with that, the log >>> indexation and treatments. >>> >>> For that, one might argue "I'm using plain files on my logger, and >>> grep-ing -r in them". That's a way to do things, and for that, plain, >>> flat logs are great. >>> >>> But… I'm pretty sure I'm not the only one wanting to use some kind of >>> ELK cluster for that kind of purpose. So the right question is: what >>> about switching the default log format to JSON? On my part, I don't >>> see >>> "cons", only "pros", but my judgment is of course biased, as I'm >>> "alone >>> in my corner". But what about you, Community? >>> >>> - Provide a way to configure the output format/handler >>> While poking around in the puppet modules code, I didn't find any >>> way to >>> set the output handler for the logs. For example, in puppet-nova³ we >>> can >>> set a lot of things, but not the useful handler for the output. >>> >>> It would be really cool to get, for each puppet module, the >>> capability >>> to set the handler so that one can just push some stuff in hiera, and >>> Voilà, we have JSON logs. >>> >>> Doing so would allow people to chose between the default (current) >>> output, and something more "computable". >> >> Using the JSON formatter currently requires setting a logging >> configuration file using the standard library configuration format >> and fully specifying things like log levels, handlers, and output >> destination. Would it make sense to add an option in oslo.log to >> give deployers an easier way to enable the JSON formatter? >> > > This would actually be very useful. Great! Let me know if you would like to help figuring out where to do that in the library code. >>> >>> There's alr
Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
Giving this a bit more thought; I'm slightly more inclined on merely adding the JSON formatter option to the standard oslo.log configuration options. This is because we right now have the ability to pass oslo.cfg options via the CLI, and we would loose that with the advanced logging configuration file. The aforementioned option is something that we're using for containerized openstack services. I'll look into adding the ability to turn that handler on/off from oslo.log. On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio wrote: > > > On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret < > cedric.jeanne...@camptocamp.com> wrote: > >> On 11/04/2017 07:08 AM, Doug Hellmann wrote: >> > Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 >> +0200: >> >>> On 3 Nov 2017 19:59, "Doug Hellmann" wrote: >> >>> >> >>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100: >> Dear Stackers, >> >> While working on my locally deployed Openstack (Pike using TripleO), >> I >> was a bit struggling with the logging part. Currently, all logs are >> pushed to per-service files, in the standard format "one line per >> entry", plain flat text. >> >> It's nice, but if one is wanting to push and index those logs in an >> ELK, >> the current, default format isn't really good. >> >> After some discussions about oslo.log, it appears it provides a nice >> JSONFormatter handler¹ one might want to use for each (python) >> service >> using oslo central library. >> >> A JSON format is really cool, as it's easy to parse for machines, >> and it >> can be on a multi-line without any bit issue - this is especially >> important for stack traces, as their output is multi-line without >> real >> way to have a common delimiter so that we can re-format it and feed >> it >> to any log parser (logstash, fluentd, …). >> >> After some more talks, olso.log will not provide a unified interface >> in >> order to output all received logs as JSON - this makes sens, as that >> would mean "rewrite almost all the python logging management >> interface"², and that's pretty useless, since (all?) services have >> their >> own "logging.conf" file. >> >> That said… to the main purpose of that mail: >> >> - Default format for logs >> A first question would be "are we all OK with the default output >> format" >> - I'm pretty sure "humans" are happy with that, as it's really >> convenient to read and grep. But on a "standard" Openstack deploy, >> I'm >> pretty sure one does not have only one controller, one ceph node and >> one >> compute. Hence comes the log centralization, and with that, the log >> indexation and treatments. >> >> For that, one might argue "I'm using plain files on my logger, and >> grep-ing -r in them". That's a way to do things, and for that, plain, >> flat logs are great. >> >> But… I'm pretty sure I'm not the only one wanting to use some kind of >> ELK cluster for that kind of purpose. So the right question is: what >> about switching the default log format to JSON? On my part, I don't >> see >> "cons", only "pros", but my judgment is of course biased, as I'm >> "alone >> in my corner". But what about you, Community? >> >> - Provide a way to configure the output format/handler >> While poking around in the puppet modules code, I didn't find any >> way to >> set the output handler for the logs. For example, in puppet-nova³ we >> can >> set a lot of things, but not the useful handler for the output. >> >> It would be really cool to get, for each puppet module, the >> capability >> to set the handler so that one can just push some stuff in hiera, and >> Voilà, we have JSON logs. >> >> Doing so would allow people to chose between the default (current) >> output, and something more "computable". >> >>> >> >>> Using the JSON formatter currently requires setting a logging >> >>> configuration file using the standard library configuration format >> >>> and fully specifying things like log levels, handlers, and output >> >>> destination. Would it make sense to add an option in oslo.log to >> >>> give deployers an easier way to enable the JSON formatter? >> >>> >> >> >> >> This would actually be very useful. >> > >> > Great! Let me know if you would like to help figuring out where to do >> > that in the library code. >> >> There's already some (not really documented) feature allowing oslo.log >> to load a configuration file. In fact, there's already one existing in >> the keystone tree (/etc/keystone/logging.conf - altougn not loaded) - we >> might base something "casual" and "generic" on that one. >> >> I think all wsgi/python services should configure the logging through >> that file so that it's clearer and cleaner. But that part is ma
[openstack-dev] Building Openstack Trove Images
Hi Team, We have installed Openstack Pike in our campus but despite of numerous attempts we are just unable to build trove images that we can use to launch database instances.We also came across a mail thread where Mr. Amrith updates that some review & update of the OpenStack Trove documents was going on, kindly provide us some reference document or link which we can follow. https://lists.gt.net/openstack/dev/58182 We will be eagerly waiting for your response. Thanks & Regards, Ritesh Vishwakarma __ 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][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret < cedric.jeanne...@camptocamp.com> wrote: > On 11/04/2017 07:08 AM, Doug Hellmann wrote: > > Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 +0200: > >>> On 3 Nov 2017 19:59, "Doug Hellmann" wrote: > >>> > >>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100: > Dear Stackers, > > While working on my locally deployed Openstack (Pike using TripleO), I > was a bit struggling with the logging part. Currently, all logs are > pushed to per-service files, in the standard format "one line per > entry", plain flat text. > > It's nice, but if one is wanting to push and index those logs in an > ELK, > the current, default format isn't really good. > > After some discussions about oslo.log, it appears it provides a nice > JSONFormatter handler¹ one might want to use for each (python) service > using oslo central library. > > A JSON format is really cool, as it's easy to parse for machines, and > it > can be on a multi-line without any bit issue - this is especially > important for stack traces, as their output is multi-line without real > way to have a common delimiter so that we can re-format it and feed it > to any log parser (logstash, fluentd, …). > > After some more talks, olso.log will not provide a unified interface > in > order to output all received logs as JSON - this makes sens, as that > would mean "rewrite almost all the python logging management > interface"², and that's pretty useless, since (all?) services have > their > own "logging.conf" file. > > That said… to the main purpose of that mail: > > - Default format for logs > A first question would be "are we all OK with the default output > format" > - I'm pretty sure "humans" are happy with that, as it's really > convenient to read and grep. But on a "standard" Openstack deploy, I'm > pretty sure one does not have only one controller, one ceph node and > one > compute. Hence comes the log centralization, and with that, the log > indexation and treatments. > > For that, one might argue "I'm using plain files on my logger, and > grep-ing -r in them". That's a way to do things, and for that, plain, > flat logs are great. > > But… I'm pretty sure I'm not the only one wanting to use some kind of > ELK cluster for that kind of purpose. So the right question is: what > about switching the default log format to JSON? On my part, I don't > see > "cons", only "pros", but my judgment is of course biased, as I'm > "alone > in my corner". But what about you, Community? > > - Provide a way to configure the output format/handler > While poking around in the puppet modules code, I didn't find any way > to > set the output handler for the logs. For example, in puppet-nova³ we > can > set a lot of things, but not the useful handler for the output. > > It would be really cool to get, for each puppet module, the capability > to set the handler so that one can just push some stuff in hiera, and > Voilà, we have JSON logs. > > Doing so would allow people to chose between the default (current) > output, and something more "computable". > >>> > >>> Using the JSON formatter currently requires setting a logging > >>> configuration file using the standard library configuration format > >>> and fully specifying things like log levels, handlers, and output > >>> destination. Would it make sense to add an option in oslo.log to > >>> give deployers an easier way to enable the JSON formatter? > >>> > >> > >> This would actually be very useful. > > > > Great! Let me know if you would like to help figuring out where to do > > that in the library code. > > There's already some (not really documented) feature allowing oslo.log > to load a configuration file. In fact, there's already one existing in > the keystone tree (/etc/keystone/logging.conf - altougn not loaded) - we > might base something "casual" and "generic" on that one. > > I think all wsgi/python services should configure the logging through > that file so that it's clearer and cleaner. But that part is maybe a bit > too big and "aggressive" :). And the logging configuration isn't that > friendly, to be honest, at least I have some issues with its doc ;). > > But I think we might come to something nice and cool. It would allow > anyone to push their own log "formatter", in the end. > So you (oslo.log) wouldn't need to work with format output requests > anymore, just provide two basics (plain and json), and let users play > with the logging configuration (and even output things in XML if they > want) ;). > > Regarding oslo.log: apparently, adding the following entry in the > service configuration file should do it: > log-config-append¹ > > Can anyone confi
Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
On 11/04/2017 07:08 AM, Doug Hellmann wrote: > Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 +0200: >>> On 3 Nov 2017 19:59, "Doug Hellmann" wrote: >>> >>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100: Dear Stackers, While working on my locally deployed Openstack (Pike using TripleO), I was a bit struggling with the logging part. Currently, all logs are pushed to per-service files, in the standard format "one line per entry", plain flat text. It's nice, but if one is wanting to push and index those logs in an ELK, the current, default format isn't really good. After some discussions about oslo.log, it appears it provides a nice JSONFormatter handler¹ one might want to use for each (python) service using oslo central library. A JSON format is really cool, as it's easy to parse for machines, and it can be on a multi-line without any bit issue - this is especially important for stack traces, as their output is multi-line without real way to have a common delimiter so that we can re-format it and feed it to any log parser (logstash, fluentd, …). After some more talks, olso.log will not provide a unified interface in order to output all received logs as JSON - this makes sens, as that would mean "rewrite almost all the python logging management interface"², and that's pretty useless, since (all?) services have their own "logging.conf" file. That said… to the main purpose of that mail: - Default format for logs A first question would be "are we all OK with the default output format" - I'm pretty sure "humans" are happy with that, as it's really convenient to read and grep. But on a "standard" Openstack deploy, I'm pretty sure one does not have only one controller, one ceph node and one compute. Hence comes the log centralization, and with that, the log indexation and treatments. For that, one might argue "I'm using plain files on my logger, and grep-ing -r in them". That's a way to do things, and for that, plain, flat logs are great. But… I'm pretty sure I'm not the only one wanting to use some kind of ELK cluster for that kind of purpose. So the right question is: what about switching the default log format to JSON? On my part, I don't see "cons", only "pros", but my judgment is of course biased, as I'm "alone in my corner". But what about you, Community? - Provide a way to configure the output format/handler While poking around in the puppet modules code, I didn't find any way to set the output handler for the logs. For example, in puppet-nova³ we can set a lot of things, but not the useful handler for the output. It would be really cool to get, for each puppet module, the capability to set the handler so that one can just push some stuff in hiera, and Voilà, we have JSON logs. Doing so would allow people to chose between the default (current) output, and something more "computable". >>> >>> Using the JSON formatter currently requires setting a logging >>> configuration file using the standard library configuration format >>> and fully specifying things like log levels, handlers, and output >>> destination. Would it make sense to add an option in oslo.log to >>> give deployers an easier way to enable the JSON formatter? >>> >> >> This would actually be very useful. > > Great! Let me know if you would like to help figuring out where to do > that in the library code. There's already some (not really documented) feature allowing oslo.log to load a configuration file. In fact, there's already one existing in the keystone tree (/etc/keystone/logging.conf - altougn not loaded) - we might base something "casual" and "generic" on that one. I think all wsgi/python services should configure the logging through that file so that it's clearer and cleaner. But that part is maybe a bit too big and "aggressive" :). And the logging configuration isn't that friendly, to be honest, at least I have some issues with its doc ;). But I think we might come to something nice and cool. It would allow anyone to push their own log "formatter", in the end. So you (oslo.log) wouldn't need to work with format output requests anymore, just provide two basics (plain and json), and let users play with the logging configuration (and even output things in XML if they want) ;). Regarding oslo.log: apparently, adding the following entry in the service configuration file should do it: log-config-append¹ Can anyone confirm that? ¹ https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L44 > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
Re: [openstack-dev] [TripleO] containerized undercloud in Queens
On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi wrote: > On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince wrote: > [...] > > > -CI resources: better use of CI resources. At the PTG we received > > feedback from the OpenStack infrastructure team that our upstream CI > > resource usage is quite high at times (even as high as 50% of the > > total). Because of the shared framework and single node capabilities we > > can re-architecture much of our upstream CI matrix around single node. > > We no longer require multinode jobs to be able to test many of the > > services in tripleo-heat-templates... we can just use a single cloud VM > > instead. We'll still want multinode undercloud -> overcloud jobs for > > testing things like HA and baremetal provisioning. But we can cover a > > large set of the services (in particular many of the new scenario jobs > > we added in Pike) with single node CI test runs in much less time. > > After the last (terrible) weeks in CI, it's pretty clear we need to > find a solution to reduce and optimize our testing. > I'm now really convinced by switching our current scenarios jobs to > NOT deploy the overcloud, and just an undercloud with composable > services & run tempest. > First off, I'm really pleased that the containerized undercloud effort has been reinvigerated for queens. The containerized undercloud work has been awesome, really nice work to everyone involved!! I totally agree we should be shifting to using the undercloud only and deploy the services we want need for the scenarios on the single node. I think we should start putting plans in place to start shifting work to the undercloud only approach, however I think it is way too early to talk about not deploying the overcloud in CI. I'd prefer to take a step by step phased approach to such a large change. Really good point Emilien and thanks for raising it!! > > Benefits: > - deploy 1 node instead of 2 nodes, so we save nodepool resources > - faster (no overcloud) > - reduce gate queue time, faster development process, faster CI > > Challenges: > - keep overcloud testing, with OVB > - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic > containerized services on overcloud. > > I really want to get consensus on these points, please raise your > voice now before we engage some work on that front. > > [...] > -- > 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 > __ 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] Privsep transition state of play
On Mon, Nov 6, 2017 at 1:26 PM, Dan Smith wrote: > > I hope everyone travelling to the Sydney Summit is enjoying jet lag > > just as much as I normally do. Revenge is sweet! My big advice is that > > caffeine is your friend, and to not lick any of the wildlife. > > I wasn't planning on licking any of it, but thanks for the warning. You're welcome. > > As of just now, all rootwrap usage has been removed from the libvirt > > driver, if you assume that the outstanding patches from the blueprint > > are merged. I think that's a pretty cool milestone. That said, I feel > > that https://review.openstack.org/#/c/517516/ needs a short talk to > > make sure that people don't think the implementation approach I've > > taken is confusing -- basically not all methods in nova/privsep are > > now escalated, as sometimes we only sometimes escalate our privs for a > > call. The review makes it clearer than I can in an email. > > I commented, agreeing with gibi. Make the exceptional cases > exceptionally named; assume non-exceptional names are escalated by > default. Ok. I'm struggling to come up with a single word which means "unescalated unless you're already escalated", but I'll keep pondering. > > We could stop now for Queens if we wanted -- we originally said we'd > > land things early to let them stabilise. That said, we haven't > > actually caused any stability problems so far -- just a few out of > > tree drivers having to play catchup. So we could also go all in and > > get this thing done fully in Queens. > > I agree we should steam ahead. I don't really want to hang the fate of > the privsep transition on the removal of cellsv2 and nova-network, so > personally I'm not opposed to privsepping those bits if you're > willing. I also agree that the lack of breakage thus far should give us > more confidence that we're safe to continue applying these changes later > in the cycle. Just MHO. I shall prepare the relevant patches then, and look forward to once again breaking the gate. Michael __ 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] Privsep transition state of play
> I hope everyone travelling to the Sydney Summit is enjoying jet lag > just as much as I normally do. Revenge is sweet! My big advice is that > caffeine is your friend, and to not lick any of the wildlife. I wasn't planning on licking any of it, but thanks for the warning. > As of just now, all rootwrap usage has been removed from the libvirt > driver, if you assume that the outstanding patches from the blueprint > are merged. I think that's a pretty cool milestone. That said, I feel > that https://review.openstack.org/#/c/517516/ needs a short talk to > make sure that people don't think the implementation approach I've > taken is confusing -- basically not all methods in nova/privsep are > now escalated, as sometimes we only sometimes escalate our privs for a > call. The review makes it clearer than I can in an email. I commented, agreeing with gibi. Make the exceptional cases exceptionally named; assume non-exceptional names are escalated by default. > We could stop now for Queens if we wanted -- we originally said we'd > land things early to let them stabilise. That said, we haven't > actually caused any stability problems so far -- just a few out of > tree drivers having to play catchup. So we could also go all in and > get this thing done fully in Queens. I agree we should steam ahead. I don't really want to hang the fate of the privsep transition on the removal of cellsv2 and nova-network, so personally I'm not opposed to privsepping those bits if you're willing. I also agree that the lack of breakage thus far should give us more confidence that we're safe to continue applying these changes later in the cycle. Just MHO. --Dan __ 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][forum] Sydney Watcher users feedback etherpad
Hi all, Unfortunately I do not go to Sydney, Yumeng Bao will be there as moderator. We created etherpad [0] and added it in forum etherpads [1] Please add additional context as you want to discuss. [0] https://etherpad.openstack.org/p/watcher-sydney-forum [1] https://wiki.openstack.org/wiki/Forum/Sydney2017 Thanks, Hidekazu Nakamura __ 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] [charms] Sydney forum user feedback session (Tues@0950)
Hi All Apologies for the late creation of this pad: https://etherpad.openstack.org/p/SYD-forum-charms-ops-feedback if your planning on attending this session please add your name and any topics for discussion! Cheers James __ 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] containerized undercloud in Queens
On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince wrote: [...] > -CI resources: better use of CI resources. At the PTG we received > feedback from the OpenStack infrastructure team that our upstream CI > resource usage is quite high at times (even as high as 50% of the > total). Because of the shared framework and single node capabilities we > can re-architecture much of our upstream CI matrix around single node. > We no longer require multinode jobs to be able to test many of the > services in tripleo-heat-templates... we can just use a single cloud VM > instead. We'll still want multinode undercloud -> overcloud jobs for > testing things like HA and baremetal provisioning. But we can cover a > large set of the services (in particular many of the new scenario jobs > we added in Pike) with single node CI test runs in much less time. After the last (terrible) weeks in CI, it's pretty clear we need to find a solution to reduce and optimize our testing. I'm now really convinced by switching our current scenarios jobs to NOT deploy the overcloud, and just an undercloud with composable services & run tempest. Benefits: - deploy 1 node instead of 2 nodes, so we save nodepool resources - faster (no overcloud) - reduce gate queue time, faster development process, faster CI Challenges: - keep overcloud testing, with OVB - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic containerized services on overcloud. I really want to get consensus on these points, please raise your voice now before we engage some work on that front. [...] -- 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
[openstack-dev] [charms] evolving the ha interface type
Hi Team Whilst working on migrating to using Python 3 as the default charm execution environment, I've hit upon a snag with presentation of data from principle charms to the hacluster subordinate charm. Specifically the data presented on the relation is simple str representation of python dicts which are then parsed used ast in the hacluster charm. This has worked OK under Python 2, but due to the non-deterministic iteration of dict keys, the data presented from the principle charm can change over time when the ha_joined function is re-exec'ed (such as during a config-changed hook execution). I'd like to propose that we move to using json to serialise this data so that we can used ordered dicts to present data in a consistent fashion. We need to evolve the interface to deal with this - we could potentially take two approaches: a) Attempt to parse presented data using json, fallback to ast for backwards compat b) Present a version flag from the hacluster charm, allowing the principle to switch to the new approach when the required version of the hacluster charm is presented to it. We'd still do a) but it would avoid hook failures in the event that a user does not upgrade hacluster application instances prior to upgrading principle charms. Anyway - that's my current thoughts. I have a prototype for a) which works nicely, but I think adding b) will provide a better UX (thanks gnuoy for pointing to this solution). Thoughts? James __ 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] [murano] failed to access storage.apps.openstack.org
On 2017-11-05 16:18:23 +0800 (+0800), Margin Hu wrote: [...] > is storage.apps.openstack.org working now ? Explained at http://lists.openstack.org/pipermail/openstack-operators/2017-July/013965.html but yes, it's been offline for months at this point. -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] New hash for master promoted
On Sun, Nov 5, 2017 at 7:55 AM, Adriano Petrich wrote: > Amazing! Thanks for the effort that took to get the promotion fixed! > > On Fri, Nov 3, 2017 at 8:17 PM, Jason E. Rist wrote: > >> On 11/03/2017 03:52 AM, Gabriele Cerami wrote: >> > Hi, >> > >> > since the failures in Tuesday's tests were caused by infra problems, we >> > believed a specific hash involved in the failures to remain the best >> > candidate for a promotion. >> > So we pinned it in our promotion pipeline and insisted on it for some >> > hours. It has passed all the tests twice, so we dacided to promote. >> > You will see the promotion date set to today, but the hash >> > >> > 3b718f3fecc866332ec0663fa77e758f8346ab93_4204ba89 >> > >> > is actually from Tuesday. >> > >> > Thanks. >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> Woot! Thanks! >> >> -J >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > Master has promoted once again on 11/04. Hopefully we'll see regular promotions on master for a while now. 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] [tricircle]Distinguish the direction of requests
For the first question, since api-paste.ini is a configuration file, you can just add your new filter to the configuration file so your filter can take effect. As Joe suggests, you can add embed the information in the oslo.context object so plugin can get it from context which is passed to plugin. On Fri, 3 Nov 2017 at 12:29 joehuang wrote: > Hello, > > As you are talking about how to distinguish the request to local Neutron > and central Neutron, do you mean how to set the "USER_AGENT" in the request > header, and how to extract the "USER_AGENT" and stored it in the context? > Though it's mentioned in > https://developer.openstack.org/sdks/python/openstacksdk/users/connection.html > > This field has not been extracted neither in oslo.context, nor neutron-lib > context: > > > https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py > > > May be we can add it in oslo.context? > > Best Regards > Chaoyi Huang (joehuang) > -- > *From:* XuZhuang [xu_ly...@163.com] > *Sent:* 01 November 2017 19:49 > *To:* openstack-dev@lists.openstack.org > *Subject:* [openstack-dev] [tricircle]Distinguish the direction of > requests > > Hello, > > I have some questions in how to distinguish the direction of requests > between local neutron and central neutron. > > > There is the preliminary plan > > > 1. For how to distinguish the requests in central neutron > > we can add a filter in neutron/…./etc/api-paste.ini. Using this filter we > can get some values about the source. > > But the question is that the process of loading filter is in Neutron. > Without changing Neutron how could we add a filter? Could we change Neutron? > > > 2. For how to add a signal in the requests > > The module of common.client in Tricircle is responsible for sending > requests. So we can add a signal in the header of requests. And central > plugin will get this signal using the filter. > > > Best Regards > > Zhuangzhuang Xu (Lyman Xu) > > > > __ > 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 > -- BR Zhiyuan __ 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] [murano] failed to access storage.apps.openstack.org
Hi, Margin Huapps.openstack.org website is tired by openstack TC, so can't get apps from there. You can clone murano-apps repo to get the package source, then zip the packages manually.Thanks,Rong Zhu On 11/05/2017 16:19, Margin Hu wrote: Hi Guys, I found I failed to download the following file: http://storage.apps.openstack.org/apps/com.example.apache.ApacheHttpServer.zip is storage.apps.openstack.org working now ? __ 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] New hash for master promoted
Amazing! Thanks for the effort that took to get the promotion fixed! On Fri, Nov 3, 2017 at 8:17 PM, Jason E. Rist wrote: > On 11/03/2017 03:52 AM, Gabriele Cerami wrote: > > Hi, > > > > since the failures in Tuesday's tests were caused by infra problems, we > > believed a specific hash involved in the failures to remain the best > > candidate for a promotion. > > So we pinned it in our promotion pipeline and insisted on it for some > > hours. It has passed all the tests twice, so we dacided to promote. > > You will see the promotion date set to today, but the hash > > > > 3b718f3fecc866332ec0663fa77e758f8346ab93_4204ba89 > > > > is actually from Tuesday. > > > > 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 > > > Woot! Thanks! > > -J > > __ > 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] [murano] failed to access storage.apps.openstack.org
Hi Guys, I found I failed to download the following file: http://storage.apps.openstack.org/apps/com.example.apache.ApacheHttpServer.zip is storage.apps.openstack.org working now ? __ 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
