Re: [smartos-discuss] Contributing to smartos-live

[Robert Mustacchi]

On 8/18/17 8:37 , Daniel Kontsek wrote:
> Thank you very much Cody for pointing me in the right direction.
> 
> I already went ahead and followed the Gerrit instructions and created a CR: 
> https://cr.joyent.us/#/c/2353/  I did this to 
> learn the process of working with Gerrit (not that the bug/CR itself isn’t 
> important - it is). The workflow is different compared to the GitHub/GitLab 
> (forks/branches) style. I’ve accidentally created and abandoned another CR 
> when pushing an update to gerrit - sorry for that. Then I followed the Gerrit 
> documentation to update the CR and I’ve just noticed the "We have one major 
> exception to the standard Gerrit workflow:…” message in the wiki. I’ve used 
> the “amend + Change-Id” method to add another patchset and again: I’m sorry 
> for that (I didn’t notice it the first time).
> 
> Should I abandon the Change 2353 and create a new one?

Hi Daniel,

There should be no need. It's fine. The only reason we're not using the
Change-Id method is because of the final commit message. Even if it's
used in the interim it shouldn't cause any problems.

Thanks,
Robert


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Contributing to smartos-live

[Daniel Kontsek]

Thank you very much Cody for pointing me in the right direction.

I already went ahead and followed the Gerrit instructions and created a CR: 
https://cr.joyent.us/#/c/2353/  I did this to 
learn the process of working with Gerrit (not that the bug/CR itself isn’t 
important - it is). The workflow is different compared to the GitHub/GitLab 
(forks/branches) style. I’ve accidentally created and abandoned another CR when 
pushing an update to gerrit - sorry for that. Then I followed the Gerrit 
documentation to update the CR and I’ve just noticed the "We have one major 
exception to the standard Gerrit workflow:…” message in the wiki. I’ve used the 
“amend + Change-Id” method to add another patchset and again: I’m sorry for 
that (I didn’t notice it the first time).

Should I abandon the Change 2353 and create a new one?

Daniel

