Re: Adding experimental arguments to nmcli tool

2022-03-08 Thread Thomas Haller via networkmanager-list
On Tue, 2022-03-08 at 22:15 +0100, Thomas Haller wrote:
> of course, that's just an example to show all pieces. Above could be
> written shorter as:
> 
>    nmcli connection modify $PROFILE --keyfile | \
>    nmcli connection modify keyfile \
>     connection.uuid $(uuidgen) \
>     autoconnect no
> 

interestingly, if you don't modify the UUID, then the profile would
already exist, and the command would not add a new profile, but
actually overwrite the existing one.

Actually, we could in general support

  nmcli connection modify "$PROFILE" connection.uuid $(uuidgen) $OPTIONS

as a way to add/clone a profile, and modifying it
... and determining the UUID (currently you cannot specify the UUID of
a new profile via nmcli).

That would be then similar to the existing

  nmcli connection clone $PROFILE1 $NAME2

except, that clone currently does not support $OPTIONS -- but it really
should, for completeness.


I am not saying that all these options should be actually implemented
(especially not in step 1). But that they might make sense in the grand
scheme of things. So it's useful to think about how that would be.



best,
Thomas

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Adding experimental arguments to nmcli tool

2022-03-08 Thread Thomas Haller via networkmanager-list
Hi,

On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via
networkmanager-list wrote:
> Hello everyone!
> 
> The proposed experimental solutions are:
> 
> 1. 'nmcli c show --keyfile $UUID' to output the profile keyfile in
> stdout.
> 2. 'nmcli c add ... --keyfile' to output the generated keyfile in
> stdout 
> instead of adding it to the NetworkManager configuration so the 
> NetworkManager daemon is not required..


re:2.: this `nmcli c add --keyfile` does not actually add the profile
in NM (via D-Bus). That's a bit odd, but ok(?).



what you also need is:

3. I think in this set, it would also make sense to have a `nmcli c
modify "$PROFILE" --keyfile $OPTIONS`, which reads $PROFILE from D-Bus,
modifies it in-memory and prints the result to stdout.

4. none of the above commands allow to add a profile from stdin. That
is necessary to tie it all together. This could be for example `nmcli
connection modify keyfile $OPTIONS`. Here, "keyfile" means to read a
keyfile from stdin. The result would be then added via D-Bus -- which
is a bid odd, that `nmcli connection modify` creates a new profile in
NM. On the other hand, it really does take a profile (from stdin),
modify it, and add it somewhere.

5. finally, `nmcli connection modify keyfile --keyfile $OPTIONS` would
read the profile from stdin, modify it, and output again to stdout.


then you can do:

   nmcli connection modify $PROFILE --keyfile | \
   nmcli connection modify keyfile \
connection.uuid $(uuidgen) \
autoconnect no \
--keyfile | \
   nmcli connection modify keyfile

of course, that's just an example to show all pieces. Above could be
written shorter as:

   nmcli connection modify $PROFILE --keyfile | \
   nmcli connection modify keyfile \
connection.uuid $(uuidgen) \
autoconnect no



these are the basic operations. I don't have a strong opinion about the
actual command line options (though, I find it odd that `nmcli-c-
modify` adds a profile).


---

also, when editing/outputting keyfile format, eventually you want to
write it to a file. With above, the user could do:

   nmcli connection show $PROFILE --keyfile > 
/etc/NetworkManager/system-connections/myfile.nmconnection

