Anaconda spoke workflow

[Pat Riehecky]

I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.

The spoke is optional (@property mandatory = False and @property
completed = True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.

My initial thoughts were to make @property ready return the value of
pyanaconda.nm.nm_is_connected(). However, if the network is never
connected then spoke is never ready and therefore install can never proceed.

Are there any suggestions for how I can get what I'm looking for where
the user can't use the spoke without the network but the spoke doesn't
block the install?

anaconda-19.31.123

Pat

[Brian C. Lane]

Post by Pat Riehecky
I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.
pyanaconda.nm.nm_is_connected(). However, if the network is never connected
then spoke is never ready and therefore install can never proceed.
Are there any suggestions for how I can get what I'm looking for where the
user can't use the spoke without the network but the spoke doesn't block the
install?
anaconda-19.31.123

Is there any state where you want the spoke to block the install, or are
you just trying to block entry into the spoke when the network is down?
Looking at the current code I'm not sure there is a way to block spoke
entry for always ready non-mandatory spokes.

[Pat Riehecky]

Post by Brian C. Lane

Post by Pat Riehecky
I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.
pyanaconda.nm.nm_is_connected(). However, if the network is never connected
then spoke is never ready and therefore install can never proceed.
Are there any suggestions for how I can get what I'm looking for where the
user can't use the spoke without the network but the spoke doesn't block the
install?
anaconda-19.31.123

Is there any state where you want the spoke to block the install, or are
you just trying to block entry into the spoke when the network is down?
Looking at the current code I'm not sure there is a way to block spoke
entry for always ready non-mandatory spokes.

There is no state where I want this spoke to block the install. I'd
prefer to prevent users from entry into the spoke until the network is up.

For now I'll just set the various properties in the interface read-only
when the network is down.

Pat

[Brian C. Lane]

Post by Brian C. Lane

Post by Pat Riehecky
I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.
pyanaconda.nm.nm_is_connected(). However, if the network is never connected
then spoke is never ready and therefore install can never proceed.
Are there any suggestions for how I can get what I'm looking for where the
user can't use the spoke without the network but the spoke doesn't block the
install?
anaconda-19.31.123

Is there any state where you want the spoke to block the install, or are
you just trying to block entry into the spoke when the network is down?
Looking at the current code I'm not sure there is a way to block spoke
entry for always ready non-mandatory spokes.

There is no state where I want this spoke to block the install. I'd prefer
to prevent users from entry into the spoke until the network is up.
For now I'll just set the various properties in the interface read-only when
the network is down.

That looks like how you'll have to do it. Maybe also set the info bar at
the bottom to tell them why.

[Pat Riehecky]

Post by Brian C. Lane

Post by Brian C. Lane

Post by Pat Riehecky
I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.
pyanaconda.nm.nm_is_connected(). However, if the network is never connected
then spoke is never ready and therefore install can never proceed.
Are there any suggestions for how I can get what I'm looking for where the
user can't use the spoke without the network but the spoke doesn't block the
install?
anaconda-19.31.123

Is there any state where you want the spoke to block the install, or are
you just trying to block entry into the spoke when the network is down?
Looking at the current code I'm not sure there is a way to block spoke
entry for always ready non-mandatory spokes.

There is no state where I want this spoke to block the install. I'd prefer
to prevent users from entry into the spoke until the network is up.
For now I'll just set the various properties in the interface read-only when
the network is down.

That looks like how you'll have to do it. Maybe also set the info bar at
the bottom to tell them why.

Do you have some example code I can look at for how to set the info bar?

Pat

[Chris Lumens]

Post by Pat Riehecky
Do you have some example code I can look at for how to set the info bar?

Look for any of set_error, set_info, or set_warning in the spokes
directory.

- Chris

[Leslie S Satenstein]

Hi,I'm an end user. I do very frequent installations of Fedora Remixes, Spins and Workstation.  Here is what I note.On the spoke wheel, behind the scenes, there is an update from the repositories in the ISO.  Some of the times, if one is on a slower than average mirror, it appears that the system is locked up.
A wait here during software update may take up to five minutes.   During during the wait for Software Selection update, I update my hostname, the keyboard layout and timezones. I noted that until the software selection  action is completed, I am unable to select and update disk selections. I thought that disk selection and software selection were independent tasks.

Is there a possibility, during the redesign of anaconda, to add a spinner, with an indication that infact, data is being transferred?
For the device selection and partition management, this part needs some rework.  We should have the ability, when selecting the option to make additional disk space available, to allow us to delete partitions located on the disks shown in the window. My last recall, it was a "all or nothing" against a chosen disk.  My practice now is to use gparted to make a contiguous unallocated partition. Can this kind of facility be improved upon?
I have also thought about other presentations regarding allocationsHere is an idea..

Considered a three columns layout,
The first has listed, the partitions such as / home, boot root, opt, swap var etc.   A middle column where partitions are presented, and a third column where the disks with those partition areas that I want to use shown linked to entries in the middle column.  In the text mode, this three column concept can be included.

The final feedback I have is about the spoke menu  is to improve help facility by providing more information. Helpful would be an extra spoke for the release notes.

If I look at the actual installation operation, one frustration I had is with anaconda's use of the ram /tmp. May I present the following idea.

Before /mnt/sysimage is setup with /var, allow anaconda to do the logging to the mentioned /tmp directory. Once the physical disk has a /var, Allow anaconda to immediately create a /var/log/anaconda. Anaconda should stop logging to /tmp and immediately begin writing the log files to /var/log/anaconda.  The initial /tmp log files may  be copied to the /var/log/anaconda prior to the switch, or at the very end of anaconda execution, as is currently done.

Why that change?  Some older versions of anaconda crashed before the installation was completed. I was using a USB flashdrive (dd if=Fedora.iso of=/myflash bs=1M && sync; ).   With dd, there is no space left on the USB drive onto which to store the /tmp file data, needed  if one is asked to create bugzilla output.  Because of my frequent use of anaconada, when problems arise, I copy the /tmp files to /mnt/sysimage/var/log/anaconda.  Don't want to make changes, then document this option.

Make the user experience easier, especially when problems arise.

What about the cloud facility. Why can't one of my disks be in the cloud?

Thanks for reading this email.


 Regards
 Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada





From: Brian C. Lane <***@redhat.com>
To: anaconda-devel-***@redhat.com
Sent: Monday, January 4, 2016 12:48 PM
Subject: Re: Anaconda spoke workflow

Post by Brian C. Lane

Post by Pat Riehecky
I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
True).
It only makes sense to manipulate the spoke's data after the network has
come online.
If nothing is set on the spoke, this is fine and no actions are performed.
pyanaconda.nm.nm_is_connected().  However, if the network is never connected
then spoke is never ready and therefore install can never proceed.
Are there any suggestions for how I can get what I'm looking for where the
user can't use the spoke without the network but the spoke doesn't block the
install?
anaconda-19.31.123

Is there any state where you want the spoke to block the install, or are
you just trying to block entry into the spoke when the network is down?
Looking at the current code I'm not sure there is a way to block spoke
entry for always ready non-mandatory spokes.

There is no state where I want this spoke to block the install.  I'd prefer
to prevent users from entry into the spoke until the network is up.
For now I'll just set the various properties in the interface read-only when
the network is down.

That looks like how you'll have to do it. Maybe also set the info bar at
the bottom to tell them why.

[David Lehman]

Post by Leslie S Satenstein
For the device selection and partition management, this part needs
some rework. We should have the ability, when selecting the option
to make additional disk space available, to allow us to delete
partitions located on the disks shown in the window. My last recall,
it was a "all or nothing" against a chosen disk. My practice now is

You have the option of removing specific partitions whether you use the
guided or custom/manual storage configuration path. In fact, I don't
see how it's possible to perform an installation and not be aware of
this unless you always start with all blank disks.

David