Thanks, once it's pushed please send me the PR so I can have a look :).
On Thu, Aug 11, 2016 at 9:45 PM, Daniel Oliveira <doliveira@xxxxxxxx> wrote:
> Sebastien,
>
> Yes, I am ok with it and finished implementing it all (including the
> behavior for unchanged settings) and planning on creating a PR still
> today on this.
>
> -Daniel
>
>
> On Thu, 2016-08-11 at 10:16 +0200, Sebastien Han wrote:
>> Daniel,
>>
>> Are you fine with my answer?
>> Just trying to keep the main subject alive here :).
>>
>> On Wed, Aug 10, 2016 at 12:34 PM, Shinobu Kinjo <shinobu.kj@xxxxxxxxx
>> > wrote:
>> > Daniel,
>> >
>> > On Wed, Aug 10, 2016 at 9:03 AM, Daniel Oliveira <
>> > doliveira@xxxxxxxx> wrote:
>> > > Shinobu,
>> > >
>> > > Sorry, but I am not sure I understand what your request is. If it
>> > > is
>> > > not related to Sebastien's feature request, we probably would
>> > > need a
>> > > different one so we can track it properly. Are you referring to a
>> > > *config file parser* kind of thing, where some checking is done
>> > > to make
>> > > sure settings are in the proper section? Or am I missing
>> > > something?
>> >
>> > Yes, that is exactly what I said.
>> > Does that capabilities make sense?
>> >
>> > >
>> > > -Daniel
>> > >
>> > >
>> > >
>> > > On Tue, 2016-08-09 at 19:51 +0900, Shinobu Kinjo wrote:
>> > > > 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
>> > > >
>> > > >
>> > > >
>> > > --
>> > > 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
>>
>>
>>
--
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
