Re: [openstack-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On Mon, 22 Jun 2015, gord chung wrote: what's 'long form transport'? it's not actually using cfg.CONF. to figure out transport url if not present. cfg.CONF passed in has nothing set and is basically just a bunch of defaults... the url obviously doesn't have a default so ceilometermiddleware will fail if you don't pass in a url. cfg.CONF contains the config instructions from the filter factory, it is being passed to messaging.get_transport, along with url= The originating issue is that get_request_url in devstack:lib/rpc_backend is insufficient because it returns a url. Since "we" are already in charge of writing the lines in the filter factory config, can't we write whatever is necessary there? -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On 22/06/15 06:39 PM, Chris Dent wrote: On Mon, 22 Jun 2015, Sean Dague wrote: Could we deprecate the use of tranport_url in ceilometermiddleware and move to an actual oslo.config file somewhere instead? That would bring it in line with the rest of the RPC configuration for services, and ensure that all connections in a cluster have access to all the same options. Replying on the top of the thread as it seems the responses have taken us on a bit of a journey and I feel like instead of narrowing the goal and figuring out what to do we've expanded scope and need to fix everything. We can't fix everything so let's back up a bit and figure out the original goal. When you (Sean) and I first talked about this I understood the problem to be that the use of just a URL was insufficient for covering the configuration settings of the various messaging solutions and additionally was not in keeping with convention. I poked around in the code and discovered (as has been mentioned elsewhere in the thread) the filter factory configuration settings are merged into the oslo config. So: is it appropriate, for now, to switch devstack:lib/swift to write long form transport configuration in filter:ceilometer of swift proxy's config (it's already writing plenty of other stuff) and kill get_transport_url. ceilometermiddleware already calls get_transport with a cfg.CONF that will be used for figuring out the transport url if 'url' is None. what's 'long form transport'? it's not actually using cfg.CONF. to figure out transport url if not present. cfg.CONF passed in has nothing set and is basically just a bunch of defaults... the url obviously doesn't have a default so ceilometermiddleware will fail if you don't pass in a url. This doesn't solve every extant issue but it does solve some of them. The ceilometer middleware, whether the old one that was in the ceilometer tree or this newer one, has always struggled to exist correctly in that weird intersection between swift and the rest of the openstack universe, but exist it does in its not quite correct way. Whatever we can do to make it exist better, even if its just a little bit better, is good. -- gord __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On Mon, 22 Jun 2015, Sean Dague wrote: Could we deprecate the use of tranport_url in ceilometermiddleware and move to an actual oslo.config file somewhere instead? That would bring it in line with the rest of the RPC configuration for services, and ensure that all connections in a cluster have access to all the same options. Replying on the top of the thread as it seems the responses have taken us on a bit of a journey and I feel like instead of narrowing the goal and figuring out what to do we've expanded scope and need to fix everything. We can't fix everything so let's back up a bit and figure out the original goal. When you (Sean) and I first talked about this I understood the problem to be that the use of just a URL was insufficient for covering the configuration settings of the various messaging solutions and additionally was not in keeping with convention. I poked around in the code and discovered (as has been mentioned elsewhere in the thread) the filter factory configuration settings are merged into the oslo config. So: is it appropriate, for now, to switch devstack:lib/swift to write long form transport configuration in filter:ceilometer of swift proxy's config (it's already writing plenty of other stuff) and kill get_transport_url. ceilometermiddleware already calls get_transport with a cfg.CONF that will be used for figuring out the transport url if 'url' is None. This doesn't solve every extant issue but it does solve some of them. The ceilometer middleware, whether the old one that was in the ceilometer tree or this newer one, has always struggled to exist correctly in that weird intersection between swift and the rest of the openstack universe, but exist it does in its not quite correct way. Whatever we can do to make it exist better, even if its just a little bit better, is good. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On Mon, Jun 22, 2015 at 2:43 PM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2015-06-22 13:30:44 -0400: > > On 06/22/2015 01:15 PM, Michael Krotscheck wrote: > > > Having _just_ done this, a couple of suggestions. > > > > > > - If the middleware is NOT optional - that is, it provides some kind of > > > a fundamental component or specification of the API, like ETag caching, > > > CORS, or DB Session management - then the middleware should be added > > > during the app initialization routine, likely in the app factory. In > > > this case, we have tight control over the initialization order, and can > > > make sure that oslo.config is there first. Yay config. > > > > > > - If the middleware _is_ optional, then I really feel this problem is > > > solved by pastedeploy's filter_factory pattern. It lets you define as > > > many required parameters as you want, and spits back a middleware > > > instance. That way you have the freedom to set whatever configuration > > > options you want, or omit the middleware altogether. > > > > > > http://pythonpaste.org/deploy/#paste-filter-factory > > > > > > Ultimately, what you should want is to ask a factory method for a thing > > > with some configuration options, and it spits an instance back at you. > > > If your project doesn't support pastedeploy, that limits your options > > > (ahem-ironic-ahem). Otherwise, it's really a team decision on whether > > > something is a 'Fundamental feature' or something that's optional. > > > > > > In the case of Ceilometer? Sorry, but I think it's optional. You should > > > be able to run any component of openstack without ceilometer. So I > don't > > > really think it should depend on oslo_config. > > > > Ok, here is where I'm confused. Ceilometer middleware *already* depends > > on oslo_config. > > > > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42 > > > > And it does stuff with it here: > > > > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107 > > > > But regardless, it uses oslo_messaging, which uses oslo_config. So it > > seems like the only issue at hand is middleware retriggering conf > parsing. > > > > Because the current model of requiring simultaneous code lands in > > oslo_messaging and ceilometermiddleware, and simultaneous config updates > > in every installer and config management system to configure the same > > thing in 2 different ways, does seem like a long term win. And honestly > > just prohibits most of what people seem to want to do with new messaging > > approaches. > > I explained this on IRC, but I'll repeat it here as a more permanent > record. > > We should not have the ceilometer middleware (re)initializing > oslo.config. That combines 2 concerns (setting up configuration and > doing whatever ceilometermiddleware is already doing) in one piece > of middleware, and that will make it more difficult to combine > ceilometermiddleware with other middleware that also wants access > to the configuration settings. > > If the application code isn't setting up oslo.config, then we should > have another piece of middleware do just that one thing. It can take > options from paste's config to tell it how to do that work, and then > other middleware later in the pipeline can rely on oslo.config being set > up and the config files being loaded. > > Doug > > Whatever is decided for this, I assume it'll also apply to the auth_token middleware, since that uses oslo.config, too. We already have a bug[1] and a proposed change[2] that isn't passing jenkins. [1] https://bugs.launchpad.net/keystonemiddleware/+bug/1406218 [2] https://review.openstack.org/#/c/143063/ Brant __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
Excerpts from Sean Dague's message of 2015-06-22 13:30:44 -0400: > On 06/22/2015 01:15 PM, Michael Krotscheck wrote: > > Having _just_ done this, a couple of suggestions. > > > > - If the middleware is NOT optional - that is, it provides some kind of > > a fundamental component or specification of the API, like ETag caching, > > CORS, or DB Session management - then the middleware should be added > > during the app initialization routine, likely in the app factory. In > > this case, we have tight control over the initialization order, and can > > make sure that oslo.config is there first. Yay config. > > > > - If the middleware _is_ optional, then I really feel this problem is > > solved by pastedeploy's filter_factory pattern. It lets you define as > > many required parameters as you want, and spits back a middleware > > instance. That way you have the freedom to set whatever configuration > > options you want, or omit the middleware altogether. > > > > http://pythonpaste.org/deploy/#paste-filter-factory > > > > Ultimately, what you should want is to ask a factory method for a thing > > with some configuration options, and it spits an instance back at you. > > If your project doesn't support pastedeploy, that limits your options > > (ahem-ironic-ahem). Otherwise, it's really a team decision on whether > > something is a 'Fundamental feature' or something that's optional. > > > > In the case of Ceilometer? Sorry, but I think it's optional. You should > > be able to run any component of openstack without ceilometer. So I don't > > really think it should depend on oslo_config. > > Ok, here is where I'm confused. Ceilometer middleware *already* depends > on oslo_config. > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42 > > And it does stuff with it here: > > https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107 > > But regardless, it uses oslo_messaging, which uses oslo_config. So it > seems like the only issue at hand is middleware retriggering conf parsing. > > Because the current model of requiring simultaneous code lands in > oslo_messaging and ceilometermiddleware, and simultaneous config updates > in every installer and config management system to configure the same > thing in 2 different ways, does seem like a long term win. And honestly > just prohibits most of what people seem to want to do with new messaging > approaches. I explained this on IRC, but I'll repeat it here as a more permanent record. We should not have the ceilometer middleware (re)initializing oslo.config. That combines 2 concerns (setting up configuration and doing whatever ceilometermiddleware is already doing) in one piece of middleware, and that will make it more difficult to combine ceilometermiddleware with other middleware that also wants access to the configuration settings. If the application code isn't setting up oslo.config, then we should have another piece of middleware do just that one thing. It can take options from paste's config to tell it how to do that work, and then other middleware later in the pipeline can rely on oslo.config being set up and the config files being loaded. 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On 06/22/2015 01:15 PM, Michael Krotscheck wrote: > Having _just_ done this, a couple of suggestions. > > - If the middleware is NOT optional - that is, it provides some kind of > a fundamental component or specification of the API, like ETag caching, > CORS, or DB Session management - then the middleware should be added > during the app initialization routine, likely in the app factory. In > this case, we have tight control over the initialization order, and can > make sure that oslo.config is there first. Yay config. > > - If the middleware _is_ optional, then I really feel this problem is > solved by pastedeploy's filter_factory pattern. It lets you define as > many required parameters as you want, and spits back a middleware > instance. That way you have the freedom to set whatever configuration > options you want, or omit the middleware altogether. > > http://pythonpaste.org/deploy/#paste-filter-factory > > Ultimately, what you should want is to ask a factory method for a thing > with some configuration options, and it spits an instance back at you. > If your project doesn't support pastedeploy, that limits your options > (ahem-ironic-ahem). Otherwise, it's really a team decision on whether > something is a 'Fundamental feature' or something that's optional. > > In the case of Ceilometer? Sorry, but I think it's optional. You should > be able to run any component of openstack without ceilometer. So I don't > really think it should depend on oslo_config. Ok, here is where I'm confused. Ceilometer middleware *already* depends on oslo_config. https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42 And it does stuff with it here: https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107 But regardless, it uses oslo_messaging, which uses oslo_config. So it seems like the only issue at hand is middleware retriggering conf parsing. Because the current model of requiring simultaneous code lands in oslo_messaging and ceilometermiddleware, and simultaneous config updates in every installer and config management system to configure the same thing in 2 different ways, does seem like a long term win. And honestly just prohibits most of what people seem to want to do with new messaging approaches. -Sean -- Sean Dague http://dague.net __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
Having _just_ done this, a couple of suggestions. - If the middleware is NOT optional - that is, it provides some kind of a fundamental component or specification of the API, like ETag caching, CORS, or DB Session management - then the middleware should be added during the app initialization routine, likely in the app factory. In this case, we have tight control over the initialization order, and can make sure that oslo.config is there first. Yay config. - If the middleware _is_ optional, then I really feel this problem is solved by pastedeploy's filter_factory pattern. It lets you define as many required parameters as you want, and spits back a middleware instance. That way you have the freedom to set whatever configuration options you want, or omit the middleware altogether. http://pythonpaste.org/deploy/#paste-filter-factory Ultimately, what you should want is to ask a factory method for a thing with some configuration options, and it spits an instance back at you. If your project doesn't support pastedeploy, that limits your options (ahem-ironic-ahem). Otherwise, it's really a team decision on whether something is a 'Fundamental feature' or something that's optional. In the case of Ceilometer? Sorry, but I think it's optional. You should be able to run any component of openstack without ceilometer. So I don't really think it should depend on oslo_config. Michael On Mon, Jun 22, 2015 at 7:59 AM Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2015-06-22 10:50:06 -0400: > > Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400: > > > On 06/22/2015 08:58 AM, Doug Hellmann wrote: > > > > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: > > > >> In extracting the contract for RPC backends in devstack (to have > most of > > > >> them live in plugins) one bit of an edge case was discovered. > > > >> > > > >> > https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 > > > >> > > > >> The connection to the RPC mechanism from ceilometermiddleware > inside of > > > >> swift uses a transport url instead of an oslo.messaging config > block. > > > >> > > > >> ceilometermiddleware requires oslo.config and oslo.messaging, so it > > > >> seems like it could use an oslo config block instead. > > > >> > > > >> One of the reasons why this seems like a better idea is that not > all the > > > >> properties of a messaging connection can be encoded in just a url > today. > > > >> For instance, Rabbit can specify heartbeating params - > > > >> > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > , > > > >> and zmq needs matchmaker info - > > > >> > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > > > >> > > > >> (Note: zmq is not currently able to be configured for swift + > ceilometer > > > >> today > > > >> > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > > > >> and given what it needs in it's config, it's not clear that it > would be > > > >> reasonable to do so.) > > > >> > > > >> Could we deprecate the use of tranport_url in ceilometermiddleware > and > > > >> move to an actual oslo.config file somewhere instead? That would > bring > > > >> it in line with the rest of the RPC configuration for services, and > > > >> ensure that all connections in a cluster have access to all the same > > > >> options. > > > > > > > > Swift doesn't use oslo.config, so we might need to make the > middleware > > > > support both configuration mechanisms. > > > > > > Right, but ceilometermiddleware does. Can't it load it's config from a > > > side channel? Or is it only possible for it to load it's config from > the > > > same file as swift? > > > > Library code that uses oslo.config relies on having an initialized > > configuration object, which means something has specified the files > > to be loaded, handled command line argument parsing, etc. We wouldn't > > want the middleware doing that, because doing it properly requires > > knowing the name of the application it's running in and what some > > of the application-specific defaults should be, and those are usually > > best left to the application. > > We had a similar issue with the CORS middleware needing a config object. > Perhaps we need a piece of middleware to set up the config using > parameters coming in from the paste.ini (application, name, default > config file, etc.). If that middleware sets up the global config > instance, other middleware could be written to rely on it being earlier > in the pipline. > > 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
Re: [openstack-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
Excerpts from Doug Hellmann's message of 2015-06-22 10:50:06 -0400: > Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400: > > On 06/22/2015 08:58 AM, Doug Hellmann wrote: > > > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: > > >> In extracting the contract for RPC backends in devstack (to have most of > > >> them live in plugins) one bit of an edge case was discovered. > > >> > > >> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 > > >> > > >> The connection to the RPC mechanism from ceilometermiddleware inside of > > >> swift uses a transport url instead of an oslo.messaging config block. > > >> > > >> ceilometermiddleware requires oslo.config and oslo.messaging, so it > > >> seems like it could use an oslo config block instead. > > >> > > >> One of the reasons why this seems like a better idea is that not all the > > >> properties of a messaging connection can be encoded in just a url today. > > >> For instance, Rabbit can specify heartbeating params - > > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, > > >> and zmq needs matchmaker info - > > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > > >> > > >> (Note: zmq is not currently able to be configured for swift + ceilometer > > >> today > > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > > >> and given what it needs in it's config, it's not clear that it would be > > >> reasonable to do so.) > > >> > > >> Could we deprecate the use of tranport_url in ceilometermiddleware and > > >> move to an actual oslo.config file somewhere instead? That would bring > > >> it in line with the rest of the RPC configuration for services, and > > >> ensure that all connections in a cluster have access to all the same > > >> options. > > > > > > Swift doesn't use oslo.config, so we might need to make the middleware > > > support both configuration mechanisms. > > > > Right, but ceilometermiddleware does. Can't it load it's config from a > > side channel? Or is it only possible for it to load it's config from the > > same file as swift? > > Library code that uses oslo.config relies on having an initialized > configuration object, which means something has specified the files > to be loaded, handled command line argument parsing, etc. We wouldn't > want the middleware doing that, because doing it properly requires > knowing the name of the application it's running in and what some > of the application-specific defaults should be, and those are usually > best left to the application. We had a similar issue with the CORS middleware needing a config object. Perhaps we need a piece of middleware to set up the config using parameters coming in from the paste.ini (application, name, default config file, etc.). If that middleware sets up the global config instance, other middleware could be written to rely on it being earlier in the pipline. 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On 22/06/15 09:02 AM, Sean Dague wrote: On 06/22/2015 08:58 AM, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: In extracting the contract for RPC backends in devstack (to have most of them live in plugins) one bit of an edge case was discovered. https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 The connection to the RPC mechanism from ceilometermiddleware inside of swift uses a transport url instead of an oslo.messaging config block. ceilometermiddleware requires oslo.config and oslo.messaging, so it seems like it could use an oslo config block instead. One of the reasons why this seems like a better idea is that not all the properties of a messaging connection can be encoded in just a url today. For instance, Rabbit can specify heartbeating params - https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, and zmq needs matchmaker info - https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 (Note: zmq is not currently able to be configured for swift + ceilometer today https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 and given what it needs in it's config, it's not clear that it would be reasonable to do so.) Could we deprecate the use of tranport_url in ceilometermiddleware and move to an actual oslo.config file somewhere instead? That would bring it in line with the rest of the RPC configuration for services, and ensure that all connections in a cluster have access to all the same options. Swift doesn't use oslo.config, so we might need to make the middleware support both configuration mechanisms. Right, but ceilometermiddleware does. Can't it load it's config from a side channel? Or is it only possible for it to load it's config from the same file as swift? i coded it under the impression of the latter -- the "swift not using oslo" part made me have to make a few adjustments. i'd be happy to accommodate both options if it's possible. -- gord __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400: > On 06/22/2015 08:58 AM, Doug Hellmann wrote: > > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: > >> In extracting the contract for RPC backends in devstack (to have most of > >> them live in plugins) one bit of an edge case was discovered. > >> > >> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 > >> > >> The connection to the RPC mechanism from ceilometermiddleware inside of > >> swift uses a transport url instead of an oslo.messaging config block. > >> > >> ceilometermiddleware requires oslo.config and oslo.messaging, so it > >> seems like it could use an oslo config block instead. > >> > >> One of the reasons why this seems like a better idea is that not all the > >> properties of a messaging connection can be encoded in just a url today. > >> For instance, Rabbit can specify heartbeating params - > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, > >> and zmq needs matchmaker info - > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > >> > >> (Note: zmq is not currently able to be configured for swift + ceilometer > >> today > >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > >> and given what it needs in it's config, it's not clear that it would be > >> reasonable to do so.) > >> > >> Could we deprecate the use of tranport_url in ceilometermiddleware and > >> move to an actual oslo.config file somewhere instead? That would bring > >> it in line with the rest of the RPC configuration for services, and > >> ensure that all connections in a cluster have access to all the same > >> options. > > > > Swift doesn't use oslo.config, so we might need to make the middleware > > support both configuration mechanisms. > > Right, but ceilometermiddleware does. Can't it load it's config from a > side channel? Or is it only possible for it to load it's config from the > same file as swift? Library code that uses oslo.config relies on having an initialized configuration object, which means something has specified the files to be loaded, handled command line argument parsing, etc. We wouldn't want the middleware doing that, because doing it properly requires knowing the name of the application it's running in and what some of the application-specific defaults should be, and those are usually best left to the application. 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
On 06/22/2015 08:58 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: >> In extracting the contract for RPC backends in devstack (to have most of >> them live in plugins) one bit of an edge case was discovered. >> >> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 >> >> The connection to the RPC mechanism from ceilometermiddleware inside of >> swift uses a transport url instead of an oslo.messaging config block. >> >> ceilometermiddleware requires oslo.config and oslo.messaging, so it >> seems like it could use an oslo config block instead. >> >> One of the reasons why this seems like a better idea is that not all the >> properties of a messaging connection can be encoded in just a url today. >> For instance, Rabbit can specify heartbeating params - >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, >> and zmq needs matchmaker info - >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 >> >> (Note: zmq is not currently able to be configured for swift + ceilometer >> today >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 >> and given what it needs in it's config, it's not clear that it would be >> reasonable to do so.) >> >> Could we deprecate the use of tranport_url in ceilometermiddleware and >> move to an actual oslo.config file somewhere instead? That would bring >> it in line with the rest of the RPC configuration for services, and >> ensure that all connections in a cluster have access to all the same >> options. > > Swift doesn't use oslo.config, so we might need to make the middleware > support both configuration mechanisms. Right, but ceilometermiddleware does. Can't it load it's config from a side channel? Or is it only possible for it to load it's config from the same file as swift? -Sean -- Sean Dague http://dague.net __ 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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400: > In extracting the contract for RPC backends in devstack (to have most of > them live in plugins) one bit of an edge case was discovered. > > https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 > > The connection to the RPC mechanism from ceilometermiddleware inside of > swift uses a transport url instead of an oslo.messaging config block. > > ceilometermiddleware requires oslo.config and oslo.messaging, so it > seems like it could use an oslo config block instead. > > One of the reasons why this seems like a better idea is that not all the > properties of a messaging connection can be encoded in just a url today. > For instance, Rabbit can specify heartbeating params - > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, > and zmq needs matchmaker info - > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > > (Note: zmq is not currently able to be configured for swift + ceilometer > today > https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 > and given what it needs in it's config, it's not clear that it would be > reasonable to do so.) > > Could we deprecate the use of tranport_url in ceilometermiddleware and > move to an actual oslo.config file somewhere instead? That would bring > it in line with the rest of the RPC configuration for services, and > ensure that all connections in a cluster have access to all the same > options. Swift doesn't use oslo.config, so we might need to make the middleware support both configuration mechanisms. 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-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
In extracting the contract for RPC backends in devstack (to have most of them live in plugins) one bit of an edge case was discovered. https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388 The connection to the RPC mechanism from ceilometermiddleware inside of swift uses a transport url instead of an oslo.messaging config block. ceilometermiddleware requires oslo.config and oslo.messaging, so it seems like it could use an oslo config block instead. One of the reasons why this seems like a better idea is that not all the properties of a messaging connection can be encoded in just a url today. For instance, Rabbit can specify heartbeating params - https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287, and zmq needs matchmaker info - https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 (Note: zmq is not currently able to be configured for swift + ceilometer today https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287 and given what it needs in it's config, it's not clear that it would be reasonable to do so.) Could we deprecate the use of tranport_url in ceilometermiddleware and move to an actual oslo.config file somewhere instead? That would bring it in line with the rest of the RPC configuration for services, and ensure that all connections in a cluster have access to all the same options. -Sean -- Sean Dague http://dague.net __ 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