the problem with this is that umask is likely wrong, so you'd need to do `chmod 
600` (and `nmcli connection load $FILENAME`).
Maybe --keyfile could accept a filename, like 

   nmcli connection show $PROFILE 
--keyfile=/etc/NetworkManager/system-connections/myfile.nmconnection


so that nmcli gets the permissions right and (opt-in or opt-out) load
the file in NM.


Also, keyfiles can only be in 3 well-known locations:
 A) /var/lib/NetworkManager/system-connections/
 B) /etc/NetworkManager/system-connections/
 C) /run/NetworkManager/system-connections/
these are the default paths, but they depend on the $PREFIX during
compilation. Also, B) can be configured in NetworkManager.conf as
[keyfile].path.

Anyway. With this, maybe it would make sense to have shortcuts:

   nmcli connection show $PROFILE --keyfile=etc:myfile.nmconnection





best,
Thomas

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Adding experimental arguments to nmcli tool

2022-03-08 Thread Thomas Haller via networkmanager-list
On Tue, 2022-03-08 at 14:57 +0100, Till Maas wrote:
> Hi,
> 
> Am Mo., 7. März 2022 um 22:38 Uhr schrieb Thomas Haller via
> networkmanager-list :
> > Hi,
> > 
> > On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via
> > networkmanager-list wrote:
> > > 
> > > It has been considered to add experimental new arguments to
> > > 'nmcli'
> > > tool 
> > > related to keyfiles. These arguments will be added with a warning
> > > message on documentation specifying they are experimental. The
> > > main
> > > idea 
> > > is to experiment and not commit to them for a long time.
> > 
> > re:experimental.
> > 
> > I don't think it's good to mark new API as experimental. Breaking
> > API
> > is annoying to users, and should only be done if there are very
> > very
> > good reasons or when no users are affected. Otherwise, the
> > annoyance is
> > the same regardless whether the API is marked as experimental. With
> > the
> > difference, that if the API was experimental, it has the notion of
> > being the fault of the user using the API (which it really isn't).
> > 
> 
> 
> Currently, the API is not delivered to users since there is no
> agreement on how to do it.
> For example the features that Fernando mentioned are not that complex
> to code but hard to find an agreement on for the command-line flags.
> Therefore, the possible annoyance of users is solved by not giving
> them a choice at all, They simply cannot use the API, therefore they
> will also not have to change it. By delivering something as
> experimental, the users get a choice: They
> can use it and accept that they might have to adapt or they can
> choose not to use it and be in the same situation as if we did not
> deliver the API at all. Basically, we will provide additional value
> to early adopters, unblock our development (the code can be written
> already) and once there is an agreement on the final API, only small
> changes would be necessary if at all. Therefore, adding experimental
> features seem to be an overall benefit.


Let's just discuss how the feature should be done. Which is not a very
controversial or hard question.

I think it's not necessary to have a meta discussion about the process
how we do it. And it's not necessary to introduce an "experimental"
API, when we can just add the real thing.

We can find agreement on the real thing, at which point it's not
experimental. That in the future the choice might turn out to be
suboptimal, is always the danger and not special about this.


best,
Thomas

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Adding experimental arguments to nmcli tool

2022-03-08 Thread Till Maas via networkmanager-list
Hi,

Am Mo., 7. März 2022 um 22:38 Uhr schrieb Thomas Haller via
networkmanager-list :

> Hi,
>
> On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via
> networkmanager-list wrote:
> >
> > It has been considered to add experimental new arguments to 'nmcli'
> > tool
> > related to keyfiles. These arguments will be added with a warning
> > message on documentation specifying they are experimental. The main
> > idea
> > is to experiment and not commit to them for a long time.
>
> re:experimental.
>
> I don't think it's good to mark new API as experimental. Breaking API
> is annoying to users, and should only be done if there are very very
> good reasons or when no users are affected. Otherwise, the annoyance is
> the same regardless whether the API is marked as experimental. With the
> difference, that if the API was experimental, it has the notion of
> being the fault of the user using the API (which it really isn't).
>

Currently, the API is not delivered to users since there is no agreement on
how to do it. For example the features that Fernando mentioned are not that
complex to code but hard to find an agreement on for the command-line
flags. Therefore, the possible annoyance of users is solved by not giving
them a choice at all, They simply cannot use the API, therefore they will
also not have to change it. By delivering something as experimental, the
users get a choice: They can use it and accept that they might have to
adapt or they can choose not to use it and be in the same situation as if
we did not deliver the API at all. Basically, we will provide additional
value to early adopters, unblock our development (the code can be written
already) and once there is an agreement on the final API, only small
changes would be necessary if at all. Therefore, adding experimental
features seem to be an overall benefit.

Cheers
Till



-- 
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Adding experimental arguments to nmcli tool

2022-03-07 Thread Thomas Haller via networkmanager-list
Hi,

On Mon, 2022-03-07 at 12:54 +0100, Fernando F. Mancera via
networkmanager-list wrote:
> 
> It has been considered to add experimental new arguments to 'nmcli'
> tool 
> related to keyfiles. These arguments will be added with a warning 
> message on documentation specifying they are experimental. The main
> idea 
> is to experiment and not commit to them for a long time.

re:experimental.

I don't think it's good to mark new API as experimental. Breaking API
is annoying to users, and should only be done if there are very very
good reasons or when no users are affected. Otherwise, the annoyance is
the same regardless whether the API is marked as experimental. With the
difference, that if the API was experimental, it has the notion of
being the fault of the user using the API (which it really isn't).

We can never be 100% sure that an API is perfectly future proof. We can
just think hard and try to make the best choices now. And if something
turns out not to be optimal, we treat that like we always do.


best,
Thomas


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list