Re: [Spacewalk-devel] Things that needs to be dobne before next release.
Silvio Moioli wrote: % On 01/09/2014 01:26 PM, Matej Kollar wrote: % Major things that we currently consider release blockers for 2.1 % from UI point of view are: %[...] %* Bare-metal systems management % Hello Silvio, % May I ask what's the status of that? Is it still planned for 2.1? Unfortunately no, we hadn't enough time to go through it. So it's been postponed after 2.1. % More importantly, is there something that prevents merging? We can help % in that case. % % From our side, we just added custom icons and I am planning to display % some more relevant data in the Bare-metal System List page in the next % weeks. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Query question regarding system.listLatestUpgradeablePackages
On 02/13/2014 05:43 AM, Jeremy D Davis wrote: My question is why use this really big query when you could use a select * from rhnserverneededcache where serverid=x and pull all the packages that way. Granted you would need to do some joins to get the correct names based on the package id but it just seem like rhnserverneededcache would be a better place to obtain the information than this long query is doing. I have not investigated all minor aspects at the moment, but a big difference I see is that rhnserverneededcache only tells you about the outdated package and not the new one. Determining the to_version, to_release, to_epoch and to_package_id outputs of listLatestUpgradablePackages is actually non trivial and I suspect it adds up quite a lot of computation. Regards, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RFC: Action Chaining mockups and ideas
On 08/01/14 13:33, Silvio Moioli wrote: Dear Spacewalk Community, here at SUSE we are about starting development on a new feature called Action Chaining, and we would like to try and get you involved from the very beginning this time. This is about scheduling a chain of actions on a server or a group of servers, instead of single operations as it is currently possible. A chain is a sequence of operations like package installs, configuration changes, reboots, etc. to be executed one after another when scheduled. To limit development time, we currently plan on supporting a subset of actions based on users' feedback we collected so far. You can find a complete list, together with a more precise description of this feature, some screenshots and mockups here: http://wiki.novell.com/index.php/SUSE_Manager/ActionChaining Note: these mockups have a SUSE Manager look and feel since they have also been used for internal discussions in SUSE. Please simply ignore the styling at this point. http://turing.suse.de/~smoioli/action-chaining-mockups/list.html I suspect this page really wants a column for when is the event scheduled to be executed. Merge/use either only created or modified, vs both - I don't think we need them both. http://turing.suse.de/~smoioli/action-chaining-mockups/editor.html This is a bit worrying, it looks like it would make it hard/complex to render information meaningfully. Because they are chained and you have different systems for each portion of the event - does it mean, you don't reboot the 10 systems, if one of the two config deployment fails? While the power to add/remove systems for each portion sounds nice, it makes my brain hurt, and I'd have to assume it would for those managing the systems - selecting X systems and being stuck to work with them only, sounds more sane approach. We appreciate your input about this, especially if there is any aspect that you consider blocking for upstreaming. Development on this feature will take place on the master-action-chaining branch on the Spacewalk repo and during in the coming weeks. I plan to regularly push commits there so that you can comment on code at any time. Hopefully this will ease acceptance checks and merging when development ends. Thanks for your cooperation in advance, I don't see anything bad in getting this into Spacewalk, or that would go against Spacewalk's future desires. Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Duncan Mac-Vicar P. wrote:
% See attached patches.
%
% They fix
%
% - time localization
% - first day of the week
% - clicking on time picker
% - autoclose
% - move the libraries to separate package
Hello Duncan,
I've reviewed and committed date picker patches. Although I have some
objections I've decided to fix it rather then send it back and forth.
...
% +private String toPhpTimeFormat(String format) {
% +String ret = format.replaceAll((a)+, a);
% +ret = ret.replaceAll((H)\\1+, H);
% +ret = ret.replaceAll((H), G);
This is wrong. It will replace HH with H and immediately H with G which
is most likely not what you meant.
% +// k (0-24) not supported, convert to the 0-23 format
% +ret = ret.replaceAll((k)\\1+, H);
% +ret = ret.replaceAll((k), G);
% +// K (0-11) not supported, convert to the 1-12 format
% +ret = ret.replaceAll((k)\\1+, h);
% +ret = ret.replaceAll((k), g);
This should likely be (K) not (k).
% +ret = ret.replaceAll((h)\\1+, h);
% +ret = ret.replaceAll((h), g);
Again hh is replaced with h and immediately h with g.
% +ret = ret.replaceAll((m)+, i);
% +ret = ret.replaceAll((s)+, s);
...
% @@ -159,15 +192,18 @@ public class DateTimePickerTag extends TagSupport {
%
% HtmlTag dateAddon = createInputAddonTag(date, fa fa-calendar);
For icons there's IconTag which ensures consistent usage of icons.
(So that one won't use fa-calendar while others use fa-calendar-o.)
...
% +/**
% + * Convert day java.util.Calendar constants
% + * (for which we can't assume a fixed value)
% + * to an index usable by the javascript picker.
% + *
% + * @return the equivalent index for the javascript
% + * picker
% + */
% +private int getJavascriptPickerDayIndex(int calIndex) throws
IllegalArgumentException {
% +switch (calIndex) {
% +case Calendar.SUNDAY:return 0;
% +case Calendar.MONDAY:return 1;
% +case Calendar.TUESDAY: return 2;
% +case Calendar.WEDNESDAY: return 3;
% +case Calendar.THURSDAY: return 4;
% +case Calendar.FRIDAY:return 5;
% +case Calendar.SATURDAY: return 6;
% +default: throw new IllegalArgumentException(Invalid day +
calIndex);
% +}
% +}
I think such switch statement is really overkill. Yes, in theory
calendar constant values may change in the future but in fact they are pretty
solid for couple of years now.
...
% +private String toWeirdDateFormat(String format) {
% +String ret = format.replaceAll((M)\\1\\1\\1+, MM);
% +ret = ret.replaceAll(MMM, M);
% +ret = ret.replaceAll(MM, mm);
% +ret = ret.replaceAll(M, m);
Exactly the same problem I described in toPhpTimeFormat().
is replaced by MM which is then replaced by mm.
MMM is replaced by M which is then replaced by m.
% +ret = ret.replaceAll((E)\\1\\1\\1+, DD);
% +ret = ret.replaceAll(E+, D);
% +ret = ret.replaceAll((D)\\1+, dd);
% +ret = ret.replaceAll(D, d);
And again to DD to dd.
% +ret = ret.replaceAll((y)\\1\\1\\1+, );
% +ret = ret.replaceAll(y+, yy);
% +return ret;
% +}
And again.
% +private void writePickerHtml(Writer out) throws IOException {
...
% +HtmlTag timeAddon = createInputAddonTag(time, fa fa-clock-o);
% +
% +HtmlTag timeInput = new HtmlTag(input);
% +//dateInput.setAttribute(value, data.getDate().toString());
% +timeInput.setAttribute(type, text);
% +timeInput.setAttribute(class, form-control);
% +timeInput.setAttribute(id, data.getName() +
_timepicker_widget_input);
% +
% +HtmlTag tzAddon = new HtmlTag(span);
% +tzAddon.setAttribute(id, data.getName() + _tz_input_addon);
% +tzAddon.setAttribute(class, input-group-addon);
% +tzAddon.addBody(
% +data.getCalendar().getTimeZone().getDisplayName(
% +false, TimeZone.SHORT, data.getLocale()));
% +
% +HtmlTag col2 = new HtmlTag(div);
% +col2.setAttribute(class, col-md-5);
% +
% +group.addBody(dateAddon);
% +group.addBody(dateInput);
% +if (!data.getDisableTime()) {
% +group.addBody(timeAddon);
% +group.addBody(timeInput);
% +group.addBody(tzAddon);
% +}
Whole timeAddon and timeInput should be better placed inside the if block.
So they aren't even generated when they aren't used later.
...
% +private void writeI18NMap(Writer out) throws IOException {
% +// generate i18n for the picker here
% +DateFormatSymbols syms = data.getDateFormatSymbols();
% +out.append(script type='text/javascript'\n);
% +out.append($.fn.datepicker.dates[' + data.getLocale() + '] =
{\n);
% +out.append(days: [ \n);
% +out.append(String.format( '%s',
Re: [Spacewalk-devel] [PATCH] Date/Time picker
On 02/14/2014 03:16 PM, Michael Mraka wrote: should likely be / otherwise it produce opening tags not self closed tags. Actually in HTML5 void tags do not need the slash (it is optional). http://www.w3.org/TR/html-markup/syntax.html#void-element self-closing as a definition does not exist anymore in HTML5, except for SVG and MathML elements! We also recently started a discussion about this same topic and decided to stick to a coding standard rule to avoid confusion - namely not using those optional slashes in new code. I hope you are also fine with that. I was supposed to start a discussion with you in the next days, but this was faster :-) Thanks, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] RFC: Action Chaining mockups and ideas
On 02/14/2014 01:05 PM, Cliff Perry wrote: http://turing.suse.de/~smoioli/action-chaining-mockups/list.html I suspect this page really wants a column for when is the event scheduled to be executed. Not really - those Action Chains are not scheduled for execution yet. When they actually get scheduled, those become regular actions in Schedule - Pending Actions (and later Completed Actions, Failed Actions, etc.). Merge/use either only created or modified, vs both - I don't think we need them both. Okay, agreed. Task scheduled for next sprint. http://turing.suse.de/~smoioli/action-chaining-mockups/editor.html This is a bit worrying, it looks like it would make it hard/complex to render information meaningfully. Because they are chained and you have different systems for each portion of the event - does it mean, you don't reboot the 10 systems, if one of the two config deployment fails? No, the chaining is done per-system, so if an action fails on a particular system then only subsequent actions in the same Chain for the same system will fail. See: http://wiki.novell.com/index.php/SUSE_Manager/ActionChaining#Definitions Rendering basically works at the moment, I still have to fix a couple of bugs but it looks very similar to that mockup. I already planned to prepare a screencast for you during the next sprint so that you can also see it. While the power to add/remove systems for each portion sounds nice, it makes my brain hurt, and I'd have to assume it would for those managing the systems - selecting X systems and being stuck to work with them only, sounds more sane approach. We do expect that users will mostly use the SSM with a fixed set of systems to chain actions, and this will be the recommended use case anyway. Please note that using the SSM automatically implies having chains with actions that are executed on different sets of systems. This is because, in general, you do not get one action per system that you have in the set as some of them might not meet the prerequisites (entitlements, channels, etc.). So, from a UI perspective, we could not really do much more than reflect that fact, so we came up with that tree-like visualization scheme. From there, adding the capability of deleting a system from an action was just a low-hanging fruit, it could also be disabled easily if you feel that it would hurt usability. Adding a system to an existing action in a chain is not possible at the moment. I don't see anything bad in getting this into Spacewalk, or that would go against Spacewalk's future desires. Great news! I will be back with a screencast soon. Thanks a lot, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Date/Time picker
Thanks for the review and fixes!. Most of it looks good except for the self-closing tag as Silvio explained. There are other changes that I would like to understand: - The css part where you override some styles (and use !important, which basically means SUSE Manager can't override it again in its css) - setting of the input size to 15 -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
