On Mon, Aug 08, 2016 at 10:17:56AM +0200, Ancor Gonzalez Sosa wrote:

On 08/08/2016 10:11 AM, Imobach González Sosa wrote:

...

Hi all,

AFAIK, you're using refinements in libstorage-ng so maybe some of you are interested in this short article: 'The Pros and Cons of Ruby Refinements'[1].

We are using it because libstorage-ng-ruby performs strict type checking (it's a binding for C++, so it makes sense). That kills duck typing and makes quite hard to use forwarders, decorators and other usual Ruby techniques. Refinements allows us to decorate classes coming from libstorage-ng without introducing other types.

You also refine standard ruby classes, e.g. Fixnum and Float in size_casts.rb. Having looked at some other refinements I must say that I don't consider them to be good. E.g. you extend 'Partition' with 'uuid' and 'label' that provide the UUID and label from the filesystem on the partition, see partition_attributes.rb. This will cause problems if the 'Partition' object should ever get a uuid or label function, which is possible since partitions on GPT have these attributes (putting aside label/name and UUID/GUID nitpicking). ciao Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 08/08/2016 12:08 PM, Ancor Gonzalez Sosa wrote:

On 08/08/2016 12:00 PM, Arvin Schnell wrote:

...

On Mon, Aug 08, 2016 at 10:17:56AM +0200, Ancor Gonzalez Sosa wrote:

...

On 08/08/2016 10:11 AM, Imobach González Sosa wrote:

...

Hi all,

AFAIK, you're using refinements in libstorage-ng so maybe some of you are interested in this short article: 'The Pros and Cons of Ruby Refinements'[1].

We are using it because libstorage-ng-ruby performs strict type checking (it's a binding for C++, so it makes sense). That kills duck typing and makes quite hard to use forwarders, decorators and other usual Ruby techniques. Refinements allows us to decorate classes coming from libstorage-ng without introducing other types.

You also refine standard ruby classes, e.g. Fixnum and Float in size_casts.rb.

Having looked at some other refinements I must say that I don't consider them to be good. E.g. you extend 'Partition' with 'uuid' and 'label' that provide the UUID and label from the filesystem on the partition, see partition_attributes.rb. This will cause problems if the 'Partition' object should ever get a uuid or label function, which is possible since partitions on GPT have these attributes (putting aside label/name and UUID/GUID nitpicking).

As yardoc documentation states, these three refinements are only used to make RSpec tests more readable: PartitionAttributes, SizeCasts, TestDevicegraph.

Those are exactly the refinements you find "not good". And you are right :-), they are there just for usage in RSpec, not in "real" code.

Should we move then to a specific namespace to make it more obvious? Something like Y2Storage::Refinements::Test::PartitionAttributes instead of Y2Storage::Refinements::PartitionAttributes -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Mon, Aug 08, 2016 at 12:12:22PM +0200, Ancor Gonzalez Sosa wrote:

On 08/08/2016 12:08 PM, Ancor Gonzalez Sosa wrote:

...

On 08/08/2016 12:00 PM, Arvin Schnell wrote:

...

...

Having looked at some other refinements I must say that I don't consider them to be good. E.g. you extend 'Partition' with 'uuid' and 'label' that provide the UUID and label from the filesystem on the partition, see partition_attributes.rb. This will cause problems if the 'Partition' object should ever get a uuid or label function, which is possible since partitions on GPT have these attributes (putting aside label/name and UUID/GUID nitpicking).

As yardoc documentation states, these three refinements are only used to make RSpec tests more readable: PartitionAttributes, SizeCasts, TestDevicegraph.

Sometimes it states "mainly".

...

Those are exactly the refinements you find "not good". And you are right :-), they are there just for usage in RSpec, not in "real" code.

Should we move then to a specific namespace to make it more obvious? Something like Y2Storage::Refinements::Test::PartitionAttributes instead of Y2Storage::Refinements::PartitionAttributes

I agree that code only use for testing should be moved to a special place. And why is it should included in the RPM? But still I don't understand why code with conceptual problems is fine if it's only used for testing. Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Wed, Aug 10, 2016 at 10:22:14PM -0600, Suresh K Hosamani wrote:

Hi,

I need this bit urgently for generating the OES iso on SLES12, I can provide more info on this.

Regards, Sureshy

...

...

...

Suresh K Hosamani 8/9/16 3:34 PM >>> Hi,

