Migrate into factory design

[ralequi]

Requested by @ulmitov

The design pattern - pystorcli uses singleton when creating the StorCLI object. while pysmart just creates it once and then passes to all rest of objects (somewhat a factory design). I think the factory is much better.

[ralequi]

Also :

if you can please make this runner same for pystorcli and pysmart :)

(related with cmdrunner)

[ulmitov]

Please see last commit ulmitov/pyarcconf@faca59f
many small changes but main thing is i added the runner and also added a class for mvcli (marvell raid)

[ralequi]

Looks like you are doing an amazing job !

[ralequi]

@ulmitov I've checked that pyarcconf is not reserved on pypi. If you wanna push there, I strongly recommend you to allocate it as quick as possible.
I can do it for u if you don't know how and give admin rights. In any case, if u don't reserve it, you may lost that name if any other wants to generate a python package with that name.

Project license is MIT, so no much trouble should be there, but, I you want to become the "main" maintainer, I recommend you to email the original author and ask him for an authorization. With that, you can ask github to make your project the main "fork".

[ulmitov]

Looks like you are doing an amazing job !

Looking forward to a single py storage package ;)

[ulmitov]

@ulmitov I've checked that pyarcconf is not reserved on pypi. If you wanna push there, I strongly recommend you to allocate it as quick as possible. I can do it for u if you don't know how and give admin rights. In any case, if u don't reserve it, you may lost that name if any other wants to generate a python package with that name.

Project license is MIT, so no much trouble should be there, but, I you want to become the "main" maintainer, I recommend you to email the original author and ask him for an authorization. With that, you can ask github to make your project the main "fork".

Oooh, never done it, will take me some time to understand what is going on there, according to your PR

[ulmitov]

But actually maybe it's not really important to reserve the project name, since i hope this code will be migrated anyway to the single raid package

[ulmitov]

The owner is ok with transfer ownerships, but in couple of month i'll be moving to other tasks and won't be able to maintain this repo.
Please update me what do you think, could move later the code to your side, or do you prefer a separate project

[ralequi]

Depends on what do you mean with "on my side".

We can move the project to "naudit/xx" repository and maintain it for a while. (Or at least try, as said I don't have such hw, so many tests would be impossible to make from my side).

In the other hand, if you mean "on my side" to merge into pystorcli/pysmart, I see too much work for the time I have to "open source projects" right now... I would leave that for september/onwards +/-

[ulmitov]

Yes, i meant into pystorcli, so it would be possible to import a single package. I see your point, ok

[ulmitov]

Hi @ralequi !
Have a question, could you please give me an approximate estimation if the universal runner will be merged soon? i just want to plan my further work steps
Thanks

[ulmitov]

Or if you could guide me whether the runner will return a proc object (like in pystorcli) or the tuple like in pysmart ?

[ralequi]

Hi!
That's a good question...
On the side of the return type, i think more complete & flexible is the best option. In this way, a namedtuple or a proc-like-object is better. With that said, something like pystorcli should be better.

In the other side, about an estimation... Well, I don't like to compromise myself. I have a bunch of work but I'm sure this could be done in a couple of months (probably even less) with full dedication. Nevertheless, as probably you've noticed, I can't be full time on open source.

So, let's be conservative... what about Dec'2023 ?

[ulmitov]

Long time but ok
i'll adapt my code anyway to use the proc object