Just question.
Do we have already something like config file validation check command?
If not, it would be better to add this capability for end users if it
would not burden you.
Because it's not a bit clear about which option must be in which section.
Thoughts?
- Shinobu
On Tue, Aug 9, 2016 at 6:52 PM, Sebastien Han <shan@xxxxxxxxxx> wrote:
> Thanks a lot Daniel, that looks exactly right.
> If nothing changed I think it's valid to keep both fields showing the
> same value.
> This is either when comparing with whatever tool because the structure
> won't change so we don't have to handle a particular case.
>
> Others? Thoughts?
>
> On Tue, Aug 9, 2016 at 4:38 AM, Daniel Oliveira <doliveira@xxxxxxxx> wrote:
>> Sebastien,
>>
>> For now, We have something like this (which follows the same standard
>> as 'config diff' and 'config get' :
>>
>> #1:
>> ./ceph --admin-daemon out/osd.1.asok config diff get
>> mon_data_avail_crit
>> {
>> "diff": {
>> "current": {
>> "mon_data_avail_crit": "1"
>> },
>> "defaults": {
>> "mon_data_avail_crit": "5"
>> }
>> },
>> "unknown": []
>> }
>>
>> ./ceph --admin-daemon out/osd.1.asok config diff get
>> mon_data_avail_warn
>> {
>> "diff": {
>> "current": {
>> "mon_data_avail_warn": "10"
>> },
>> "defaults": {
>> "mon_data_avail_warn": "30"
>> }
>> },
>> "unknown": []
>> }
>>
>> What would be the proper way to display a setting that *was not*
>> changed from its default?, for example:
>> ./ceph --admin-daemon out/osd.1.asok config diff get num_client
>> {
>> "diff": {
>> "current": {},
>> "defaults": {}
>> },
>> "unknown": []
>> }
>>
>> Or only the "current" value?
>>
>> Thanks,
>> -Daniel
>>
>>
>> On Mon, 2016-08-08 at 15:32 -0600, Daniel Oliveira wrote:
>>> Sebastien,
>>>
>>> As I was working on a couple of other things related to validating
>>> parameters/settings, I ended up adding the feature in question and I
>>> am just in the process of testing it. I will keep you posted.
>>>
>>> Thanks,
>>> -Daniel
>>>
>>>
>>> On Mon, 2016-08-08 at 14:16 +0200, Sebastien Han wrote:
>>> > Would be nice if you could get a stab at it, actually I don't know
>>> > where to look in the code to see where the magic is happening for
>>> > the
>>> > admin socket.
>>> > Most of the logic is there so this shouldn't be too difficult :).
>>> >
>>> > Did you get a chance to look into this Jesse?
>>> > Thanks for offering your help on this one!
>>> >
>>> > On Fri, Jul 29, 2016 at 8:32 PM, Jesse Williamson <
>>> > jwilliamson@xxxxxxx> wrote:
>>> > > On Fri, 29 Jul 2016, Sebastien Han wrote:
>>> > >
>>> > > Hi Sebastien,
>>> > >
>>> > > > I'd like to have the same but for a specific option only.
>>> > > >
>>> > > > So something like:
>>> > > >
>>> > > > ceph daemon mon.ceph-mon-01 config diff get <field>
>>> > > >
>>> > > > Which will return the diff between the actual config value and
>>> > > > the
>>> > > > original config value.
>>> > >
>>> > >
>>> > > I might be able to help with this, if there's no support that
>>> > > anyone already
>>> > > knows of, or clear takers. I'm working on a small config-related
>>> > > librados
>>> > > feature right now and am somewhat familiar with the relevant
>>> > > moving parts on
>>> > > that end, so I might be in a good position to work on it.
>>> > >
>>> > > WRT the admin socket, I'm less clear, but can be pointed in the
>>> > > right
>>> > > direction. :-)
>>> > >
>>> > > -Jesse
>>> >
>>> >
>>> >
>
>
>
> --
> Cheers
>
> ––––––
> Sébastien Han
> Principal Storage Architect
>
> "Always give 100%. Unless you're giving blood."
>
> Mail: seb@xxxxxxxxxx
> Address: 11 bis, rue Roquépine - 75008 Paris
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Email:
shinobu@xxxxxxxxx
shinobu@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