OES has around 17 modules and each module refers to a pattern, based on the pattern selection and installation, corresponding proposals will be executed and information will be displayed the summary screen (from read method), bu on SLES12, even though the pattern is not installed proposal will be displayed as modulename_proposal with a hyper link to module_1 module_2 etc..,

Looking at proposal_store, if the description id is not available for the proposals for which pattern is not installed, its getting displayed as modulename_proposal with a hyper link to module_1 module_2 etc...

For OES, it should display the proposals for which pattern is installed.

Hi Suresh, sorry, I cannot quite understand your problem. Are we talking about the installation proposal? Or about another proposal ran during the 2nd stage of the installation? Can you phrase your question in terms of the contents of the control file, like here? https://github.com/yast/skelcd-control-openSUSE/blob/aed5928b8b1aa0bd7bc1acd... If you already have an ISO where the problem can be demonstrated, can we download it? Or can you share (a portion of) your control file? -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

Hi, Need urgent help on this, by next week I need to be ready for the first iso. Regards, Suresh

...

...

"Suresh K Hosamani" 8/16/16 2:48 PM >>> Hi Martin,

You can access the content of iso at http://164.99.103.82/download/au/sles12_ruby_packages_without_patterns/ What I understood from the code is, every proposal module gets the "rich_text_title", "menu_title" and "id" from modulename_proposal.rb file, Ex. elsif @func == "Description" # Determine if we should be in the proposal screen or not. @force_proposal = Ops.get_boolean(@param, "force_proposal", false) @isSelected = NovellPatterns.IsPatternInstalled("novell-sms") # FIXME: is this needed anymore? @isSelected = @isSelected && NovellAddonInstall.IsProductSelected("sms") Builtins.y2milestone("Proposal:IsSelected:novell-sms: %1", @isSelected) if @isSelected || @force_proposal @ret = { # Rich text title for Sms in proposals "rich_text_title" => _( "Storage Management Services (SMS)" ), # Menu title for Sms in proposals "menu_title" => _( "&Storage Management Services (SMS)" ), "id" => "sms" } else @ret = {} end # write the proposal In my case, since the pattern is not installed, proposal module is not returning "rich_text_title", "menu_title" and "id", so its considering the modulename_proposal as the rich_text_title and creating a link as module_1 module_2 etc.. Note: Since OES is not yet ready on SLES12, I am using OES2015SP1 (on sles11sp4) and installing by breaking the dependencies. Regards, Suresh

...

...

Martin Vidner 8/15/16 4:34 PM >>> On Wed, Aug 10, 2016 at 10:22:14PM -0600, Suresh K Hosamani wrote: Hi,

I need this bit urgently for generating the OES iso on SLES12, I can provide more info on this.

Regards, Sureshy

...

...

...

Suresh K Hosamani 8/9/16 3:34 PM >>> Hi,

OES has around 17 modules and each module refers to a pattern, based on the pattern selection and installation, corresponding proposals will be executed and information will be displayed the summary screen (from read method), bu on SLES12, even though the pattern is not installed proposal will be displayed as modulename_proposal with a hyper link to module_1 module_2 etc..,

Looking at proposal_store, if the description id is not available for the proposals for which pattern is not installed, its getting displayed as modulename_proposal with a hyper link to module_1 module_2 etc...

For OES, it should display the proposals for which pattern is installed.

Hi Suresh, sorry, I cannot quite understand your problem. Are we talking about the installation proposal? Or about another proposal ran during the 2nd stage of the installation? Can you phrase your question in terms of the contents of the control file, like here? https://github.com/yast/skelcd-control-openSUSE/blob/aed5928b8b1aa0bd7bc1acd... If you already have an ISO where the problem can be demonstrated, can we download it? Or can you share (a portion of) your control file? -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

Hi, In media installation of SLES12, ca_mgm module does'nt get configured automatically, in autoyast install it gets configured. During installation of OES we are dependent on this module (/etc/ssl/servercerts/servercert.pem), should we add this a prerequisite before OES installation or is it ok to ignore this module. Regards, Suresh

Hello, Am Donnerstag, 18. August 2016, 00:45:14 CEST schrieb Suresh K Hosamani:

In media installation of SLES12, ca_mgm module does'nt get configured automatically, in autoyast install it gets configured. During installation of OES we are dependent on this module

Just as a sidenote: there is a request to drop the ca management module, see https://github.com/yast/yast-auth-server/pull/21 and https://features.opensuse.org/319119 You probably want to add a comment there ;-) Regards, Christian Boltz -- could somebody please send me a duplicator so my clone can do all the work? :-) [Martin Lasarsch in opensuse-wiki] -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org