On Wed, Jul 29, 2015 at 12:01 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:
>
> add to fuel-menu ability to load yaml file with network scheme.
>> However, I can't predict how serial console can live with zmodem (or
>> something else serial communication protocol) on the same serial por
Hi,
On Wed, Jul 29, 2015 at 10:19 AM, Sergey Vasilenko
wrote:
> add to fuel-menu ability to load yaml file with network scheme.
> However, I can't predict how serial console can live with zmodem (or
> something else serial communication protocol) on the same serial port.
>
Why should we overcom
On Wed, Jul 29, 2015 at 7:08 AM, Mike Scherbakov
wrote:
> Looks like Fuel Menu can't solve this one. Is there workaround possible
> (even with worse UX)?
add to fuel-menu ability to load yaml file with network scheme.
However, I can't predict how serial console can live with zmodem (or
somethin
Guys,
how do we deal with use case provide in this bug:
https://bugs.launchpad.net/fuel/7.0.x/+bug/1438658
?
Looks like Fuel Menu can't solve this one. Is there workaround possible
(even with worse UX)?
On Fri, Jul 24, 2015 at 5:26 AM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Guys,
Guys, thanks a lot for your opinions. Now it is quite clear for me that
vim+text UX is definitely not our way even though many developers (not all)
prefer this.
Vladimir Kozhukalov
On Fri, Jul 24, 2015 at 12:47 AM, Fabrizio Soppelsa
wrote:
> Hello Vladimir, from me -1.
>
> We can discuss if en
Hello Vladimir, from me -1.
We can discuss if enable fuelmenu=yes or not in grub, but I wouldn't get
rid of it. I've never heard complaints against fuelmenu from users, and
it's widely used for basic settings afterinstall.
If the users had to manually edit another configuration file, should
I'm against getting rid of fuelmenu. As Alex wrote - we need to remember
who are the people that we are targeting.
We are adding multiple dialog windows with confirmations, warnings and
special way to do dangerous actions
(like environment deletion or reset), but in the same time we want to force
u
For this to be consumable by end-users, a config file and editor (vim
seriously?) is terrible UX. We need to remember who we are targeting to
consume this functionality as it may not be an expert or even someone
absolutely familiar with the linux tool set. While the existing thing may
be awkward,
-1 for using kernel parameters for configuring the whole master node
installation. User should be able to edit configuration and then re-deploy
the master node. I have no idea what would UX look like if we used kernel
paramenters.
Vladimir Kozhukalov
On Thu, Jul 23, 2015 at 7:49 PM, Vladimir Kozh
The topic is NOT 'get rid of validation' but rather 'get rid of
semi-graphical ncurses based interface'. It is not so hard to adopt every
piece of validation we currently have in fuelmenu and implement even more
including syntax validation using, for example, PLY and logic validation.
My idea is to
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn
mailto:mmoses...@mirantis.com>> wrote:
Here's a relic of what users used to have to configure by
hand:
https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/s
Oleg, those parameters are no longer documented (because there was no
validation) and are absent from the Fuel User Guide. They are,
however, still used by fuel-qa scripts.
On Thu, Jul 23, 2015 at 5:26 PM, Oleg Gelbukh wrote:
> Unless I am mistaken, it is possible to set most of the parameters su
Hi,
> Am I alone in thinking it's not the best use of our development
> resources to throw it away and replace it with a text file that is
> edited by hand?
Nope. I'm with you :)
> Many people prefer vim UX instead of wandering through the semi-graphical
interface.
Are those ppl developers or e
Unless I am mistaken, it is possible to set most of the parameters
supported by Fuel menu as kernel boot parameters. Isn't it sufficient
replacement for fuelmenu for dev's purposes?
-Oleg
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn
wrote:
> How much effort are we spending? I'm not so sure
How much effort are we spending? I'm not so sure it's a major development drain.
Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
commits into Fuelmenu:
* New features/functionality: 12
* Bugfix: 15
* Other: 7 (version bumps, and commits without bug ID)
Across 3 releases, that's
Hello,
Here's my 2 cents on it.
I think the effort we put to support fuelmenu doesn't worth it. I used
to deploy fuel too often in previous release, and I never used
features of fuelmenu? Why? Because I prefer to apply changes on
already deployed node. Moreover, I don't like that users are prompt
We had that before and had very poor validation. Removing fuelmenu
would make the experience quite manual and prone to errors.
This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.
The actual Fuel deployer
Dear colleagues,
What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro of
this is that text file is easier to extend and edit. Many people prefer vim
UX instead of wandering through the semi-graphical interface.
18 matches
Mail list logo