> On 17 Aug 2017, at 20:51, Cody Mello  wrote:
> 
> Hi Daniel,
> 
> On Wed, Aug 9, 2017 at 12:33 AM, Daniel Kontsek  wrote:
>> AFAIK we should open merge requests here: https://cr.joyent.us/ and not on
>> GitHub, but we should create an issue on GitHub first, is this correct, or 
>> can
>> we just create CRs in Gerrit?
> 
> Yes, merge requests should go through Gerrit for code review. You can
> find instructions on how to get started using Gerrit here:
> 
> https://github.com/joyent/joyent-gerrit/tree/master/docs/user
> 
> You should create an issue on GitHub under the appropriate repository,
> and then reference it in the commit message. For example, something
> like:
> 
> joyent/smartos-live#12345 This Is The Issue's Subject Line
> Reviewed by: Joe Smith 
> Approved by: Jane Doe 
> 
> If you know of an open Joyent JIRA ticket (you can see them at
> http://smartos.org/bugview/) then you're welcome to reference that in
> the commit message instead.
> 
> Once you have a change on Gerrit, you can ping people in #smartos or
> the Github ticket about it to find reviewers.
> 
>> Shell scripts coding style (mainly svc/methods and prompt_config) is a
>> problem. We are seeing mixing of bash coding patterns, even in scripts where
>> new bash features are used. (e.g. $var vs ${var} vs "${var}", `` vs $(), [ vs
>> [[). I assume lots of these are just Solaris heritage, but some scripts are
>> new and yet we see these strange inconsistencies. I'm not going to argue 
>> about
>> line length and tabs vs spaces (although please don't mix them). But as we 
>> are
>> saying: at least do it consistently wrong :) We are happily using shellcheck
>> [2] for most of our bash scripts and it does solve these kind of problems. Is
>> there a coding style guide for shell scripts?
> 
> This is the bash style guide, but it could definitely do with some
> additional recommendations:
> 
> https://github.com/joyent/eng/blob/master/docs/index.md#bash-programming-guidelines
> 
> Dave Eddy at Joyent wrote some personal recommendations for writing
> shell scripts, many of which should probably also be in the guide:
> 
> http://daveeddy.com/bash/
> 
> A lot of the scripts in smartos-live have vastly different styles. If
> you're making changes in an area where someone has diverged from the
> prevailing style of the file, then please do update that region to
> match, so that over time each file can at least become consistent with
> itself. In the long run, I'd like to flesh out the style guide and
> write a linter/style checker to help enforce the guidelines.
> 
>> For example: we would love to rewrite the smartos_prompt_config.sh script so
>> it does not use global variables. Would you accept such change?
> 
> smartos_prompt_config.sh could definitely do with some love. If you
> can clean it up to be more readable and safer, we'd probably take
> those changes. Just please make sure to also do testing for all of the
> paths you change, and attach testing notes to the Github issue.
> 
> -  Cody
> 


signature.asc
Description: Message signed with OpenPGP




---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Contributing to smartos-live

[Cody Mello]

Hi Daniel,

On Wed, Aug 9, 2017 at 12:33 AM, Daniel Kontsek  wrote:
> AFAIK we should open merge requests here: https://cr.joyent.us/ and not on
> GitHub, but we should create an issue on GitHub first, is this correct, or can
> we just create CRs in Gerrit?

Yes, merge requests should go through Gerrit for code review. You can
find instructions on how to get started using Gerrit here:

https://github.com/joyent/joyent-gerrit/tree/master/docs/user

You should create an issue on GitHub under the appropriate repository,
and then reference it in the commit message. For example, something
like:

joyent/smartos-live#12345 This Is The Issue's Subject Line
Reviewed by: Joe Smith 
Approved by: Jane Doe 

If you know of an open Joyent JIRA ticket (you can see them at
http://smartos.org/bugview/) then you're welcome to reference that in
the commit message instead.

Once you have a change on Gerrit, you can ping people in #smartos or
the Github ticket about it to find reviewers.

> Shell scripts coding style (mainly svc/methods and prompt_config) is a
> problem. We are seeing mixing of bash coding patterns, even in scripts where
> new bash features are used. (e.g. $var vs ${var} vs "${var}", `` vs $(), [ vs
> [[). I assume lots of these are just Solaris heritage, but some scripts are
> new and yet we see these strange inconsistencies. I'm not going to argue about
> line length and tabs vs spaces (although please don't mix them). But as we are
> saying: at least do it consistently wrong :) We are happily using shellcheck
> [2] for most of our bash scripts and it does solve these kind of problems. Is
> there a coding style guide for shell scripts?

This is the bash style guide, but it could definitely do with some
additional recommendations:

https://github.com/joyent/eng/blob/master/docs/index.md#bash-programming-guidelines

Dave Eddy at Joyent wrote some personal recommendations for writing
shell scripts, many of which should probably also be in the guide:

http://daveeddy.com/bash/

A lot of the scripts in smartos-live have vastly different styles. If
you're making changes in an area where someone has diverged from the
prevailing style of the file, then please do update that region to
match, so that over time each file can at least become consistent with
itself. In the long run, I'd like to flesh out the style guide and
write a linter/style checker to help enforce the guidelines.

> For example: we would love to rewrite the smartos_prompt_config.sh script so
> it does not use global variables. Would you accept such change?

smartos_prompt_config.sh could definitely do with some love. If you
can clean it up to be more readable and safer, we'd probably take
those changes. Just please make sure to also do testing for all of the
paths you change, and attach testing notes to the Github issue.

- Cody


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Contributing to smartos-live

[Lonnie Cumberland]

Hi Jan,

Thanks for your quick response and for pointing out some differences.
Please forgive if the implication was about a competition as that was not
my intention, but mainly to just try and determine what were the main
differences between the two implementations.

Being still new here, I am just trying to wrap my head around all of the
information and sort it appropriately so that it will allow me to better
install and setup a solidly performing private cloud on which I easily work
with our own project.

Thanks again,
Lonnie

On Wed, Aug 9, 2017 at 8:33 AM, Ján Poctavek 
wrote:

> Hi Lonnie,
>
> thank you for pointing out that we don't have this comparison, we'll try
> to fix that. But this is not about competition anyway. Our focus is a bit
> different.
>
> To answer your question: first of all, Danube Cloud (DC) is trying to be
> user friendly and easy to use in the first place. You don't need the
> dedicated headnode (the management are just few VMs that can be migrated
> anywhere). On top of that, DC includes full Zabbix install for automated
> monitoring of all nodes and hosted VMs, full featured VM backups using
> incremental ZFS snapshots, DNS server, multi-tenant IP address and networks
> management, etc.
>
> All this stuff is in community edition. Enterprise version is about SLA
> support, not about features (all our new work goes into the community
> edition).
> Cheers.
> Jan
>
> On 9. 8. 2017 13:11, Lonnie Cumberland wrote:
>
> Hi Daniel,
>
> I just started looking at the Danube release and it looks like you have
> brought things together nicely, but was trying to locate what major
> changes, improvements, or modifications the Danube release has over Triton
> and could not find a list anywhere to look over.
>
> I am sure that you have made some changes as your post describes to some
> degree, but was looking to try and get a feel for why I might be interested
> in installing your Danube release over Triton. One thing that I did
> immediately see on your site is that you have a Community release which
> seems to have less features than your Enterprise release while also
> offering the Danube Cloud while Joyent seems to have their single Triton
> release while focusing on the Triton Cloud services.
>
> This was just meant to be quick observation and I have not looked heavily
> into the Danube software while still very new to the Triton Data Center as
> well so I'm not really one to do any type of evaluations or comparisons at
> this point, but I am all for making things easier so that one can setup a
> solidly functioning private cloud so as to be able to focus on containers
> and their uses while minimizing the concerns about the infrastructure.
>
> Personally, I am setting up a private cloud to learn from and test, with a
> major focus on running Docker containers, micro-services and possibly
> Kubernetes at some future point.
>
> Cheers and have a good day,
> Lonnie
>
>
> On Wed, Aug 9, 2017 at 3:33 AM, Daniel Kontsek  wrote:
>
>> Dear Joyent and SmartOS Community,
>> 
>> we have been successfully using and integrating SmartOS at Danube Cloud
>> (Erigones) for about 5 years now. At the beginning we've built an IaaS
>> platform, which we've transformed into a full-featured software solution -
>> Danube Cloud (former Erigones SDDC) [1]. During this time, there were
>> occasional moments where we thought that a Linux hypervisor would maybe be
>> a better choice... But the strengths of SmartOS / illumos gave ourselves
>> repeatedly arguments that - YES - it was the right choice (Zones, ZFS,
>> Crossbow, DTrace... you know the perks...). We would like to say to all
>> illumos and SmartOS contributors: THANK YOU for the amazing work.
>> 
>> Although, we would like to use the SmartOS platform as it is, we have to
>> maintain some changes to the illumos-joyent and smartos-live repositories.
>> This is mostly because of support for installation/boot from hard drive
>> (contributed by Juraj Lutter), installer (prompt-config) script location
>> and other smaller changes to the installer. As far as my understanding
>> goes, Joyent would not want to support installation to hard drive but maybe
>> some other (smaller) features would be beneficial for Joyent and the
>> SmartOS community. We can create pull requests for that, but there are a
>> few topics I would like to discuss first:
>> 
>> -  AFAIK we should open merge requests here: https://cr.joyent.us/ and
>> not on GitHub, but we should create an issue on GitHub first, is this
>> correct, or can we just create CRs in Gerrit?
>> 
>> -  Shell scripts coding style (mainly svc/methods and prompt_config) is a
>> problem. We are seeing mixing of bash coding patterns, even in scripts
>> where new bash features are used. (e.g. $var vs ${var} vs "${var}", `` vs
>> $(), [ vs [[). I assume lots of these are just Solaris heritage, but some
>> scripts are new and yet we see these strange inconsistencies. I'm not 

Re: [smartos-discuss] Contributing to smartos-live

[Ján Poctavek]

Hi Lonnie,

thank you for pointing out that we don't have this comparison, we'll try 
to fix that. But this is not about competition anyway. Our focus is a 
bit different.


To answer your question: first of all, Danube Cloud (DC) is trying to be 
user friendly and easy to use in the first place. You don't need the 
dedicated headnode (the management are just few VMs that can be migrated 
anywhere). On top of that, DC includes full Zabbix install for automated 
monitoring of all nodes and hosted VMs, full featured VM backups using 
incremental ZFS snapshots, DNS server, multi-tenant IP address and 
networks management, etc.


All this stuff is in community edition. Enterprise version is about SLA 
support, not about features (all our new work goes into the community 
edition).


Cheers.
Jan

On 9. 8. 2017 13:11, Lonnie Cumberland wrote:

Hi Daniel,

I just started looking at the Danube release and it looks like you
have brought things together nicely, but was trying to locate what
major changes, improvements, or modifications the Danube release has
over Triton and could not find a list anywhere to look over.

I am sure that you have made some changes as your post describes to
some degree, but was looking to try and get a feel for why I might be
interested in installing your Danube release over Triton. One thing
that I did immediately see on your site is that you have a Community
release which seems to have less features than your Enterprise release
while also offering the Danube Cloud while Joyent seems to have their
single Triton release while focusing on the Triton Cloud services.

This was just meant to be quick observation and I have not looked
heavily into the Danube software while still very new to the Triton
Data Center as well so I'm not really one to do any type of
evaluations or comparisons at this point, but I am all for making
things easier so that one can setup a solidly functioning private
cloud so as to be able to focus on containers and their uses while
minimizing the concerns about the infrastructure.

Personally, I am setting up a private cloud to learn from and test,
with a major focus on running Docker containers, micro-services and
possibly Kubernetes at some future point.

Cheers and have a good day,
Lonnie

On Wed, Aug 9, 2017 at 3:33 AM, Daniel Kontsek > wrote:

Dear Joyent and SmartOS Community,

we have been successfully using and integrating SmartOS at Danube
Cloud (Erigones) for about 5 years now. At the beginning we've
built an IaaS platform, which we've transformed into a
full-featured software solution - Danube Cloud (former Erigones
SDDC) [1]. During this time, there were occasional moments where
we thought that a Linux hypervisor would maybe be a better
choice... But the strengths of SmartOS / illumos gave ourselves
repeatedly arguments that - YES - it was the right choice (Zones,
ZFS, Crossbow, DTrace... you know the perks...). We would like to
say to all illumos and SmartOS contributors: THANK YOU for the
amazing work.

Although, we would like to use the SmartOS platform as it is, we
have to maintain some changes to the illumos-joyent and
smartos-live repositories. This is mostly because of support for
installation/boot from hard drive (contributed by Juraj Lutter),
installer (prompt-config) script location and other smaller
changes to the installer. As far as my understanding goes, Joyent
would not want to support installation to hard drive but maybe
some other (smaller) features would be beneficial for Joyent and
the SmartOS community. We can create pull requests for that, but
there are a few topics I would like to discuss first:

-  AFAIK we should open merge requests here: https://cr.joyent.us/
and not on GitHub, but we should create an issue on GitHub first,
is this correct, or can we just create CRs in Gerrit?

-  Shell scripts coding style (mainly svc/methods and
prompt_config) is a problem. We are seeing mixing of bash coding
patterns, even in scripts where new bash features are used. (e.g.
$var vs ${var} vs "${var}", `` vs $(), [ vs [[). I assume lots of
these are just Solaris heritage, but some scripts are new and yet
we see these strange inconsistencies. I'm not going to argue about
line length and tabs vs spaces (although please don't mix them).
But as we are saying: at least do it consistently wrong :) We are
happily using shellcheck [2] for most of our bash scripts and it
does solve these kind of problems. Is there a coding style guide
for shell scripts?

-  For example: we would love to rewrite the
smartos_prompt_config.sh script so it does not use global
variables. Would you accept such change?

Daniel

[1]  https://github.com/erigones/esdc-ce/wiki

 https://github.com/koalaman/shellcheck


*smartos-discuss* | Archives

Re: [smartos-discuss] Contributing to smartos-live

[Lonnie Cumberland]

Hi Daniel,

I just started looking at the Danube release and it looks like you have
brought things together nicely, but was trying to locate what major
changes, improvements, or modifications the Danube release has over Triton
and could not find a list anywhere to look over.

I am sure that you have made some changes as your post describes to some
degree, but was looking to try and get a feel for why I might be interested
in installing your Danube release over Triton. One thing that I did
immediately see on your site is that you have a Community release which
seems to have less features than your Enterprise release while also
offering the Danube Cloud while Joyent seems to have their single Triton
release while focusing on the Triton Cloud services.

This was just meant to be quick observation and I have not looked heavily
into the Danube software while still very new to the Triton Data Center as
well so I'm not really one to do any type of evaluations or comparisons at
this point, but I am all for making things easier so that one can setup a
solidly functioning private cloud so as to be able to focus on containers
and their uses while minimizing the concerns about the infrastructure.

Personally, I am setting up a private cloud to learn from and test, with a
major focus on running Docker containers, micro-services and possibly
Kubernetes at some future point.

Cheers and have a good day,
Lonnie


On Wed, Aug 9, 2017 at 3:33 AM, Daniel Kontsek  wrote:

> Dear Joyent and SmartOS Community,
> 
> we have been successfully using and integrating SmartOS at Danube Cloud
> (Erigones) for about 5 years now. At the beginning we've built an IaaS
> platform, which we've transformed into a full-featured software solution -
> Danube Cloud (former Erigones SDDC) [1]. During this time, there were
> occasional moments where we thought that a Linux hypervisor would maybe be
> a better choice... But the strengths of SmartOS / illumos gave ourselves
> repeatedly arguments that - YES - it was the right choice (Zones, ZFS,
> Crossbow, DTrace... you know the perks...). We would like to say to all
> illumos and SmartOS contributors: THANK YOU for the amazing work.
> 
> Although, we would like to use the SmartOS platform as it is, we have to
> maintain some changes to the illumos-joyent and smartos-live repositories.
> This is mostly because of support for installation/boot from hard drive
> (contributed by Juraj Lutter), installer (prompt-config) script location
> and other smaller changes to the installer. As far as my understanding
> goes, Joyent would not want to support installation to hard drive but maybe
> some other (smaller) features would be beneficial for Joyent and the
> SmartOS community. We can create pull requests for that, but there are a
> few topics I would like to discuss first:
> 
> -  AFAIK we should open merge requests here: https://cr.joyent.us/ and not
> on GitHub, but we should create an issue on GitHub first, is this correct,
> or can we just create CRs in Gerrit?
> 
> -  Shell scripts coding style (mainly svc/methods and prompt_config) is a
> problem. We are seeing mixing of bash coding patterns, even in scripts
> where new bash features are used. (e.g. $var vs ${var} vs "${var}", `` vs
> $(), [ vs [[). I assume lots of these are just Solaris heritage, but some
> scripts are new and yet we see these strange inconsistencies. I'm not going
> to argue about line length and tabs vs spaces (although please don't mix
> them). But as we are saying: at least do it consistently wrong :) We are
> happily using shellcheck [2] for most of our bash scripts and it does solve
> these kind of problems. Is there a coding style guide for shell scripts?
> 
> -  For example: we would love to rewrite the smartos_prompt_config.sh
> script so it does not use global variables. Would you accept such change?
> 
> Daniel
> 
> [1]  https://github.com/erigones/esdc-ce/wiki
>  https://github.com/koalaman/shellcheck
> 



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] Contributing to smartos-live

[Daniel Kontsek]

Dear Joyent and SmartOS Community,

we have been successfully using and integrating SmartOS at Danube Cloud 
(Erigones) for about 5 years now. At the beginning we've built an IaaS 
platform, which we've transformed into a full-featured software solution - 
Danube Cloud (former Erigones SDDC) [1]. During this time, there were 
occasional moments where we thought that a Linux hypervisor would maybe be a 
better choice... But the strengths of SmartOS / illumos gave ourselves 
repeatedly arguments that - YES - it was the right choice (Zones, ZFS, 
Crossbow, DTrace... you know the perks...). We would like to say to all illumos 
and SmartOS contributors: THANK YOU for the amazing work.

Although, we would like to use the SmartOS platform as it is, we have to 
maintain some changes to the illumos-joyent and smartos-live repositories. This 
is mostly because of support for installation/boot from hard drive (contributed 
by Juraj Lutter), installer (prompt-config) script location and other smaller 
changes to the installer. As far as my understanding goes, Joyent would not 
want to support installation to hard drive but maybe some other (smaller) 
features would be beneficial for Joyent and the SmartOS community. We can 
create pull requests for that, but there are a few topics I would like to 
discuss first:

- AFAIK we should open merge requests here: https://cr.joyent.us/ and not on 
GitHub, but we should create an issue on GitHub first, is this correct, or can 
we just create CRs in Gerrit?

- Shell scripts coding style (mainly svc/methods and prompt_config) is a 
problem. We are seeing mixing of bash coding patterns, even in scripts where 
new bash features are used. (e.g. $var vs ${var} vs "${var}", `` vs $(), [ vs 
[[). I assume lots of these are just Solaris heritage, but some scripts are new 
and yet we see these strange inconsistencies. I'm not going to argue about line 
length and tabs vs spaces (although please don't mix them). But as we are 
saying: at least do it consistently wrong :) We are happily using shellcheck 
[2] for most of our bash scripts and it does solve these kind of problems. Is 
there a coding style guide for shell scripts?

- For example: we would love to rewrite the smartos_prompt_config.sh script so 
it does not use global variables. Would you accept such change?

Daniel


[1] https://github.com/erigones/esdc-ce/wiki
[2] https://github.com/koalaman/shellcheck


signature.asc
Description: Message signed with OpenPGP




---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com