Fields changed

description: There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory. Provided state_data is opdated to point to this memory and state_data_size is updated to point to the size (in bytes) of the state data. The appname is the same as the first parameter passed to the INI reading functions config_from_file(), config_from_file_with_lines() or config_for_app(). The last parameter is the configuration object acquired by config_from_file(), config_from_file_with_lines() or config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is different. If attribute is NULL the function will compare the while section. Any additions or modifications to that section will cause the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.
=> There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory.
Provided state_data is opdated to point to this memory and
state_data_size is updated to point to the size (in bytes)
of the state data. The appname is the same as the first
parameter passed to the INI reading functions config_from_file(),
config_from_file_with_lines() or config_for_app(). The last
parameter is the configuration object acquired by
config_from_file(), config_from_file_with_lines() or
config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is
different. If attribute is NULL the function will compare the while
section. Any additions or modifications to that section will cause
the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.

version: 0.4.1 => 0.5.0

Fields changed

description: There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory. Provided state_data is opdated to point to this memory and state_data_size is updated to point to the size (in bytes) of the state data. The appname is the same as the first parameter passed to the INI reading functions config_from_file(), config_from_file_with_lines() or config_for_app(). The last parameter is the configuration object acquired by config_from_file(), config_from_file_with_lines() or config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is different. If attribute is NULL the function will compare the while section. Any additions or modifications to that section will cause the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.
=> There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory.
Provided state_data is opdated to point to this memory and
state_data_size is updated to point to the size (in bytes)
of the state data. The appname is the same as the first
parameter passed to the INI reading functions config_from_file(),
config_from_file_with_lines() or config_for_app(). The last
parameter is the configuration object acquired by
config_from_file(), config_from_file_with_lines() or
config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is
different. If attribute is NULL the function will compare the while
section. Any additions or modifications to that section will cause
the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.

version: 0.4.1 => 0.5.0

Fields changed

description: There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory. Provided state_data is opdated to point to this memory and state_data_size is updated to point to the size (in bytes) of the state data. The appname is the same as the first parameter passed to the INI reading functions config_from_file(), config_from_file_with_lines() or config_for_app(). The last parameter is the configuration object acquired by config_from_file(), config_from_file_with_lines() or config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is different. If attribute is NULL the function will compare the while section. Any additions or modifications to that section will cause the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.
=> There are many cases when if configuration changes the application needs to do something significant at the start time. Open a new file for log, rebuild some cache, reestablish or re-provision something. The INI interface should provide a way to detect this.
The usual way of doing things like that is comparing time stamp of the configuration file to some previously recorded or acquired time stamp. The issue with INI is that it can be a merge of the two ini files so it is unclear which one has changed. Another thing that needs to be taken into the account is that it might be too costly to trigger the operation on any change to the configuration file. I think the INI interface should be capable of saying did this section of config change or did this value in this section of config changed.
This generally means that INI interface should provide some sort of the "state object" against which checks can be performed.
I envision the interface as something like this:
{{{
int ini_get_state(void state_data,
size_t state_data_size,
const char appname,
struct collection_item *ini_config);

Creates an opaque "state" object and stores it in the memory.
Provided state_data is opdated to point to this memory and
state_data_size is updated to point to the size (in bytes)
of the state data. The appname is the same as the first
parameter passed to the INI reading functions config_from_file(),
config_from_file_with_lines() or config_for_app(). The last
parameter is the configuration object acquired by
config_from_file(), config_from_file_with_lines() or
config_for_app().

int ini_check_state(uint32_t changed,
void state_data,
size_t state_data_size,
struct collection_item ini_config,
const char section,
const char *attribute);

Function will set changed to non zero if the provided attribute is
different. If attribute is NULL the function will compare the while
section. Any additions or modifications to that section will cause
the function to set value of changed to non zero.
}}}

It is up to the application to deal with the state blob and store it in between the launches. Different executable will use different methods. It depends upon whether executable is a daemon utility or something else.

version: 0.4.1 => 0.5.0

Fields changed

doc: => 0
docupdated: => 0
milestone: SSSD 1.0 => SSSD Deferred
tests: => 0
testsupdated: => 0

Fields changed

doc: => 0
docupdated: => 0
milestone: SSSD 1.0 => SSSD Deferred
tests: => 0
testsupdated: => 0

Fields changed

doc: => 0
docupdated: => 0
milestone: SSSD 1.0 => SSSD Deferred
tests: => 0
testsupdated: => 0

Nice to have but low priority. Definitely after ELAPI 1.0 so we should target it for 2.0 time frame.

proposed: => 2.0

Nice to have but low priority. Definitely after ELAPI 1.0 so we should target it for 2.0 time frame.

proposed: => 2.0

Nice to have but low priority. Definitely after ELAPI 1.0 so we should target it for 2.0 time frame.

proposed: => 2.0

This is actually a tough one. May be it should boil to just comparing two config objects?

This is actually a tough one. May be it should boil to just comparing two config objects?

This is actually a tough one. May be it should boil to just comparing two config objects?

For the compare part adding it to the Tools 1.0 release. The other part should probably be dropped.

milestone: SSSD Deferred => Tools 1.0

For the compare part adding it to the Tools 1.0 release. The other part should probably be dropped.

milestone: SSSD Deferred => Tools 1.0

For the compare part adding it to the Tools 1.0 release. The other part should probably be dropped.

milestone: SSSD Deferred => Tools 1.0

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

Fields changed

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

Fields changed

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

Fields changed

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

There is a way in the new interface to assess whether there were any changes to the config file.

design: =>
design_review: => 0
fedora_test_page: =>

There is a way in the new interface to assess whether there were any changes to the config file.

design: =>
design_review: => 0
fedora_test_page: =>

There is a way in the new interface to assess whether there were any changes to the config file.

design: =>
design_review: => 0
fedora_test_page: =>

Fields changed

resolution: => fixed
status: new => closed

Fields changed

resolution: => fixed
status: new => closed

Fields changed

resolution: => fixed
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1182

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.